ms z tego co mi opowiadają, rekrutuje dużo ludzi ze środowisk akademickich (na przykład od razu po studiach albo jakichś doktorów) i możliwe że tam brakuje trochę przygotowania w tym zakresie. z drugiej strony wypuszczane technologie, takie jak choćby Enterprise Library czy różne Guidances pełne są dobrze użytych wzorców projektowych. jak dla mnie więc na zewnątrz obraz jest ok, jak jest w środku - wiem tylko z drugiej ręki.
Właśnie relatywnie niewiele. Google przyjmuje takich na potęgę, MS ma ich mniejszość. Pracowali ze mną przy kodzie ludzie po budowie maszyn w Bułgarii czy prawie w Australii.
Doktora miała jedna z ~40 osób, które znam na tyle dobrze, by wiedzieć jakie mają stopnie. Większość miała bakałarza, część mastera.
chodziło mi raczej o to że 1000/1000 powinni wiedzieć, że JEST COŚ TAKIEGO. akurat z ORM nie jest tak źle, ale zapytaj 100 programistów co to jest Dependency Injection, strzelam że z 10 będzie wiedziało.
Teraz czaję o co chodziło. Wciąż jednak uważam, że wymaganie znajomości np. DI nie jest za bardzo wartościowym kryterium. Po pierwsze szansa, że DI załatwi jakiś problem, którego nie załatwi fabryka jest niewielka. A fabrykę można "wymyślić" samemu. Zresztą - nie trzeba myśleć, wystarczy poużywać jakiegokolwiek API by z fabryką lub jej mniej ogólną postacią się spotkać. Nawet COMowe CreateInstance jest de facto wyspecjalizowaną fabryką.
Wspominałeś singletona - dla mnie to jest kardynalny przykład na to jak edukacja jest zwalona.
W 3 przypadkach na 4 ktoś, kto używa singletona robi to nie tam gdzie trzeba. Dla mnie (i z tym się z pewnością nie zgodzisz) uczenie OOP na uczelniach jest toksyczne i szkodliwe. Efektem jest nieuzasadniony lęk przed goto (brr!), makrami (brr!) i zmiennymi globalnymi (brr!) i nagle okazuje się, że w pędzie ku OOP zaprzęga się szablony, singletony i wyjątki w sytuacjach, w których makro, goto i zmienna globalna są dokładnie takimi rozwiązaniami, jakich potrzeba. Straszy się ludzi wmawiając im, że jeśli nie piszesz obiektowo to tkwisz w poprzedniej epoce. I wychodzą poczwarki.
Poza tym ja wychodzę z założenia, że lepiej pisać kod prosty, taki który zrozumie każdy, niż pchać się w wysublimowane techniki, których koniec końców ktoś w zespole nie zrozumie. Bzdury gadają ludzie, według których w efekcie uzyskuje się kod nieczytelny i trudny w utrzymaniu. Trudny w utrzymaniu jest kod najeżony magią OOP, kiedy autor zmieni pracę. ;>
jak dla mnie od momentu w którym wchodzisz w próg świadomości istnienia czegoś tak interesującego, zaczyna się najciekawsza zabawa. bo nagle okazuje się, że różnych implementacji danego wzorca jest powiedzmy 5 i musisz umieć je porównać i wybrać najlepszy do danego rodzaju projektu. mnie to kręci najbardziej - nie sama świadomość że jest coś takiego jak powiedzmy nhibernate, ale świadomość że istnieje jeszcze np. linq2sql i xpo i wybieram technologię pod projekt, a nie jedyną jaką znam do każdego rodzaju projektu.
A ja uważam, że to marnotrawienie czasu. Pochwalam uczenie się, ale w moim wypadku wszystko sprowadza się do dwóch rzeczy. Pierwsza: jak to, czego używam, można ulepszyć czerpiąc z doświadczeń z innymi technologiami. Druga: mając świadomość tego, że coś innego jest lepsze w jakichś brzegowych przypadkach, jak unikać problemów z tym, czego używam, kiedy nie mogę tego ulepszyć. Nie zamierzam przeskakiwać z jQuery na Moo albo ExtJS tylko dlatego, że istnieje w nich lepszy komponent realizujący kontrolkę drzewo. Znajomość alternatywnych rozwiązań pozwala mi na rozszerzenie jQuery o kontrolkę zbudowaną tak, jak uważam za najodpowiedniejsze w danym wypadku.
zauważ tylko, że kategoria ludzi "umie sobie odtworzyć wzorzec ale nie jest do końca świadomy" trochę komplikuje duży projekt. od ludzi oczekujesz bowiem znajomości sprawdzonych narzędzi. tak jak przychodzi do mnie dwóch hydraulików i jadą jakimś swoim "tu dwudziestka, tam kolanko", tak samo chciałbym żeby mi człowiek na hasło "tu zrób chain of responsibility" od razu kumał, a nie dopiero szperał po literaturze i robił duże oczy.
Z mojego punktu widzenia jeśli używasz słownictwa, którego nie rozumieją współpracownicy, to zawiodłeś Ty. To nie jest tak, że głąb nie rozumie, tylko tak, że nie potrafisz wytłumaczyć. Ja tak zawsze do sprawy podchodzę. Jak przychodził do mnie ktoś z pytaniem o kawałek kodu, to tłumaczyłem skrajnie łopatologicznie, żeby mieć pewność, że zrozumie wszystko i różnice w lingo nie uniemożliwią jemu czy jej pracę nad projektem. Może wynika to z mieszanki kulturowej w której pracowałem, nie wiem. Wiem natomiast, że się sprawdza i każdy pattern można wytłumaczyć w 2-3 zdaniach, nie wspominając nawet nazwy wzorca. I odbiorca zrozumie. Nie tracę masy czasu na tłumaczenie w ten sposób a uzyskuję pewność, że zostałem zrozumiany.
świadomość wzorców to świadomość przestrzeni po której poruszasz się projektując kod aplikacji. nie mając takiej świadomości niepotrzebnie możesz tracić czas miotając się i wymyślając rozwiazania, które już dawno ktoś wymyślił, sprawdził i opisał.
Ale to co innego niż znajomość języka, o której pisałeś w poprzednim akapicie. Ja przykładowo bardzo długo znałem wzorce strukturalne i potrafiłem ich używać, chociaż nie miałem pojęcia o ich nazwach. Nie zamierzam tym bardziej oceniać negatywnie kogoś kto nie rozumie o czym mówię, bo potencjalnie na poziomie kodu może mnie rozumieć znakomicie a być może nawet jego słownictwo jest bogatsze od mojego.
podnadto stając przed problemem najpierw myślisz o wzorcu który do niego pasuje i jeśli jakiś pasuje to go wybierasz. potem ktoś kto odziedziczy Twoje rozwiazanie znajdując w dokumentacji czy kodzie informację "to zbudowałem na bazie wzorca Composite/Visitor" dziesięc razy szybciej załapie o co chodzi niż mętne wyjaśnienia struktury dużego fragmentu kodu, jakkolwiek przejrzyście byś tego nie opisał.
I tu się, znowu, nie zgadzam. Nigdy nie widziałem tego typu komentarzy w praktyce, ale wiem jak bym na nie zareagował. Alergicznie.
Śmiem twierdzić, że jeśli w 4 z 23 depotów Windowsa z którymi pracowałem nie było tego typu komentarzy, to musi być praktyczny ku temu powód.
Ogólnie jednak - musimy się zgodzić nie zgodzić. ;]
