Как инженеры-лидеры могут расставить приоритеты по качеству кода
1 марта 2023 г.Технологии развиваются быстро. По мере приближения крайних сроков может возникнуть соблазн написать код как можно быстрее, чтобы получить его как можно быстрее.
Но быстро и хорошо не всегда тождественны. И что еще хуже, там, где есть неработающий код, есть болван, который рефакторит грязный код своих предшественников и имеет дело с горой технического долга. И никто не хочет, чтобы это был ты.
К счастью, ведущие инженеры могут устанавливать стандарты, отдавая приоритет показателям качества и работоспособности кода.
В этой статье я расскажу…
- Почему важно качество кода
- Самые важные показатели качества кода
- Как решать проблемы с качеством кода
Почему важно качество кода
Качество кода имеет решающее значение для разработки программного обеспечения, поскольку оно определяет, насколько хорошо кодовая база функционирует, масштабируется и поддерживается с течением времени.
Качественный код гарантирует стабильность, безопасность и эффективность программного обеспечения.
С другой стороны, некачественный код может привести к ошибкам, уязвимостям в системе безопасности, проблемам с производительностью и масштабируемостью.
Качество кода влияет на объем технического долга, который со временем накапливается.
Технический долг относится к затратам на поддержание кодовой базы, разработанной с использованием неоптимальных методов или сокращений. Со временем он накапливается, и если его не остановить, это может затруднить или сделать невозможным поддержку или улучшение кодовой базы без значительных усилий или затрат.
Из-за сроков, бюджетов и других ограничений разработчики часто вынуждены идти на компромисс между качеством и скоростью, и накопление технического долга неизбежно.
Однако необдуманное накопление технического долга может увеличить риск появления ошибок и уязвимостей в системе безопасности, затруднить добавление функций, замедлить разработку и даже в крайних случаях потребовать полного переписывания кодовой базы.
Но как нам добраться до этого места? Ни одна метрика или точка фокусировки не могут полностью отразить качество кода. Скорее это совместные усилия, которые помогают создавать и поддерживать здоровую кодовую базу. Вот некоторые из важнейших показателей, которым необходимо уделить приоритетное внимание:
Отмена кода
Давайте будем ясны. Смена кода — нормальная часть процесса разработки. Но объем оттока кода также помогает вам измерить эффективность и производительность вашей команды разработчиков. Если большую часть времени разработчик тратит на написание и переписывание одних и тех же фрагментов кода, это может свидетельствовать о двух вещах:
- Проблемный код тестируется, обрабатывается и уточняется. Это хорошо, особенно когда имеешь дело со сложной проблемой или задачей, требующей регулярной доработки в рамках эволюционного процесса. Время, потраченное на обучение, которое приводит к победе, всегда потрачено с пользой. Изменение кода в ответ на отзывы клиентов является плюсом.
-
Есть большая проблема. Отток кода, согласованность которого приводит к низкой производительности, может быть признаком:
-
Плохая практика программирования
- Отсутствие опыта или навыков самостоятельного редактирования.
- Низкий моральный дух или выгорание
- Внешние проблемы, такие как постоянно меняющиеся требования со стороны других отделов или внешних заинтересованных сторон. (Да, именно поэтому они платят вам большие деньги).
Здесь мы подробно рассмотрели отмену кода.
Помимо регулярного обсуждения с вашей командой процесса и регулярных проверок кода, вы также можете измерять отток кода с помощью различных инструментов, таких как:
Соглашения о написании кода
В большинстве компаний у отделов маркетинга и редакционных отделов есть руководство по стилю, живой документ, в котором излагаются правила для письменного контента — подумайте обо всем, от грамматики до того, что вы пишете: 1 миллион или 1 миллион.
Команды разработчиков также должны иметь соглашения о написании кода — они могут относиться к конкретным проектам или ко всей команде.
В конце концов, код также предназначен для межличностного общения, а не только для машин. А общий язык помогает создавать качественный чистый код, улучшая читабельность и удобство сопровождения. Это также помогает членам команды понимать код друг друга и легко находить файлы или классы. Некоторые распространенные соглашения о кодировании:
* соглашения об именах * Комментарии * пробелы * операторы * декларации * отступ * файловая организация * архитектурные узоры
Вы можете подумать об использовании линтера кода, чтобы выявить запахи кода или пробелы в безопасности, но вы также можете использовать его для отслеживания соглашений о коде. Инструменты включают:
* Красивее (JavaScript) * Rubocop (Ruby) * StyleCop (C#) * И множество вариантов с открытым исходным кодом. Успевайте!
При этом потратьте некоторое время на согласованный подход к документации. Думайте об этом как о передаче факела или эстафеты знаний от вас из прошлого к вам в будущем.
Сложность кода
Хорошо, некоторый код — это просто запутанный лабиринт, порожденный болью. Но это также могут быть непроходимые джунгли, которые невозможно понять никому, кроме того, кто их написал. Каждый раз, когда команда говорит о рефакторинге, чтобы уменьшить технический долг, он перетасовывается в конец стопки.
И помните, многие разработчики остаются на одной должности только несколько лет, чтобы этот человек мог распространить свои джунгли сложного кода, как вирус, по нескольким организациям, если его не остановить. Ужасно.
Но вернемся к делу. Проще говоря, сложность кода относится к тому, насколько сложно код понять, поддерживать и модифицировать. Чрезмерно сложный код также может содержать ошибки и может препятствовать добавлению новых.
Существует два основных метода измерения сложности кода:
- Цикломатическая сложность измеряет сложность программы на основе количества независимых путей прохождения кода. Это количественная мера количества точек принятия решений в коде, таких как операторы if и циклы for/while. Чем больше путей в вашем коде, тем больше потенциальных проблемных областей в коде, которые могут потребовать дальнейшего тестирования или рефакторинга.
- Метрика сложности Холстеда, которая измеряет размер и сложность программы на основе длины программы, объема словарного запаса, количество различных операторов и операндов, количество операторов и количество ошибок на тысячу строк кода.
Эти показатели оценивают качество и ремонтопригодность программного обеспечения, а также прогнозируют усилия, необходимые для разработки, отладки и обслуживания программных систем.
Тем не менее, Halstead Complexity Metrics не учитывает другие важные показатели, такие как читабельность кода, производительность, безопасность и удобство использования, поэтому его нельзя использовать как отдельный инструмент. Посетите сайт Verifysoft, если хотите больше узнать о показателях.
Поддерживаемость кода
Сопровождаемость кода — это то, на что это похоже: насколько легко поддерживать и модифицировать кодовую базу с течением времени. Плохо поддерживаемый код приводит к задержкам, так как требуется больше времени для обновления, и это может стать серьезным недостатком по сравнению с вашими конкурентами.
Но если все сделано правильно, он объединяет все самое лучшее, включая ясность кода, сложность, соглашения об именах, рефакторинг кода, документацию, контроль версий, проверку кода и модульное тестирование.
Таким образом, речь идет о более широкой приверженности качеству кода, а не об отдельной задаче или инструменте. И всегда стоит помнить, что, как и при рефакторинге, вы будете поддерживать свой и чужой код долгое время после первой записи.
К счастью, существует множество инструментов автоматизации с самого начала, когда дело доходит до удобства обслуживания. Например, инструменты статического анализа кода выявляют риски ошибок, анти-шаблоны, проблемы с производительностью и неиспользуемый код.
Новые и закрытые ошибки
Каждая ошибка в вашем программном обеспечении — это небольшая часть технического долга, который со временем накапливается. Чтобы отслеживать ваш технический долг, ваши инженеры должны отслеживать и документировать каждую ошибку, в том числе когда она исправлена.
Один из способов измерить качество вашего кода — сравнить количество обнаруженных новых ошибок с количеством ошибок, которые были устранены. Если новых ошибок постоянно больше, чем исправленных, это признак того, что ваш технический долг растет и вам необходимо принять меры для эффективного управления им.
Отслеживание новых ошибок по сравнению с закрытыми ошибками помогает выявить потенциальные проблемы в процессе разработки, такие как недостаточное тестирование, плохой контроль качества или нехватка ресурсов для исправления ошибок. Сравнивая, вы можете принимать обоснованные решения о распределении ресурсов, определении приоритетов исправления ошибок и улучшении методов разработки, чтобы сократить технический долг и улучшить качество кода с течением времени.
Я стал соучредителем Stepsize, чтобы решить эту проблему. Наш инструмент помогает современным инженерным командам повышать качество кода, упрощая выявление, отслеживание, определение приоритетов и исправление технического долга или проблем с качеством кода. Создавайте, просматривайте и управляйте проблемами непосредственно из вашей кодовой базы с помощью инструмента Stepsize. Проблемы связаны с кодом, что упрощает их понимание и определение приоритетов.
Используйте инструмент визуализации кодовой базы, чтобы понять распределение технического долга и проблем с качеством кода в кодовой базе. Используйте мощные фильтры, чтобы понять, как это повлияет на кодовую базу, продукт, команду и бизнес-приоритеты.
Подробнее о инструмент Stepsize здесь.
Округление
Важно помнить, что для эффективного управления качеством кода недостаточно полагаться только на одну метрику или инструмент.
Вместо этого ведущие инженеры должны уделить первоочередное внимание внедрению задач и инструментов по обеспечению качества кода в ежедневный рабочий процесс, чтобы обеспечить постоянное улучшение с течением времени.
Это включает в себя помощь членам команды в разработке надлежащей гигиены кода путем накопления привычек и развития навыков, что может значительно улучшить их карьеру.
Отслеживание и приоритизация технического долга — критически важный аспект повышения качества кода. Таким образом, команды могут обосновать рефакторинг основных частей своей кодовой базы, что в конечном итоге приведет к созданию более эффективного и удобного в сопровождении программного обеспечения.
Также опубликовано здесь
Оригинал