Архив
● Форум в архиве

Форум сообщества Zettelkasten работал с 2021 по 2026 год. Читать можно всё, писать — уже нет. Вся жизнь сообщества теперь — в книжном клубе ККРА: встречи, задания, записи и разговоры.

В книжный клуб →
Архив форума / Делимся опытом

Документация больших и 'пёстрых' софтовых проектов

15 сообщений · 469 просмотров 8 сентября 2022 — 10 сентября 2022
Hoodoo #1

Вроде тут были технические писатели в том числе.

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

Поделитесь опытом, что на эту тему есть почитать и с самого начала предусмотреть внедрение.

Я не знаю, глоссарии, трансклюзия, шаблоны, всё что угодно.

Тема — сопровождение софта, упор на типовые инструкции, наверное.

Уточнение: основная проблема не в стиле и не в стандартах. Основная проблема в том, что документацию должно быть удобно поддерживать сотрудникам из разных команд.

♥ 1
Рустам@Rustam #2

Я бы попробовал что-то рассказать, но больше собирал методологии :slight_smile:

Описывал бизнес процессы и потом менял документацию по мере необходимости. Такая была у меня инструкция пользования АЗС, листов на 200-300

Gudleifr #3

Три очевидных варианта:

  1. По стандарту той конторы, куда будете представлять.
  2. По ГОСТ.
  3. По нормам GitHub.
♥ 1
Рустам@Rustam #4 · ↩ #3

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

Правильно понимаю?

Gudleifr #5 · ↩ #4

Скорее всего, нет. Большинство серьезных контор требуют документацию, весящую больше, чем сама программа.

Рустам@Rustam #6 · ↩ #5

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

Но справедливости ради, грамотная и структурная документация сильно упрощает жизнь.

♥ 1
Gudleifr #7 · ↩ #6

Прогресс бы вымыл. Но он давно закончился.

♥ 1
Hoodoo #8

Кое-какую идею я нащупал и сейчас с ней играюсь. Идея почёрпнута в общих чертах из чатика и форума, и вот в чём она заключается.

1: В основном люди пишут документацию в виде огромных портянок, которые страшно лишний раз трогать
2: То, что очевидно для одного человека, может оказаться неочевидным для другого.
3: Разные люди отвечают за разные аспекты поддержки приложения

Берём идею атомарных заметок, трансклюзию, шаблоны, немного иерархии и немного тегов.

Иерархия выглядит, допустим, следующим образом:

  • Служебная директория
    • Глоссарий
    • Выкладка
    • Мониторинг
  • Документация разработчиков
  • Документация сопровождения

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

Когда нужно составить документ для разработчиков или администраторов, мы набираем из служебной директории “кубики”. На “кубики” вешаются тэги.

Внутри документов, которые используют люди с помощью плагина “контент по тегу” кубики компонуются в нужном порядке: все определения, описания операций, контакты, что угодно.

“Человеческие” документы состоят из объяснений, как стыкуются между собой части и почему так сделано.

Может получиться интересно.

Gudleifr #9 · ↩ #8

Попытка применить Zettelkastel-подобную схему в программировании называлась Literate Programming - разбиение программы при написании на маленькие фрагменты с указанием ссылок и документированием. Потом две отдельные программы делали из этой заготовки программу и полную документацию (с оглавлениями и глоссарием). К сожалению, это, как раз и привело к появлению

В обычных производственных системах документирования такого не бывает, наоборот, старая портянка копируется почти без изменений. Вплоть до:
1-ое изделие: Надо разобраться: полгода тебе на анализ, три месяца - на отчет.
2-ое изделие: Ну анализ почти такой же, как и в первый раз, новый только отчет, три месяца на все.
3-е изделие: Знаешь, изделие-то еще и не начинали делать, но пока отчет напишешь, месяца за три, может, сделают?

Hoodoo #10 · ↩ #9

Это не принцип zettelkasten, это обычная декомпозиция.

Для каждого сервиса есть графички, метрички, текущие открытые таски, процедуры, мониторинг, деплой.

Описывается каждый кусок отдельно. Куски по необходимости собираются инклюдами в документы: свой набор для QA, свой для админов и т.д.

Теги и ссылки по вкусу.

Я щас сделал прототип в Confluence, мне нравится. Но вообще оно независимо от вики, могу аналогично в Org-mode накидать.

Главное не упороться.

♥ 1
Hoodoo #11 · ↩ #4

Задача была несколько сложнее, но мне кажется я подход нащупал.

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

Рустам@Rustam #12 · ↩ #11

Мне крайне интересно посмотреть что получиться. Хотя бы на кусочек.

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

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

Hoodoo #13 · ↩ #12

Если я эту фигню продам, постараюсь что-нибудь где-нибудь развернуть для демонстрации.

Да даже если и нет.

♥ 1
Дмитрий Н@dimonier #14
  1. Атомарные блоки документации лучше писать в простом формате: markdown, asciidoc, rst.
  2. Готовые руководства лучше собирать отдельно под каждую целевую аудиторию (пользователи, админы, поддержка, разработчики, …).
  3. Формат готовых руководств - online html с хорошим поиском + загружаемый pdf. В виде ваулта мало кто оценит, наверно :grin:
  4. Как именно структурировать информацию, подсмотрите в документации по похожим продуктам Яндекс, Google.
  5. Глоссарий и стилистическое руководство с определенного уровня зрелости документации должны быть.
♥ 2
Hoodoo #15 · ↩ #14

1 и 2 - шо я и подумал

По остальным пунктам есть нюанасы.

♥ 1
● Продолжить разговор

Обсуждение закрыто вместе с форумом. Поговорить об этом можно в книжном клубе ККРА — там теперь живёт сообщество.

В книжный клуб →