Как лучше документировать разработку программы.

Вопросы программирования и использования среды Lazarus.

Модератор: Модераторы

Re: Как лучше документировать разработку программы.

Сообщение wofs » 04.05.2018 21:28:08

Mirage писал(а):А писать приходящие мысли в веб решение это нонсенс.
Они убегут, я даже залогиниться не успею. :)

Я пишу сюда: pyrus.com
Есть клиенты на телефон (iOS/Android), работающие оффлайн и умеющие при появлении интернета синхронизацию.
Можно всякие меточки ставить, сроки и т.п.
Мне бесплатного варианта хватает для личных нужд с головой.
Накидываю мысли по ходу дня в телефоне, а вечером захожу через веб-морду и раскидываю по задачам.
Аватара пользователя
wofs
постоялец
 
Сообщения: 379
Зарегистрирован: 05.10.2009 10:16:55
Откуда: Астрахань

Re: Как лучше документировать разработку программы.

Сообщение Mirage » 05.05.2018 00:21:15

скалогрыз писал(а):в локальную репозиторию.


В общем, могёт писать в директорию, как git. Зачем тогда сервер и что не получалось у ТС?

скалогрыз писал(а):а я скажу - "так в мантисе же есть API, для плагинов"


Ну, плагины это такое... Интеграция с мессенджерами через плагины логично, а вот канбан уже сомнительно. Особенно, учитывая опыт c Redmine, где тоже все теоретически есть через плагины.

скалогрыз писал(а):ну "написать фильтр" такого плагина ещё не состряпали.


А зря, очень удобно. Чуть ли не лучшая фича джиры. В ютреке додумались слямзить.
А плагином может и не получиться - API должно быть соответствующее.

скалогрыз писал(а):Открой старый fpc мантис на мобилке.


Адаптивная верстка возможна и без бутстрапа. А для трекера задач на мобилке нужно приложение. В браузере мучения будут все равно.

Trac пользовал году в 2010-2011. Простенький был, но задачу выполнял. Сейчас не знаю. Тоже наверное бутстрап и все такое.

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

wofs писал(а):Я пишу сюда: pyrus.com


Да, годная вещь. Только хранить свои мысли фиг знает где как-то некомфортно. Ну и все те же проблемы с вебом. А уж как с мобильника что-то быстро ввести не знаю даже.
Вот такое бы, да на базе нормального десктопного клиента, с локальным хранением и синхронизацией между клиентами. Была бы бомба.
Есть CherryTree, но там нет синхронизации и он не особо удобен.
Mirage
энтузиаст
 
Сообщения: 881
Зарегистрирован: 06.05.2005 20:29:07
Откуда: Russia

Re: Как лучше документировать разработку программы.

Сообщение скалогрыз » 05.05.2018 04:44:25

Mirage писал(а): вот канбан уже сомнительно. Особенно, учитывая опыт c Redmine, где тоже все теоретически есть через плагины.

Канбан это дело моды и вкуса. Через плагины - то самое реализовывать.
Завтра появится мода на какую-нибудь 3д доску задач (webgl-же давно в браузерах), и всё - канбан станет прошлым веком. А чтобы его было легко убрать из системы, удобнее, чтобы он был плагином.

Mirage писал(а):А зря, очень удобно. Чуть ли не лучшая фича джиры. В ютреке додумались слямзить.
А плагином может и не получиться - API должно быть соответствующее

На самом деле в Мантисе руками можно описать сортировку полей (даже в той версии на которой крутится FPC)
вопрос в написании фильтров упирается в синтаксис:
1) должен быть человеколюбивым;
2) непротиворечить возможностям системы; (т.е. чтобы то что нащёлкано мышкой можно было описать текстом, и то, что написано словами, можно было бы нащёлкать мышкой - иначе в какой-то момент система может встать в тупик)
а API есть - "расширение HTML странички фильтров" - соответственно плагин должен будет парсить запрос и вызывать "приминить фильтр"

Mirage писал(а):Адаптивная верстка возможна и без бутстрапа. А для трекера задач на мобилке нужно приложение. В браузере мучения будут все равно.

А она была. И тоже шла как отдельный плагин, и распространялась платно.
Но умерла, ибо разработчикам лень 2 версии кода (вёрстки) поддерживать.

Mirage писал(а):А что касается канбана, то я о канбан доске, а не методологии. На ней очень наглядно видно кто чем занимается и в каком состоянии задачи на текущий момент. В принципе, это может быть интересно не только менеджерам, но и всем, кому не все равно что происходит с проектом. А если проект свой, так вообще...

а так вот, чем плохо?
скалогрыз
долгожитель
 
Сообщения: 1803
Зарегистрирован: 03.09.2008 02:36:48

Re: Как лучше документировать разработку программы.

Сообщение wofs » 05.05.2018 10:29:41

Mirage писал(а):Вот такое бы, да на базе нормального десктопного клиента, с локальным хранением и синхронизацией между клиентами. Была бы бомба.

А в чем сложность реализации, если столь остра необходимость? Правда все одно придется хранить копию где-то в вебе.
Аватара пользователя
wofs
постоялец
 
Сообщения: 379
Зарегистрирован: 05.10.2009 10:16:55
Откуда: Астрахань

Re: Как лучше документировать разработку программы.

Сообщение Mirage » 05.05.2018 13:28:25

скалогрыз писал(а):Но умерла, ибо разработчикам лень 2 версии кода (вёрстки) поддерживать.


Две версии это адаптивная и обычная? И умерла адаптивная? :)
Вообще-то лишняя - обычная.
А сейчас видимо только адаптивная осталась на базе бутстрапа.

скалогрыз писал(а):а так вот, чем плохо?


Тем, что это нагромождение цифр какое-то непонятное.
На канбан доску достаточно одного взгляда, чтобы понять текущее состояние.
https://www.codeproject.com/KB/architec ... hboard.png
Причем для опенсорса это по-моему еще важнее, т.к. в "спринтах" могут участвовать малознакомые люди.
И да, придется чуть организованней подходить, что тоже полезно.

wofs писал(а):А в чем сложность реализации, если столь остра необходимость?


Ну это получается как бы гибрид Telegram и CherryTree. Действительно, на пару вечеров. А на Лазарусе-то и того меньше!
А если серьезно, то я даже библиотеки шифрования современного не нашел.
Да и с UI как обычно будут проблемы, если качественно делать.

wofs писал(а):Правда все одно придется хранить копию где-то в вебе.


Не надо ее хранить. По-хорошему серверная часть и не нужна. Синхронизация между клиентами только.
Но из-за всяких NATов и файрволов может понадобиться простая серверная часть, плюс синхронизация, если клиент офлайн. За отдельные деньги. ;)
Mirage
энтузиаст
 
Сообщения: 881
Зарегистрирован: 06.05.2005 20:29:07
Откуда: Russia

Re: Как лучше документировать разработку программы.

Сообщение скалогрыз » 05.05.2018 18:45:47

Mirage писал(а):Причем для опенсорса это по-моему еще важнее, т.к. в "спринтах" могут участвовать малознакомые люди.

а какая длина такого "спринта" по времени? (особенно для оперсорц проекта)

Mirage писал(а):И да, придется чуть организованней подходить, что тоже полезно.

организованность на манитсе в примерах. (почему-то версии идут от раней к поздней, но это тоже маленький кусочек неорганизованности) (в глаза бросается, что FPC 4.0.0 недоделан только из-за господина Мюллера)

то же самое, но на новом Манитсе.
Разница в том, что "todo" идёт первыми строчками, "in progress" отливом синего, а "done" уже синенькми и сереньким.
скалогрыз
долгожитель
 
Сообщения: 1803
Зарегистрирован: 03.09.2008 02:36:48

Re: Как лучше документировать разработку программы.

Сообщение Mirage » 05.05.2018 22:53:29

скалогрыз писал(а):а какая длина такого "спринта" по времени? (особенно для оперсорц проекта)


Понятно, что большой она быть не может, иначе канбан доска превратится в кашу, по типу той, что по ссылкам твоим. Хотя в FPC 4.0.0 задач вроде совсем немного. Видимо это не все.
Обычно неделя-две. Я стараюсь, чтобы было не более месяца. Думаю, и для небольшого коллектива будет оптимально что-то около того. Тут важнее количество задач. Можно дробить по платформам или как-то еще и рисовать разные доски.
Кстати, релизы ежемесячные тоже не самое плохое дело. Тут проблема, как я читал, в том, что процесс релиза непрост. Потому стараются пореже.
Mirage
энтузиаст
 
Сообщения: 881
Зарегистрирован: 06.05.2005 20:29:07
Откуда: Russia

Re: Как лучше документировать разработку программы.

Сообщение mirk » 06.05.2018 23:32:11

serbod писал(а):Для предотвращения регрессии нужно чаще коммитить в SVN и подробнее писать в комментах, почему так сделано и на что это может повлиять.

Не получится из SVN сделать нормлальный трекер, это не задача системы контроля версий.
Да и какой смысл, если трекер ставится очень легко.

Mirage писал(а):Тут рядом говорят, что можно и без. А если про git, то мне непонятно что именно Вы утверждаете? Что программа git является сервером?

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

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

Погоди, а почему у тебя если десктопное приложение - то продумано, а если веб - так сразу не продумано.
Все наоборот - в веб приложении все быстро, а десктопное пока найдешь в меню, пока проинсталируешь... можно еще чего нибудь придумать :roll:
Имхо в 90% случаев веб приложение будет удобнее инспользовать.

Mirage писал(а):Как раз это все успешно делаю в текстовом файлике. Где плюсы-то?
Кроме документации конечно.

Можно из буханки и карандашей сделать троллейбус, но зачем?
Да, в тектовых файлах можно писать тексты, можно даже поиск по ним сделать, можно тратить время на агрегирование, но зачем? Есть готовые системы упрощающие жизнь. Но подобный подход конечно не нов, в 1811 луддиты так вообще технику портили :lol:

Mirage писал(а):Кто вообще придумал вики пихать в трекер? Отдельные же продукты.

Тут смотря что именно считать продуктом.
Система управления разработкой - продукт, но этот продукт состоит из других - трекер, вики и многое другое.

serbod писал(а):Канбан - это методика визуализации задач, чтобы сделать их более "осязаемыми". Когда задачи висят где-то в трекере, то нет ощутимой разницы, сколько там в трекере задач висит - 1, 10 или 100.

Для этого в трекере есть воркспейсы, фильтры и т.п.
Кабан конечно визуально прикольный, но он не осилит выборку из трекера (просто перестанет быть наглядным). А значит добавится новое действие по добавлению задач в кабан из трекера. Зачем усложнять процесс?
mirk
постоялец
 
Сообщения: 317
Зарегистрирован: 24.09.2007 10:03:39

Re: Как лучше документировать разработку программы.

Сообщение Mirage » 07.05.2018 00:44:33

mirk писал(а):Погоди, а почему у тебя если десктопное приложение - то продумано, а если веб - так сразу не продумано.


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

mirk писал(а):Все наоборот - в веб приложении все быстро, а десктопное пока найдешь в меню, пока проинсталируешь... можно еще чего нибудь придумать Имхо в 90% случаев веб приложение будет удобнее инспользовать.


Ну вот взять хваленый GMail и TheBat. В последнем гораздо приятнее работать с почтой, потому как быстрее. Хотя в GMail тоже старались. А вот обратных примеров что-то не приходит на ум.

mirk писал(а):Можно из буханки и карандашей сделать троллейбус, но зачем?Да, в тектовых файлах можно писать тексты, можно даже поиск по ним сделать, можно тратить время на агрегирование, но зачем? Есть готовые системы упрощающие жизнь. Но подобный подход конечно не нов, в 1811 луддиты так вообще технику портили


Напомню, вопрос был не про троллейбусы и луддитов, а про конкретные плюсы, даваемые трекером на базе веба, по сравнению с ведением дел в текстовом файле. В случае работы в одиночку.
Были названы: Учет багов, поиск в старых багах и во внесенных изменениях.Учет планируемых новшеств.Планирование релизов.
Однако все это достигается файлом, причем меньшими усилиями, т.к. процесс заведения бага/задачи в трекере сложнее написания строчки в файле.
Mirage
энтузиаст
 
Сообщения: 881
Зарегистрирован: 06.05.2005 20:29:07
Откуда: Russia

Re: Как лучше документировать разработку программы.

Сообщение wofs » 09.05.2018 20:59:16

Mirage писал(а):Ну вот взять хваленый GMail и TheBat. В последнем гораздо приятнее работать с почтой, потому как быстрее. Хотя в GMail тоже старались. А вот обратных примеров что-то не приходит на ум.

Очень удобно и функционально - Yandex Mail (оба - Web и iOS). А вот самый неюзабельный интерфейс веб-морды у рамблера (что старый, что новый).

Mirage писал(а):Тут конкретно речь про скорость. Десктопному приложению не надо лезть в сеть, чтобы показать задачи, если они есть локально.

Если интерфейс продуман до мелочей, то никакой разницы веб-морда или десктоп. Логиниться последнее время уже не очень модно - сессии педалят, так что скорость доступа равна скорости запуска выбранного браузера.
Аватара пользователя
wofs
постоялец
 
Сообщения: 379
Зарегистрирован: 05.10.2009 10:16:55
Откуда: Астрахань

Re: Как лучше документировать разработку программы.

Сообщение serbod » 10.05.2018 11:10:38

mirk писал(а):
serbod писал(а):Для предотвращения регрессии нужно чаще коммитить в SVN и подробнее писать в комментах, почему так сделано и на что это может повлиять.

Не получится из SVN сделать нормлальный трекер, это не задача системы контроля версий.
Да и какой смысл, если трекер ставится очень легко.


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

mirk писал(а):
serbod писал(а):Канбан - это методика визуализации задач, чтобы сделать их более "осязаемыми". Когда задачи висят где-то в трекере, то нет ощутимой разницы, сколько там в трекере задач висит - 1, 10 или 100.

Для этого в трекере есть воркспейсы, фильтры и т.п.
Кабан конечно визуально прикольный, но он не осилит выборку из трекера (просто перестанет быть наглядным). А значит добавится новое действие по добавлению задач в кабан из трекера. Зачем усложнять процесс?


Канбан для того и нужен, чтобы была не выборка на 5 страниц, а минимум активных задач на человека. И чтобы пока одну задачу не доделал, за другую не брался. Ведь "почтовый ящик" нерешенных проблем и задач особых ограничений не имеет, туда можно сотнями задачи пихать без проблем. А вот исполнитель задачи это "узкое место", на котором тормозит весь процесс и которое невозможно обойти. И чтобы это "узкое место" не затыкалось и не перегружалось, необходимо делать его нагрузку максимально заметной и осязаемой.
Аватара пользователя
serbod
постоялец
 
Сообщения: 449
Зарегистрирован: 16.09.2016 11:03:02
Откуда: Минск

Re: Как лучше документировать разработку программы.

Сообщение Mirage » 12.05.2018 01:05:26

wofs писал(а):Очень удобно и функционально - Yandex Mail (оба - Web и iOS).


Для веб клиента неплохо, да. Но функциональность никакая. Сравни с TheBat.
Скорость тоже обычная для веба. А полные перезагрузки страницы периодические вообще вымораживают.
Mirage
энтузиаст
 
Сообщения: 881
Зарегистрирован: 06.05.2005 20:29:07
Откуда: Russia

Пред.

Вернуться в Lazarus

Кто сейчас на конференции

Сейчас этот форум просматривают: нет зарегистрированных пользователей и гости: 30

Рейтинг@Mail.ru
cron