нужна помощь, если мы описываем программу которая всегда устанавливается у заказчиков типовым образом в виртуальный контейнер, то 19 серия подходит?

по сути глубокой доработки кода на стороне заказчика не происходит - передается контейнер с продуктом

На нецензурщину можно и нужно линтер вешать, чтобы нельзя было запушить в репу ничего подобного

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

линтер не вычистит креды

Это неверно. ГОСТ-34 применяется для автоматизированных систем, состоящих не только из ПО, ГОСТ-19 — к ПО.

Действительно, это неверная информация.

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

Спасибо

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

Всем привет. Меня зовут Павел Жовнер, я руковожу проектом Flipper Zero

Мои статьи на хабре: habr.com/zhovner
Еще я веду блог проекта: blog.flipperzero.one

И сейчас пытаюсь организовать огромную техническую документацию по проекту docs.flipperzero.one
------------

Мы с коллегами опробовали все движки для тех. документации, от mkDocs и прочих генераторов на markdown, до сервисов вроде readme.com и прочих.

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

Интересно найти единомышленников и людей с опытом в этой теме. Можно я буду здесь задавать вопросы о том кто какие инструменты и как использует?

Это Супергерой который нужен городу

Видимо, плохо пробовали.

Спасибо, очень ценное замечание

А как именно вы поняли, что движков нет? Каковы ваши специфические задачи?

Я тут недавно кидал ссылку на свою статью как раз по выбору генератора статических сайтов. Безбожная реклама себя, но правда будет в тему.

Воть

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

ой, ой, зачем я поглядела дальше... Вот вам запятых: ,,,,,,,,,