вторник, 25 января 2011 г.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

4 комментария:

имя комментирует...

> Тем, что человек стремиться определить для себя более-менее формальные критерии, по которым его будут оценивать и которым он должен будет соответствовать.

это если про соискателя

а я это делаю совсем не для этого

я это делаю, чтобы формализовать свои эстетические представления, точно так же, как например кто-то может формализовать свои потребности в еде "мне нужен хороший ланч, фактический второй обед" или "мне не нужен ланч, в крайнем случае выпью чай с бутербродом" -- но это не значит, что он ей << должен будет соответствовать >> или применять ее для оценки его окружающими

впрочем, для само-оценки "не много ли я в последнее время ем" ее применять может и можно

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

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

имя комментирует...

> при этом, однако, обязательно надо учитывать влияние языка программирование на эти представления

я выразился слишком политкорректно

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

имя комментирует...

ну и очевидно, что полезно было бы найти общий знаментаель у всех этих эстетических представлений, почему я на ЛОРе и спрашивал "а как тебе такой вариант..."

eao197 комментирует...

@имя:

С эстетическими оценками сложно.

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

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

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

В-четвертых, (наверное, это причина для в-третьих) у каждого очень разный опыт. Для человека с 10 годами hard-real time проектов на C best practicies из какого-нибуд корпоративного энтерпрайза могут быть очень странными и неприемлимыми. И наоборот.

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

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