Сферическое программирование в вакууме
Sep. 12th, 2008 09:15 amИтак, тезис первый.
Программист - не дятел, который если не долбит, то он умер. И программировать в нерабочее время может, но не обязан. Особенно если в рабочее ему программировать хватает. Я могу предъявить сколько-то скриптов, написанных для автоматизации задач жены, но это - скорее случайность.
Тезис второй.
Не все OpenSource-проекты одинаково полезны. При попытках отправить патч в различные я наблюдал 4 позиции
1. Принять патч после переписки. Самая простая и понятная.
2. Принять патч к сведению, через какое-то время выпустить новую версию, в котором интерфейс, предложенный в патче, будет переименован нафиг.
3. Не принимать патч, но реализовать свой, дающий тот же функционал. Патч в этом случае используется как ТЗ/основа для ТЗ.
4. Разработчик в гибернации, на патчи не реагирует.
Желающие сами могут сделать вывод о продуктивности посылки патча.
Тезис третий, главный.
От программиста на работе требуется писать поддерживаемый код. Потому что времена солистов, к счастью, прошли. Поэтому вопросы на собеседованиях "Что означает это выражение - переменную или функцию" для меня имеют один однозначный ответ: "Автора этой строчки надо уволить нафиг". Да, и к большинству нестандартных и к половине высокоуровневых идиом это тоже относится - код, написанный человеком, перечитавшим Александреску, в отличие от кода человека, остановившегося на Саттере или Мейерсе, скорее всего к поддержке непригоден.
А от веб-программистов разумно требовать хотя бы структуру нижележащей базы. Потому как из этого можно понять степень ясности мышления.
Давай разберемся со шляпами
Date: 2008-09-12 06:46 am (UTC)Первый тезис - с позиции условно-абстрактной. Да, у нанимаемого она такой может быть. Вообще жизнь больше работы, и для вас с Раном это тоже так, иначе бы спорить с вами было бы бессмысленно.
Второй - он в тезисы попал зря. Это иллюстрация к соотношению жизни и модели.
А третий тезис - он с точки зрения что программиста-коллеги, что руководителя. Собственно, ради него все и написано.
Всегда должен быть человек, который закроет дырку в коде. А дырка там есть с вероятностью 1, просто туда еще никто не проваливался, или текущий владелец кода ее затыкает быстро.
Я согласен с тем, что брать надо программиста не ниже какого-то уровня. Так вот, уровень определяется умением писать поддерживаемый код. С низким порогом вхождения в оный код. С понятными архитектурными концепциями, в частности.
А теперь прикинь сам - какой объем кода надо для этого представить и проанализировать. А отсеять можно проще - предъявив кусок кода на разбор и объяснение.
Re: Давай разберемся со шляпами
Date: 2008-09-12 07:38 am (UTC)Поэтому и есть соблазн самому не возиться с анализом представленного кода. А воспользоваться результатами работы других людей. Если какая-то опенсурсная команда приняла от этого человека код, значит есть подозрение, что они сочли его поддерживаемым.
Re: Давай разберемся со шляпами
Date: 2008-09-12 07:53 am (UTC)