|
Иструменты для генерации документации API
|
|||
---|---|---|---|
#18+
Стало вдруг интересно, может узнаем про другие инструменты и решения :) ... |
|||
:
Нравится:
Не нравится:
|
|||
30.06.2019, 01:37 |
|
Иструменты для генерации документации API
|
|||
---|---|---|---|
#18+
Сразу поясню, речь идёт не о публичном API, типа REST API и т.п., а документация кода проекта. ... |
|||
:
Нравится:
Не нравится:
|
|||
30.06.2019, 01:41 |
|
Иструменты для генерации документации API
|
|||
---|---|---|---|
#18+
hVostt, Сколько я этот Doxygen применительно к чужим OpenSource ни пытался читать, никогда как правило ничего не понимал без ковыряний самих кодов и разбора примеров (при наличии). ИМХО, хочешь делать на паблик чтоб тебя понимали, пиши Help сам, тяжело долго и нудно, вооружившись гуглопереводчиком, подсматривая фразообороты у конкурентов по схожей тематике и т.п. А для себя (чтоб через N лет понять что имелось ввиду) мне отдельных комментариев в коде хватает. ... |
|||
:
Нравится:
Не нравится:
|
|||
01.07.2019, 01:35 |
|
Иструменты для генерации документации API
|
|||
---|---|---|---|
#18+
Дмитрий77, Проблема в качестве комментирования кода. Если комментарии повторяют то, что говорится в названии конструкции, конечно в этом смысла нет. Первое, чему приходится учить джунов, это правильно документировать код. Большой опыт показывает, что это вознаграждается десятикратно и очень скоро. Генерация документации позволяет давать ссылки на АПИ из постановок задач, добавлять туда примеры, линковать страницы, а нормальный полнотекстовый поиск позволяет в доке быстро находить нужные АПИ. Жаль, что тенденция отсутствия документации в коде сохраняется. ... |
|||
:
Нравится:
Не нравится:
|
|||
02.07.2019, 00:57 |
|
Иструменты для генерации документации API
|
|||
---|---|---|---|
#18+
hVostt, Я более 10 лет работаю с вот этим: OpalVoip Библиотека ну очень крута и востребована теми кто в теме. Как видим, ссылки на документацию ныне вообще не доступны (потому что эта "документация" видимо не востребована, чего править ссылки, вчера svn, сегодня git, завтра "сообщество" еще какую-нибудь хрень придумает). APIDocumentation Копать нормально можно вместе с кодом только. Собственно весь этот Doxygen берется очевидно из комментариев из файла ниже, и в общем они не плохи. https://sourceforge.net/p/opalvoip/opal/ci/master/tree/include/opal.h Ответная часть с кодами этих API: https://sourceforge.net/p/opalvoip/opal/ci/master/tree/src/opal/opal_c.cxx Но без самого кода фиг чего поймешь. Плюс примеры, плюс переписка с автором. Причем все эти API я лично под себя еще дополнял и подправлял (и не только сами API но и многие другие места в километрах кода). Ну, если чего-нибудь простенькое и с закрытыми кодами, тогда м.б. смысл этой документации и есть, но чтоб эти комменты для генерации доков написать, чтоб другому человеку было хоть что-то понятно, все одно надо будет потратить кучу времени. ... |
|||
:
Нравится:
Не нравится:
|
|||
02.07.2019, 20:44 |
|
Иструменты для генерации документации API
|
|||
---|---|---|---|
#18+
hVosttДмитрий77, Проблема в качестве комментирования кода. Если комментарии повторяют то, что говорится в названии конструкции , конечно в этом смысла нет. Первое, чему приходится учить джунов, это правильно документировать код. Большой опыт показывает, что это вознаграждается десятикратно и очень скоро. Генерация документации позволяет давать ссылки на АПИ из постановок задач, добавлять туда примеры, линковать страницы, а нормальный полнотекстовый поиск позволяет в доке быстро находить нужные АПИ. Жаль, что тенденция отсутствия документации в коде сохраняется. а что еще должно там быть? обычно есть некоторый контекст, архитектура, и там нет смысла городить комментарии, это если для внутреннего пользования - решают названия методов, переменных. а для внешнего - одного описания метода мало: надо описывать сценарии, в каких он используется. и там эссе на много буков. это имеет смысл для API, например, припомощи Swagger ... |
|||
:
Нравится:
Не нравится:
|
|||
02.07.2019, 21:23 |
|
Иструменты для генерации документации API
|
|||
---|---|---|---|
#18+
love_bachа что еще должно там быть? 1. Пояснение: бизнесовый, инфраструктурный или архитектурный смысл. 2. Ограничения, применение, рекомендации, различные тонкости и ньюансы, если они есть. 3. Примеры использования, ссылки на связанные конструкции. love_bachобычно есть некоторый контекст, архитектура, и там нет смысла городить комментарии, это если для внутреннего пользования - решают названия методов, переменных. Я говорю про комментирование публичных структур, интерфейсов и методов -- XML документация. Названия методов и переменных "решают" только в простых и примитивных проектаха. Конечно в любом коде можно при желании разобраться, но наличие документации ускоряют работу с кодом в несколько раз и напрямую влияет на качество его развития. love_bachа для внешнего - одного описания метода мало: надо описывать сценарии, в каких он используется. и там эссе на много буков. это имеет смысл для API, например, припомощи Swagger Если требуется, конечно сценарии использования нужны. Но если весь код правильно документируется, то количество текста, которое надо писать на каждый метод выходит не много. Всё решает полнота и кросс-ссылки по коду. Одно из крупнейших заблуждений, что дока нужна только для внешнего публичного API. Но не умение писать внутреннюю документацию АПИ также отражается и на качестве внешней. Не вооружённым глазом видны потуги и кровавые страдания человека, который вынужден заниматься тем, чем заниматься абсолютно не умеет и не привык :) ... |
|||
:
Нравится:
Не нравится:
|
|||
03.07.2019, 00:04 |
|
Иструменты для генерации документации API
|
|||
---|---|---|---|
#18+
Дмитрий77Но без самого кода фиг чего поймешь. Плюс примеры, плюс переписка с автором. Ну я и не утверждал, что исходный код не нужен :) Зачастую приходится дизассемблить код даже при наличии доки... не очень хорошей доки. Дмитрий77Ну, если чего-нибудь простенькое и с закрытыми кодами, тогда м.б. смысл этой документации и есть, но чтоб эти комменты для генерации доков написать, чтоб другому человеку было хоть что-то понятно, все одно надо будет потратить кучу времени. Насчёт генераторов доки, зачем они нужны.. вот же пример из ссылки, которую ты дал: Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23. 24. 25. 26. 27. 28. 29. 30. 31. 32. 33. 34. 35. 36. 37. 38. 39. 40. 41. 42. 43. 44. 45. 46. 47. 48. 49. 50. 51. 52. 53. 54. 55. 56. 57. 58. 59. 60. 61. 62. 63. 64. 65. 66. 67. 68. 69. 70. 71. 72. 73. 74. 75. 76. 77. 78. 79. 80. 81. 82. 83. 84. 85. 86. 87. 88.
В сгенерированном виде это будет явно читабельней, а также с нормальной навигацией по иерархии, навигацией по ссылкам и подсветкой синтаксиса в примерах. Ну и самое главное. Полнотекстовый поиск по документации -- маст хев. Дмитрий77Как видим, ссылки на документацию ныне вообще не доступны (потому что эта "документация" видимо не востребована, чего править ссылки, вчера svn, сегодня git, завтра "сообщество" еще какую-нибудь хрень придумает). APIDocumentation Просто некому поддерживать видимо. Иначе уже давно бы утащили на гитхаб :) ... |
|||
:
Нравится:
Не нравится:
|
|||
03.07.2019, 00:14 |
|
Иструменты для генерации документации API
|
|||
---|---|---|---|
#18+
hVosttПросто некому поддерживать видимо. Иначе уже давно бы утащили на гитхаб :) Ну, судя по последним изменениям автор либу то поддерживает: https://sourceforge.net/p/opalvoip/opal/ci/master/tree/ К слову, какие-то старые ссылки открываются (которые depricated, начиная с 3-ей): http://files.opalvoip.org/docs/opal-v3_14/index.html hVosttвот же пример из ссылки, которую ты дал:... В сгенерированном виде это будет явно читабельней, а также с нормальной навигацией по иерархии, навигацией по ссылкам и подсветкой синтаксиса в примерах. Ну вот оно кажется: opal.h File Reference Ну, я лично пользуюсь двумя старыми версиями, 2012 и кажется 2010 года. Просто в один прекрасный момент автор (фактически автор один, австралиец) начал дурить и портить собственное детище что-то фундаментально переписав, из-за чего нормальные проекты (не мои) перестали нормально работать, компилироваться и т.д. Ему про это написали (уважаемые люди), он не согласился. Точка невозврата была пройдена. Последние годы автор так понимаю наедине с собой, видимо кому-то что-то делает какую-то работу, под себя и правит как хочет. ... |
|||
:
Нравится:
Не нравится:
|
|||
03.07.2019, 00:45 |
|
Иструменты для генерации документации API
|
|||
---|---|---|---|
#18+
hVosttЖаль, что тенденция отсутствия документации ... сохраняется. Ну, а что вы хотите. Допустим у меня есть новая идея, я хочу ее добавить в продукт. 1) Чтоб примерно понять алгоритм чего хочу пары часов - полдня достаточно 2) Чтоб сделать функциональный код (API, классы, говнокод, да какая разница), ну допустим несколько дней - неделя 3) Чтоб сделать достойное GUI под это дело, скажем недели 2-3 4) Чтоб воткнуть "многоязычнось" - механизм, перевод хотя б на один язык - еще столько же 5) сделать En Help (из хэлпа предыдущей версии) -иногда месяц, если идей/изменений несколько и добавлен новый функционал, а не просто фиксы: картинки, описания, навигация 6) сделать еще скажем русский help - не намного меньше 7) скомпоновать все это в готовый setup.exe, размещение, реклама, вэбсайт - еще месяц может уйти Времени уходит вагон, ну в итоге оно оправдывается. И естественно большинство людей сосредоточены на п.п. 1-2, потому что все что дальше это рутина (хотя когда-то в освоение GUI, принципа хэлпов, перевода было вложено много творческих "программных" сил - ток. когда это было). "Проф. роста" - никакого, программирование - стремится к нулю, одно копирование кодов и использование своих же когда-то написанных модулей/классов про которые уже порой плохо понимаешь как они устроены, хорошо если помнишь "как приткнуть". Но в то же время без п.п. 3-7 кота не продашь. Отупеваешь, но продукт то "развивается". А что делать? ... |
|||
:
Нравится:
Не нравится:
|
|||
03.07.2019, 01:49 |
|
Иструменты для генерации документации API
|
|||
---|---|---|---|
#18+
Дмитрий77Ну, судя по последним изменениям автор либу то поддерживает: https://sourceforge.net/p/opalvoip/opal/ci/master/tree/ в одиночку тяжело тащить такие проекты, контрибьтеров судя по логу больше нет ( Дмитрий77Ему про это написали (уважаемые люди), он не согласился. Точка невозврата была пройдена. Последние годы автор так понимаю наедине с собой, видимо кому-то что-то делает какую-то работу, под себя и правит как хочет. к успеху идёт... но медленно ) Дмитрий77Допустим у меня есть новая идея, я хочу ее добавить в продукт. 1) Чтоб примерно понять алгоритм чего хочу пары часов - полдня достаточно 2) Чтоб сделать функциональный код (API, классы, говнокод, да какая разница), ну допустим несколько дней - неделя 3) Чтоб сделать достойное GUI под это дело, скажем недели 2-3 4) Чтоб воткнуть "многоязычнось" - механизм, перевод хотя б на один язык - еще столько же 5) сделать En Help (из хэлпа предыдущей версии) -иногда месяц, если идей/изменений несколько и добавлен новый функционал, а не просто фиксы: картинки, описания, навигация 6) сделать еще скажем русский help - не намного меньше 7) скомпоновать все это в готовый setup.exe, размещение, реклама, вэбсайт - еще месяц может уйти это всё понятно. а теперь заменим в условии "я", на "мы", и это "мы" может быть командой разработчиков десяток другой, в которой также имеется какая никакая текучка. мне вот интересно, сколько удовольствия ты найдёшь в том, чтобы согласовывать, пояснять и погрязнуть в коммуникации вместо того, чтобы собственно работой заниматься :) конечно, проекты с одним или парой разработчиков не требуют хорошей документации. но, как обычно, у этого есть последствия. отсутствия навыка, привычки, умения писать доку и понимания зачем и для чего это нужно. хотя, набив руку, это практически не отнимает время, так как доку пишешь прямо вместе с написанием кода и прям в коде. при чём выраженная мысль обычным русским языком (или английским, зависит от проекта) отлично помогает структурировать код и в любой момент включить в разработку людей. Дмитрий775) сделать En Help (из хэлпа предыдущей версии) -иногда месяц, если идей/изменений несколько и добавлен новый функционал, а не просто фиксы: картинки, описания, навигация хелп это немного другое. разработчики не должны этим заниматься. Дмитрий77хорошо если помнишь "как приткнуть" вот именно. чтобы не быть зависимым от данных в своей памяти, нужно их фиксировать в доке. просто без навыка и привычки это видится лишней потерей времени. Дмитрий77Отупеваешь, но продукт то "развивается". А что делать? ну это как про уровень комфорта. кому-то комфортно жить в бардаке и на дошираке. но повысив свой уровень комфорта, уже непонятно как можно было так жить :) ... |
|||
:
Нравится:
Не нравится:
|
|||
03.07.2019, 16:49 |
|
Иструменты для генерации документации API
|
|||
---|---|---|---|
#18+
hVosttэто всё понятно. а теперь заменим в условии "я", на "мы", и это "мы" может быть командой разработчиков десяток другой, в которой также имеется какая никакая текучка. мне вот интересно, сколько удовольствия ты найдёшь в том, чтобы согласовывать, пояснять и погрязнуть в коммуникации вместо того, чтобы собственно работой заниматься :) хелп это немного другое. разработчики не должны этим заниматься. Как бы это сказать, пытался уже довести похожую мысль недавно. Из того что в бизнесе занято 20 человек, еще не следует что денег будет в 20 или в 200 раз больше и в 20 раз быстрее. При этом любой наемник заинтересован "денег побольше" и "работать по меньше". При этом он как правило не является специалистом в узкой области (в коей только ты специалист и фанат своего дела), и ему придется объяснять, контролировать, и скорее всего будет кивать, не поймет, все сделает не так и не качественно. Понятно, что с командой можно добиться сильно больше. Но это не каждому дано и не всегда оправдано. Но команда - это когда команда единомышленников, каждый из которых реальный специалист этого дела. Можно замутить бизнес, набрать кредитов и прогореть. А можно спокойно и стабильно заниматься чем-то в одиночку, спокойно и без рисков (и даже без вложений). При этом вполне комфортно и не "на дошираках". Ну, к "славе Высоцкого Зеленского" (очень хороший пример "команды") конечно таким путем не прийти, это ясно. Но каждому своя ниша. ... |
|||
:
Нравится:
Не нравится:
|
|||
03.07.2019, 19:49 |
|
Иструменты для генерации документации API
|
|||
---|---|---|---|
#18+
Дмитрий77Из того что в бизнесе занято 20 человек, еще не следует что денег будет в 20 или в 200 раз больше и в 20 раз быстрее. Вроде как не следует. Однако всем известные крупные продукты разрабатывают не три человека :) Мой же опыт показывает, что командная разработка имеет абсолютное преимущество по всем фронтам без исключения против инди. Из хороших продуктов, написанных одним человеком можно найти разве что вылизанные до блеска утилиты, или крутые плагины. Но не полноценные решения, которые будут интересны бизнесу. Инди можно найти в кабинетах компаний, не причастных никаким боком к ИТ. Несколько человек в таких конторах не являются командой, они просто коллеги и сидят либо в одном либо в соседних кабинетах, и у каждого свой _проэкт_, а то и несколько. По совокупности, это небольшие АРМы, по большему счёту на сопровождении, так как никто не предъявляет никакие требования ни по качеству, ни по надёжности, ни по расширяемости, ни по чему. Как-то работает вроде, ну и зашибись :) Ну и фрилансеры конечно, обычно на подряде. Дмитрий77А можно спокойно и стабильно заниматься чем-то в одиночку, спокойно и без рисков (и даже без вложений). При этом вполне комфортно и не "на дошираках". Ну, к "славе Высоцкого Зеленского" (очень хороший пример "команды") конечно таким путем не прийти, это ясно. Но каждому своя ниша. Как бы вопрос не в том, как жить хорошо и зарабатывать. И не в славе дело. Тем более это личное дело каждого. И для одиночной разработки писать документацию без желания и видимых перспектив командной работы, это даже выглядит глупо, так что спорить тут я не могу )) ... |
|||
:
Нравится:
Не нравится:
|
|||
03.07.2019, 20:00 |
|
Иструменты для генерации документации API
|
|||
---|---|---|---|
#18+
hVosttКак бы вопрос не в том, ... Согласен. Вопрос/опрос был не в том. Вопрос был "какие инструменты используете " а не "зачем это надо и чего вообще надо". Чет меня понесло... Сам не люблю когда задаю конкретный вопрос, ответ давно получен, а начинаются рассуждения на общие темы. ... |
|||
:
Нравится:
Не нравится:
|
|||
03.07.2019, 20:36 |
|
Иструменты для генерации документации API
|
|||
---|---|---|---|
#18+
всё плохо, товарищи и ни кто не хочет за это платить, хотят, чтоб платили за это мы, по сути ... |
|||
:
Нравится:
Не нравится:
|
|||
03.07.2019, 23:09 |
|
Иструменты для генерации документации API
|
|||
---|---|---|---|
#18+
Roman Mejtes, Кому по сути эти доки нужны. Тому кто писал код - он и без них и через 10 лет легко разберется что он написал и сумеет воспользоваться. А нужны они хозяину "команды", который наемного сотрудника выгонит и посадит на его место другого, а вот и доки - все ходы записаны и оформлены. А тому кто писал код они в этом смысле даже вредны. Нужны эти комменты хозяину - пусть платит, причем в 5 раз больше чем за код, который они описывают. ... |
|||
:
Нравится:
Не нравится:
|
|||
04.07.2019, 00:23 |
|
Иструменты для генерации документации API
|
|||
---|---|---|---|
#18+
Дмитрий77Roman Mejtes, Кому по сути эти доки нужны. Тому кто писал код - он и без них и через 10 лет легко разберется что он написал и сумеет воспользоваться. А нужны они хозяину "команды", который наемного сотрудника выгонит и посадит на его место другого, а вот и доки - все ходы записаны и оформлены. А тому кто писал код они в этом смысле даже вредны. Нужны эти комменты хозяину - пусть платит, причем в 5 раз больше чем за код, который они описывают. да вот фиг, есть проект, меньше года на нём, документации кроме моих комментариев никто не ведет. ни черта изначально не продумали, 30 раз всё меняли и переделывали, у меня в голове уже кисель от их "переделок". уже горит жопа прямо, совершенно не проработали на этапе проектирования, я теперь уже сам плохо помню, где, что и как должно и как работает. короче худший проект в моей жизни. а когда проект изначально нормально продуман, архитектура, все постановки и спец., то всё помнится и через 5 лет. ... |
|||
:
Нравится:
Не нравится:
|
|||
04.07.2019, 00:39 |
|
Иструменты для генерации документации API
|
|||
---|---|---|---|
#18+
Roman Mejtesда вот фиг, есть проект, меньше года на нём, документации кроме моих комментариев никто не ведет. ни черта изначально не продумали, 30 раз всё меняли и переделывали, у меня в голове уже кисель от их "переделок". уже горит жопа прямо, совершенно не проработали на этапе проектирования, я теперь уже сам плохо помню, где, что и как должно и как работает. короче худший проект в моей жизни. а когда проект изначально нормально продуман, архитектура, все постановки и спец., то всё помнится и через 5 лет. Нормальный проект продумать изначально невозможно. Продумывается некоторый концепт(ы), потом она сама живет и развивается, если это кому то надо. Обычно все через некоторое время умирает, если никто усиленно не занимается маркетингом. Но, легче заниматься каким то Орал - Д в плане маркетинга и прибылей, чем ОС/2. ... |
|||
:
Нравится:
Не нравится:
|
|||
04.07.2019, 02:01 |
|
|
start [/forum/topic.php?fid=20&fpage=19&tid=1398887]: |
0ms |
get settings: |
9ms |
get forum list: |
13ms |
check forum access: |
4ms |
check topic access: |
4ms |
track hit: |
27ms |
get topic data: |
11ms |
get forum data: |
3ms |
get page messages: |
78ms |
get tp. blocked users: |
2ms |
others: | 10ms |
total: | 161ms |
0 / 0 |