Вам в наследство досталось руководство пользователя МИС на 1160 страниц в формате .docx, тысячи повторяющихся скриншотов, процесс обновления вызывает глубокую грусть. Что с этим «добром» делать?
В этой статье я расскажу о своём проекте по переводу такой документации на рельсы docs-as-code: переосмысление структуры, укрощение размера скриншотов, борьба с кириллицей в Asciidoctor, настройка автоматической сборки HTML и PDF через GitLab CI/CD.
В работе аналитика 1С хватает задач, которые находятся между обсуждением потребности заказчика и разработкой: оформить требования, проверить связи объектов, собрать пример решения, подготовить сценарии испытаний.
В данный момент я постепенно делегирую свои процессы ИИ и агентам, для построения своего процесса так, чтобы сократить время на формирование документации, подготовку анкет для интервью и подведение итогов обследований.
Пока для себя выделил четыре направления, в которых на текущий момент получилось его использовать.
Документация. Само это слово стало синонимом нерешаемой проблемы.
Цитата одного менеджера:
“Разработчики держат знание на кончиках пальцев”.
Цитата меня:
“Одних нужно заставлять писать,
других нужно заставлять читать,
третьих нужно заставлять заставлять”.
Итоговое соотношение цена/скорость/качество это то, о чём не принято говорить вслух.
ИИ пока не спасает ситуацию. На больших кодовых базах он ожидаемо упускает контекст и галлюцинирует.
Читать полностью »
Привет, мир. Хочу начать немного с себя: меня зовут Дмитрий, я 15 лет профессионально занимаюсь разработкой ПО. Поработал в крупных компаниях и госучреждениях, последние 8 лет занимал должность руководителя разработки, а полгода назад вышел из найма — чтобы сбить оскомину от заказной разработки, изучить новые технологии в сфере ИИ и пропустить эти знания через свой опыт.
README редко ломается в один момент. Обычно документация постепенно перестаёт соответствовать проекту: переименовали команду, перенесли файл, удалили .env.example, поменяли package manager или Docker service, а инструкция осталась прежней.
Сначала мы делали вид, что ничего не происходит.
Портал документации то открывался, то нет. Кто-то из коллег замечал, обновлял страницу, всё грузилось — ну ок, и мы шли дальше. Так продолжалось пару месяцев, пока «то работает, то нет» не превратилось в «чаще не работает». Портал жил на GitBook, большая часть пользователей у нас из России, и в какой-то момент эти два факта перестали быть совместимы — но признавать это очень не хотелось.
Привет!
Буду с вами честен, для меня читать сухие переводы документации или смотреть 40-часовые видеокурсы - то еще удовольствие. Поэтому я решил устроить эксперимент и разбирать Go прямо в публичном поле, шаг за шагом документируя весь процесс.
Я не новичок в разработке - повседневно пишу на Python и TypeScript, знаком с базовым devops. Но вот на территорию Go осознанно захожу впервые.
Я возьму за основу официальный трек обученияЧитать полностью »
Недавно на Хабре вышла статья Ивана Потапенко «Зачем и как избавляться от незаменимых сотрудников». Там про bus factor, про бутылочное горлышко, про ротацию, про дубляж знаний и работу вслух. Выглядит убедительно. Автор с 20 летним опытом, управлял отделами, доклад на конференции. Но есть одна проблема.
Иван описал идеальную команду в идеальном мире. Мир, где все хотят читать документацию. Где сотрудники сами пишут статьи в Wiki. Где ротация воспринимается с энтузиазмом, а не как «опять этот менеджер придумал». В реальности живут другие люди.
Всем привет. Меня зовут Никита, я руковожу командой Цикл-ОН. Мы уже более 5 лет ведем проекты по заказной разработке ПО и, как и многие, сталкиваемся с необходимостью разработки не только качественного кода, но и документацию на продукты. В нашей нише особенность, что заказчики живут в парадигме ГОСТа. Я бы здесь хотел оставить небольшую заметку о нашем опыте — как то, что для начаиналось как откровенное мучение превратилось сначала в умную идеологию, а по итогу в самостоятельное решение для подготовки документации — Платформа «ГОСТ‑ОН».
