DB
По сути визуальное регрессионное тестирование 👍
Size: a a a
2019 March 26
OI
А возможно ли повесить на read the doc (который self-hosted) какую-нибудь аналитику/метрику (просмотры, вебвизор или что-то вроде того)? Не разбираюсь в теме, но очень хочется )
NV
А возможно ли повесить на read the doc (который self-hosted) какую-нибудь аналитику/метрику (просмотры, вебвизор или что-то вроде того)? Не разбираюсь в теме, но очень хочется )
Google analytics, Яндекс метрика
НН
А возможно ли повесить на read the doc (который self-hosted) какую-нибудь аналитику/метрику (просмотры, вебвизор или что-то вроде того)? Не разбираюсь в теме, но очень хочется )
NV
Любой клиентский JavaScript можно добавить в шаблон
OI
оч круто. Спасибо!
RT
У нас это сделано на Springfox.
Писать тесты на полноту Javadoc я считаю бесполезной тратой времени,
лечить пациента надо до того как он умер.
У нас спецификацию API пишут люди в OpenAPI формате, этот файл является ТЗ для разработчика.
Сгенерированная из кода документация является дополнительной к файлу написанному человеком - просто отражает срез текущей сборки приложения.
На мой взгляд строить документацию из реализации порочная практика: ведь прежде чем что-то делать, надо бы понять ЧТО нужно сделать.
Писать тесты на полноту Javadoc я считаю бесполезной тратой времени,
лечить пациента надо до того как он умер.
У нас спецификацию API пишут люди в OpenAPI формате, этот файл является ТЗ для разработчика.
Сгенерированная из кода документация является дополнительной к файлу написанному человеком - просто отражает срез текущей сборки приложения.
На мой взгляд строить документацию из реализации порочная практика: ведь прежде чем что-то делать, надо бы понять ЧТО нужно сделать.
RT
Кто-нибудь выгружает описания API в OpenAPI (swagger) из кода на Java? У вас есть тесты на полноту javadoc'ов? Поделитесь опытом в @docsascode, пожалуйста.
RT
Документация, написанная человеком дает ответ на вопросы:
- что нужно сделать
- почему именно так нужно сделать
- как это должно работать
Документация, сгенерированная из реализации отвечает на вопрос:
- как это сейчас сделано
- что нужно сделать
- почему именно так нужно сделать
- как это должно работать
Документация, сгенерированная из реализации отвечает на вопрос:
- как это сейчас сделано
RT
то есть javadoc-style документация годится лишь как технический справочник
DB
У нас это сделано на Springfox.
Писать тесты на полноту Javadoc я считаю бесполезной тратой времени,
лечить пациента надо до того как он умер.
У нас спецификацию API пишут люди в OpenAPI формате, этот файл является ТЗ для разработчика.
Сгенерированная из кода документация является дополнительной к файлу написанному человеком - просто отражает срез текущей сборки приложения.
На мой взгляд строить документацию из реализации порочная практика: ведь прежде чем что-то делать, надо бы понять ЧТО нужно сделать.
Писать тесты на полноту Javadoc я считаю бесполезной тратой времени,
лечить пациента надо до того как он умер.
У нас спецификацию API пишут люди в OpenAPI формате, этот файл является ТЗ для разработчика.
Сгенерированная из кода документация является дополнительной к файлу написанному человеком - просто отражает срез текущей сборки приложения.
На мой взгляд строить документацию из реализации порочная практика: ведь прежде чем что-то делать, надо бы понять ЧТО нужно сделать.
я пока не работал в командах, в которых процесс разработки настолько формализован 🤔
RT
Формализация приходит с ростом компании, когда людей в проекте столько что многие уже лично не знакомы друг с другом, то по другому уже очень сложно - без проектной документации организация уже работать не может)
НН
Формализация приходит с ростом компании, когда людей в проекте столько что многие уже лично не знакомы друг с другом, то по другому уже очень сложно - без проектной документации организация уже работать не может)
Тру
RT
По опыту у нас самое больное место не в технической документации, а в правильной фиксации бизнес-требований.
А бизнес-требования как раз определяют ответ на вопрос "почему так сделано" на техническом уровне - просто глядя в некое описание АПИ или компонента вы ничего не поймете в том почему и зачем это сделано.
А бизнес-требования как раз определяют ответ на вопрос "почему так сделано" на техническом уровне - просто глядя в некое описание АПИ или компонента вы ничего не поймете в том почему и зачем это сделано.
2019 March 27
ДС
Fox Mulder
Если серьёзно, то мне действительно не ясно
сегодня пришло письмо с приглашением
FM
Да, я уже увидел. Спасибо
2019 March 30
EN
@Nick_Volynkin вы квартирники случаем не записываете?
NV
@Nick_Volynkin вы квартирники случаем не записываете?
Я предложил конспектировать слушателям
OI
Будет ли запись? Не успела послушать
OI
Через час (17 по Новосибирску, 13 по Москве) мы с Семёном Факторовичем и Татьяной Фокиной будем рассказывать про документацию и DocOps на радио ЦФТ. Трансляция тут: https://team.cft.ru/radio