Очищайте код, с которым вы работаете каждый день, проявляя бдительность.
Мы создаем программное обеспечение на основе нашего текущего понимания проблемы, требований и технологий. Инженеры-программисты все (на данный момент) люди, а это означает, что мы делаем ошибки. Это приводит к пропущенным ошибкам и запахам кода. Даже небольшие беспорядки со временем накапливаются, оставляя огромный запутанный код. Если вы не будете активно работать над поддержанием чистоты своей кодовой базы, вы получите неряшливую и сложную в обслуживании систему.
Это то, что известно как гниение кода.
Поскольку кодовая база меняется с каждой новой функцией или рефакторингом, это может привести к неиспользуемому коду, пропущенным предупреждающим сообщениям и тесно связанному коду. Добавление к трудоемкому беспорядку, чтобы понять или изменить. Мы пытаемся решить все, но сроки складываются, а технический долг переносится на бизнес-цели. Итак, как нам опередить этот беспорядок и защитить нашу кодовую базу от гниения?
1. Правило 20%
Правило 20% для работы с техническим долгом. Выделите время в своем спринте на устранение технического долга.
В кодовой базе идет война, борьба между выкачиванием функций или устранением технического долга. Может быть трудно убедить вашего менеджера по продукту в том, что решение проблемы технического долга может принести пользу команде и повысить производительность, но кодовый стержень реален и будет распространяться, если его не решить.
Часто трудно заметить, что у вас есть технический долг, поскольку все больше рук погружается в кодовую базу. Мы можем отслеживать только определенное количество запросов на вытягивание, и даже если мы это делаем, остаются незамеченные побочные эффекты, которые вызывают ошибки консоли, неиспользуемый код или ошибки, на выявление которых могут уйти месяцы.
Как только мы решим, что гниение кода реально, мы должны выяснить, как убрать его из нашей системы. Это можно сделать несколькими способами, и в зависимости от того, кому принадлежит продукт, у вас может возникнуть больше проблем с его выполнением, чем у других.
В Google есть правило 20%, которое позволяет вам тратить 20% своего времени на то, что приносит пользу компании помимо обычной работы над продуктом. Это правило показывает, что они ценят автономию сотрудников, чтобы они выполняли работу над чем-то, что их интересует и в то же время помогает компании.
Это правило, которое вы можете применить к своей кодовой базе, чтобы выделить определенное количество времени в течение дня для устранения технического долга или гниения кода. К ним относятся небольшие рефакторинги, избавление вашего приложения от предупреждений или сообщений об ошибках или даже добавление модульных тестов. Цель — маленькие победы, которые сделают ваше приложение здоровым, а ваша команда будет гордиться тем, что у вас есть.
Я слышал, как некоторые из вас спрашивают, что делать, если мой менеджер или владелец продукта не хочет расставлять приоритеты для этих задач. Что ж, это ваша работа как инженера — донести, насколько важна чистая и хорошо поддерживаемая кодовая база. Если вы не можете справиться с техническим долгом, это будет мешать команде выполнять работу над функциями и сдвигать сроки проекта, потому что труднее вносить простые изменения.
В одной из моих команд у нас было соглашение о выделении 20% очков истории на технический долг (предметы, не связанные с продуктом). Пока у нас были помеченные и отмеченные билеты, мы могли использовать их в нашем спринте для решения задач, к которым мы хотим добраться. Это позволяет нам поддерживать чистоту нашего приложения, инфраструктуру или даже инструменты разработчика.
20% это идея.
Возможно, 20 % — это слишком много, а 10 % — это все, что вам нужно для вашего приложения. Идея состоит в том, что вы и ваша команда уделяете приоритетное внимание работоспособности вашего приложения, чтобы вы могли легко кодировать, не отвлекаясь на технические проблемы.
2. Определите их до того, как они объединятся
Это сложнее реализовать, так как вам нужно будет определить способы предотвращения проникновения гниения кода в кодовую базу, но это сэкономит время в будущем.
Однажды я был в команде, где у нас постоянно возникали проблемы с ошибками консоли и накоплением предупреждений. Я говорю о десятках безобидных предупреждений и потенциально проблемных ошибок, постоянно поступающих в приложение. Это усложняло разработку, так как было трудно определить, являются ли эти ошибки «ожидаемыми», поскольку они уже есть в кодовой базе.
В результате команда собралась вместе, чтобы выявить проблему и попытаться ее исправить. Теперь в рамках нашего процесса обеспечения качества мы добавили проверку консоли, чтобы предотвратить попадание ошибок и предупреждений в приложение.
Это, конечно, ручной процесс, и каждый раз, когда мы можем что-то автоматизировать, мы экономим время и добавляем уровень согласованности в проверку.
Интеграционные тесты — отличный способ предотвратить попадание ошибок и других проблем в базу кода. Запускайте их на каждом PR, чтобы предотвратить их слияние.
еще одним примером превентивных мер является линтинг.
Линтеры — наиболее распространенный способ предотвратить попадание определенных запахов кода в вашу систему. Eslint для javascript, autopep8 для python и практически каждый язык имеет встроенные или сторонние пакеты для линтинга, которые можно адаптировать к рекомендациям и стилю кода команды. Это требование предотвращает слияние простых запахов кода.
3. Правило бойскаута
«Всегда проверяйте модуль чище, чем когда вы его извлекали» — Роберт Мартин (дядя Боб)
Дядя Боб, автор книги «Чистый код», провел аналогию с правилом бойскаутов: всегда оставлять кемпинг чище, чем вы его нашли. Он предлагает применить это к вашей кодовой базе как упреждающий способ борьбы с гниением кода.
По мере реализации функций вы, несомненно, столкнетесь с проблемами, которые следует исправить.
Мы должны искать изменения, которые были упущены, обычно это документация.
JSDoc — это удобный способ добавить информацию о функции, чтобы дать больше контекста входным и возвращаемым значениям. Но это может быстро устареть, поскольку оно изменено.
Даже если вы не изменяете параметры функции, исправление опечатки или неправильного значения поможет будущим разработчикам, которые хотят понять, что происходит.
Это имеет свои ограничения.
Когда мы очищаем кодовую базу, мы должны сбалансировать работу над функциями с очисткой. Если будет слишком много несвязанных изменений, вашим рецензентам будет трудно понять, что происходит, и это приведет к более длительному процессу рецензирования и путанице.
По моему личному опыту, если изменения в очистке разрастаются настолько, что запутывают цель PR, то их следует разделить между работой над функциями и очисткой кемпинга.
Вы владелец
Ваша работа как инженера заключается в решении бизнес-задач. Это означает, что если вы хотите добиться успеха, вам нужно сделать его устойчивым, выстраивая процессы и планируя, как достичь этих целей снова и снова. Мы хотим, чтобы наша кодовая база была чистой и простой в обслуживании, чтобы вы могли работать на уровне, ожидаемом вашей компанией.
