Как исправить «битые окна» и сохранить блестящий код
Некачественный код - подлый враг. Выглядит как таковой не вредно. Плохо написанные программы могут соответствовать требованиям. Их просто чертовски сложно отлаживать и поддерживать, вот в чем проблема.
Некоторая динамика делает его еще более рискованным и может стать источником других проблем. Чтобы свести к минимуму такой риск, необходимо разумно контролировать качество кода и технический долг и управлять ими.
Теория разбитых окон
« Теория разбитых окон - это криминологическая теория, которая утверждает, что видимые признаки преступности, антиобщественного поведения и гражданских беспорядков создают городскую среду, которая способствует дальнейшим преступлениям и беспорядкам, включая серьезные преступления» ( источник Википедия)
Но что связывает криминологию и разработку программного обеспечения? Вот и все, такая же динамика имеет место в командном программировании. Если вы опытный разработчик, возможно, вы уже сталкивались с этим. Конечно, никакого преступления здесь нет. Имея дело с некачественным кодом, кому-то может казаться, что он может себе позволить. «Ой, да ладно, у этого компонента действительно дрянное покрытие, действительно ли нам нужно покрывать этот кусок кода?» они говорят; или «Этот класс настолько плох, мы можем просто выложить этот код как есть, а позже мы его реорганизуем». Эти позиции понятны, но весьма нелогичны.
Кодовая база может быть не такой уж и хорошей. Но это правильная мотивация, чтобы не баловаться и как можно больше сдерживать проблему. Там, где качество кода низкое, есть лучшее место, где можно проявить внимание и сосредоточиться, приложить усилия.
Временный код, сохраняющийся навсегда
Низкокачественный код - это серьезная основа для проведения анализа рентабельности. Вроде проблем нет. Приложение работает, критерии приемки выполнены, спецификации выполнены, результаты получены. Так что, видимо, не во что вкладывать, не во что приносить выгоду. Но это быстрая и грязная оценка, и в большинстве случаев она неверна: сказывается низкое качество. Приведу несколько примеров: ремонтопригодность, усилия по дальнейшему развитию или исправление ошибок. Может быть место для инвестиций. Если инженерам нужно на 30% больше времени из-за спагетти-кода, вы можете провести его рефакторинг.
Чтобы подчеркнуть, качественное разрешение долга имеет долгосрочные или среднесрочные эффекты. Остерегайтесь учитывать это при оценке пользы от вмешательств по рефакторингу. Эффективность тоже имеет значение. Охват тестированием может быть намного важнее гармонизации структуры. Вероятность неожиданного поведения намного выше, если кодовая база имеет недостаточный охват. Эта чистая выгода замечательна. Рефакторинг ради единообразия имеет более низкий приоритет.
Дополнительный код и братья и сестры
Иногда случается, что умелым и желающим разработчикам приходится вмешиваться в некачественный исходный код. Желая уважать стандарты качества кода, они переживают тяжелые времена. Они видят так много кода для рефакторинга, что вскоре понимают, что не уложатся в срок, если будут работать над этим. Представьте себе целый класс обслуживания, имеющий дюжину методов. Никаких исключений не генерировалось / не перехватывалось, но возвращалось целое число как статус успеха / ошибки. Что делать?
В большинстве случаев выбор заключается в том, чтобы отказаться от неприятного кода. Но вместо того, чтобы реорганизовать тонны строк, они параллельно программируют параллельный код. Звучит хорошо, не работает. Это избавляет часть кода от чумы и «зараженного кода». Затраты на запутанную и сложную в обслуживании структуру проекта.
Побочный код и его братья и сестры, по-видимому, являются быстрым решением, позволяющим избежать роста плохого кода, но это не долгосрочное решение. Только хороший (широкий?) Рефакторинг, убирающий некачественный код, может решить проблемы.
Укрощение низкокачественной дегенерации
Теперь ясно, что разбитые окна не исчезнут и не починятся сами собой. Некачественный код необходимо предотвращать, сдерживать и исправлять.
Рекомендации по кодированию
Главное - определить, что такое плохой код. Вскоре концепции могут стать мнениями. Антишаблоны, неправильное именование классов, громоздкая структура проекта: все может стать нечетким. Руководящие принципы предназначены для определения того, что хорошо, а что плохо.
Помните, что это постепенный процесс. Так что будьте готовы интегрировать их и изменять при необходимости. Они представляют позицию всей команды. Если команда передумает, правила должны измениться, а не наоборот. Тем не менее, они должны быть стабильными: они не могут меняться каждую неделю или около того.
Определение правил на основе семантики полезно для многих контекстов, но не только для синтаксиса и «эстетики». В рекомендациях следует уделять больше внимания семантике. Имена методов и классов, а не скобки и символы новой строки.
Существует множество примеров и общедоступных руководств, которые вы можете принять и настроить. Лично я предлагаю всегда проверять https://google.github.io/styleguide/, где (почти наверняка) вы найдете стиль Google для вашего любимого языка.
Инструменты анализа исходного кода
Автоматические инструменты действительно являются идеальным способом унифицировать форму кода. Они предотвращают все те недобросовестные действия, которые могут быть обнаружены машиной. Они не вникают в семантику, они стремятся к дублированию кода и всем этим проблемам с голым кодом, ведущим к ошибкам. Возможно, название инструмента изменится с одного языка на другой, но наверняка их много.
Что касается Checkstyle, вы можете применять статические правила в своей среде IDE или в конвейере CI. Кроме того, некоторые из приведенных выше рекомендаций представлены в версиях XML. Эти файлы можно использовать для обучения вашей IDE автоматической проверке (и даже исправлению) кода по мере ввода. Дополнительная информация:
https://checkstyle.sourceforge.io/
https://plugins.jetbrains.com/plugin/1065-checkstyle-idea
https : //checkstyle.org/eclipse-cs/#! /
Если вместо этого вас интересует конкретный инструмент для выявления проблем, существует очень хороший список от OWASP Foundation:
https://owasp.org/www-community/Source_Code_Analysis_Tools
Он сообщает почти сотня инструментов для разных языков и с разными целями. Не забудьте также список Википедии для статического анализа кода:
https://en.wikipedia.org/wiki/List_of_tools_for_static_code_analysis
Запросы на вытягивание и проверка кода
Ничто не заменит человеческий мозг. Действительно, кодирование инструктирует машину, что-то неорганическое. Тем не менее, помимо исходного кода, существует множество семантики и аргументов. Настолько, что ничто не может заменить мнение третьего лица. Кто может определить, соответствует ли имя, данное классу, его роли?
Code Review - это момент (связанный с интеграцией нового кода через pull request), когда разработчики помогают каждому, улучшая код. Авторы и рецензенты вместе анализируют код. Следуя рекомендациям Google Code Review:
При проверке кода следует учитывать:
Дизайн: хорошо ли разработан и подходит ли код вашей системе?
Функциональность: ведет ли код как автор скорее всего рассчитывал? Удобно ли поведение кода для пользователей?
Сложность. Можно ли сделать код проще? Сможет ли другой разработчик легко понять и использовать этот код, когда он столкнется с ним в будущем?
Тесты: есть ли в коде правильные и хорошо продуманные автоматизированные тесты?
Именование: выбрал ли разработчик четкие имена для переменных, классов, методов и т. д.?
Комментарии: насколько понятны и полезны комментарии?
Style: соответствует ли код нашим руководствам по стилю?
Документация: обновил ли разработчик соответствующую документацию?
Даже если противостояние друг другу в коде может вызвать разочарование и споры, всегда помните, что нет правильного или неправильного. Вы вместе пытаетесь создать лучший код.
Еще раз, если вы хотите углубить тему, ничего лучше, чем опыт большой G: https://google.github.io/eng-practices/review/
Вывод
Низкокачественный код является проблемой не только для удобства сопровождения, он также имеет тенденцию распространяться по кодовой базе и способствует созданию параллельного «хорошего» программного обеспечения. Об этих двух побочных эффектах следует очень внимательно относиться, поскольку они приводят к эпилогу «давайте перепишем с нуля».
Используйте автоматические инструменты, определите набор руководящих принципов и используйте PR для мониторинга исходного кода. Имейте в виду, что это не раздражающие обязанности, а скорее защита от изнурительной отладки, громоздкой интеграции и т. Д.
