Имеется проект, над которым работают 2-3 человека. Нет никакого желания разводить бюрократию и ставить какие-то софты для багов. По сути сейчас всё в текстовом файлике TODO в свободной форме. Нашёл баг или что-то, что можно улучшить — записал туда.
Хочется сделать шаг вперёд и как-то улучшить этот файлик. Т.е. сделать его структурированным, чтобы можно было по нему какие-то запросы делать, но при этом он оставался простым текстовым файликом. Ещё в идеале как-то это всё синхронизировать с git, т.е. я делаю изменение, проставляю задаче статус в файлике, коммичу этот файлик вместе с остальными исходниками и в истории VCS это видно. Но, повторюсь, не слишком большой шаг вперёд, до полноценного багтрекера ещё не доросли.
Можно, наверное, это самому всё изобрести, по сути я это вижу, как что-то вроде HTTP, типа
Type: Refactoring
Priority: Low
Status: Open
Summary: Refactor bla.foo.FooBar
FooBar слишком разросся, нужно проанализировать его, вероятно выделить Parser и Formatter.
но если просто это всё руками вбивать, как-то многовато писанины...
Так же думал о том, чтобы вести подобные записи прямо в исходниках. Та же Idea умеет собирать TODO со всех файлов в один агрегированный список. Но непонятно, что с новыми фичами делать или с багами, которые непонятно, куда относить.
Вообще проектов в репозитории около десятка и все мелкие, если это имеет значение. Связей между ними нет (кроме пары общих модулей-библиотек). Для разработки используется Idea, языки Java и Kotlin.
Здравствуйте, vsb, Вы писали:
vsb>Хочется сделать шаг вперёд и как-то улучшить этот файлик. Т.е. сделать его структурированным, чтобы можно было по нему какие-то запросы делать, но при этом он оставался простым текстовым файликом.
Можете в текстовый файлик дописывать метки для каждой задачи. Просто пишите около каждой задачи пометки типа [bug] [feat] [open] [close] [refactoring] [cur-release] [next-release] и т.п (искать по ctrl-f). На основе меток достаточно сложные процессы можно реализовать.
P.S. Надо идти от целей. Почему перестал устраивать файлик? Зачем делать запросы?
можно в той же Idea поставить плагин и так как он в виде текста всё хранит то там и записывать, а CVS будет вполне нормально его мерджить, а тикеты и инфу хранить прямо в сырцах проекта если что (как сделано например у постгрес дб)
Здравствуйте, vsb, Вы писали:
vsb>Хочется сделать шаг вперёд и как-то улучшить этот файлик. Т.е. сделать его структурированным, чтобы можно было по нему какие-то запросы делать, но при этом он оставался простым текстовым файликом.
По сути лучшим способом структурировать что-то ничего не изобретая это использовать файловую систему. Если все задачи находятся в одном текстовом файле, то можно для каждой создать свой текстовый файл. Таким образом получается естественный багтрекер или даже менеджер задач. Далее файлы задач можно перемещать между папками, к примеру, категорий, статуса, исполнителя.
Как вариант статус и прочие атрибуты могут быть выражены в имени файла. Использование разных файлов во многом устраняет проблему слияния, которая присутствует когда несколько человек работает над одним проектом и одновременно изменяет один файл. Опять же никто не мешает ставить в задачах и кодах специальные метки, которые потом можно искать текстовым поиском по файлам.
Здравствуйте, vsb, Вы писали:
vsb> Хочется сделать шаг вперёд и как-то улучшить этот файлик. Т.е. сделать его структурированным, чтобы можно было по нему какие-то запросы делать, но при этом он оставался простым текстовым файликом. Ещё в идеале как-то это всё синхронизировать с git, т.е. я делаю изменение, проставляю задаче статус в файлике, коммичу этот файлик вместе с остальными исходниками и в истории VCS это видно. Но, повторюсь, не слишком большой шаг вперёд, до полноценного багтрекера ещё не доросли.
git-bug или git-issue не подойдет? Они умеют синхронизироваться с git. Есть еще старый добрый fossil-scm, у него под капотом обычный SQLite, который можно дампить/ресторить в sql.txt.
спрашивал у Олега Бартунова (postgres-pro) как они хранят документацию по разработке проекта, он сказал, что в каждом пакете хранится README файл в который надо вносить изменения по мере работы и таким образом хранится рабочая дока по проекту в довесок к исходникам, я сам в их исходниках не копался, но на фоне того в какую мусорку превращаются всякие конфлюэнсы, в этом что-то есть
Здравствуйте, vsb, Вы писали: vsb>Можно, наверное, это самому всё изобрести, по сути я это вижу, как что-то вроде HTTP, типа vsb>
vsb>Type: Refactoring
vsb>Priority: Low
vsb>Status: Open
vsb>Summary: Refactor bla.foo.FooBar
vsb>FooBar слишком разросся, нужно проанализировать его, вероятно выделить Parser и Formatter.
vsb>
vsb>но если просто это всё руками вбивать, как-то многовато писанины...
Почитал другие комментарии, если нужна документация в виде плоского текста, но с возможностью переделки в html, то пока самое лучшее, что нашёл это asciidoctor без сторонних генераторов статических сайтов. В данном случае ручная писанина это плюс, а не минус. Есть возможность создавать документацию на большинстве языков программирования с синтаксической подсветкой и встраиванием из файлов по ссылке. И там полный фарш от оформления до встройки изображений, видео с ютуба, генерируемых диаграмм plantuml и syntrax, математических формул и многого другого. А ещё работает трюк с фреймами, когда можно по правилу трёх кликов создать документацию, где первый клик в левом фрейме это основной раздел, второй клик там же вторичный, а третий уже в правом фрейме по созданному оглавлению.
Генератор сайта может выглядеть как-то так:
site_generator.sh
#!/bin/bash
# directories
current_directory="$PWD"
source_directory="/mnt/data_00/archive/develop/"
destination_directory="/mnt/data_00/archive/sites/develop/"
# files
parameter_file="*.txt"
parameter_maxdepth="-maxdepth 0"
# toc
parameter_toc="-a toc=macro"
# translate
parameter_toc_title="-a toc-title=\"Оглавление\""
parameter_figure_caption="-a figure-caption=\"Изображение\""
# source
parameter_source_highlighter="-a source-highlighter=pygments"
parameter_pygments_linenums_mode="-a pygments-linenums-mode=inline"
parameter_pygments_style="-a pygments-style=native"
# math
parameter_asciidoctor_diagram="-r asciidoctor-diagram"
parameter_stem="-a stem"
# style
parameter_nofooter="-a nofooter=true"
parameter_stylesheet="-a stylesheet=/mnt/data_00/archive/develop/boot-darkly.css"
for index_directory in `find $current_directory $parameter_maxdepth -type d`
do
# set directories
cd $index_directory;
relative_directory=$destination_directory`realpath --relative-to=$source_directory $index_directory`;
# run asciidoctor
asciidoctor `
`$parameter_toc `
# translate
`$parameter_toc_title `
`$parameter_figure_caption `
# source
`$parameter_source_highlighter `
`$parameter_pygments_linenums_mode `
`$parameter_pygments_style `
# math
`$parameter_asciidoctor_diagram `
`$parameter_stem `
# style
`$parameter_nofooter `
`$parameter_stylesheet `
# other
`-a icons=font `
`-a experimental=true `
# path
`-D $relative_directory `
`$parameter_file
# show result
echo from ${relative_directory} to $index_directory;
done
for index_directory in `find $destination_directory -type d -name ".asciidoctor"`
do
rm -rf $index_directory;
echo remove directory $index_directory;
done
Генератор хоть и работающий, но сильно недоделанный, однако для примера идеи сойдёт. Из source_directory где лежит код, документация и всё что угодно в destination_directory с повторением структуры папок генерируются файлы html. А current_directory и глубина вложения -maxdepth служат ограничениями, чтобы не генерировать слишком много за раз.
результат
А в чём спрашивается отличие? Отличие в том, что становится доступным форматирование. К примеру, в виде таблицы можно было бы написать вот так:
[cols="0,1",frame=topbot]
|===
|Type |Refactoring
|Priority|Low
|Status |Open
|Summary |Refactor bla.foo.FooBar
|===
FooBar слишком разросся, нужно проанализировать его, вероятно выделить
Parser и Formatter.
Но при этом это по прежнему текст, и его можно даже переносить если есть ограничение по длине строки. Если говорить о форматировании, то тот же markdown уступает asciidoctor. Основная же суть это использование в основном текста, а не чего-либо другого требующего WYSIWYG редактор или какие-то нестандартные средства, но с перспективной генерации более сложного оформления в виде html, pdf и так далее. Если оформление не требуется и будет использоваться лишь плоский текст, то по идее можно писать как вздумается.
А идея всё та же, использования файловой системы для структурирования кода, задач, багов, документации и прочего, вместо сторонних инструментов.
Здравствуйте, vsb, Вы писали:
vsb>Имеется проект, над которым работают 2-3 человека. Нет никакого желания разводить бюрократию и ставить какие-то софты для багов.
Ставить ничего и не надо. Достаточно просто завести платный аккаунт на гитхабе. Там все просто, я бы сказал примитивно.
Здравствуйте, Ночной Смотрящий, Вы писали:
vsb>>Имеется проект, над которым работают 2-3 человека. Нет никакого желания разводить бюрократию и ставить какие-то софты для багов.
НС>Ставить ничего и не надо. Достаточно просто завести платный аккаунт на гитхабе. Там все просто, я бы сказал примитивно.
Рабочее место в закрытой организации, там с интернетом всё сложно. Нужно оффлайн-решение.
Здравствуйте, vsb, Вы писали:
vsb>Имеется проект, над которым работают 2-3 человека. Нет никакого желания разводить бюрократию и ставить какие-то софты для багов. По сути сейчас всё в текстовом файлике TODO в свободной форме. Нашёл баг или что-то, что можно улучшить — записал туда.
vsb>Хочется сделать шаг вперёд и как-то улучшить этот файлик. Т.е. сделать его структурированным, чтобы можно было по нему какие-то запросы делать, но при этом он оставался простым текстовым файликом. Ещё в идеале как-то это всё синхронизировать с git, т.е. я делаю изменение, проставляю задаче статус в файлике, коммичу этот файлик вместе с остальными исходниками и в истории VCS это видно. Но, повторюсь, не слишком большой шаг вперёд, до полноценного багтрекера ещё не доросли.
Ха, задачку с вот буквально таким же ТЗ мы решали (тоже для себя) несколько лет назад (и я помнится тогда даже писал об этом на этом форуме). Причём наше решение (несколько экранов кода на Питоне) имеет продвинутый GUI в стиле современных систем контроля задач. Но в отличие от них является полностью децентрализованной — живёт в репозитории проекта. Единственная разница, что у нас Mercurial, а не Git является "транспортом", но это вообще никак не влияет.
Здравствуйте, vsb, Вы писали:
vsb>Имеется проект, над которым работают 2-3 человека. Нет никакого желания разводить бюрократию и ставить какие-то софты для багов. По сути сейчас всё в текстовом файлике TODO в свободной форме. Нашёл баг или что-то, что можно улучшить — записал туда.
Собственно, нормальный вариант, только свободную форму лучше заменить более-менее формальной.
Я обычно делал так,
символы ! ? . x и тд в начале строчки означают статус, приоритет и тд.
! — критично, !!! — ппц
? — ахез — непонятная проблема или просто вопрос, на который надо раскопать ответ, ??? — происходит непойми что. Обычно или закрывается, или переформулируется.
+ готово
— делать не будем
% — в процессе
x готово и закрыто — такие уходят в архив
f фича
F приоритетная фича
далее в этой же строчке идет тайтл. Внутри тайтла идут теги. На следующей строке — подробности.
Разделитель между задачами — новая строка.Поскольку вы работаете вместе, то основные задачи люди будут худо-бедно представлять, а соответсвенно много задач будет однострочниками.
Подзадачи идут без разделителя, с отступом
В целом тайтл должен быть максимально коротким, но понятным.
Первая часть файла — фичи, середина — баги, хвост — архив. Структура архива сначала фичи, потом баги.
Общий протокол доступа — один человек правит структуру, добавляет тикеты, убирает в архив, другие только меняют статус, формулировки и тд, ничего не двигают, что бы не было проблем с мержем. Файл должен быть максимально diffable
Выглядело примерно так:
F [what-if] анализ
+F [hierarchy] анализ
??? [OutOfMemory] при свободном хипе:
непойми что, потенциально из System.Drawing
+ памяти валом
+ фрагментация слабая
% LOH
? воркараунд - все найденные примитивы врапать в try-catch с игнором OOM
! [OutOfMemory] [draw.line] длиной менее пиксела
% [OutOfMemory] [draw.arc] радиусом менее пиксела
. [OutOfMemory] [draw.line] конская длина
--ARCHIVE--
xf [collapse] режим
x! [hangs] [draw.line][dashed] конские координаты
Здравствуйте, vsb, Вы писали:
vsb>Имеется проект, над которым работают 2-3 человека. Нет никакого желания разводить бюрократию и ставить какие-то софты для багов. По сути сейчас всё в текстовом файлике TODO в свободной форме. Нашёл баг или что-то, что можно улучшить — записал туда.
достоинство:
* все таски лежат вместе с кодом, с рабочей копией можно ездить в командировки где нет доступа к интернету
недостатки:
* не развивается уже 10 лет
* когда я на него смотрел много лет назад, когда он еще развивался у него были проблемы с языками отличными от английского
(толи совсем нельзя по русски писать, толи только название тасков)
Здравствуйте, vsb, Вы писали:
vsb>Имеется проект, над которым работают 2-3 человека. Нет никакого желания разводить бюрократию и ставить какие-то софты для багов. По сути сейчас всё в текстовом файлике TODO в свободной форме. Нашёл баг или что-то, что можно улучшить — записал туда.
vsb>Хочется сделать шаг вперёд и как-то улучшить этот файлик.
Сделай сразу нормально. У JIRA есть докер образ, возьми её и поставь. Потом прикрутишь интеграцию с git и вам хватит на 100 лет.
