Наша экспертиза и 7 принципов работы

Практически любой здоровый рабочий процесс программирования будет включать в себя проверку кода в какой-то его момент. Как бы Вы это ни делали, не вся экспертиза кода одинакова. В Лаборатории 42 у нас есть строго обязательный рабочий процесс, который включает в себя анализ кода. Это помогло нам выловить много ошибок и фрагментов неоптимального кода на ранних этапах разработки. Поэтому наша команда предоставляет такого рода услуги также и другим разработчикам.

Наши 7 принципов работы

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

Второй принцип фактически вытекает из первого. Мы стремимся понять каждую строку кода. Это важно потому, что простой элегантный код, лучше сложного. А чтобы понять действительно ли применено лучшее решение, нужно понять текущее. И если у нас возникли проблемы с пониманием кода, его, скорее всего, требуется реорганизовать, очистить или лучше прокомментировать.

Третий принцип. Мы отталкиваемся от того, что изначально код вполне может и не работать – собираем его, используя систему сборки (если она есть), и тестируем самостоятельно! В Лаборатории 42 мы также используем автоматическое тестирование.

Четвертый принцип. Комментирование имеет значение. Лаборатория 42 разработала и использует свой стандарт (комментариев, показывающих намерение – КПН), который требует, чтобы примерно в каждом логическом утверждении должен быть комментарий, описывающий намерение программиста. Предполагается, что если вы работаете над проектом, который следует этому соглашению, и вы не видите намеренный комментарий, вы должны запросить его добавление в код.
Что же касается самих комментариев, то недостаточно чтобы там просто было что-то написано. Намеренные комментарии должны фактически описывать намерение. При экспертизе кода мы посоветуем Вам решить следующие проблемы:
1. Намеренный комментарий не соответствует логике. Это указывает на то, что комментарий, код или оба неверны. Таким образом, наша команда обнаружила много потенциально неприятных ошибок!
2. Намеренный комментарий не имеет смысла. Если комментарий сбивает с толку, он так же полезен, как и вообще его отсутствие.

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

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

Седьмой принцип. Мы досконально проверяем документацию, тесты и файлы сборки. Хороший код не просто включает в себя код, он включает в себя все атрибуты, которые идут с ним. При добавлении, удалении или переименовании файлов временного кода файлы сборки должны отражать эти изменения. Точно так же, если какие-либо зависимости изменились, файлы сборки должны это отражать.