5 правил хорошего кода: советы от наших разработчиков
Введение
Постепенно мы стали замечать, что в работе разработчиков, вне зависимости от проекта, стали выделяться паттерны, которые можно сформулировать в виде правил написания хорошего кода. Чем чаще и чем больше правил мы применяем в одном проекте – тем быстрее проходит онбординг специалиста на проект, выше удовлетворенность заказчика результатом работы, повышается скорость внедрения функционала, снижается количество критичных багов.
Компания Software Cats уже более пяти лет занимается аутстафом и аутсорсом по направлениям
Если у вас есть ИТ-проблема, оставьте ваши контакты, и мы поможем составить план ее решения.
Правило 1: Всегда пишите тесты
Чем больше тестов вы пишете и чем более они разнообразны (от юнит до интеграционных), тем дешевле обходится поддержание проекта. Это всем известная истина. К сожалению, до сих пор в нашей практике встречаются проекты на десятки тысяч строк кодовой базы, где не написано ни единого теста!
Зачастую разработчику, не являющемуся автором кода, бывает очень трудно восстановить цепочку событий, которая привела к тому, что зафиксировано в коде. Комментарии могут не отражать полную картину, в большинстве же случаев никто не комментирует код. Другое дело – тесты. Тесты отражают необходимые начальные условия для выполнения кода, отражают изменения, происходящие в системе, а также говорят, какой спектр значений является приемлемым для бизнеса в данной ситуации, а в каком мы должны выбросить ошибку и ни в коем случае не обрабатывать данные.
Написание хороших тестов – целая наука, на которой мы не будем здесь останавливаться, но скажем лишь, что тесты, будь то юнит или компонентные, необходимо учиться продавать также, как, скажем, хорошую архитектуру. Бывают ситуации, когда действительно нужно очень быстро применить изменения, потому что бизнес теряет деньги прямо сейчас. Но это обстоятельство не должно быть практикой.
Настраивайте рабочие процессы так, чтобы каждый шаг заботился о качестве. Делайте непрерывное тестирование неотъемлемой частью процесса CI/CD. Настраивайте метрики качества, например sonar, в каждом из проектов. Тестируйте на уязвимости вашу кодовую базу постоянно, ведь уязвимости в свободном ПО выявляются и устраняются каждый день.
Правило 2: Всё, что было в чате, останется в чате
Поэтому старайтесь фиксировать как можно больше договоренностей в письменной форме в специальном месте – это может быть Jira, YouTrack, Confluence и т.д. На практике уже спустя полгода затруднительно вспомнить, на основе каких предпосылок было принято то или иное решение. Может быть это было смс руководителю в 3 часа ночи? Или разговор в курилке. Никто никогда этого не узнает. Но если вести все договоренности в одном месте, например в задаче в Jira, детективный процесс распутывания клубка противоречий станет чуть более приятным и быстрым.
Отправляйте краткое резюме после каждого звонка с просьбой подтвердить договоренности всех участников встречи. Прикладывайте письмо в список ссылок на артефакты в документации в Confluence. Переносите ссылку на Confluence в код проекта. Помните: у человека, который займется расследованием происшествия спустя 4 года, должны быть зацепки, по которым он спустится к источнику истины. Вполне вероятно, что этим человеком будете вы.
Правило 3: Лучший код – тот, который не написан
Используйте кодогенераторы для рутинных предсказуемых операций. Прекрасные возможности для экономии времени предоставляют генераторы мапперов от Mapstruct, классов из спецификации Openapi, классов из json и xml схем. При умелом использовании и настройке вы можете значительно выиграть по времени реализации по сравнению с тем, кто не использует вышеперечисленные технологии.
Не пишите код на будущее прямо сейчас. Не стоит закладывать конкретную реализацию функциональности, которая еще не до конца формализована и не понятна всем участникам процесса. Можно заложиться на будущее авансом, добавив несколько методов в интерфейс взаимодействия, которые будут возвращать стандартные ответы (или ошибки), но делать детальную реализацию на базе еще не существующих или подверженных сильным изменениям требованиям не стоит точно. Помните: всё может поменяться и строить систему можно только на прочном фундаменте. Выделите в требованиях то, что не будет претерпевать существенных изменений, и стройте систему на базе этих требований, играючи заменяя отдельные меняющиеся компоненты.
Правило 4: Всё может сломаться
Очень часто на проектах мы встречались с ситуацией, когда авторы системы ошибочно полагали, что все элементы системы будут работать без сбоев. Когда всё-таки что-то шло не так и отказывала важная часть системы, которая ни при каких обстоятельствах не должна была отказать, начинались проблемы: потеря данных, невозможность быстро восстановиться до работоспособного состояния, блокировки и так далее.
Старайтесь всегда “подстелить себе соломки”. Задавайте неудобные вопросы уже на этапе аналитики. Вашим лейтмотивом при разработке всегда должен быть вопрос: “А что мы будем делать, если это сломается?”.
Правило 5: Результат важнее методологий
Очень важно в таких ситуациях иметь чёткое представление о последствиях и доносить его до заказчика – мы сейчас сделаем быстро и поступившись качеством, а в следующих итерациях разработки заложим 20, 30 или 40% времени на улучшение кодовой базы. В противном случае мы рискуем получить уже через пару месяцев тяжело изменяемый, не тестируемый и практически не поддерживаемый код.
Заключение
Наша команда уже более пяти лет занимается реализацией проектов на Java и усилением команд по направлениям
За время существования компании, мы принимали участие в работе над более чем 100 проектами различного объема и длительности.
Если перед вами стоят вызовы, для достижения которых вам может понадобится наша экспертиза, просто напишите нам,
- client@softwarecats.dev,
- https://t.me/alex_zarubin,
- или через любую форму на сайте.
Мы договоримся с вами об онлайн-встрече, чтобы подробнее обсудить ваш проект и вашу проблему.
Еще почитать по теме:
политике конфиденциальности
