Телеграм канал «Developer's mind»

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

И тут вспомнилась мне цитата Бенджамина Франклина про размен свободы на безопасность.

И вот что я хочу сказать:

Когда мы отказываемся от качества кода ради функциональности, в итоге теряем и качество, и функциональность.

Но куда уж мне выходцу из стартапов тягаться с тяжеловесами из яндекса ;D придется, видимо, пропустить такое в ревью 😞

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

Обычно это делается из благих намерений: вовлечь всех в процесс, дать высказаться, «у нас демократия». Но на практике в таких обсуждениях чаще рождается не самое изящное и подходящее решение, а социальный компромисс. Причём компромиссы здесь не технические, а скорее зависящие от того, кто успел убедить остальных в рамках короткого обсуждения.

Я несколько раз наблюдал, как в попытке учесть все мнения разработчик в итоге реализовывал решение, которое аккумулировало минусы разных подходов. Единственный явный плюс — «учли позицию каждого». С точки зрения архитектуры или долгосрочной поддержки это не всегда было выигрышем.

Проблема, на мой взгляд, не в обсуждении как таковом, а в отсутствии явной ответственности за итоговое решение. Когда решение принимается коллективно, сложно определить, кто отвечает за его качество и последствия.

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

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

Обсуждение полезно. Но ответственность за дизайн решения должна быть персональной. Это то самое ownership-ство.

Дизайнер у дизайна должен быть один.