Как повысить качество кода
Все мы наслышаны о красивом коде. Книги и страницы специализированных ресурсов пестрят рекомендациями, стандартами и просто хорошими советами. Современные языки предлагают множество путей изящного выражения идей разработчика. Вообще все хорошо. Вроде бы. Но реальная жизнь сурова. По ряду вполне объективных причин только самые счастливые из нас имеют возможность работать с действительно качественной кодовой базой. Большинство же, зная чуть ли не все подробности идеального способа работы, живут здесь и сейчас, за пределами рая, довольствуясь имеющимся.
Но как сделать свою жизнь лучше? Как заставить уровень качества кода расти. Приведу несколько собственных правил-размышлений на эту тему.
1.Полная осознанность выполняемых действий.
Нужно требовать от программистов полного осознания каждой написанной строчки кода. Правило звучит очень просто: «Не понял, почему заработало — не проталкивай изменения в общее хранилище». В последнее время я уделяю особое внимание реализациям «наугад». Распознать их достаточно просто: вычурные конструкции, отсутствие комментариев или их старательно размытые формулировки… Самый точный способ — попросить программиста объяснить механизм реализации подозрительной функциональности.
Результаты наблюдений выглядят пугающе — почти вся «неосознанная» функциональность содержит ошибки, которые проявляются практически мгновенно. Причем чаще всего это оказываются так называемые четные баги, когда исправляешь неверный участок и понимаешь, что только благодаря ему все остальное работало хоть приблизительно правильно.
Плюсы: осознавая выполненную работу, а не просто добиваясь похожих на правду результатов, программисты растут профессионально. Количество ошибок также уменьшается, причем большинство из них по сложности исправления лежит на уровне банальных опечаток. Реализация получается более оптимальной, простой и наглядной — алгоритм легко читается даже без дополнительной документации или комментариев.
Минусы. По времени это очень затратно. Особенно если уровень программистов не сильно высок. Костыльщики будут плохо приживаться в команде, где слишком старательно придерживаются этого правила. И это не так уж и хорошо: в тяжелые времена (например, когда нужно срочно готовить продукт к релизу) пара качественных любителей костылей жизненно необходимы. Да и в спокойные времена они будут помогать коллективу не застревать слишком подолгу в аналитических тупиках.
2. Наличие четких рамок допустимого зла.
Иногда приходится уступить идеалам и пропустить не вполне качественный код. Даже еще хуже. Постоянно приходится идти на те или иные уступки — жизнь жестока и несправедлива. Однако нужно иметь четкие пределы, дальше которых ни-ни. Так, в напряженные периоды, можно смотреть сквозь пальцы на несоблюдение интервалов и правил именования, но опасные небрежности лучше пресекать резко и жестоко, даже если оно как-то работает и сроки жмут.
Плюсы. Если чувствуешь, что реализация некорректна, несмотря на видимость правильной работы, нужно это исправлять. Потому что, во-первых, напряжение в ответственные моменты и так высоко — не хватает еще терзаний совести и накопления негатива. Во-вторых, сдать продукт — это, конечно, первоочередная цель, но он должен выполнять свои основные функции. Одно дело выпускать приложение с рядом мелких недочетов и другое — осчастливить заказчика бесполезным куском скомпилированного кода. Уж не знаю, плюс это или минус, но без развитого чутья здесь не обойтись. Как и без набитых шишек. Но все равно оставлю в плюсах.
Минусы. Нужно быть готовым к давлению, как снизу, так и сверху. Как же так — нужно скорее, а команда отвлекается на наведение блеска. Без потери нервов не обойтись. К тому же можно сильно подставиться в случае неудачи проекта. Короче, сплошной риск.
3. Откровенность.
Допустим, человек неспособен решать задачи полностью осознанно. Может, просто нет времени сделать правильно — часть параметров пришлось подобрать методом тыка. Или правильное решение слишком сложно — проще сделать упрощенный вариант и подпереть его парой костылей. Такое бывает гораздо чаще, чем этого хочется. Но просто смириться мало. Гораздо лучше культивировать в команде откровенность. Сделал не очень хорошо — признайся в этом в комментарии, тексте описания коммита, а еще лучше, оставь запись в системе управления проектами.
Естественно, наказаний за признания быть не должно.
Плюсы. Хорошие времена случаются, чем больше зацепок будет оставлено, тем больше шансов, что к незаконченным задачам вернутся и сделают все правильно. Даже если не вернутся — честный предупреждающий комментарий сэкономит в будущем много времени и нервов другим программистам, если не на исправление ошибки, то хотя бы на ее поиск… Лучше человек узнает о том, что функция разбора файла не полностью поддерживает некоторые его форматы, из описания этой функции, чем после недели странных проблем поймет это сам. К тому же всегда есть шанс, что, признаваясь в недоделке, автор устыдится и переделает хорошо.
Минусы. Очень легко потерять контроль — сотрудники могут привыкнуть, что достаточно признаться в косяке, чтобы тебе за это ничего не было. Здесь все снова упирается в чутье руководителя. Недоделки не должны превращаться в «ароматные» кучки гуано, гордо разбросанные по всему проекту. Другими словами, основная сложность данного подхода — правильная дозировка безнаказанности.
Конечно же, ни одно правило ничего не гарантирует. К тому же каждое из них допускает перегибы, способные свести на нет любой положительный результат. Но что-то делать нужно. И начать с признания проблемы: идеально сделать, наверняка не выйдет, но стремиться использовать ресурсы максимально эффективно мы обязаны.
8 советов по улучшению качества кода
Качественный код — это командная работа, вне зависимости от должности. Менеджер, разработчик и тестировщик должны вместе работать над созданием высококачественного кода.
Ниже представлен список методов по улучшению кода, которые будут полезны для любого проекта.
1. Используйте линтер совместно с IDE
С помощью линтера можно избежать множество проблем. Как мы все знаем, линтер читает код, выдает ошибки и предупреждения, если код не соответствует определенному стандарту языка.
Такие интегрированные среды разработки, как VS Code, JetBrain, Atom имеют множество функций и дополнений для кодового линта. Например, VS Code обладает линтингом для Python, JSLint и других популярных языков программирования.
При добавлении линтинга для существующей базы кода я бы порекомендовал начать с минимального набора правил. Затем вы сможете добавить новые правила на основе полученных результатов проверки кода вручную.
Интеграция инструментов Linter совместно с процессом CI помогает командам обеспечить качество кода и установить систему управления. Мы можем сделать это с помощью таких инструментов CI/CD, как Jenkins, Azure DevOps, Bamboo и т.д. В качестве примеров для автоматического линтера можно выделить flake8, black, pre-commit.
Некоторые платформы оценки качества кода, такие как SonarCloud, также предоставляют линтер для запуска в интегрированной среде разработки. При этом используется один и тот же набор правил, определенный для платформы в одном месте.
Более того, существуют методы, с помощью которых вы сможете заставить команду разработчиков проверить линтинг перед созданием кода, сокращая при этом общее время на итерацию.
Вы можете это сделать, добавив осуществление линтера на крючках предварительного коммита git.
2. Правильный баланс комментариев
Можно выделить два типа разработчиков — те, кто постоянно комментирует все, и те, кто ничего не комментирует.
Как многие знают, добавление слишком большого количества комментариев к коду делает его нагроможденным и трудным для чтения. С другой стороны, отсутствие каких-либо комментариев оставляет будущих разработчиков в состоянии смятения.
Поэтому мы рекомендуем сделать код настолько понятным, чтобы потребовалось минимальное количество комментариев.
Объясняйте то, что код делает, а не определяет.
Однако добавление комментариев бесполезно, если они не обновляются при изменении кода.
Совет: делитесь своими часто используемыми компонентами с помощью Bit (Github).
Bit упрощает совместное использование, документирование и повторное использование независимых компонентов между проектами. Примените его для максимального повторного использования кода, обеспечения согласованного дизайна, ускорения доставки и создания масштабируемых приложений.
Bit поддерживает Node, TypeScript, React, Vue, Angular, и т.д.
3. Автоматизация тестирования
Тестирование необходимо для написания качественного кода. Автоматизация данного процесса поможет снизить расходы на ручное повторное тестирование. Однако это не значит, что мы можем отказаться от ручного тестирования.
Наличие комплексного тестирования помогает выявить ошибки кода и упрощает рефакторинг.
Возможно, вы зададитесь вопросом, где же нам стоит начать? На каких тестах мы должны сфокусироваться?
Это зависит от характера приложения, API и т.д. Например, если вы разрабатываете API, вы можете полагаться на автоматическое тестирование API и модульное тестирование. Если это веб-приложение, вы можете использовать сквозное и модульное тестирование. Более того, вы можете обратиться к тестовой пирамиде, чтобы лучше понять необходимые тесты.
В зависимости от вашей стратегии, вы можете использовать действенные методы тестирования. Например, тестирование моментальных снимков после разработки.
4. Обзор кода вручную
Обзор кода — это самый важный этап в написании качественного кода. Как правило, мы проводим обзор кода на Git Pull Request, где этому способствуют такие современные Git-платформы, как GitHub, Azure DevOps, GitLab. Это поможет проверить код перед объединением с соответствующей веткой.
Кроме того, можно автоматически добавить комментарии к ревью кода, используя такие инструменты анализа, как SonarCloud. Благодаря им можно значительно сократить усилия.
Однако ни один статический анализатор на данный момент не способен полностью заменить опытного разработчика, который проводит ручную проверку.
В качестве непрерывного процесса улучшения вы можете периодически оценивать распространенные ошибки и находить новые правила или новые статические анализаторы кода для их автоматизации.
5. Quality Gates
Quality Gates устанавливает условия и руководящие принципы, которые указывают, соответствует ли предмет необходимым критериям для перехода к следующему этапу.
Как Quality Gates помогает улучшить качество кода?
Quality Gate определяет проблемы с качеством кода и блокирует плохо разработанный код до того, как он попадет в производственную среду. Таким образом, Quality Gate выполняет следующие действия:
· Измеряет масштаб тестирования и проверяет, что он превышает определенный уровень.
· Выполняет автоматизированные тесты (модульное тестирование, интегрированное тестирование и E2E).
· Анализирует статический код.
Однако важно понимать время выполнения и использовать Quality Gate в нужном месте CI/CD-конвейера. Например, мы проводим модульные тесты, статический анализ качества кода во время выполнения интеграционных тестов и E2E-тестов после объединения кода или в зависимости от времени и ресурсов, которые для этого требуются.
6. Периодическая осмотрительность
Техническая проверка — это процесс, которого мы придерживаемся для оценки технологии, продукта, архитектуры и процедуры.
Для чего нужна комплексная проверка программного обеспечения?
В современном мире технологий важность программного обеспечения для успеха бизнеса возрастает. Программное обеспечение выступает основой современной цифровизацией. В условиях высокого спроса и конкуренции в программных активах важно определить архитектуру приложений, которая разработана с учетом современных технологий и открыта для будущих расширений.
После нескольких проверок нам стоит следить за разработкой программного обеспечения:
· Убедитесь, что команда выполняет процесс соответствующим образом. Например, должны быть выявлены требования, функции и ошибки, а изменения кода записываются в соответствии с процессом.
· Убедитесь, что команда придерживается эффективного процесса создания приложения. Например, в кратчайшие сроки можно протестировать новую версию приложения.
· Возможно ли отслеживать каждую версию в отношении запланированных и развернутых функций?
· В какой степени пользователь включен в процесс отслеживания ошибок, чтобы обеспечить своевременный и комплексный отчет об ошибках?
· Как автоматизированы механизмы обновления программного обеспечения?
· Периодически выплачиваются технические долги и создается необходимая развивающаяся архитектура.
· Команда придерживается рекомендаций по безопасности и качеству кода с постоянными улучшениями.
Ниже представлены некоторые из них.
7. Определите стандарты написания кода
Обозначение стандартов имеет позитивное влияние на любую команду. То же самое относится и к разработке программного обеспечения. Определение стандарта написания кода помогает предприятиям организовать и сфокусировать внимание команды разработчиков на повышении качества продукта.
Стандарты написания кода помогают разработчикам и членам команды работать над проектом, который соблюдает определенный набор руководящих принципов. Плюсы грамотно выстроенных стандартов:
· Снижение риска провала проекта.
· Простота в использовании.
Более того, важно также определить ценности для команды, чтобы улучшить качество. Хорошим примером может служить правило бойскаутов.
Всегда оставляйте палаточный лагерь чище, чем вы его нашли. Если вы обнаружите беспорядок на земле, уберите его независимо от того, кто мог это сделать. (Источник)
Это отличная аналогия, чтобы мотивировать команду не оставлять недоделанный код.
8. Сканирование уязвимостей
Регулировка уязвимости является ключевой обязанностью любой компании IT-безопасности и команд разработки программного обеспечения. Этот процесс включает оценку, уменьшение и отчет о любых слабых местах безопасности в системах и программном обеспечении организации.
Сканер уязвимости — это приложение, которое определяет любые слабые места CVS в коде. Он сканирует кодовую базу приложения и уведомляет о наличии в коде каких-либо слабых мест.
Если вы хотите начать с малого, то можете использовать команду npm audit в CI/CD-конвейере для JavaScript, анализа уязвимостей библиотеки узлов.
Большинство организаций автоматизируют сканирование уязвимостей с помощью CI/CD-конвейеров. Мы можем внедрить DevSecOps в приложение, чтобы выявить слабые места до того, как оно будет задействовано в производственной системе.
8 советов по улучшению качества кода
May 29 · 6 min read
Качественный код — это командная работа, вне зависимости от должности. Менеджер, разработчик и тестировщик должны вместе работать над созданием высококачественного кода.
Ниже представлен список методов по улучшению кода, которые будут полезны для любого проекта.
1. Используйте линтер совместно с IDE
С помощью линтера можно избежать множество проблем. Как мы все знаем, линтер читает код, выдает ошибки и предупреждения, если код не соответствует определенному стандарту языка.
Такие интегрированные среды разработки, как VS Code, JetBrain, Atom имеют множество функций и дополнений для кодового линта. Например, VS Code обладает линтингом для Python, JSLint и других популярных языков программирования.
При добавлении линтинга для существующей базы кода я бы порекомендовал начать с минимального набора правил. Затем вы сможете добавить новые правила на основе полученных результатов проверки кода вручную.
Интеграция инструментов Linter с о вместно с процессом CI помогает командам обеспечить качество кода и установить систему управления. Мы можем сделать это с помощью таких инструментов CI/CD, как Jenkins, Azure DevOps, Bamboo и т.д. В качестве примеров для автоматического линтера можно выделить flake8, black, pre-commit.
Некоторые платформы оценки качества кода, такие как SonarCloud, также предоставляют линтер для запуска в интегрированной среде разработки. При этом используется один и тот же набор правил, определенный для платформы в одном месте.
Более того, существуют методы, с помощью которых вы сможете заставить команду разработчиков проверить линтинг перед созданием кода, сокращая при этом общее время на итерацию.
Вы можете это сделать, добавив осуществление линтера на крючках предварительного коммита git.
2. Правильный баланс комментариев
Можно выделить два типа разработчиков — те, кто постоянно комментирует все, и те, кто ничего не комментирует.
Как многие знают, добавление слишком большого количества комментариев к коду делает его нагроможденным и трудным для чтения. С другой стороны, отсутствие каких-либо комментариев оставляет будущих разработчиков в состоянии смятения.
Поэтому мы рекомендуем сделать код настолько понятным, чтобы потребовалось минимальное количество комментариев.
Объясняйте то, что код делает, а не определяет.
Однако добавление комментариев бесполезно, если они не обновляются при изменении кода.
Совет: делитесь своими часто используемыми компонентами с помощью Bit (Github).
Bit упрощает совместное использование, документирование и повторное использование независимых компонентов между проектами. Примените его для максимального повторного использования кода, обеспечения согласованного дизайна, ускорения доставки и создания масштабируемых приложений.
Bit поддерживает Node, TypeScript, React, Vue, Angular, и т.д.
3. Автоматизация тестирования
Тестирование необходимо для написания качественного кода. Автоматизация данного процесса поможет снизить расходы на ручное повторное тестирование. Однако это не значит, что мы можем отказаться от ручного тестирования.
Наличие комплексного тестирования помогает выявить ошибки кода и упрощает рефакторинг.
Возможно, вы зададитесь вопросом, где же нам стоит начать? На каких тестах мы должны сфокусироваться?
Это зависит от характера приложения, API и т.д. Например, если вы разрабатываете API, вы можете полагаться на автоматическое тестирование API и модульное тестирование. Если это веб-приложение, вы можете использовать сквозное и модульное тестирование. Более того, вы можете обратиться к тестовой пирамиде, чтобы лучше понять необходимые тесты.
В зависимости от вашей стратегии, вы можете использовать действенные методы тестирования. Например, тестирование моментальных снимков после разработки.
4. Обзор кода вручную
Обзор кода — это самый важный этап в написании качественного кода. Как правило, мы проводим обзор кода на Git Pull Request, где этому способствуют такие современные Git-платформы, как GitHub, Azure DevOps, GitLab. Это поможет проверить код перед объединением с соответствующей веткой.
Кроме того, можно автоматически добавить комментарии к ревью кода, используя такие инструменты анализа, как SonarCloud. Благодаря им можно значительно сократить усилия.
Однако ни один статический анализатор на данный момент не способен полностью заменить опытного разработчика, который проводит ручную проверку.
В качестве непрерывного процесса улучшения вы можете периодически оценивать распространенные ошибки и находить новые правила или новые статические анализаторы кода для их автоматизации.
5. Quality Gates
Quality Gates устанавливает условия и руководящие принципы, которые указывают, соответствует ли предмет необходимым критериям для перехода к следующему этапу.
Как Quality Gates помогает улучшить качество кода?
Quality Gate определяет проблемы с качеством кода и блокирует плохо разработанный код до того, как он попадет в производственную среду. Таким образом, Quality Gate выполняет следующие действия:
· Измеряет масштаб тестирования и проверяет, что он превышает определенный уровень.
· Выполняет автоматизированные тесты (модульное тестирование, интегрированное тестирование и E2E).
· Анализирует статический код.
Однако важно понимать время выполнения и использовать Quality Gate в нужном месте CI/CD-конвейера. Например, мы проводим модульные тесты, статический анализ качества кода во время выполнения интеграционных тестов и E2E-тестов после объединения кода или в зависимости от времени и ресурсов, которые для этого требуются.
6. Периодическая осмотрительность
Техническая проверка — это процесс, которого мы придерживаемся для оценки технологии, продукта, архитектуры и процедуры.
Для чего нужна комплексная проверка программного обеспечения?
В современном мире технологий важность программного обеспечения для успеха бизнеса возрастает. Программное обеспечение выступает основой современной цифровизацией. В условиях высокого спроса и конкуренции в программных активах важно определить архитектуру приложений, которая разработана с учетом современных технологий и открыта для будущих расширений.
После нескольких проверок нам стоит следить за разработкой программного обеспечения:
· Убедитесь, что команда выполняет процесс соответствующим образом. Например, должны быть выявлены требования, функции и ошибки, а изменения кода записываются в соответствии с процессом.
· Убедитесь, что команда придерживается эффективного процесса создания приложения. Например, в кратчайшие сроки можно протестировать новую версию приложения.
· Возможно ли отслеживать каждую версию в отношении запланированных и развернутых функций?
· В какой степени пользователь включен в процесс отслеживания ошибок, чтобы обеспечить своевременный и комплексный отчет об ошибках?
· Как автоматизированы механизмы обновления программного обеспечения?
· Периодически выплачиваются технические долги и создается необходимая развивающаяся архитектура.
· Команда придерживается рекомендаций по безопасности и качеству кода с постоянными улучшениями.
Ниже представлены некоторые из них.
7. Определите стандарты написания кода
Обозначение стандартов имеет позитивное влияние на любую команду. То же самое относится и к разработке программного обеспечения. Определение стандарта написания кода помогает предприятиям организовать и сфокусировать внимание команды разработчиков на повышении качества продукта.
Стандарты написания кода помогают разработчикам и членам команды работать над проектом, который соблюдает определенный набор руководящих принципов. Плюсы грамотно выстроенных стандартов:
· Снижение риска провала проекта.
· Простота в использовании.
Более того, важно также определить ценности для команды, чтобы улучшить качество. Хорошим примером может служить правило бойскаутов.
Всегда оставляйте палаточный лагерь чище, чем вы его нашли. Если вы обнаружите беспорядок на земле, уберите его независимо от того, кто мог это сделать. (Источник)
Это отличная аналогия, чтобы мотивировать команду не оставлять недоделанный код.
8. Сканирование уязвимостей
Регулировка уязвимости является ключевой обязанностью любой компании IT-безопасности и команд разработки программного обеспечения. Этот процесс включает оценку, уменьшение и отчет о любых слабых местах безопасности в системах и программном обеспечении организации.
Сканер уязвимости — это приложение, которое определяет любые слабые места CVS в коде. Он сканирует кодовую базу приложения и уведомляет о наличии в коде каких-либо слабых мест.
Если вы хотите начать с малого, то можете использовать команду npm audit в CI/CD-конвейере для JavaScript, анализа уязвимостей библиотеки узлов.
Большинство организаций автоматизируют сканирование уязвимостей с помощью CI/CD-конвейеров. Мы можем внедрить DevSecOps в приложение, чтобы выявить слабые места до того, как оно будет задействовано в производственной системе.
