[prog; work] В продолжение и вчерашней темы, и темы тестовых заданий до собеседования

Вчера я позволил себе высказать оценку чужого кода и предложил собственную реализацию. Чем вызвал бурную реакцию автора оригинального фрагмента. Это заставило меня вспомнить об очень неоднозначной теме тестовых заданий, выдаваемых соискателям до собеседований.

Когда я описывал причины, побуждающие меня давать тестовые задания, то среди прочих я указывал такую: умеет ли человек критически относиться к написанному им коду. И вот последовавшее на LOR-е обсуждение моего рефакторинга отлично продемонстрировало, зачем я это делаю.

Если вы предъявляете претензии к чужому коду (речь идет об обсуждении тестовых заданий на собеседованиях), то вам необходимо указать, что именно вам не нравится и почему. Еще лучше, если вы сможете показать свой, исправленный вариант. Но, в любом случае, реакция собеседника будет либо адекватной (при этом не обязательно лояльной к вам), либо нет.

В состоявшемся флейме на LOR-е можно найти примеры и того, и другого.

Вот пример нормальной реакции, которая, однако, вам может и не понравится:

Знаешь, мне совершенно не нравится твой код. Я и сам люблю писать длинные паттерн-матчинги с большим количеством гардов и всегда предпочитаю локальные функции отдельным методам. А количество методов стараюсь всегда минимизировать. Так получается лаконичнее, декларативнее и понятнее на мой частный взгляд. И мне кажется, что Ф.П. провоцирует писать код именно в таком стиле.

Понятно, что человек не разделяет моего взгляда на оформление кода и у него есть свое мнение на этот счет. Не понятно, сможем ли мы договориться до чего-нибудь или нет, но пробовать можно и нужно.

Еще один пример нормальной реакции. Хотя этот случай сложнее, но и перспективнее предыдущего. Часть первая:

а по-моему ты сильно перебрал с количеством функций

я бы максимум согласился на дополнительные функции doAncientLogin (альтернативное название doPetrivkaLogin) и doModernLogin; опять же вполне нормальным были бы не эти функции, а просто строки комментариев перед их началом

Часть вторая:

твой стиль напоминает канцелярский слог, которых прокатывает в простых случаях, но невыносим в сложных

"с целью предотвращения случаев успешных террористстических актов, ..." нормальный человек сократит до "чтобы не было террактов, ..."

Чем сложнее этот случай? Тем, что человек стремиться определить для себя более-менее формальные критерии, по которым его будут оценивать и которым он должен будет соответствовать. А это не просто, т.е. далеко не всегда оказывается возможно в двух словах выразить свои собственные привычки и, по большому счету, эстетические взгляды.

А перспективнее данный случай тем, что в процессе могут быть сформированы более менее четкие правила, вроде вот таких (предупреждаю, что это только пример, с которым я далеко не согласен):

1. комментарии в виде названий переменных -- нормально, хотя и малость говорливо

2. комментарии в виде названий функций -- неприемлемо

3. функция должна выделяться тогда, когда цель (или инвариант) функции достаточно далека от средства ее достижения

Это были примеры адекватных реакций. Повторюсь, что далеко не факт, что соискатель согласиться с вашей критикой и примет вашу точку зрения. Однако, у вас будут большие шансы оценить степень конструктивности спора с потенциальным коллегой.

А могут (и обязательно будут) и неадекватные реакции. Вроде вот такой. За которой последует многочасовый бесплодный спор о том, что такое сайд-эффекты, откуда они взялись и куда пропали.

Не важно, чем этот спор закончится и кто в нем победит (что вряд ли). Наверняка будут неправы оба. Важен сам факт такого спора. Если человек с пеной у рта защищает свой код и пытается опустить ваш, значит тоже самое будет происходить и в будущем. И вы не сможете договориться.

Еще раз повторюсь. В процессе жаркого спора вы будете неправы оба. Никто не пишет совершенного кода, в любом коде есть проблемы и любой код можно улучшить. Поэтому сам факт жаркого спора говорит о том, что обе стороны не желают признавать недостатки собственных решений.

Однако, только в форумном флейме каждый собеседник может считать себя правым и до бесконечности отстаивать собственную точку зрения. На собеседовании ситуация чуть иная. Поскольку there are many ways to skin a cat, то встает вопрос о том, какой из ways будет считаться более предпочтительным в данной конкретной организации. И здесь ситуация как в спорте – судья может и ошибаться, но он судья и его решения неоспоримы на поле. Если соискатель не понимает этого и все равно будет защищать собственное решение не смотря на ваши доводы, то это просто показатель того, что правила игры он не будет соблюдать и в будущем.

Впрочем, соискатель также должен делать свои выводы. Если он видит, что его доводы отвергаются без разумных на то оснований, то он может сделать выводы о том, что же его ждет дальше. И нужна ли ему эта конкретная компания.

Напоследок подчеркну еще один момент. Тестовые задания требуют много сил от тех, кто их выдает и оценивает. Вам нужно будет серьезно подготовиться, чтобы найти объективные недостатки кода. Чтобы ваши претензии и ваши предложения были обоснованны, технически грамотны и корректно поданы. Называть вещи своими именами Обзывать код соискателя говнокодом не нужно, даже если это так :) Все-таки, собеседование – это не праздный флейм в профильном форуме.