Как правильно составить документацию для проекта на C++?

Как можно дополнительно документировать проект на C++ (около 20к строк), чтобы улучшить его понимание новичками, помимо Doxygen? Рассматривается возможность применения UML для описания не только отдельных функций и классов, но и целых модулей.
  • 15 января 2024 г. 8:28
Ответы на вопрос 2
Документация является ключевым элементом любого проекта программного обеспечения, так как позволяет новым разработчикам быстрее понять структуру и логику работы кода. Вот несколько способов, как можно улучшить документацию проекта на C++:

1. **Использование Doxygen**
   Doxygen – это наиболее популярный инструмент для создания документации в коде на C++, который может автоматически генерировать документацию из исходных файлов. Убедитесь, что вы максимально используете возможности Doxygen. Используйте теги \brief, \param, \return, \details для описания функций и классов, и \page или \section для структурирования документации на более высоком уровне.

2. **UML Диаграммы**
   UML диаграммы могут очень помочь в визуализации структуры и взаимодействия компонентов системы. Включение таких диаграмм как Диаграммы классов (Class Diagrams), Диаграммы последовательности (Sequence Diagrams), и Диаграммы состояний (State Diagrams) поможет новым сотрудникам лучше понять архитектуру системы. Инструменты вроде PlantUML или StarUML могут быть полезны для создания UML диаграмм.

3. **Техническая Спецификация**
   Помимо кода и встроенной документации, полезно составить техническую спецификацию, которая детально описывает архитектуру системы, используемые паттерны проектирования, интерфейсы взаимодействия между модулями, алгоритмы и ключевые концепции.

4. **Руководства пользователя и разработчика**
   Руководства пользователя и разработчика помогают понять, как работает система, и как работать с кодом. Они должны включать примеры использования, шаги для настройки окружения, процедуры сборки и установки.

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

6. **Wiki или FAQ**
   Создание внутреннего Wiki или FAQ, где расписаны ответы на часто задаваемые вопросы, может сэкономить время разработчиков.

7. **Чейнджлог**
   Не забывайте вести чейнджлог (журнал изменений), где будут отражены все значимые изменения в проекте.

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

Если вспомнить умозаключение Боба Мартина из книги "Чистый код". Чистый код не требует документирования или требует, но не значительного. Чистый код — это код, который легко читать, понимать и изменять другими разработчиками. Он является выразительным, кратким и организованным.

В своей практике я встречал 3 подхода к документированию:
- Нет документирования (лишь комментарии к отдельным блокам кода)
- Документируют, но только то что захотели
- Документируют все

Когда я документирую что-либо я стараюсь показать 2 вещи:
- структуру без реализации (реализацию можно посмотреть в коде)
- бизнес задачу/ бизнес подход (для чего это нужно?)

Читал статью (оч. давно) про чрезмерное документирование... Но ни разу не встречал.

Чаще всего я видел документирование через MarkDown, UML, OpenAPI, Swagger, просто использование интерфейсов.

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

UML отлично подойдет для описания отношения (классов/объектов) или для взаимодействия модулей. Ни разу не использовал UML для описания (функций/методов), но почему бы и нет? Были случаи когда я использовал просто блок схему для описания поведения (функции/метода)...

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