Онанизм на код ревьюВ ит любят поднимать тему карго-культов, но забывают упомянуть главный обитель. Наши пулл-реквесты.
Разворачивая тему приоритетов с прошлого поста хочется поделиться наблюдениями, когда проблема бездумного следования стайлгайду становятся системной.
Одно дело, когда это литкод. Куда страшнее, если погоня за косметикой и соответствие стайлгайду становится первостепенной в продакшене больших компаний. Спойлер. Стайлгайд необходим, но споры о соответствии должны быть в умеренных дозах.
Хороший код — это не косметика, читабельность, соответствие линтер правилам.
Хороший код — быстрый, стабильный и поддерживаемый. В последнюю очередь это про правила линтера
У нас есть заблуждение, подкормленное отделами техпиара, что в больших компаниях делают все правильно.
Не редкость, когда именно там, где нет никого кто может возразить, делается дичь. Культура компетенций нарушена. Ориентиры сбиты.
Люди тратят время на споры о важности чтения, жертвуя стабильностью, быстротой и гибкостью программы. Сроками и деньгами. Говоря о той далекой выгоде в будущем, о которой пишут в книгах. Сомнительная метрика.
Код ревью становится бюрократией стайлгайда, которая только вредит, а не дает пользу.
Никому не будет плохо от лишнего пробела, неочевидного нэйминга, переноса аргумента, неприватных методов.
Совершенный код — миф. На моей практике я видел только пару программистов, кто был доволен чужим кодом. Сотни нет. Единственный вариант его написать — это рефакторинг или TDD. Хорошие процессы и бизнес идеи приводят к хорошему коду на проде.
Ведь если твоя задача нужна коллегам для закрытия показателей или бизнес импакта, то я считаю эгоистичным сидеть и дрочить читабельность.
Нет, я не говорю выкинуть стайлгайд. Он нужен как общий ориентир. Но если выбирать между сложной и срочной задачей и спорами на ревью, то последний пункт можно принести в жертву.
Задача программиста решать задачу. А потом учиться решать ее красиво
