5 правил хорошего кода: советы от наших разработчиков

Введение

За более чем пятилетнюю историю существования нашей команды мы успели поработать над десятками проектов. Были небольшие, буквально на 2-3 недели на 1 инженера. Поправить баг или подготовить документацию по сервису перед передачей заказчику. Были и гигантские – на несколько лет разработки командой в десятки инженеров. Например, написать портал для продажи электронных учебников и обучения по ним с ролевой моделью, сервером лицензий и уведомлениями по email.

Постепенно мы стали замечать, что в работе разработчиков, вне зависимости от проекта, стали выделяться паттерны, которые можно сформулировать в виде правил написания хорошего кода. Чем чаще и чем больше правил мы применяем в одном проекте – тем быстрее проходит онбординг специалиста на проект, выше удовлетворенность заказчика результатом работы, повышается скорость внедрения функционала, снижается количество критичных багов.

Правило 1: Всегда пишите тесты

Чем больше тестов вы пишете и чем более они разнообразны (от юнит до интеграционных), тем дешевле обходится поддержание проекта. Это всем известная истина. К сожалению, до сих пор в нашей практике встречаются проекты на десятки тысяч строк кодовой базы, где не написано ни единого теста!

Зачастую разработчику, не являющемуся автором кода, бывает очень трудно восстановить цепочку событий, которая привела к тому, что зафиксировано в коде. Комментарии могут не отражать полную картину, в большинстве же случаев никто не комментирует код. Другое дело – тесты. Тесты отражают необходимые начальные условия для выполнения кода, отражают изменения, происходящие в системе, а также говорят, какой спектр значений является приемлемым для бизнеса в данной ситуации, а в каком мы должны выбросить ошибку и ни в коем случае не обрабатывать данные.

Написание хороших тестов – целая наука, на которой мы не будем здесь останавливаться, но скажем лишь, что тесты, будь то юнит или компонентные, необходимо учиться продавать также, как, скажем, хорошую архитектуру. Бывают ситуации, когда действительно нужно очень быстро применить изменения, потому что бизнес теряет деньги прямо сейчас. Но это обстоятельство не должно быть практикой.

Настраивайте рабочие процессы так, чтобы каждый шаг заботился о качестве. Делайте непрерывное тестирование неотъемлемой частью процесса CI/CD. Настраивайте метрики качества, например sonar, в каждом из проектов. Тестируйте на уязвимости вашу кодовую базу постоянно, ведь уязвимости в свободном ПО выявляются и устраняются каждый день.

Правило 2: Всё, что было в чате, останется в чате

В идеальном мире все договоренности должны быть тщательно задокументированы, понятны и согласованы между всеми участниками процесса разработки. Увы, мы живем в несовершенном мире, и какая-то часть правил может игнорироваться или опускаться в угоду срокам реализации или критичности задачи.

Поэтому старайтесь фиксировать как можно больше договоренностей в письменной форме в специальном месте – это может быть Jira, YouTrack, Confluence и т.д. На практике уже спустя полгода затруднительно вспомнить, на основе каких предпосылок было принято то или иное решение. Может быть это было смс руководителю в 3 часа ночи? Или разговор в курилке. Никто никогда этого не узнает. Но если вести все договоренности в одном месте, например в задаче в Jira, детективный процесс распутывания клубка противоречий станет чуть более приятным и быстрым.

Отправляйте краткое резюме после каждого звонка с просьбой подтвердить договоренности всех участников встречи. Прикладывайте письмо в список ссылок на артефакты в документации в Confluence. Переносите ссылку на Confluence в код проекта. Помните: у человека, который займется расследованием происшествия спустя 4 года, должны быть зацепки, по которым он спустится к источнику истины. Вполне вероятно, что этим человеком будете вы.

Правило 3: Лучший код – тот, который не написан

Пишите лаконичный и хорошо структурированный код. Учитесь делить классы на компоненты. Используйте композицию вместо агрегации. Старайтесь избегать наследования везде, где только возможно. Чем меньше кода вы напишите, тем меньше вам необходимо будет тестировать его. Сборка проекта будет занимать меньше времени и вы сможете быстрее обучать новых сотрудников, как работать с вашей кодовой базой на проекте.

Используйте кодогенераторы для рутинных предсказуемых операций. Прекрасные возможности для экономии времени предоставляют генераторы мапперов от Mapstruct, классов из спецификации Openapi, классов из json и xml схем. При умелом использовании и настройке вы можете значительно выиграть по времени реализации по сравнению с тем, кто не использует вышеперечисленные технологии.

Не пишите код на будущее прямо сейчас. Не стоит закладывать конкретную реализацию функциональности, которая еще не до конца формализована и не понятна всем участникам процесса. Можно заложиться на будущее авансом, добавив несколько методов в интерфейс взаимодействия, которые будут возвращать стандартные ответы (или ошибки), но делать детальную реализацию на базе еще не существующих или подверженных сильным изменениям требованиям не стоит точно. Помните: всё может поменяться и строить систему можно только на прочном фундаменте. Выделите в требованиях то, что не будет претерпевать существенных изменений, и стройте систему на базе этих требований, играючи заменяя отдельные меняющиеся компоненты.

Правило 4: Всё может сломаться

Пишите код так, будто отказать может всё, что вы используете. Причиной сбоя может стать любая часть в вашем коде – от языка до операционной системы. Учитывайте в архитектуре отказ любой системы – от файлового хранилища, до брокера сообщений и базы данных.

Очень часто на проектах мы встречались с ситуацией, когда авторы системы ошибочно полагали, что все элементы системы будут работать без сбоев. Когда всё-таки что-то шло не так и отказывала важная часть системы, которая ни при каких обстоятельствах не должна была отказать, начинались проблемы: потеря данных, невозможность быстро восстановиться до работоспособного состояния, блокировки и так далее.

Старайтесь всегда “подстелить себе соломки”. Задавайте неудобные вопросы уже на этапе аналитики. Вашим лейтмотивом при разработке всегда должен быть вопрос: “А что мы будем делать, если это сломается?”.

Правило 5: Результат важнее методологий

Как разработчики программного обеспечения мы руководствуемся разнообразными принципами и методологиями при разработке. SOLID, DRY, KISS, YAGNI и многие другие. Зачастую условия проекта требуют высокой скорости реакции на возникающие вызовы и, к сожалению, мы не всегда сможем обеспечить соблюдение всех стандартов и методологий в озвученные сроки. В таких случаях мы всегда делаем ставку на результат. Переписать код можно в любой момент, а сдать проект в срок возможно только один раз.

Очень важно в таких ситуациях иметь чёткое представление о последствиях и доносить его до заказчика – мы сейчас сделаем быстро и поступившись качеством, а в следующих итерациях разработки заложим 20, 30 или 40% времени на улучшение кодовой базы. В противном случае мы рискуем получить уже через пару месяцев тяжело изменяемый, не тестируемый и практически не поддерживаемый код.

Заключение

Мы рассмотрели 5 ключевых правил, которыми руководствуются наши разработчики при работе на проектах заказчиков. Список правил далеко не исчерпывающий, но, как показывает практика, даже руководствуясь пятью данными правилами вы сможете существенно повысить качество разрабатываемого продукта и, самое главное, удовлетворенность заказчика конечным результатом.

Наша команда уже более пяти лет занимается реализацией проектов на Java и усилением команд по направлениям

За время существования компании мы принимали участие в работе над более чем 100 проектами различного объема и длительности.

Если перед вами стоят вызовы, при которых вам может пригодится наша экспертиза, просто напишите нам,

Мы договоримся с вами об онлайн-встрече, чтобы подробнее обсудить ваш проект и вашу проблему.
Александр Романюк
Team lead java dev

Еще почитать по теме:

    Обсудить проект_
    Если у вас есть ИТ-проблема, оставьте ваши контакты, и мы поможем составить план ее решения. Обещаем не слать спам.
    Нажимая, я говорю «Да»
    политике конфиденциальности
    hello@swcats.kz


    Контакты_