Czy można oczekiwać, że starszy programista wie, jakie są wzorce projektowe OOP? [Zamknięte]

Przygotowuję pytania na rozmowy kwalifikacyjne na wyższe stanowisko rozwojowe. Praca obejmowałaby projektowanie obiektowe, a istniejące oprogramowanie wykorzystuje wzorce projektowe, dlatego chciałbym poprosić kandydatów o wyjaśnienie kilku wzorców projektowych, które znają, wykorzystali, jak je wykorzystali, dlaczego użyłem ich i tak dalej. Jednak w poprzednich wywiadach, kiedy pytałem starszych programistów z co najmniej 5-10-letnim doświadczeniem na temat wzorców projektowych, prawie nikt nigdy o nich nie słyszał. Myślę, że dwóch z dwudziestu programistów mogłoby wymienić jeden wzorzec projektowy (odpowiednio Singleton i MVC).

Moje pytanie brzmi więc: czy warto zadawać te pytania? A może jest to tak niejasny temat, że nie można oczekiwać, że nowi pracownicy już go znają?

Czy starszy programista powinien mieć wcześniejsze doświadczenie z wzorami projektowymi, czy może powiedziałbyś, że wzorce projektowe są tak prostym tematem, że każdy porządny programista może je zdobyć podczas szkolenia? Jeśli tak, jakie pytania zadałbyś zamiast tego, aby ocenić ich umiejętności projektowe?

Dodaj Po przeczytaniu dotychczasowych odpowiedzi powinienem podać kilka wyjaśnień:

• Zadanie jest dla programisty .NET z doświadczeniem w OOP / OOD
• Istniejący kod używa nazw klas, takich jak IParameterGraphVisitori IStorageFactoryw wielu miejscach
• Jak pytasz ludzi o ich wcześniejsze doświadczenia z projektami OO, które stworzyli, jeśli nie mają słownictwa, aby wyjaśnić swoje projekty? To właśnie chcę zrobić i wszystko, co mogę wymyślić, to „proszę narysować hierarchię projektu / obiektu swojego ostatniego projektu na tablicy”.

Szanse są oni zrobić je znać. Mogą po prostu nie znać ich jako „wzorców projektowych”; tzn. mogą nie znać akademickiej terminologii dotyczącej takich rzeczy. To, co postrzegasz jako „maszynę stanową”, może być po prostu rozsądnym podejściem do problemu dla starszego, bardziej doświadczonego programisty. Na przykład nigdy nie zwracałem uwagi na „wzorce projektowe”, ale kiedy dowiedziałem się, co to jest maszyna państwowa, musiałem się śmiać, ponieważ robiłem to od lat. Kto wiedział, że jestem takim akademikiem? Zawsze uważałem to za podstawową umiejętność kodowania, a nie „wzorzec projektowy”.

Chodzi o to, że doświadczeni programiści nie znają terminów z podręcznika; zamiast tego zapytaj ich, jak ustrukturyzują klasy lub jak podejdą do zadania.

Twoje oczekiwania są dość rozsądne dla starszego programisty OO. Każdy, kto nazywa siebie, że bez znajomości wzorców projektowych, po prostu pokazuje, że doświadczenie nie jest przenoszone automatycznie przez lata :-( Pewnie, że jest wielu programistów, którzy spędzili lata lub nawet dekady w terenie, nigdy nie słysząc o projektowaniu wzorce - to tylko pokazuje, że nie byli zainteresowani poznawaniem nowych pomysłów, doskonaleniem się i wdrażaniem najlepszych praktyk.

Czy starszy programista powinien mieć wcześniejsze doświadczenie z wzorami projektowymi, czy może powiedziałbyś, że wzorce projektowe są tak prostym tematem, że każdy porządny programista może je zdobyć podczas szkolenia?

Doświadczenie IMO się liczy. Teoretycznie przyzwoity programista może przeczytać wzorce projektowe w książce lub nawet na Wikipedii i zrozumieć podstawową koncepcję w 15 minut. Jednak prawidłowe stosowanie tych koncepcji wymaga ciężko zdobytych doświadczeń. Łatwo jest zauroczyć się wzorami, próbując wcisnąć je w każdy możliwy fragment kodu, l'art pour l'art. Łatwo je również odrzucić, mówiąc: „Wzory nie są srebrną kulą, wystarczy użyć najprostszej rzeczy, która może działać”. Znalezienie środka między dwiema skrajnościami poprzez nauczenie się, kiedy i jak używać wzorców do rozwiązywania prawdziwych problemów, a kiedy ich nie używać, wymaga wieloletniego doświadczenia .

jakie pytania zadałbyś zamiast tego, aby ocenić ich umiejętności projektowe?

W zgodzie z powyższym dodam tylko te pytania do twojej listy:

• Jakie są wady wzorów projektowych (ogólnie i tych, o których wyraźnie wspominają)?
• Kiedy ich nie używać i dlaczego?

Aktualizacja

@GrandmasterB ma dobrą rację, ponieważ niektórzy programiści mogą używać określonych wzorców projektowych, nie znając ich nazwy. W pewnym sensie ma rację, ponieważ jest to pytanie terminologiczne / komunikacyjne. Jednak drugą stroną medalu jest to, że jest to rzeczywiście pytanie terminologiczne / komunikacyjne :-) Oznacza to, że jedną z głównych zalet wzorców projektowych jest zapewnienie wspólnego słownictwa programistom, co znacznie poprawia komunikację . (Spróbuj wyjaśnić podstawową ideę adaptera bez użycia samego słowa lub jego synonimów „wrapper” i inni!) Tak więc, jakkolwiek utalentowany i kompetentny może być kandydat, nie znając powszechnie akceptowanej terminologii, wprowadzi problem z komunikacją w twoim zespole.

Starszy programista? Zdecydowanie. Junior powinien. Mam 15 lat, nie mam formalnego wykształcenia na ten temat i nawet je rozumiem. Nie tylko uzasadnione jest oczekiwanie, że je znają, ale niedopuszczalne byłoby, gdyby tego nie wiedzieli. Zakładając, że wiedzą coś o programowaniu obiektowym, co najprawdopodobniej robią.

W rozmowie kwalifikacyjnej powinieneś zapytać, co jest ważne, aby kandydat wiedział o wykonywanej pracy.

Jeśli muszą znać nazwy wzorców z Gang of Four, jest to ważny wymóg.

Z drugiej strony, jeśli chcesz, aby wyświetlały odpowiednią wiedzę praktyczną na temat architektury programu, myślę, że lepiej jest dać im problem i zapytać, jak ustrukturyzuje kod. Jeśli podadzą ci odpowiednie rozwiązanie wzorcowe, to masz dowód, że je znają, niezależnie od użytej nazwy.

Ilekroć przeprowadzam wywiad na wyższe stanowiska, są one bardziej „praktyczne” niż pytania i odpowiedzi. Chcę wyraźnego wykazania umiejętności i komfortu programowania. Chcę również solidnego fundamentu w koncepcjach CS, co oznacza bardziej ogólne umiejętności stosowania takich koncepcji, jak enkapsulacja, algorytmy, sprzężenie / spójność itp. Doświadczenie i znajomość wielu języków i paradygmatów.

Zależy od obszaru ich wiedzy specjalistycznej. Nie spodziewałbym się, że wbudowany programista C będzie wiedział dużo o wzorcach projektowych. Jeśli mówimy o programistach Java lub .NET, powinni oni znać wzorce projektowe, a zwłaszcza, jak nie dać się ponieść emocjom.

Zakładając, że szukasz starszeństwa w OOP, odpowiedź brzmi zdecydowanie tak. Wzorce projektowe są leksykonem języka OOP.

Ponadto obecnie nieuzasadnione jest, aby przyzwoity programista OOP z 10-letnim doświadczeniem nie mógł nazwać wzorca projektowego, ponieważ jest wzorcem projektowym szeroko stosowanym w standardowych interfejsach API, bibliotekach i platformach programistycznych.

Od lat zadaję to pytanie podczas wywiadów i jest to showstopper, gdy kandydat nie udziela satysfakcjonujących odpowiedzi na ten temat.

Tak, ale prawdopodobnie powinieneś uzyskać ich zrozumienie, zadając pytania projektowe, a nie prosząc ludzi o wyliczenie wzorców projektowych, o których słyszeli. Nie mam nic przeciwko wzorom opisanym w PoEAA, GoF, a nawet niektórym wzorcom programowania funkcjonalnego i nadal nie sądzę, że dowiesz się więcej o moim podejściu do rozwiązywania problemów, prosząc mnie o podanie kilku wzorców.

Biorąc pod uwagę pytanie typu „zaprojektuj mi edytor tekstu” z następującymi pytaniami: „Jak zamierzasz obsługiwać osadzone obiekty, takie jak obrazy? Pogrubienie i kursywa? Prawdopodobnie w końcu usłyszysz wystarczająco dużo, aby rozpoznać wzór polecenia, wzór złożony, wzór pamiątkowy i kilka innych nawet przy krótkiej rozmowie.

Wzorce projektowe zostały odkryte, a następnie opisane, abyśmy mieli wspólny język do komunikowania decyzji projektowych.

Niestety pracowałem dla kogoś, dla kogo każde użycie wzorca projektowego musiało zostać wyjaśnione i uzasadnione, nie z powodu należytej staranności, ale dlatego, że po prostu ich nie znał. To nie jest zabawne. Ale najpoważniejsi programiści, przypadkowo lub projektowo, nauczyli się nazw najczęściej używanych wzorców OO, jeśli nic więcej, a większość programistów aplikacji korporacyjnych warta swojej soli przynajmniej wie coś o najczęstszych wzorcach PoEAA.

Rozsądny. Zdecydowanie Niezbędny. Nie

Pytam potencjalnych kandydatów, czy znają wzorce projektowe. To tylko jedno z kilku kryteriów ważenia jako całości. Nie pomijaj całego obrazu.

Tak, wielu programistów nieświadomie stosuje pewne wzorce projektowe, bez wątpienia.

Nie dlatego zadaję to pytanie.

Ważne jest, aby wiedzieć, że mogę szybko i skutecznie komunikować się z innym programistą. Nie chcę spędzać 20 minut na tablicy, wyjaśniając maszynę stanu, tylko po to, by dowiedzieć się, że „używali jej wcześniej, ale nigdy nie wiedzieli, jak to nazwać”. To nie jest produktywne.

Pomagają również w procesie refaktoryzacji. Przeglądając kod, można przypadkowo wdrożyć jakąś formę wzorca fabrycznego, ale wzorzec fabryczny GoF przetrwał próbę czasu. Dlatego jest to wzór fabryczny, a NIE JESZCZE fp (wynalezienie koła nie jest lepsze, Joel w oprogramowaniu ma wiele wad tego działania).

Zespół, który wykorzystuje i rozpoznaje znaczenie wzorców projektowych, poprawia komunikację i wydajność. Jeśli twój zespół, jako jednostka, nie używa dp, wówczas traci znaczenie.

Mówiąc z własnego doświadczenia, przez pewien czas ignorowałem wzorce projektowe. Wiedziałem, że istnieją, po prostu nigdy o nich nie czytałem. Kiedy w końcu ugryzłem kulę, zdałem sobie sprawę, że cały czas używałem wzoru projektowego i po prostu nie zdawałem sobie z tego sprawy lub nie wiedziałem, że moje rozwiązania projektowe faktycznie mają wspólną nazwę.

Byłbym bardziej skłonny wymyślić zestaw problemów, w których konkretny wzór projektowy dobrze pasuje do rozwiązania, i zobaczyć, jak programista wymyślił coś podobnego do wzoru. Jeśli tak, to świetnie. Mogę być jeszcze bardziej skłonny zatrudnić programistę, który nieświadomie używał wzorców projektowych, ponieważ widzę wielu programistów, którzy mają wiedzę na temat wzorców projektowych, próbując dopasować rozwiązanie do wzorca, gdy nie jest to właściwe, zamiast uświadomić sobie, że konkretny wzorzec rozwiązuje problem. problem dobrze.

Myślę, że lepszym pytaniem byłoby: biorąc pod uwagę nazwę wzoru i opis wzoru, na przykład wzór fabryczny z książki Gang of Four, kandydat powinien być w stanie wymyślić scenariusz, w którym wzór byłby rozsądne podejście.

Są programiści z 5-10-letnim doświadczeniem i są starsi programiści. To wcale nie są to samo. Tak, jeśli zatrudniasz na wyższym szczeblu i oczekujesz, że ludzie będą znali i stosowali wzorce projektowe, nie zatrudniłbym osoby starszej, która ich nie znała. To byłoby jak zatrudnienie specjalisty ds. Baz danych, który nie rozumiał pozostawionych połączeń. To dość podstawowe rzeczy dla prawdziwego starszego programisty. Prawdopodobnie jednak zatrudniłbym młodszą osobę.

Tak, rzeczywiście powinni znać ten termin, a nawet umieć wymienić kilka wzorców - ale nie popełnij błędu, myląc wiedzę teoretyczną z doświadczeniem.

Jest wiele osób, które przed rozmową wyszczerbiają wzorce projektowe i mogą je zepsuć krótkim opisem - ale to tylko teoria. Jest to prawdziwy starszy programista, który potrafi dostrzec, kiedy go użyć, lub bez znajomości formalnego wzorca rozwiązałby problem w klasyczny sposób.

Najlepszym sposobem, aby to sprawdzić, jest zaprojektowanie czegoś przed sobą i zadawanie pytań. Starszy programista to ktoś, kto potrafi myśleć naturalnie na poziomie abstrakcji. To ludzie, którzy „tworzą” wzorce projektowe.

Podobnie jak klasa Peopleware, która mówi o zatrudnianiu żonglera bez proszenia go o żonglowanie - tylko dlatego, że twierdzą, że nie mogą wiele znaczyć… wypróbuj je.

Jak już wspomniano, uważam również, że jest OK, jeśli nie pamiętają modnych słów na pamięć. Ale ponieważ jest to najwyższe stanowisko, powinni wiedzieć, kiedy zastosować schemat optymalnego rozwiązania problemu zamiast stosować najgorsze rozwiązania. Daj im więc problem, który powinien zostać rozwiązany za pomocą wzorca (na przykład, jak stworzyć obiekt bez twardego kodowania swojej klasy, jak uzyskać dostęp do elementów obiektu bez szczegółów dotyczących jego implementacji itp.) I zobacz, jak to zrobić zaatakują to.

Zdecydowanie powinni znać wzorce, ale niekoniecznie modne słowa.

Na przykład MVC ma wiele bardzo podobnych alternatyw, takich jak PAC, 3-poziomowy. Kilka lat temu innym popularnym hasłem dla MVC było „Model 2”. Właściwie znam bardzo dobrych programistów, którzy doskonale znają ten wzorzec, ale nie wiedziałem, że obecne hasło to MVC.

Bardzo prosto: jeśli ich używasz, musisz zapytać kandydatów. Jeśli znają wzorce, powinno dodać kilka dodatkowych punktów; ale nieświadomość niekoniecznie powinna je rozwiązywać, szczególnie jeśli wykazują dobre umiejętności OOD. Deweloperzy, którzy zajmowali się projektami konserwacyjnymi, raczej nie wiedzą dużo o wzorcach projektowych w porównaniu z tymi, którzy je projektowali. zależy to również od tego, czy uczono ich wzorców projektowych na studiach. Z mojego doświadczenia wynika, że ​​raczej nie będą. Większość uniwersytetów i prywatnych kursów uczy Cię OOP, ale nie OOD. Szanse, że będą studiować DP są jeszcze mniejsze.

Osobiście nie studiowałem DP, dopóki mój projekt mnie nie wymagał. Nawet wtedy odkryłem, że użyłem kilku wzorów, przynajmniej w podobny sposób, jeśli nie dokładnie w sposób opisany w książce. Zaskoczyło mnie, że zostały skodyfikowane. Więc szukaj dobrych umiejętności projektowych, jeśli nie znają DP. Jeśli znają DP, jest prawdopodobne, że mają dobrą konstrukcję, ale nadal je testują. Być może po prostu wygłosili jakieś bzyczące słowo o DP lub dowiedzieli się od kogoś z wewnątrz i po prostu przestudiowali kilka wzorów bez ich zastosowania.

Rozsądne jest oczekiwanie od osób, które ubiegają się o pracę z tobą, aby wiedzieć (lub nauczyć się) rzeczy, które są potrzebne na danym stanowisku pracy, niezależnie od tego, czy są one standardem branżowym, czy nie. W przeciwnym razie skazujesz się na mierność. Ale uważaj, aby uczynić pewną wiedzę (lub umiejętności) wymaganiem zawodowym, jeśli tak naprawdę nie jest potrzebne.

Załóżmy, że masz dwóch kandydatów o zbliżonym pochodzeniu, a jeden jest w stanie opowiedzieć o wzorach projektowych, a drugi nie. Co ci to powie o tym, jak będą wykonywać pracę?

Mówisz, że istniejące oprogramowanie wykorzystuje wzorce projektowe. Czy to zaleta? Jeśli tak to jak? Czy Twoim celem jest, aby napisane nowe oprogramowanie było zgodne z istniejącymi wzorcami, czy też wprowadzono nowe wzorce? Czemu?

Mogę wymyślić starszego programistę, który nie zna wzorców projektowych w następującej sytuacji:

1. Jest tylko jedna książka o wzorach projektowych. To książka, która sprawiła, że ​​stały się popularne. Jeśli dana osoba nie przeczytała tej jednej książki, możliwe, że nie wie o wzorach projektowych lub mogła o nich słyszeć, ale nie wie właściwie, po co jest
2. Zamiast tego musieliby wiedzieć coś w rodzaju uml ....
3. Znalezienie dobrych informacji o wzorcach projektowych z Internetu nie jest łatwe. Masz szczęście, że trafiłeś na odpowiednią stronę internetową, która ma dobrą znajomość wzorców projektowych. Samo przyjście do oprogramowania po 1995 roku może sprawić, że osoba nie będzie wiedziała o wzorcach projektowych, ponieważ książka jest stara.

Dlaczego każdy programista w środowisku innym niż OO powinien wiedzieć o wzorcach projektowych OO? Pracowałem w sklepach, robiąc tylko Cobol, tylko PL / SQL, tylko Progress 4GL, itp. Zasady projektowania OO są tam nieistotne, oczekiwałbym, że seniorzy w tych środowiskach będą mieli odpowiednią wiedzę na temat tych środowisk, a nie projektowania OO wzory.

Zdolność bezmyślnego cytowania z katalogu wzorców również nie czyni z ciebie dobrego programisty (w rzeczywistości z mojego doświadczenia wynika, że ​​tworzy on niektóre z najgorszych fragmentów kodu, jakie kiedykolwiek widziałem). Jednak tego oczekujesz od „starszego programisty”. Pracuję w branży od 15 lat, ale nie proś mnie o narysowanie schematu wzorcowego. Nigdy nie poświęcałem mu dużo czasu, nie muszę. Zdobyłem wystarczające doświadczenie, aby znaleźć to, co działa, bez nadawania mu konkretnej nazwy, a jeśli potrzebuję formalnej definicji, wiem, gdzie to sprawdzić (i tak, mam podręczniki w mojej osobistej bibliotece). To znak doświadczonego programisty, a nie rutynowa wiedza zdobyta podczas wkuwania podręczników szkolnych.