Чому використання абстракцій (таких як LINQ) настільки табу? [зачинено]

Я незалежний підрядник і, як такий, провожу інтерв'ю 3-4 рази на рік для нових концертів. Зараз я в самому розпалі цього циклу, і мені відмовилися за можливість, хоча я відчував, що інтерв'ю пройшло добре. Те саме трапилося зі мною пару разів цього року.

Зараз я не є ідеальним хлопцем, і не сподіваюся, що я добре підходить для кожної організації. Але це означає, що мій середній показник менший, ніж зазвичай, тому я ввічливо попросив мого останнього інтерв'ю про деякі конструктивні відгуки, і він виступив!

Головним, на думку інтерв'юера, було те, що я, здається, занадто схилявся до використання абстракцій (наприклад, LINQ), а не до алгоритмів, органічно вирощених на нижчому рівні.

На перший погляд, це має сенс - насправді, в інших відхиленнях є сенс і тому, що я також клопотався про LINQ в цих інтерв'ю, і не здавалося, що інтерв'юери знали багато про LINQ (хоча вони були .NET хлопці).

Тож тепер у мене залишається таке питання: Якщо ми повинні «стояти на плечах гігантів» і використовувати доступні нам абстракції (як LINQ), то чому деякі люди вважають це таким табу? Чи не має сенсу знімати код «з полиці», якщо він досягає тих же цілей без зайвих витрат?

Здавалося б мені , що LINQ, навіть якщо це абстракція, це просто абстракція всіх тих же алгоритмів , можна було б написати для виконання точно такий же кінець. Тільки тест на ефективність може сказати вам, чи був ваш індивідуальний підхід кращим, але якщо щось на зразок LINQ відповідало вимогам, навіщо взагалі турбуватися писати власні заняття?

Я не хочу тут зосереджуватися на LINQ. Я впевнений, що у світі JAVA є щось порівнянне, я просто хотів би знати, чому деяким людям стає так незручно з ідеєю використання абстракції, яку вони самі не написали.

ОНОВЛЕННЯ

Як зазначав Ейфорік, у світі Java немає нічого подібного до LINQ. Отже, якщо ви розробляєте стек .NET, чому б не завжди спробувати його використати? Чи можливо, люди просто не повністю розуміють, що це робить?

Я не думаю, що використання абстракцій само по собі є незаперечним. Можливі два пояснення. Одне полягає в тому, що в той чи інший момент абстракції є протікаючими . Якщо ви створюєте враження, правильне чи ні, ви не розумієте основоположних основ, які можуть відображатися погано в інтерв'ю.

Інше можливе пояснення - ефект фанбоя. Якщо ви з захопленням говорите про LINQ і неодноразово піднімаєте це в інтерв'ю з компанією, яка не використовує його і не має поточних планів цього робити, це створює враження, що ви були б незадоволені або навіть незадоволені, працюючи зі старими технологіями. Це також може створити враження, що ваше захоплення одним продуктом засліпило вас альтернативою.

Якщо ви дійсно думаєте , що ви були б щасливі в магазині , НЕ LINQ, спробуйте запитати про те, що вони дійсно використовують, і адаптувати свої відповіді відповідно. Покажіть їм, що, віддаючи перевагу LINQ, ви грамотно використовуєте будь-які підручні засоби.

Деякі програмісти .NET, особливо ті, що надходять або з класичного VB / ASP, або з C ++, не люблять нових матеріалів, таких як LINQ, MVC та Entity Framework.

Виходячи з того, що я спостерігав, колишні VB'ers цієї групи, ймовірно, все ще будуть використовувати шари доступу до даних та інший код, спочатку написаний 10+ років тому. Вони також використовуватимуть старі мовленнєві слова, такі як "n-level" і подібні, і насправді нічого не розуміють ні про що, крім .NET Framework 2.0, і не хочуть нічого дізнатися про це.

C ++ 'є тенденцією бути академічно орієнтованими програмістами, які люблять кодувати круті алгоритми, навіть якщо це означає переосмислити колесо. Вони ненавидять залежно від того, що вони самі не передавали. Деякі з цих людей також захоплені тим, що опитувані відчувають себе неповноцінними, особливо ті, хто має менш традиційний досвід.

Ви, ймовірно, натрапите на подібні організації під час співбесіди. Але ви також натрапите на тих, хто використовує новіші методи. Не дозволяйте кілька поганих інтерв'ю відкинути вас.

Майкрософт має довгу історію виходу з новими гарячими технологіями, а потім забуває про них 5, 10 або 20 років вниз. LINQ для деяких людей може виглядати ще одним. Вони відзначать, що Microsoft не може застаріти SQL, але LINQ може слідувати Silverlight . Таким чином, ви можете бачити параноїю внаслідок важкого досвіду або просто людей, які залишилися позаду сучасних технологій і які обурюються.

Чи не має сенсу витягувати код «з полиці», якщо він виконує ті самі цілі без зайвих витрат?

Завжди є додаткові витрати.

Крива навчання для речей з полиці завжди є. Біль від отримання оновлень (і залежностей) завжди є. Неможливість накрутити кишки завжди є.

Для LINQ стосується лише першого. Багато людей вважають, що дивний код виглядає важко для читання і важче налагодити. Синтаксис, схожий на sql, є значною мірою персона-нон-гратою, кожен професійний концерт, з якого я працював з моменту його виходу. LINQ до SQL (та інших джерел даних) має ряд варіантів та обмежених варіантів оптимізації.

Це загальні аргументи проти сторонніх інструментів та конкретно LINQ. Все, що сказано, LINQ - це проклятий корисний інструмент, якому слід віддавати перевагу в більшості ситуацій. Тут плач не придумується, і абстракції не повинні віддавати перевагу когмативному дисонансу .

Вони не знають / не можуть вивчити LINQ, але вони "очевидно" хороші розробники, тому LINQ не повинен бути вартим. Це звичайна пастка.

Ще щось, що вам слід врахувати, - це те, що ваш ентузіазм щодо класної нової технології може просто змусити людей почувати себе некомфортно і не бажати вас поруч. Ви не «наділяєте їх» повноваженнями, бо саме ви знаєте цю технологію, а не вони. Навіть якщо вони самі цього не усвідомлюють, вони можуть шукати кандидатів, які підкріплять те, в що вже вклали стільки часу.

Ви хочете представити ставлення, яке говорить: "Що б ви не робили, я хочу допомогти вам досягти цього", а не давати підтекст, який говорить: "Ви можете робити щось погано, і те, що мене навколо, доведе, це ".

Я берусь на це (і я думаю, що ніхто з нас не може сказати, про що думали ці інтерв'юери) - це те, що часто ви йдете на співбесіду, щоб пояснити, чому вони повинні найняти вас, щоб вони відповідали їх команді та їхньому способу роботи .

Ви можете бути ідеальним розробником, богом рок-коду, але це не означає абсолютно нічого, якщо те, що ви хочете робити (підкреслюючи, що ви говорите надмірно і занадто захоплено про якісь круті технології губбіни), просто говорить їм про вас, і що ви не хочете відповідати тому, що вони хочуть. Якщо у них є система доступу до даних у старому стилі, її неможливо оновити з будь-якої причини, їм не потрібен той, хто забув, як її підтримувати. Якщо вони розробляють нові речі, і ви дійсно хочете поставити цей класний новий технологій скрізь, то очевидно, що у них виникне велика проблема з майбутнім обслуговуванням коду та / або навчанням персоналу.

Як фрілансер, це набагато більша проблема, що якби вони найняли пермі. З пермеєю, навчання та розробка нових способів роботи - це не погано, в рамках існуючого кодексу та практики - ви будете там довго, щоб покращити справи. З фрілансером вони насправді не дають прошукати те, що ви хочете, ви тільки там, щоб виконувати свою роботу так, як вони хочуть, і не ваша робота робити щось інше. (не згоден - стань постійним працівником)

Це, мабуть, не має нічого спільного з самим LINQ, я відхилив кандидата, який з’явився, і пояснив, наскільки краще все буде написано в Haskell. Ми не робимо Haskell. Те саме стосується будь-яких технологій, які не використовуються компанією, зазвичай це не є проблемою, якщо ви згадуєте її як щось хороше. Проблема виникає, коли ви занадто захоплені і захоплені цим.

Є одне дійсне занепокоєння, яке я почув від тих, хто не використовує Linq, і це одне, що я приймаю до душі: "Тільки тому, що ти не бачиш реалізації, це не означає, що це не дорого".

Візьміть такий фрагмент:

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

Тут ініціюється LINQ. Чому? Тому що тільки те, що цей код виглядає приємно і елегантно, не означає, що він не жахливо неефективний. Count () за допомогою присудка оцінює кожен елемент його батьківського перелічувального числа і підсумовує кількість разів, коли присудок повернувся істинним. Отже, не тільки це N ^ 2 (коли inputList та otherInputList мають приблизно рівну кардинальність N), це абсолютно гірший випадок N ^ 2; КОЖНИЙ елемент otherInputList проходить для ВСЕГО елемента введення. Натомість, перший крок - використовувати Any () замість Count, адже це дійсно те, що ви хочете знати, і воно припиниться, як тільки відповідь буде відома "так". Налаштування HashSet, який зберігає різні значення, otherInputListObject.OtherPropertyможе також допомогти вам; доступ стає O (1) замість O (N),найгірша складність, а не квадратична найкраща складність.

Таким чином, ми бачимо, що ці приємні елегантні методи мають за собою серйозні витрати, і якщо ви не знаєте, що це за витрати, ви можете дуже легко кодувати алгоритм складності O (мій GD) у високоефективний центральний сервер файлів вашого потенційного роботодавця або головна сторінка цільового порталу наступного разу, коли їм може знадобитися налаштування. Звільнення вас після того, як ви це зробите, не скасує те, що ви зробили, але не найме вас, якщо вони думають, що ви це зробите, заважатиме. Отже, щоб уникнути цього, ви повинні довести їх неправильно; обговоріть, що ці методи роблять (маючи на увазі, що ви повинні знати себе) та їх складність, і як дійти відповіді в ефективний (NlogN або кращий) час.

Ще одна стурбованість - це добрий старий аргумент "Коли єдиним інструментом є молот". Поставте себе на місце, коли інтерв'юер взяв інтерв'ю у цього фаната Linq. Кандидату подобається Linq, хоче використовувати її, вважає, що це найкраще. Можливо, може здатися, що кандидат не міг кодувати без нього, оскільки кожна задана програма програмування вирішувалась з Linq. Ну що станеться, коли його не можна використовувати? Існує ще багато .NET 2.0 коду, що якби оновлення потребувало болісних оновлень до серверів, робочих станцій користувачів тощо, і т. Д., Все, щоб ви могли використовувати свої фантазійні методи розширення. Як інтерв'юер, я б спробував змусити вас показати, що ви можете кодувати ефективний сортування або використовувати методи сортування 2.0, якщо вам доведеться, як би я не погодився з вами, що бібліотеки Linq та подібні методи розширення досить гарні солодкий. Інтерв'юер, який не бачить сенсу, може навіть не турбуватися, намагаючись змусити вас проявити здібності до чогось іншого; вони припускають, що у вас цього немає, і рухаються далі.

Цей трохи довгий, але це може бути корисним комусь, тому я дозволю.

Я фактично зіткнувся з чимось подібним, пройшовши трохи більше 20 інтерв'ю минулого місяця (поєднання телефону та віч-на-віч). Напевно відбувалося щось несподіване, на що я не міг цілком покласти пальця.

Однією з речей, яку я помітив, було те, що речі, які зазвичай були центром циклів інтерв'ю протягом останніх п’яти-шести років, було вирішено не обговорюватись і не давати їм короткого скорочення. Такі речі, як основи аналізу / дизайну ООП, зразки (дизайнерські та архітектурні), деякі більш розвинені / орієнтовані на абстракцію особливості .net (включаючи лямбда або LINQ, зокрема, загальну інформацію, серіалізацію / прив'язку даних тощо) і навіть Зазвичай гаряча тема прихильної методології (здавалося, ніхто не переймається спритним проти водоспаду чи ароматом спритного) та інструментами чи вибором ORM чи бажаних засобів співпраці чи управління джерелами. У деяких випадках, які взагалі не згадуються, майже у всіх випадках, очевидно, це не викликає занепокоєння.

Що було приділено увазі в декількох інтерв'ю та різних непов'язаних фірмах у споріднених галузях, було таким чином:

• Дивна фіксація застарілих / застарілих конвенцій та обмежень "назад до кам'яних віків". Як розробляючи примітивний веб-додаток у VS2003 зі списком абсурдних обмежень, що додатково забороняє використання явних функцій в межах тієї епохи .net ... ніби це справжній показник здатності сучасних розробників ... можливість запам'ятати парадигма та обмеження 9 років тому ще більше покалічені нереальними / довільними обмеженнями. Ще одне місце було дуже зайняте темою колекцій на замовлення, навколо догенеральних колекцій. Ще одне місце викреслило зразок коду моделі класу, який я викреслив, оскільки не використовував каскадні конструктори (вони, здавалося, не знають про підтримку ініціалізації властивостей при декларуванні, що було достатньо для потреби).

• Надзвичайний фокус на конкретних деталях реалізації в настройках мікрокосму та / або конфігурації, навіть якщо це стосується технологій, орієнтованих на те, що вони є платформою або протоколом агностиком (тобто. Вся справа в тому, щоб НЕ фіксуватись на конкретній реалізації чи конкретному використанні, а навпаки про повторне використання / повторне призначення / розширення / за необхідності інтеграції).

• Готовність до розгляду / нагляду / огляду коду / та іншим способом відключення роботи від команди та від берега, а також навичок кодування, пов'язаних із цим.

• Використання конкретних версій продуктів / платформ / модулів / тощо. Іноді безглуздо; "Отже ... ви використовували версії 1, 2 і 4? Але не 3, е? Хммм ... {коментує ваше резюме з" без v3 !!!} ". Ступінь використання, здається, не має значення; тільки те , що у вас є або не використали що - то взагалі , а конкретна річ , яку вони просять також ... немає замін , здавалося порахувати, навіть більш широко використовується і повнофункціональний конкуруючого продукту.

• Набагато більше уваги на те, "наскільки добре ви будете вписуватися в нашу команду" більше ", чи ви насправді будь-який товар як розробник програмного забезпечення" або "чи маєте ви навички та досвід, щоб додати вартість компанії та допомогти нам забезпечити якість продукт "або навіть" ти небезпечний ідіот, який зайдеш і в крамниці крах ". У деяких випадках моє резюме просто сприймалося як дане, і навіть так званий "екран екрану" або технічне інтерв'ю було оцінкою особистості набагато більше, ніж оцінка вмінь. Навіть на відносно короткострокових контрактних посадах, де ви були б там і знову пішли до того, як змінилися два сезони.

• Компанії цього разу, здавалося, не зосередилися на вирішенні конкретних технічних проблем, запусканні нових проектів розвитку зеленого поля або великих 2.0, або отримання конкретного продукту на ринок, щоб скористатися новою тенденцією чи можливістю, або звичайними великими невдачами . Повторною темою, яку я помітив принаймні в 15 місцях, було те, що невелика група з 3-5 розробників, в основному тих, хто вижив після аварії на ринку в 08 році, змогла розмелювати продукт протягом останніх 3 років або близько того і вони знайшли певний успіх, або їхня компанія в цілому процвітає, і вони наймають нових людей, щоб не відставати від зростаючих вимог до функцій, або вирішити / подолати недоліки дизайну, вбудовані в ці системи, або взяти вищезазначені платформи безкоштовно створити основну команду, яка побудувала його для виконання "інших проектів".

Але ... якщо є одне, що я знаю про цю справу, це те, що це циклічно. Наступного разу, коли я шукаю новий концерт, я не здивуюся, якщо гра змінилася ще раз. Вам просто потрібно залишатись розумово гнучкими, робити активне слухання, уникати абсолютних заяв, якщо вони непотрібні, але також не будьте нікчемними, і не виходьте як одновимірні (ви як ідіот або завзяття, не бажаного) або як занадто хороший (це може загрожувати і коштувати вам концерту).

Просто налаштуйте свій підхід і спробуйте дати більш зважну відповідь наступного разу ... згадайте кілька різних способів, як ви можете підійти до проблеми ... але навіть якщо це знання про вас, ви поводитесь так, ніби ви насправді думаєте про це і міркуючи це на місці. Це здається більш скромним і менш залякуючим або зневажливим таким чином.

Звичайно, закон Мерфі, який він є, саме наступне інтерв'ю після того, як ти перестанеш бути "захопленим моїм улюбленим моїм улюбленим хлопцем з технологій" і приймеш більш врівноважену / погладжує бороду позицію, - це те почуття, яке б ти отримав, якби ти був божевільним ревний хлопець. ;)

Я думаю, ви робите помилковий висновок, оскільки ваш набір зразків занадто обмежений. Хоча я бачив неабияку частку ІТ-магазинів із сильною відразою до чого-небудь "не винайденого там" ¹ , жоден із них не дискваліфікував кандидатів, виходячи зі своїх переваг у стеку технологій: вони були справедливо переконані, що можуть навчити правильного кандидата використовувати їхні домашні бібліотеки.

Я серйозно сумніваюся, що компанія заборонила використовувати LINQ прямо. Швидше за все, вони хотіли, щоб ви продемонстрували їм свої навички на більш глибокому рівні.

Наприклад, один із способів з'ясувати, чи знаєте ви свої хеш-таблиці, - це попросити запровадити примітивну на дошці. Ця проста вправа розглядає рецензента дивовижну кількість даних про ваші знання: він миттєво дізнається, чи знаєте ви хеш-код / ​​рівність і що ви знаєте про хеш-зіткнення. У той же час, важко уявити, щоб хтось із розуму повторно реалізував хеш-таблицю, тому що Microsoft зробив цю роботу дуже добре. Те ж саме стосується багатьох алгоритмів, таких як сортування та пошук: інтерв'юерам часто хотілося б дізнатися, чи достатньо твого досвіду для розуміння взаємодій на низькому рівні, а не перевіряти, чи володіє ти знаннями бібліотек .NET.

Це майже впевненість, що вони будуть наполягати на використанні бібліотечних реалізацій, а не власних, коли вас найнять працювати у їхній компанії. Але під час інтерв'ю вони підштовхнуть вас до коду низького рівня, щоб краще зрозуміти свої справжні здібності.

Я думаю, ви робите там кілька шалених узагальнень типу "Я побачив чорну корову в Шотландії, тому всі шотландські корови чорні".

Якби я взяв інтерв'ю з вами, я був би розчарований, якби ви не змогли відповісти на мої linq питання.

Хоча Linq є хитрою, але багато людей сприймають це як вуду, що несправедливо, оскільки насправді це дуже просто і тим більше розумно.

Для того, щоб грати в захисника диявола, причина в тому, що багато розробників просто не переймаються новими речами і вважають, що все має бути вирішено за допомогою домашніх (зазвичай неповноцінних) інструментів. У використанні абстракцій немає нічого поганого. Чорт, зазвичай немає вагомих причин не використовувати ці абстракції.

Це здається, що ви щойно взяли інтерв'ю у бідного розробника, який не в курсі речей і застосовує молот і цвяхи до всього. Це типи розробників, які нічого не знають про корисні інструменти з відкритим кодом, такі як NUnit, NHibernate чи різні контейнери IoC; ті, хто намагається вирішити кожну проблему з масовим зберігається процесом у базі даних; ті, хто абсолютно нічого не знає про MVC, незважаючи на те, що він вже кілька років.