Всем привет!
Сегодня хотел бы поднять такую тему - что должно быть в проекте сервиса (в исходниках)?
Кроме собственно кода и файлов с настройками.
1) readme.md
Наличие: обязательно.
Содержимое: описание проекта, его идентификатор (для DevOps pipeline или в вашем реестре сервисов), описание вариантов сборки (отладка, запуск модульных и интеграционных тестов, чистовая сборка), структура каталогов, возможно важные особенности сборки
2) .gitignore
Наличие: обязательно
3) test.http
Наличие: крайне желательно
Содержимое: список URL для отладки на localhost в формате, который понимает IntelliJ IDEA
4) IDEA run configuration
Наличие: крайне желательно
Да, конфигурации тоже можно сохранять. Особенно полезны для больших проектов, допускающих отладку отдельных частей для скорости.
5) скрипты и настройки CI
Наличие: крайне желательно
Часто скрипты меняются вместе с кодом, лучше держать их вместе
6) todo.md
Наличие: желательно
Содержимое: техдолг с точки зрения разработчиков сервиса. Я специально делаю акцент на происхождение, т.к. еще есть внешний техдолг от архитекторов, сопровождения, ИБ, его обычно заводят в JIRA. Почему бы и внутренний техдолг не завести в JIRA? Можно, но есть два риска: если работа идет не по Scrum - задача потеряется в недрах системы, если работа идет по Scrum - слишком рьяный Scrum мастер в рамках гигиены JIRA может настоять на удалении задачи как непонятной\неактуальной. Храня же техдолг вместе с кодом мы можем свободно уточнять формулировки, разбивать на более мелкие задачи для последующего переноса в JIRA с взятием в ближайший спринт.
7) Maven или Gradle wrapper
Наличие: желательно, чтобы не зависеть от наличия утилиты в среде сборки
8) профили checkstyle и ему подобных утилит статического анализа кода
Наличие: возможно, если требуется подстройка для вашего сервиса
9) статическая часть папки .idea
Наличие: возможно по договоренности с командой
10) settings.xml для Maven
Наличие: возможно если они меняются от проекта к проекту
11) документация, естественно через автогенерацию
Наличие: возможно, особенно для библиотек
P.S. Еще может возникнуть вопрос про схемы API - их лучше держать отдельно, чтобы физически разделить интерфейс и реализацию.
#sources
Сегодня хотел бы поднять такую тему - что должно быть в проекте сервиса (в исходниках)?
Кроме собственно кода и файлов с настройками.
1) readme.md
Наличие: обязательно.
Содержимое: описание проекта, его идентификатор (для DevOps pipeline или в вашем реестре сервисов), описание вариантов сборки (отладка, запуск модульных и интеграционных тестов, чистовая сборка), структура каталогов, возможно важные особенности сборки
2) .gitignore
Наличие: обязательно
3) test.http
Наличие: крайне желательно
Содержимое: список URL для отладки на localhost в формате, который понимает IntelliJ IDEA
4) IDEA run configuration
Наличие: крайне желательно
Да, конфигурации тоже можно сохранять. Особенно полезны для больших проектов, допускающих отладку отдельных частей для скорости.
5) скрипты и настройки CI
Наличие: крайне желательно
Часто скрипты меняются вместе с кодом, лучше держать их вместе
6) todo.md
Наличие: желательно
Содержимое: техдолг с точки зрения разработчиков сервиса. Я специально делаю акцент на происхождение, т.к. еще есть внешний техдолг от архитекторов, сопровождения, ИБ, его обычно заводят в JIRA. Почему бы и внутренний техдолг не завести в JIRA? Можно, но есть два риска: если работа идет не по Scrum - задача потеряется в недрах системы, если работа идет по Scrum - слишком рьяный Scrum мастер в рамках гигиены JIRA может настоять на удалении задачи как непонятной\неактуальной. Храня же техдолг вместе с кодом мы можем свободно уточнять формулировки, разбивать на более мелкие задачи для последующего переноса в JIRA с взятием в ближайший спринт.
7) Maven или Gradle wrapper
Наличие: желательно, чтобы не зависеть от наличия утилиты в среде сборки
8) профили checkstyle и ему подобных утилит статического анализа кода
Наличие: возможно, если требуется подстройка для вашего сервиса
9) статическая часть папки .idea
Наличие: возможно по договоренности с командой
10) settings.xml для Maven
Наличие: возможно если они меняются от проекта к проекту
11) документация, естественно через автогенерацию
Наличие: возможно, особенно для библиотек
P.S. Еще может возникнуть вопрос про схемы API - их лучше держать отдельно, чтобы физически разделить интерфейс и реализацию.
#sources