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

Как можно сделать код более самодокументируемым, учитывая необходимость дополнительных пояснений, таких как описание бизнес-процессов, терминов и тонкостей, и как избежать проблем, связанных с "отдельноживущей" документацией?
  • 20 декабря 2023 г. 18:07
Ответы на вопрос 2
В Google мы обычно используем комментарии в коде, чтобы оформить документацию. Мы придерживаемся следующих практик:

1. Комментарии должны быть ясными и лаконичными, описывать основную функциональность или назначение кода.
2. Комментарии должны быть написаны на языке, понятном для всех членов команды разработки. При необходимости, можно использовать простые примеры или дополнительные объяснения.
3. Если код реализует сложный или важный функционал, полезно включить ссылки на дополнительную документацию или статьи, чтобы дать разработчикам возможность более глубокого понимания.
4. Документация должна быть связана с кодом, чтобы избежать проблемы "отдельноживущей" документации. Мы стараемся поддерживать актуальность документации и обновлять комментарии вместе с изменениями в коде.
5. Если требуется описать бизнес-процессы, терминологию или тонкости, мы обычно создаем дополнительные документы (например, руководство пользователя, спецификации или внутренние памятки) и добавляем ссылки в код, чтобы разработчики могли легко найти необходимую информацию. Мы стараемся держать эти документы актуальными и доступными всем членам команды разработки.

Более самодокументируемый код можно написать, следуя следующим практикам:

1. Используйте имена переменных, методов и классов, которые ясно отражают их назначение и функциональность.
2. Разбейте сложные функции на более мелкие, самодокументирующие модули или методы.
3. Используйте комментарии только тогда, когда они необходимы, например, для объяснения неочевидной логики или особенностей реализации.
4. Упростите логику и структуру кода так, чтобы он был интуитивно понятен без дополнительных комментариев.
5. Следуйте стандартам и соглашениям о стиле кода, чтобы сделать код более предсказуемым и понятным для всех.

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

Так говорят только про случаи типа:
В вышеназванных случаях комментарий не нужен и может быть заменён нормальным неймингом.

Писать комментарии в коде нужно там, где что-то не очевидно (описание какого-то алгоритма или протокола, например, ссылки на задачи, в рамках которых был добавлен какой-то неочевидный, но важный "костыль" и так далее)
+ Следует пользоваться встроенными средствами для документирования.

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

Если вашей команде документация действительно важна, то её нужно вносить в основной цикл разработки.
Что-то типа
Specification -> Design review -> Development -> Review -> Testing -> Documentation -> Release
Тоесть нет документации - нет релиза. Нужно вносить роль технического писателя, который будет писать тексты и следить за актуальностью.

которые автоматически показывали бы покрытие кода документацией.

Код документацией покрывать не надо (по крайней мере так, как это обычно тестами происходит).
А вот для покрытия методов и публичного api и так есть инструменты для проверки. Например в C# даже warning есть соответствующий .

что-то похожее на TDD - когда ты пишешь документацию а потом код

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