KISS и делай код-ревью

Код-ревью - залог качественного кода, не считая хорошего программиста, который пишет этот код :) В этом наша команда стойко уверена, поэтому код-ревью у нас относится к правилам хорошего тона. Для чего он нужен? Для того, чтобы максимально очистить код от возможных ошибок и запутанных решений, ведь большинство отчасти придерживается именно метода KISS (Keep It Simple, Stupid! - «Делай это проще, тупица!»). И с этим не поспоришь, чем проще и яснее код, тем лучше, главное, не переборщить с упрощением. Да, процесс проверки и внесения правок не быстрый, но мы ему уделяем внимание и вам советуем.

Итак, цель данной статьи поделиться нашим подходом к проверке кода, и быть как всегда полезными для вас. Поскольку в нашей компании есть фронт/бекэндеры и фуллстеки, то этапы код-ревью затронут обе стороны медали.

 

Общие принципы ревью кода:

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

2. Легко ли читается код? Существуют ли функции с 5+ аргументами? Нет ли файлов на 500-1000+ строк, а если есть - то можно ли с ними что-то сделать?

3. Используются ли устаревшие конструкции (var, callback hell)?

4. Как работают алгоритмы? Их сложность. Микро-оптимизации (например, замена map на for) иногда нужны, но к ним стоит возвращаться позже. Но, например, заменить постоянный опрос сервера на websocket может быть полезным.

5. Можно ли поведение нескольких похожих методов объединить в один, не ухудшая понимание функционала?

 

Фронтэнд:

1. Обратить внимание на то, как описан роутинг. Защищены ли роуты от юзеров, не имеющих соответствующие права? Как настроены редиректы? Разделяется ли на чанки, если это возможно?

2. Обратить внимание на то, как описан стор и стейт компонентов. Дублируются ли данные, можно ли их вычислить мемоизаторами и селекторами? Как описываются редьюсеры в сторах, нет ли нагромождения, можно ли их разнести по разным доменам?

3. Как происходит стилизация приложения? Как инкапсулируются стили, чтобы не было пересечений классов в будущем?

4. Разделена ли архитектура на модули, чтобы не смешивать стор с отображением и с запросами в сеть?

5. Соблюдается ли код-стайл, принятый на проекте? Настроены ли линтеры? И настроены ли они так, чтобы не отвлекать разработчика и при этом находить потенциальные ошибки в коде?

6. Специфичные выбранной технологии вещи. Например, в React есть проблема с перерендерингом компонента по множеству раз и, чтобы улучшить производительность, надо использовать PureComponent, мемоизировать данные и так далее.

 

Бекэнд:

1. Легко ли добавить новый ендпоинт в систему?

2. Насколько понятно ведется работа с БД?

3. Насколько детально выделены слои и сущности (мидлвейры, сервисы, утилиты, контроллеры, роуты, модели и тд)?

4. Учитываются ли пограничные условия при проверке входящих данных в методах и контроллерах?

5. Как ведется логирование ошибок и каким образом они формируются и отдаются клиенту?

6. Как происходит работа с event-loop (нет ли где-то блокирования потока)?

 

Совет от нас - смотри на код, задавай себе эти вопросы, расчищай, упрощай и повышай его качество.