Dlaczego używanie abstrakcji (takich jak LINQ) jest tak tabu? [Zamknięte]


60

Jestem niezależnym wykonawcą i jako taki udzielam wywiadów 3-4 razy w roku na nowe koncerty. Jestem teraz w trakcie tego cyklu i zostałem odrzucony na okazję, mimo że czułem, że wywiad poszedł dobrze. To samo zdarzyło mi się kilka razy w tym roku.

Teraz nie jestem idealnym facetem i nie oczekuję, że będę dobrze pasować do każdej organizacji. To powiedziawszy, moja średnia mrugnięcia jest niższa niż zwykle, więc uprzejmie poprosiłem mojego ostatniego ankietera o konstruktywną informację zwrotną, a on dostarczył!

Najważniejsze, według ankietera, było to, że wydawało mi się, że zbytnio skłaniam się ku stosowaniu abstrakcji (takich jak LINQ) niż ku algorytmom niższego poziomu, hodowanym organicznie.

Na pierwszy rzut oka ma to sens - w rzeczywistości sprawiło, że inne odrzucenia też mają sens, ponieważ w tych wywiadach pisałem o LINQ i nie wyglądało na to, że ankieterzy wiedzieli dużo o LINQ (mimo że byli oni .NET faceci).

Pozostaje mi więc pytanie: jeśli mamy „stać na ramionach gigantów” i korzystać z dostępnych nam abstrakcji (takich jak LINQ), to dlaczego niektórzy ludzie uważają to za tabu? Czy nie ma sensu ściągać kodu „z półki”, jeśli osiąga te same cele bez dodatkowych kosztów?

Wydaje mi się, że LINQ, nawet jeśli jest to abstrakcja, jest po prostu abstrakcją wszystkich tych samych algorytmów, które napisalibyśmy, aby osiągnąć dokładnie ten sam cel. Tylko test wydajności może ci powiedzieć, czy twoje niestandardowe podejście było lepsze, ale jeśli coś takiego jak LINQ spełnia wymagania, po co męczyć się pisząc własne klasy?

Nie chcę tutaj koncentrować się na LINQ. Jestem pewien, że świat JAVA ma coś porównywalnego, chciałbym tylko wiedzieć, dlaczego niektórzy ludzie czują się tak niekomfortowo z pomysłem użycia abstrakcji, której sami nie napisali.

AKTUALIZACJA

Jak zauważył Euphoric, w świecie Java nie ma nic porównywalnego z LINQ. Jeśli więc tworzysz na stosie .NET, dlaczego nie zawsze spróbować z niego skorzystać? Czy to możliwe, że ludzie po prostu nie rozumieją, co robi?


8
Myślę, że nie wiesz, czym jest „abstrakcja”, ponieważ LINQ nie ma z tym nic wspólnego.
Euforyczny

8
„Jestem pewien, że świat JAVA ma coś porównywalnego”. W rzeczywistości LINQ jest jedną z niewielu rzeczy, które ma .NET, a Java nie.
Euforyczny

42
@ Euphoric - Czy LINQ nie abstrakcyjny dala pracę niższy poziom zadań, takich jak sortowanie i filtrowanie na przykład? Jestem całkiem pewien, że objectCollection.Where(oc=>oc.price > 100)na przykład będzie jakiś dodatkowy kod . Czy nie byłoby to użycie abstrakcji? Może możesz mi powiedzieć, czego mi brakuje. . .
Matt Cashatt,

37
Zawsze istnieje szansa, że ​​po prostu nie rozumieją LINQ i nie widzą wartości w nauce go. Funkcjonalne aspekty pisania są bardzo różne od programowania imperatywnego. Jako kontrahent widziałem niedawno w 2009 r. „Starszych” programistów Java, którzy nie rozumieją języka SQL w stopniu wystarczającym do pisania zaawansowanych zapytań, dlatego spędzają tygodnie na optymalizacji kodu, który przenosi wszystkie dane po stronie Java i filtruje je za pomocą kodu Java, zamiast mieć baza danych to robi. W branży tworzenia oprogramowania szerzy się ignorancja .

18
Jeśli rozumiesz LINQ, ale twoi ankieterzy nie rozumieją, jesteś lepszy niż oni. Ustaw swoje cele wyżej.
Jay Bazuzi,

Odpowiedzi:


74

Nie sądzę, aby stosowanie abstrakcji jako takiej było budzące zastrzeżenia. Istnieją dwa inne możliwe wyjaśnienia. Jednym z nich jest to, że wszystkie abstrakcje są nieszczelne w tym czy innym czasie. Jeśli robisz wrażenie, poprawne lub nie, że nie rozumiesz podstawowych zasad, może to źle odzwierciedlać w wywiadzie.

Innym możliwym wyjaśnieniem jest efekt fanboya. Jeśli mówisz z podekscytowaniem o LINQ i wielokrotnie poruszasz go w rozmowie z firmą, która go nie używa i nie planuje tego robić, sprawia to wrażenie, że byłbyś niezadowolony, a nawet niezadowolony ze starszych technologii. Może również sprawiać wrażenie, że twój entuzjazm dla jednego produktu oślepił cię do alternatyw.

Jeśli naprawdę uważasz, że byłbyś szczęśliwy w sklepie innym niż LINQ, spróbuj zapytać o to, czego używają i odpowiednio dopasuj swoje odpowiedzi. Pokaż im, że choć wolisz LINQ, jesteś kompetentny w użyciu dostępnych narzędzi.


4
@MatthewPatrickCashatt Nie można edytować i kontynuować debuggera w ramach metod zawierających instrukcje linq. To nie wystarczy, że go nie używam; ale to był główny powód, dla którego wahałem się przez chwilę.
Dan Neely,

3
+1, szczególnie dla drugiego akapitu. To dotyczy mnie całkowicie, ponieważ byłbym całkowicie niezadowolony z pracy nad kodem C # bez możliwości korzystania z LINQ.
Arseni Mourzenko,

5
Istnieje również fakt, że oprócz nieszczelnej abstrakcji często pojawia się hit wydajności. Wymieniasz łatwość użycia na precyzję, a utrata precyzji często zawiera szczegóły, które przyspieszyłyby sprawę. Im dalej jesteś usunięty ze źródła, tym więcej tracisz szczegółów i większe prawdopodobieństwo, że te szczegóły są ważne dla wydajności.
jmoreno,

6
+1, ale może też działać w drugą stronę. Jeśli ktoś powie mi, że mnie nie zatrudnił, ponieważ używam Yacc do budowania parserów zamiast tworzenia własnych, to i tak nie jest to miejsce, w którym chcę pracować.
Spencer Rathbun,

5
@MatthewPatrickCashatt: ta odpowiedź (i mój komentarz do niej) nie są specyficzne dla LINQ, ale ogólne stwierdzenia. Ale dla LINQ oto fragment C # 4.0 / 5.0 w pigułce, mówiący o problemach z wydajnością LINQ. Powrót do ogólnych: w wielu przypadkach uderzenie wydajności będzie tego warte, 5% +/- nie ma znaczenia. Ale czasami będzie większy, a czasem nawet. 1% jest niedopuszczalny. Jeśli nie sądzisz, że kiedykolwiek może to być problem, lub że wydajność dotyczy tylko firm takich jak Google ....
jmoreno

29

Niektórzy programiści .NET, szczególnie ci z klasycznego VB / ASP lub C ++, nie lubią nowych rzeczy, takich jak LINQ, MVC i Entity Framework.

Na podstawie tego, co zaobserwowałem, byli VB'erzy w tej grupie prawdopodobnie nadal używają warstw dostępu do danych i innego kodu napisanego pierwotnie ponad 10 lat temu. Będą również używać starych modnych słów, takich jak „n-tier” i tym podobne, i tak naprawdę nie rozumieją niczego o niczym poza .NET Framework 2.0, ani nie chcą się niczego o tym dowiedzieć.

C ++ to programiści zorientowani na naukę, którzy uwielbiają kodować fajne algorytmy, nawet jeśli oznacza to ponowne wynalezienie koła. Nienawidzą, zależnie od wszystkiego, czego sami nie kodowali. Niektóre z tych osób lubią również sprawiać, że rozmówcy czują się gorzej, szczególnie ci o mniej tradycyjnym pochodzeniu.

Podczas przeprowadzania rozmowy prawdopodobnie napotkasz takie organizacje. Ale spotkasz także niektórych, którzy używają nowszych metod. Nie pozwól, aby kilka złych wywiadów cię zrzuciło.


2
Dzięki jfrankcarr. Podejrzewałem, że może tak być - były pytania dotyczące otwierania i zamykania datareaders!
Matt Cashatt,

2
+1 za nazwanie MVC „nowymi rzeczami”. Rozśmieszyło mnie głośno. Jest już od lat 70-tych. Być może miałeś na myśli MVVM, który jest zasadniczo MVP (wariant MVC), który używa powiązań.

14
@ GlenH7 Myślę, że z kontekstu było całkiem jasne, że miał na myśli produkt „ASP.NET MVC”, a nie podstawową koncepcję Model-View-Controller.
Carson63000,

4
@ GlenH7 - Mówiłem całkowicie w kontekście linii produktów .NET i Visual Studio oraz modnych słów Microsoft.
jfrankcarr

6
Dobry Boże, czy naprawdę są sklepy, które uważają Linq za „nowy”? Istnieje już od ponad 4 lat. Rozumiem, że nie dogoniłem oczekujących zadań, nie korzystałem z dynamic/ ExpandoObject/ itp. Ani nie przejmowałem się platformą Azure i wszystkimi innymi chmurami ... Rozumiem nawet, że nadal korzystam ze starej szkoły formularzy WebForms silnik w MVC lub w samych formularzach internetowych, lub pisanie kodu WPF / WinRT bez MVVM ... ale Linq? Jeśli jeszcze tego nie wiesz, czas odejść z pracy jako programista .NET.
Aaronaught

16

Microsoft ma długą historię opracowywania nowych, gorących technologii, a następnie zapominania o nich za 5, 10 lub 20 lat. LINQ może dla niektórych wyglądać jak inny. Zauważą, że Microsoft nie może wycofać SQL, ale LINQ może śledzić Silverlight . Mogłeś więc widzieć paranoję wynikającą z trudnych doświadczeń lub po prostu ludzi, którzy zostali pozostawieni przez nowoczesną technologię i nie cierpią jej.


12
Szczerze mówiąc, choć widzę podstawową kwestię, nie sądzę, żeby Linq wkrótce odszedł. Linq2SQL, tak, przestali go używać na rzecz znacznie potężniejszego EF. Ale sam Linq jest podstawą tak wielu innych lśniących nowości w ostatnich 3 wydaniach .NET, że jeśli przestaną go używać, cofną połowę swojej nowej technologii warstwy trwałej, takiej jak Azure i EF, nie mówiąc już o okaleczeniu praktycznie każdej ORM i mnóstwo przetwarzania list w pamięci poza tym.
KeithS,

6
czekaj ... "przerażony odejściem od starej, przestarzałej technologii, ponieważ działa" ... WTF. Czy doszliśmy do punktu, w którym rzeczy robocze, które są wypróbowane, przetestowane, zrozumiałe i łatwe w utrzymaniu oraz dojrzałe, NIE są dobre.
gbjbaanb,

7
@ gbjbaanb - Nie. Ale - jak anegdota - czy chciałbyś, aby lekarz zdiagnozował bóle w klatce piersiowej za pomocą prześwietlenia klatki piersiowej, ponieważ metoda ta jest „wypróbowana, przetestowana, zrozumiała”, czy też chcesz fMRI, który jest nowszy, ale ma wyższą rozdzielczość , lepsze prognozy i więcej informacji? Nikt nie mówi tutaj o odwróceniu się od klasycznych zasad; wręcz przeciwnie. Widzisz, LINQ (jako przykład) jest zbudowany na tych zasadach. Myślę, że jak wspomnieli inni, to uczenie się części sprawia, że ​​LINQ i jego właściwe użycie powoduje momenty „WTF”, takie jak twoje.
Matt Cashatt,

2
@MatthewPatrickCashatt: zależy, jeśli lekarz nie został przeszkolony do czytania wyników fMRI, przeszedłbym zdjęcie rentgenowskie, zamiast zgadywać diagnozę. Gdybym zachorował na wodach stojących, wolałbym mieć lekarza, który mógłby zdiagnozować jedynie stetoskop, niż być w stanie poradzić sobie bez najnowocześniejszych narzędzi.
gbjbaanb

2
@MatthewPatrickCashatt Rozumiem twój punkt widzenia, ale czynnikiem równoważącym jest to, że nie chcesz podążać za każdym trendem tylko dlatego, że jest nowszy. Z radością podążę za nową technologią, która pasuje do jednej z dwóch kategorii. 1. Podnieca mnie i jestem gotów poświęcić na to swój wolny czas. 2. Okazuje się, że faktycznie jest lepszy i wydaje się, że będzie trwał wystarczająco długo, aby był wart inwestycji. Trendy, które nie pasują do jednej z dwóch kategorii, są co najwyżej hazardem.
TimothyAWiseman

15

Czy nie ma sensu ściągać kodu „z półki”, jeśli osiąga te same cele bez dodatkowych kosztów?

Zawsze jest dodatkowa opłata.

Krzywa uczenia się z półki jest zawsze dostępna. Ból związany z otrzymywaniem aktualizacji (i zależności) jest zawsze obecny. Niemożność wkręcania się z jelitami jest zawsze obecna.

W przypadku LINQ pierwsze tak naprawdę ma zastosowanie. Wiele osób uważa, że ​​„dziwnie” wyglądający kod jest trudny do odczytania i trudniejszy do debugowania. Składnia podobna do sql jest niemal osobista, bez grata na każdym profesjonalnym koncercie, na którym pracowałem, odkąd się pojawił. LINQ to SQL (i inne źródła danych) mają wiele gotów i ograniczone opcje optymalizacji.

Są to ogólne argumenty przeciwko narzędziom stron trzecich, a konkretnie LINQ. To powiedziawszy, LINQ jest cholernie użytecznym narzędziem i powinno być preferowane w większości sytuacji. Nie wymyślono tutaj płaczu, a abstrakcjom nie należy się sprzyjać silnym uderzeniem dysonansu poznawczego .

Nie znają / nie mogą nauczyć się LINQ, ale są „oczywiście” dobrymi programistami, więc LINQ nie może być tego wart. To powszechna pułapka.


1
Słuszne uwagi. Uzgodnij koszty, o których wspominasz, i to jest dobre wyjaśnienie. Mówiąc bardziej ogólnie, tworzenie klas wychowawczych, z którymi nie mogą się zapoznać nowi pracownicy, ponieważ nie istnieją one poza organizacją, stawiają te same wyzwania, oprócz kosztów podstawowego rozwoju.
Matt Cashatt,

2
@MatthewPatrickCashatt - Och, absolutnie. Ten domowy kod powinien więc prawie zawsze wymagać więcej wysiłku dla tej samej wygranej, ale niekoniecznie. Podobnie jak wiele innych rzeczy, koszt / nagroda powinna być określona i najlepsze praktyki korzystne , a nie ślepo.
Telastyn,

@Telastyn Kod domowy jest również miły, ponieważ wiesz, co robi i możesz go naprawić w krótkim czasie. Ponadto możesz zoptymalizować pod kątem konkretnych okoliczności w oparciu o własne użycie, a nie średnią każdego.
Hawken,

13

Inną rzeczą, którą powinieneś wziąć pod uwagę, jest to, że twój entuzjazm dla nowej, fajnej technologii może po prostu sprawić, że ludzie poczują się nieswojo i nie będą cię chcieli. Nie „wzmacniasz” ich, ponieważ to ty znasz tę technologię, a nie oni. Nawet jeśli sami nie zdają sobie z tego sprawy, mogą szukać kandydatów, którzy wzmocnią to, w co już zainwestowali tyle czasu.

Chcesz przedstawić postawę, która mówi: „Cokolwiek robisz, chcę ci pomóc w osiągnięciu tego”, a nie podtekst, który mówi: „Być może robisz coś źle, a obecność mnie w pobliżu okaże się to."


+1 - oprócz powiedzenia im, o czym wiesz, zapytaj ich, co robią i w czym się specjalizują.
Kirk Broadhurst

12

Moje zdanie na ten temat (i zgaduję TBH, ponieważ nikt z nas nie wie, o czym myśleli ci ankieterzy) polega na tym, że często chodzisz na rozmowę, aby wyjaśnić, dlaczego powinni zatrudnić cię, aby dopasować się do ich zespołu, ich sposobu pracy .

Możesz być idealnym programistą, boga rocka startowego, ale to absolutnie nic nie znaczy, jeśli to, co chcesz zrobić (podkreślone przez nadmierne i zbyt entuzjastyczne mówienie o fajnych technologicznych gubinach) po prostu mówi im o tobie, i że nie zrobiłbyś tego dopasuj się do tego, czego chcą. Jeśli mają system dostępu do danych w starym stylu, którego nie można uaktualnić z jakiegokolwiek powodu, nie potrzebują kogoś, kto zapomniałby go obsługiwać. Jeśli opracowują nowe rzeczy, a naprawdę naprawdę chcesz wszędzie umieścić tę fajną nową technologię, to oczywiste, że będą mieli duży problem z utrzymaniem kodu i / lub szkoleniem personelu.

Jako freelancer jest to o wiele większy problem, niż gdyby zatrudniali permie. Z pozwoleniem, szkolenie i rozwój nowych sposobów pracy nie są złymi rzeczami, w ramach istniejącego kodu i praktyk - będziesz tam przez długi czas, aby poprawić sytuację. Z freelancerem naprawdę nie dadzą rady, czego chcesz, jesteś tam tylko po to, aby wykonywać swoją pracę tak, jak tego chcą, a nie twoim zadaniem jest robić cokolwiek innego. (nie zgadzam się - zostań stałym pracownikiem)

Prawdopodobnie nie ma to nic wspólnego z samym LINQ, odrzuciłem kandydata, który pojawił się i wyjaśniłem, o ile lepiej wszystko będzie napisane w Haskell. Nie robimy Haskell. To samo dotyczy każdej technologii, która nie jest używana przez firmę, zwykle nie stanowi problemu, jeśli wspominasz o niej jako o czymś dobrym. Problem pojawia się, gdy jesteś zbyt entuzjastyczny i chętny.


2
Zgadzam się z tym, ale zauważyłem o wiele więcej osób, które stosują to podejście do odrzucania dobrych pomysłów, których po prostu nie rozumieją (np. Testowanie, wzorce projektowe, ORM). Tak więc, chociaż zgadzam się, że dobre dopasowanie do zespołu jest dobrą rzeczą, ważne jest, aby zdawać sobie sprawę, że możesz być lepszy niż reszta zespołu i powinieneś znaleźć osoby o podobnych poglądach, w których dobra znajomość nie jest zła abstrakcje.
Wayne Molina,

1
@WayneM na pewno, ale OP jest freelancerem, więc to naprawdę nie ma znaczenia, czy jest bogiem kodującym, chyba że są przygotowani na zatrudnienie go na stałe w celu utrzymania kodu, którego reszta zespołu nie rozumie (hmm), to musi robić to, czego chcą, a nie to, czego chce.
gbjbaanb,

1
@WayneM podobnie wiele osób użyłoby czegoś podobnego do tego, co właśnie powiedziałeś, aby promować swoje pomysły nad czyimiś innymi (mając pewność, że do kogo rozmawia, po prostu tego nie rozumie). Ostatecznie obie strony są stronnicze, ale OP polega na zatrudnieniu, a nie na wygraniu wielkiej wojny z majsterkowaniem / abstrakcją. Każdy będzie miał własne zdanie, ale ktoś musi się z tym pogodzić; Zgaduję, że w tym przypadku nie będzie to pracodawca. :(
Hawken,

10

Jest jedna ważna obawa, którą usłyszałem od tych, którzy nie używają Linqa, i jedną z nich biorę sobie do serca: „To, że nie widzisz wdrożenia, nie oznacza, że ​​nie jest drogie”.

Weź następujący fragment:

var resultList = inputList.Where(i=>otherInputList.Count(o=>o.Property == i.OtherProperty) > 0);

Zainicjowani tutaj LINQ kulą się. Dlaczego? Ponieważ to, że ten kod wygląda ładnie i elegancko, nie oznacza, że ​​nie jest strasznie nieefektywne. Funkcja Count () z predykatem ocenia każdy element swojego elementu nadrzędnego w postaci wyliczalnej i podsumowuje czasy, w których predykat zwrócił wartość true. Zatem nie tylko ten N ^ 2 (gdy inputList i otherInputList mają mniej więcej równą liczność N), jest to absolutnie najgorszy przypadek N ^ 2; KAŻDY element otherInputList przechodzi przez KAŻDY element wejściowy. Zamiast tego pierwszym krokiem jest użycie Any () zamiast Count, ponieważ tak naprawdę chcesz wiedzieć, i zakończy działanie, gdy tylko odpowiedź będzie brzmiała „tak”. Skonfigurowanie zestawu HashSet przechowującego różne wartości otherInputListObject.OtherPropertymoże również pomóc; dostęp staje się O (1) zamiast O (N),złożoność najgorszego przypadku zamiast kwadratowej złożoności najlepszego przypadku .

Widzimy więc, że te ładne eleganckie metody wiążą się z poważnymi kosztami, a jeśli nie wiesz, jakie są te koszty, możesz bardzo łatwo zakodować algorytm złożoności O (mój GD) w wysokowydajnym centralnym serwerze plików potencjalnego pracodawcy lub główną stronę portalu docelowego, kiedy następnym razem będą potrzebować poprawki. Zwolnienie cię po tym, co zrobisz, nie cofnie tego, co zrobiłeś, ale nie zatrudnienie cię, jeśli będą myśleć, że to zrobisz, by temu zapobiec. Aby tego uniknąć, musisz udowodnić, że się mylą; przedyskutuj, co robią te metody (co oznacza, że ​​musisz znać siebie) i ich złożoność oraz jak dotrzeć do odpowiedzi w efektywnym (NlogN lub lepszym) czasie.

Innym problemem jest stary, dobry argument „Gdy jedynym narzędziem jest młot”. Postaw się na miejscu ankietera, który przeprowadza wywiad z tym fanem Linq. Kandydat lubi Linq, chce go używać, uważa, że ​​to najlepsza rzecz na świecie. Mogłoby się nawet wydawać, że kandydat nie mógłby bez niego kodować, ponieważ każdy podany problem programistyczny został rozwiązany za pomocą Linq. Co się stanie, gdy nie będzie można go użyć? Nadal istnieje wiele kodów .NET 2.0, które, gdyby zostały uaktualnione, wymagałyby bolesnych uaktualnień do serwerów, stacji roboczych użytkowników itp. Itd., Wszystko po to, abyś mógł użyć swoich wymyślnych metod rozszerzenia. Jako ankieter chciałbym zachęcić cię do pokazania, że ​​możesz kodować wydajne sortowanie lub użyć metod sortowania 2.0, jeśli to konieczne, bez względu na to, jak bardzo mogę się zgodzić, że biblioteki Linq i podobne metody rozszerzenia są ładne Słodkie. Ankieter, który nie rozumie sensu, może nawet nie zawracać sobie głowy próbą nakłonienia cię do wykazania zdolności do czegokolwiek innego; zakładają, że go nie masz i idą dalej.


Dlaczego po prostu nie napisałeś swojego zapytania jako var resultList = inputList.Select(i=>i.Property).Intersect(otherInputList.Select(o=>o.Property));? Mogłem to zrobić, ale mam na myśli to, że LINQ ma lepsze sposoby wykonywania zapytania, o którym wspomniałeś powyżej (.Join () to inny sposób). Zdaję sobie sprawę, że istnieją sposoby korzystania z LINQ, które mogą nie być tak sprawne jak inne sposoby, ale to nie znaczy, że musisz polegać na tych złych implementacjach.
Matt Cashatt,

4
@MatthewPatrickCashatt Nie sądzę, aby jego celem było twierdzenie, że LINQ jest zawsze nieefektywny - podczas gdy zawsze możesz pokonać dane zapytanie LINQ, niektóre zastosowania dają lepszą wydajność na godzinę programisty niż wiele podejść innych niż LINQ. Raczej może być stosunkowo łatwo napisać zapytanie LINQ, które jest nieefektywne i nie zdawać sobie z tego sprawy, ponieważ nieefektywność nie jest tak rażąca.
Jon Hanna,

3
@JonHanna: Być może bardziej chodzi o to, że wartość abstrakcji jest znacznie zmniejszona, jeśli trzeba zbadać, jaki kod „naprawdę robi”, aby ustalić, które nietypowe, ale prawdopodobne scenariusze mogą spowodować, że wydajność będzie o wiele rzędów wielkości gorsza niż oczekiwano. Jeśli przejście z jednej struktury danych na drugą spowoduje, że kod będzie działał 10 000 razy wolniej, możliwość dokonania takiej zmiany bez zmiany jakiegokolwiek innego kodu może nie zawsze być dobrą rzeczą.
supercat,

1
@ supercat: tak i nie. Tylko dlatego, że wiedza o tym, jak coś się robi w implementacji strony trzeciej, ma kluczowe znaczenie dla zrozumienia wpływu na wydajność i unikania nieefektywności, nie oznacza, że ​​biblioteki, które zawierają te narzędzia, mają mniejszą wartość. To dwie strony tej samej monety; poznaj naturę implementacji i możesz jej użyć z kilkoma naciśnięciami klawiszy zamiast zliczania własnych godzin. Ale musisz znać obie strony, a stereotypowy fanatyk Linq, który uważa, że ​​jest idealny, nic złego, użyj go do wszystkiego, co prawdopodobnie nie.
KeithS,

@KeithS: Wydaje mi się, że jedną rzeczą, której bardzo brakuje w Javie i .net, jest standardowy sposób zadawania pytań o przedmioty lub kolekcje różnych rzeczy o sobie. Na przykład kod, który odbiera wymienną kolekcję, może zyskać na wiedzy, czy liczba elementów i / lub kolejność istniejących elementów może się kiedykolwiek zmienić, czy wiadomo, że liczba elementów jest skończona czy nieskończona (lub nieznana w żaden sposób) i czy kolekcja z natury wie, ile jest w niej przedmiotów. Technologie takie jak LINQ często muszą przyjmować założenia dotyczące takich rzeczy, które mogą, ale nie muszą być poprawne, i ...
supercat

10

Ten był trochę długi, ale może być komuś pomocny, więc na to pozwolę.

W rzeczywistości spotkałem coś podobnego, przechodząc w ubiegłym miesiącu trochę ponad 20 wywiadów (połączenie telefonu i osobiście). Zdecydowanie działo się coś nieoczekiwanego, czego nie mogłem dosięgnąć.

Jedną z rzeczy, które zauważyłem, było to, że rzeczy, które zwykle były centralnym punktem cykli wywiadów w ciągu ostatnich pięciu lub sześciu lat, zdecydowanie nie były omawiane ani poddawane krótkiej analizie. Rzeczy takie jak podstawy analizy / projektowania OOP, wzorce (zarówno projektowe, jak i architektoniczne), niektóre bardziej zaawansowane / zorientowane na abstrakcję funkcje .net (w tym lambdas lub LINQ, generyczne, serializacja / wiązanie danych itp.), A nawet zwykle gorący temat preferowanej metodologii (nikomu nie zależało na zwinności w porównaniu z wodospadem ani na smaku zwinności) i narzędziach lub wyborze ORM lub preferowanych sposobów współpracy lub zarządzania kontrolą źródła. W niektórych przypadkach w ogóle nie wspomniano, w prawie wszystkich przypadkach najwyraźniej nie dotyczy.

W wielu wywiadach i różnych niepowiązanych firmach w niepowiązanych branżach skupiono się na następujących kwestiach:

  • Dziwna fiksacja na temat przestarzałych / przestarzałych konwencji i ograniczeń „powrotu do epoki kamienia”. Jak tworzenie prymitywnej aplikacji internetowej w VS2003 z listą absurdalnych ograniczeń, które dodatkowo zabraniają korzystania z jawnych funkcji w erze .net ... tak jakby to był prawdziwy miernik umiejętności współczesnych programistów ... zdolność zapamiętywania paradygmat i ograniczenia sprzed 9 lat zostały dodatkowo osłabione przez nierealne / arbitralne ograniczenia. Inne miejsce było bardzo uparte w kwestii kolekcji niestandardowych, około kolekcji pre-generycznych. W innym miejscu zapisałem próbkę kodu modelu klasy, który wypisałem, ponieważ nie używałem kaskadowych konstruktorów (wydawało się, że nie byli świadomi obsługi inicjowania właściwości podczas deklaracji, co było wystarczające w razie potrzeby).

  • Szczególny nacisk kładziony jest na konkretne szczegóły implementacji w mikrokosmosie i / lub ustawieniach konfiguracyjnych, nawet w przypadku technologii, które koncentrują się na byciu niezależnym od platformy lub protokołu (tj.… Cały punkt NIE powinien być ustalany na konkretnej implementacji lub określonym użyciu, ale raczej w sprawie ponownego wykorzystania / ponownego przeznaczenia / rozszerzalności / w razie potrzeby integracji).

  • Gotowość do sprecyzowania / nadzorowania / przeglądu kodu / i w inny sposób odpychania pracy do zespołu od brzegu oraz od umiejętności niekodowania związanych z tym.

  • Wykorzystanie określonych wersji produktów / platform / modułów / itp. W niekiedy absurdalnym stopniu; „Więc… używałeś wersji 1, 2 i 4? Ale nie 3, co? Hmmm… {adnotuje twoje CV słowem„ no v3 !!!} ”. Stopień wykorzystania nie wydawał się mieć znaczenia; tylko, że masz lub nie stosować coś w ogóle , a szczególna rzecz, że są one również z prośbą o ... brak podstawienia wydawało się liczyć, nawet z bardziej powszechnie stosowane i pełni funkcjonalny produktu konkurencyjnego.

  • Znacznie większy nacisk na „jak dobrze dopasujesz się do naszego zespołu” nad „czy faktycznie jesteś dobry jako programista” lub „czy masz umiejętności i doświadczenie, aby dodać wartość firmie i pomóc nam dostarczać jakość produkt ”czy nawet„ czy jesteś niebezpiecznym idiotą, który wejdzie i zniszczy sklep ”. W niektórych przypadkach moje CV było po prostu traktowane jako dane, a nawet tak zwany „ekran technologiczny” lub wywiad techniczny był oceną osobowości znacznie więcej niż oceną umiejętności. Nawet dla stosunkowo krótkoterminowych pozycji kontraktowych, w których byłbyś tam i odszedłeś przed dwoma sezonami.

  • Wydawało się, że firmy tym razem mniej koncentrują się na rozwiązywaniu konkretnych problemów technicznych, rozpoczynaniu nowych projektów deweloperskich lub dużych projektów rozwoju 2.0, lub na wprowadzaniu określonego produktu na rynek, aby wykorzystać pojawiający się trend lub szansę, lub zwykłe duże premiery . Powtarzającym się tematem, który zauważyłem w co najmniej 15 miejscach, było to, że niewielka grupa 3-5 programistów, głównie tych, którzy przeżyli krach na rynku w 08 roku, była w stanie opracować produkt w ciągu ostatnich 3 lat i osiągnęli sukces lub ich firma cały czas się rozwija i zatrudniają nowych pracowników, aby nadążać za rosnącymi wymaganiami dotyczącymi funkcji lub zaradzić wadom projektowym wbudowanym w te systemy, lub też przejąć wspomniane platformy, aby uwolnić zespół podstawowy, który zbudował go do „innych projektów”.

Ale ... jeśli wiem coś o tym biznesie, to że ma on charakter cykliczny. Następnym razem, gdy szukam nowego koncertu, nie będę zaskoczony, jeśli gra zmieni się jeszcze raz. Musisz tylko pozostać elastycznym umysłowo, aktywnie słuchać, unikać wypowiadania absolutnych oświadczeń, jeśli są niepotrzebne, ale nie bądź też łasicą i nie należy traktować jako jednowymiarowy (jesteś idiotą lub fanatycy, ani pożądani, ani zbyt dobrzy (może to grozić i kosztować koncert).

Po prostu dostosuj swoje podejście i postaraj się udzielić bardziej wymiernej odpowiedzi następnym razem ... wymień kilka różnych sposobów rozwiązania problemu ... ale nawet jeśli jest to rutynowa wiedza, zachowujesz się tak, jakbyś naprawdę o tym myślał i rozumowanie na miejscu. W ten sposób wydaje się bardziej pokorny i mniej onieśmielający lub obraźliwy.

Oczywiście, Prawo Murphy'ego jest jaka jest, już następnego wywiad po zaprzestaniu bycia „pasjonatem mojego obecnego ulubionej technologii faceta” i przyjąć bardziej zrównoważony / brody-głaszcząc stanowisko jest koncert, który będzie zdobyć, gdybyś był szalony gorliwy facet. ;)


6

Myślę, że wyciągasz fałszywy wniosek, ponieważ twój zestaw próbek jest zbyt ograniczony. Chociaż widziałem spory odsetek sklepów IT z dużą niechęcią do czegokolwiek „tam nie wymyślonego” 1 , żaden z nich nie zdyskwalifikowałby kandydatów na podstawie ich preferencji w stosie technologii: byli słusznie przekonani, że mogą nauczyć właściwego kandydata korzystania z niego ich domowe biblioteki.

Poważnie wątpię, aby firma całkowicie zakazała używania LINQ. Bardziej prawdopodobne jest, że chcieli, abyś pokazał im swoje umiejętności na głębszym poziomie.

Na przykład jednym ze sposobów sprawdzenia, czy znasz swoje tabele skrótów, jest poproszenie Cię o zaimplementowanie prymitywnej tabeli na tablicy. To proste ćwiczenie ujawnia zaskakującą ilość danych o twojej wiedzy recenzentowi: natychmiast uczy się, jeśli wiesz o haszowaniu / wartości równej oraz o tym, co wiesz o kolizjach skrótu. Jednocześnie trudno jest sobie wyobrazić kogoś przy zdrowych zmysłach, który ponownie wdrożyłby tablicę skrótów, ponieważ Microsoft wykonał tak dobrą robotę. To samo dotyczy wielu algorytmów, takich jak sortowanie i wyszukiwanie: ankieterzy często chcieliby wiedzieć, czy Twoje doświadczenie wystarcza do zrozumienia interakcji na niskim poziomie, zamiast sprawdzać, czy masz praktyczną wiedzę na temat bibliotek .NET.

Jest niemal pewne, że nalegaliby na ciebie, abyś używał implementacji biblioteki zamiast własnej, gdy zostaniesz zatrudniony do pracy w ich firmie. Ale podczas wywiadu popychaliby cię do kodu niskiego poziomu, aby lepiej zrozumieć twoje prawdziwe umiejętności.


1 jeden sklep posunął się do zbudowania własnego, dość prymitywnego narzędzia do budowania!


2
Wszystkie twoje uwagi są dobrze przemyślane, ale powinienem dać ci trochę koloru wokół ostatniego wywiadu: ankieter nalegał, że LINQ był „przestarzały”. Zapytałem: „nie masz na myśli, że stwardnienie rozsiane nie będzie już inwestować w Linq-to-SQL, ale że Linq-to-Entities będzie w pobliżu”, a jego odpowiedź brzmiała, że ​​miał na myśli to, co powiedział: LINQ jest „przestarzały” więc nie, nie sądzę, aby wiedział zbyt wiele o LINQ lub nalegał na jego użycie.
Matt Cashatt,

1
@MatthewPatrickCashatt Jeśli ktoś pomylił LINQ z LINQ2SQL pod względem przestarzałej technologii, wymyśliłem jakąś głupią wymówkę, aby wcześnie opuścić wywiad i nigdy nie oddzwoniłem do tej firmy. Jeśli rzeczywiście tak było, powinieneś być szczęśliwy, że cię nie zatrudniają :)
dasblinkenlight,

1
100% pewności, że tak było. W rzeczywistości nie mogłem się powstrzymać przed wysłaniem mu kilku linków, aby skierować go na właściwą ścieżkę w tym temacie, nie jako dźgnięcie, ponieważ nie dostałem koncertu, ale ponieważ tak naprawdę czułem się zawstydzony za niego i miałem nadzieję, że mogę pomóż mu nie popełnić dwukrotnie tego samego błędu;).
Matt Cashatt,

4
Wydaje się, że ma to mniej wspólnego ze stosem technologii, a więcej z faktem, że go poprawiłeś. Ludzie nie lubią być poprawiani. To tylko ludzka natura. Kiedy ludzie podejmują decyzje, takie jak zatrudnianie ludzi, 99% idzie z ich intuicją. Mijają, czy sprawiłeś, że poczuliście pozytywne lub negatywne emocje. Poprawienie go mogło spowodować, że poczuł negatywne emocje. A potem wiąże tę negatywność z sytuacją.
koder

1
Nie wiem, jak hashtable działają wewnętrznie. Takie głębokie testy techniczne wyrzucają osoby z właściwie przeszkolonymi szkoleniami, które są jednak dobrymi kandydatami. Wymaganie od ludzi niskiego poziomu wiedzy, której nigdy nie będą używać, wydaje mi się niepotrzebne. Zasady projektowania stały się znacznie ważniejsze!
Tjaart

4

Myślę, że dokonujesz szalonych uogólnień na temat typu „Widziałem czarną krowę w Szkocji, więc wszystkie szkockie krowy są czarne”.

Gdybym przeprowadził z tobą wywiad, byłbym rozczarowany, gdybyś nie mógł odpowiedzieć na moje pytania dotyczące linq.

Linq jest jednak trudny, wiele osób uważa go za voodoo, co jest niesprawiedliwe, ponieważ jest w rzeczywistości bardzo proste i tym bardziej sprytne.


3

Aby zagrać w adwokata diabła, powodem jest to, że wielu programistów po prostu nie przejmuje się nowymi rzeczami i uważa, że ​​wszystko musi zostać rozwiązane za pomocą domowych narzędzi (zwykle gorszych). Nie ma nic złego w korzystaniu z abstrakcji. Do diabła, zwykle nie ma dobrego powodu, aby nie używać tych abstrakcji.

Wygląda na to, że właśnie przeprowadziłeś wywiad ze słabym deweloperem, który nie jest na bieżąco z rzeczami i przyjmuje podejście do wszystkiego. Są to typy programistów, którzy nie wiedzą nic o pomocnych narzędziach open source, takich jak NUnit, NHibernate lub różnych kontenerach IoC; ci, którzy próbują rozwiązać każdy problem za pomocą ogromnego przechowywanego proc w bazie danych; tych, którzy nie wiedzą absolutnie nic o MVC, mimo że jest dostępny od kilku lat.


Możesz wrzucić LINQ do puli modnych słów zawierających Nhibernate itp. Nie zrobiłbym tego. Właściwie myślę, że modne słowa są przykładem naszej niezdolności do wyjaśnienia abstrakcji właściwymi wyrażeniami.
AndreasScheinert

Mówisz o „byciu na bieżąco”. Myślę, że odwrotność byłaby o wiele bardziej odpowiednia. W przeszłości odkryto i użyto wiele przydatnych pojęć, na przykład DSL. Od nas zależy poprawa komunikacji i zrozumienie takich pojęć, że nie musimy wymyślać nowych słów dla starych pojęć.
AndreasScheinert
Korzystając z naszej strony potwierdzasz, że przeczytałeś(-aś) i rozumiesz nasze zasady używania plików cookie i zasady ochrony prywatności.
Licensed under cc by-sa 3.0 with attribution required.