Чтобы определить, насколько аккуратна кодовая база в проекте, прибегают к метрикам качества.
Цикломатическая сложность
Цикломатическая сложность — это количество возможных путей, которые интерпретатор проходит через один блок кода. Вот, смотрите:
def charge(user): subscription = user.subscriptions.last() bank = Bank(user) if bank.charge(subscription.cost): subscription.prolong()
Внутри функции charge() всего два пути: если получилось снять деньги с пользователя, то подписка продляется, если не получилось — ничего не происходит.
Наверняка во время продления подписки мы уведомляем пользователя и менеджера об успешной операции, автоматически создаём новую подписку в случае, если её ещё нет, обновляем дату следующего продления. В примере выше всё это попрятано по отдельным местам — в методе подписки prolong() или вообще вне функции charge(). Смотрите, что будет, если это не прятать:
def charge(user): if user.subscriptions.count(): subscription = user.subscriptions.last() order = Order.objects.create(user=user, subscription=subscription, created=datetime.now()) response = requests.post(‘https://bank.api/init’, dict( amount=subscription.cost * 100, order_id=order.id, )) if response[‘OK’] is True: payment_id = response[‘payment_id’] new_response = requests.post(‘https://bank,api/charge’, dict(payment_id=payment_id)) if new_response[‘OK’] is False: requests.post(‘htps://api.slack.com’, < ‘to’: ‘#money’, ‘message’: f’Не удалось оплатить подписку пользователя ‘, >) else: subscription.due_date = datetime.now() + timedelta(month=1) subscription.save() else: Subscription.objects.create(user=user) charge(user)
В этом примере 6 возможных путей. Это уже многовато — алгоритм воспринимается с трудом, если возможных путей в нём больше 4.
Архитектура кода (С++)
Чтобы избежать высокой сложности, программисты раскладывают код по полочкам так, чтобы на каждой полочке оказался небольшой понятный кусочек. Если ваша программа, наоборот, состоит из больших кусков с высокой сложностью, как во втором примере, — это проблема.
Процент покрытия тестами
CI (Continous Integration) — процесс непрерывной сборки и проверки программы. Рассмотрим его подробно в следующем совете
Вторая важная метрика — это процент кода, покрытого тестами. Скажем, если ваша программа покрыта на 90% — значит, в процессе прогона тестов в CI вы задействуете 90% из всего написанного кода. Скорее всего, это означает, что 90% вашего кода работает так, как задумал программист. 90% — неплохой уровень покрытия, 80% и ниже — сигнал, что что‑то идёт не так.
CI (Continous Integration) — процесс непрерывной сборки и проверки программы. Рассмотрим его подробно в следующем совете
Сервис Codecov подсвечивает непротестированную строчку
К сожалению, высокий процент покрытия необязательно говорит, что ваши тесты написаны хорошо. К примеру, код из первого примера можно полностью покрыть одним тестом, но он всё равно упадёт, если вызвать функцию charge() для пользователя, у которого подписки нет вообще.
OOP-3-3-01 Критерии чистого кода
Зато, если покрытие у вас низкое, это однозначно сигнализирует, что вы пишете недостаточно тестов, а значит, вам не избежать регрессий.
Время ответа и частота ошибок
Эти метрики показывают не совсем качество кода, а скорее качество работы программного обеспечения в продакшене. Обычно частота ошибок и время ответа растут очень медленно, по мере усложнения программы. Если у вас резко выросла одна из этих метрик — это сигнализирует, что только что в вашу кодовую базу привнесли серьёзное ухудшение.
Экран мониторинга производительности в Datadog: видны графики времени ответа и ошибок
Для снятия этих метрик подходит множество инструментов. Мы в «Гдематериале» используем Datadog в связке с Sentry. Datadog измеряет частоту ошибок и время ответа, а Sentry помогает с расследованием, показывая состояние приложения во время ошибок.
Добавьте свою метрику
Существует множество более специфичных метрик — количество и длина строк, время сборки, количество коммитов на один файл, размер готового образа. Чем больше вы снимаете метрик и чем больше ограничений на их значения ставите — тем здоровее ваш проект.
P. S. Это был совет об управлении разработкой. Хотите больше знать о планировании спринтов, управлении продуктом или о настройке инфраструктуры? Присылайте вопросы.
Источник: bureau.ru
Что такое Code Review
Понятие Code Review появилось в обиходе не так давно. Дословно, оно подразумевает проверку, инспектирование, обзор, коррекцию программного кода. Целью данной работы является нахождение нестыковок, отклонений, некорректного поведения ПО. Основной задачей проведения код ревью считается улучшение показателей программы.
Code Review может быть проведен одним специалистом или группой разработчиков. Процесс проведения зависит от сложности поставленных задач и может проходить как чтение кода программы по основным точкам или, в виде совещания команды специалистов, с последующими выводами по произведенной работе. Хороший Code Review подразумевает не только поиск нестыковок, но и рекомендации по их устранению, совещание по этапам дальнейших действий.
Критерии хорошего кода
Разработчики, создающие программу, всегда понимают, как должен быть написан хороший код. Каждый специалист, работающий над новым сайтом или приложением, начинает процесс с создания качественной основы. Что подразумевается под качественным кодом? Главное – это простота и гибкость. Создать простой код сложно, это не означает упростить и сократить.
Простой код – это максимальная ясность в процессе работы. Для определения качества исходного кодирования, существует несколько точек, по которым нужно ориентироваться:
- Простота восприятия кода. Хороший код не должен содержать множество запутанных конструкций. Специалист должен понять принцип кодирования без дополнительных пояснений и документов.
- Гибкость кода. Простой, но грамотно продуманный код, позволяет производить коррекцию и внесение изменений без потери качества. В случае хорошего исходного кода, в дальнейшем есть возможность изменения конфигурации.
- Возможность дополнения. Код должен позволять вносить новый функционал без опасения нарушения основных алгоритмов.
- Легкость эксплуатации. При возникновении каких-либо неполадок должна быть возможность быстрого решения.
- Доступность. Хороший код подразумевает, что при необходимости, его можно передать для дальнейшей работы другому специалисту. И новый разработчик сможет без труда разобраться в программе, внести изменения и добавить новые пункты.
Для того, чтобы облегчить процесс разработки нового кода, любой язык программирования включает свои стандарты. Стандарты code style подробно описывают процесс расстановки знаков, отделения конструкций, расстановки пробелов. Неопытные специалисты иногда игнорируют данные стандарты. Это не желательно, так как соблюдение правил, дает гарантии, что последующий работник сможет разобраться в программе.
- Тест на знание основ HTML
- Тест на знание основ PHP
- Тест на знание ООП в PHP
Повышение качества кода
Для того чтобы повысить качество кодирования, создана техника Code Review. Проведение мероприятий по проверке кода повышает вероятность того, что изменения, планируемые разработчиком, будут отслежены и сохранены.
Часть работ по проверке кода можно осуществлять в специальных программах — для обнаружения простых ошибок в расстановке пробелов или сделанных отступов, человек потратит гораздо больше времени, чем специализированная программа. В то же время живые люди должны сконцентрироваться непосредственно на логике программы. Когда в команде задействованы профильные сотрудники, они имеют собственный опыт и особое видение ситуации. Все это поможет создать по-настоящему качественный продукт.
Как происходит процесс оценки качества
После создания нового кода и перед тем, как внести изменения в программное обеспечение, сотрудник доносит предложение до стальных членов команды, производящих Code Review. Далее команда разбирается в смысле предложенных изменений и комментирует результат. Начинает команда с найденных багов, затем указывает структурные ошибки, возможное некорректное использование некоторых инструментов.
Автор разработки может выслушать предложения и начать работу по исправлению. Не всегда разработчик должен соглашаться со всеми пунктами, если у него имеются весомые аргументы в пользу своей работы, он должен их прокомментировать.
- Курс HTML для начинающих
- Курс PHP для начинающих
- Курс MySQL для начинающих
- Курс ООП в PHP
Последующие изменения вносятся по такому же алгоритму. Сначала процесс проверки, обсуждение, озвучивание выводов и предложения по исправлению. Для автора разработки процесс Review является хорошей помощью в дальнейшей работе. Все замечания и комментарии пригодятся при создании следующих программ. Поэтому разработчик не должен относится к замечаниям, как к помехам в завершении процесса.
Преимущества и недостатки процесса проверки кода
Проверка в технике Code Review выявляет недочеты в разработанном коде на ранних этапах. Такая тактика дает возможность избежать внеплановых ситуаций и затрат в будущем. Можно определить еще несколько плюсов такого подхода:
- Свежий взгляд. В процессе работы свою роль играет человеческий фактор. Возможное отсутствие опыта, усталость, желание упростить, могут привести к некачественному итогу работы. Новый взгляд на созданный продукт, сразу же обнаружит все недочеты.
- Передача. При условии, что в работу вникли несколько сотрудников, всегда есть возможность делегировать дальнейшие действия каждому из них. При любом незапланированном случае сотрудник может заменить коллегу и продолжить работу.
Каждый качественный процесс имеет такой недостаток, как потеря времени. Работа с Code Review предполагает большой промежуток времени, так как качественная проверка – процесс, который не допускает спешки. При планировании сроков создания программного продукта, необходимо учитывать время на оценку, и вероятность сдвига этапов работы в графике.
Преимуществ использования Code Review намного больше, чем недостатков, но нужно понимать, что его применение не всегда актуально. Есть проекты, в которых нет необходимости в таком подходе. При создании стационарных программ, в которые не планируется вносить изменения, можно обойтись и без фиксации кода несколькими специалистами.
Но если есть тенденция к добавке функционала, появлению новых возможностей в дальнейшем, тогда проводить Code Review необходимо. Если планируется большой, долгосрочный проект, всегда есть вероятность привлечения новых специалистов, увеличения аудитории, внедрения новых технологий. Тогда проведенная работа по проверке и оценке, поможет в дальнейшем избежать финансовых затрат, сделает работу быстрее, легче и качественнее. Поэтому многие компании сегодня делают Code Review обязательным пунктом при внесении программных изменений, даже при наличии опытного разработчика.
Источник: php.zone
Как отличить качественный программный код
Сегодня не существует какого-либо унифицированного подхода к написанию программных кодов. Различные разработчики могут написать одну и ту же программу совершенно разными способами. И при этом все способы написания могут быть верными. Именно поэтому говорить, что определенный участок кода написан неправильно бывает очень сложно.
Требования к программному коду
Главное требование к любому программному коду – он должен работать так, как это задумывал разработчик. В этом случае код принято считать правильным. Если же код выполняет неожиданные или совершенно ненужные действия, то он считается неправильным.
Поддержка кода
Одним из основных признаков хорошей программы является поддерживаемость кода. Востребованная программа должна быть готова к добавлению дополнительных функциональных возможностей. Это нереально сделать в том случае, если программный код запутан и не организован. В такой ситуации другие программисты, работающие над расширением функционала, не смогут понять задумок первоначального разработчика и реализовать все свои идеи.
Скорость исполнения
Еще одной важнейшей характеристикой качественно написанного кода считается скорость исполнения программы. Ни одному пользователю не будет интересна медленная программа. При этом программистам не следует пытаться ускорить абсолютно все участки кода. Достаточно определить «медленные» фрагменты и улучшить их с целью повышения скорости исполнения программы.
Маскировка ошибок
В процессе разработки кода зачастую возникают ошибки, происхождение которых сложно определить. В такой ситуации ошибку исправить очень сложно. Поэтому многие разработчики используют такую хитрость, как проверка или исключение ситуаций, в которых может возникнуть данная ошибка. Но подобных хитростей бывает недостаточно. В некоторых случаях требуется не маскировка, а исправление ошибки.
Разработчики должны понимать, что одно неправильное действие программы может повлечь за собой порцию новых ошибок, которые возникнут поверх старых и окончательно сломают программу.
Поэтому маскировка является лишь временным решением проблемы. Причем такое решение может стать причиной возникновения других куда более серьезных проблем, в результате которых программа становится абсолютно неуправляемой.
Чрезмерное комментирование
Программный код должен быть понятен не только его разработчику, но и другим программистам, которые впоследствии будут с ним работать. Поэтому опытные разработчики прекрасно знают одно из главных правил программирования: «Все переменные, функции и методы должны быть названы понятными именами, с трактовкой которых не возникнет проблем».
В некоторых случаях для пояснения тех или иных особенностей кода может использоваться комментирование. При этом не стоит переусердствовать с данным атрибутом программирования. Комментарии нужны только там, где без них действительно не обойтись. Стоит понимать, что исправление какого-то участка кода требует удаления и комментариев, относящихся к нему.
В противном случае потеряется смысл комментариев. Более того, они вообще могут запутать разработчика. Именно поэтому не нужно детально описывать все переменные и функции. Для понимания кода следует указать только то, за что отвечает конкретный метод или модуль.
Преждевременная оптимизация
В процессе разработки кода не стоит сразу же все упрощать и оптимизировать. Нередко неоптимизированные строки намного проще для понимания, чем короткие и непонятные выражения. В первую очередь, нужно писать понятный код. И только потом, когда «скелет» программы будет готов, можно будет приступить к ее улучшению.
В завершение хотелось бы узнать, что вы думаете относительно отличий между правильным и неправильным программным кодом. Есть ли какая-то грань, которая позволяет назвать код «хорошим» или «плохим».
Источник: fokit.ru