Comments 6
Отличная статья! Спасибо за выжимку опыта.
Как это классно, когда рукль несёт в себе такие ценности и делиться ими со своими сотрудниками.
Вот по большей части я и стал тем, кто я есть в профессиональном смысле, благодаря одному из первых мест работы, где я оказался.
Рукль почти с порога мне и ещё нескольким ребятам, кто устроился примерно тогда же, подготовил презентацию, где доходчиво погрузил в coupling, cohesion, viscosity, rigidity, fragility, immobility и прочее.
Вся компания жила в духе победившего Agile, жили опен-спейсом, за соседними столами на пару за клавой.
Всё ещё немного тешу себя надеждой, что найду когда-нибудь подобную компанию с тем же духом в моём родном городе (вот забавно было бы, если бы вы оказались в НН)!
P.S. тоже вырос на Фаулере. Я б далее сказал уже давно его перерос, а рефакторинг настолько сильно вошёл в мой инструментарий, что у меня ощущение, что 80% времени я занимаюсь рефакторингом, а 20% - остальным. При этом это не вместо, а дополнительно :) Фактическая продуктивность x5, видимая снаружи x1, но качество и поддерживаемость кода - (неизмеримо) потрясная!
А главное courage: почти любой код становится подвластен, неважно какое legacy :)
Сколько тестов вы написали для этой фичи? Покрытие выше 80%?" Этот вопрос скорее не про контроль, а про то, чтобы разработчики сами задумались: а как проверить, что это работает? А что будет, если завтра кто-то изменит этот код?
Зачем? Если автоматическая проверка легко встраивается в пайплайн CI/CD и систему контроля версий?
Когда последний раз вы рефакторили этот модуль? Он не стал сложнее за последний год?" Вопрос про технический долг. Он накапливается незаметно. Один раз не почистили, второй, третий. И вот уже модуль превратился в лабиринт, в котором страшно что-то менять.
А кто включил задачу на рефакторинг в бэклог и обозначил приоритет для команды разработки?
Если завтра ты уйдешь в отпуск, кто сможет поддержать этот код?" Вопрос про знание кодовой базы. Если код понятен только одному человеку, это риск для компании. Знания должны распределяться.
«Код понятен» и «знание кодовой базы» — это не одно и тоже. Ожидать, что разработчик будет «наизусть» знать кодовую базу среднего по размеру проекта как-то наивно даже.
Новичок придет через месяц. Как он поймет, что делает этот модуль? Где документация?" Вопрос про долгосрочность. Код живет годами. Люди, которые его писали, могут уйти. Но код останется. И кто-то должен его понять.
Зачем, если с документацией к коду уже неплохо справляются автоинструменты?
Пока статья больше из серии «Делай хорошо и будет хорошо». Ни слова о прибыли для собственников, дедлайнах, межличностных отношениях в коллективе, «перетягивания одеяла».. Всё красиво — как по книжкам, а по факту — поверхностный взгляд на чудесную организацию в идеальных условиях
От Фаулера до продакшена: как в небольшой компании выращивают качественный код