Советы принял
Я вот тоже после ресерча склоняюсь к тому что лучше держать рядом с соответствующим кодом в репозиториях

Для себя понял что это эффективно и к счастью маркдаун настолько приятен что описывать и оформлять доки вообще одно удовольствие, чем разбираться с замудренными вики.

Да, генерирование документации само собой.
просто тут возникают нюансы когда проект мультиязычный… (имеется ввиду зоопарк языков программирования), тогда автогенерация это боль.
Разве что swagger.. реализация автогенерации под разные языки более менее вменяемая.
Печаль только что он заточен исключительно для описания ввода вывода API в основном.

@this_self это вообще лучший вариант, но если есть менеджеры которые не умеют гит - то можно confluence. Но лучше всего когда вместе с кодом или функционалом к нему же пишется дока в md. А md на самом деле можно в портал оформить с документацией

менеджеров которые не умеют гит нужно уволить и проблем нет

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

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

Если чеговек не может гитхаб или гитлаб через веб даже, то он просто профнепригоден, сори

Согласен
В общем с этим проблем нет, к счастью все в компании могут открыть веб страничку и по знакомым словам мышкой потыкать :D

Халва Аллаху!

удобно еще то, что рядом с гитом есть issues-трекер, можно создавать issues, привязывать их к определенным пул реквестам и коммитам и это вообще очень радостно трекать.

документация отдельно от кода, может быть только высокоуровневым описанием работы сервиса(модуля, app) и его запуска, все остальное автогенерация! иначе через некоторое время она не будет соответсвовать тому, что в коде с вероятностью 99%. Очень трудно сапортить актуальность, особенно на больших проектах. Мы используем swagger для API и compodoc для всего остального.

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

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

Как раз фичи, которые просят юнит тестов имеют высокую вариативность и описать её в документации порой долго.

Юнит тесты, функциональные тесты и дока на АПИ снижают объем текста в обычной документации. Как правило в проекте остаётся одна две сложные бизнесовые части, которые и нужно описать текстом.

Compodoc очень интересно, спасибо.
Жаль что только для ангуляра.

И ещё вопрос об организации разработки вообще.

Есть ли тут динозавры, которые используют unfuddle?
Ну Jira / confluence это понятно, оно популярно.

Что может быть хорошей заменой для unfuddle? Скажем, где можно создавать тикеты, затем привязывать их к комитам, и в общем с гитом внутри.
Где можно делать доку на группу проектов, который включал бы в себя несколько репозиториев.
И чтобы оно маркдаун умело адекватно красиво отображать ))

он не только для ангуляра. Мы на nestjs его используем. При желании можно разобраться как его туда всунули, и подключить к своему проекту.

Привет

Помогите плез з задачей , если можете

Давай спершу задачу

Объективно, давай задачу 😅

Я только вопросы умею предсказывать... (
Без задачи не могу (

Уже не надо , сам разобрался и написал . Всё получилось

кому-то приходилось делать профилирование ноды, какие-то посоветуете инструменты или лучше просто обойтись встроенным?