По поводу трассировки - я считаю нужным и необходимым, но к сожалению на это нет времени и нет никаких предпосылок что будут движения в реализации данного инструмента
так чаще всего бывает. непонятно, какие из "хотелок" между собой конфликтуют, что уже сделано, что нет итд. кмк, основная сложность этого - в начале все еще можно держать в голове, все забивают, а потом уже поздно делать реверс-инж матрицы, все забивают)
А это не оверхэд? Ну то есть есть сервис и то как он работает. Команда разработки знает как он работает и код является документацией. Есть пользовательский путь, тесты. Зачем плодить документацию о том как когда-то кто-то что-то сделал?
А это не оверхэд? Ну то есть есть сервис и то как он работает. Команда разработки знает как он работает и код является документацией. Есть пользовательский путь, тесты. Зачем плодить документацию о том как когда-то кто-то что-то сделал?
Далеко не факт что команда разработки знает как он работает, а тем более как он должен работать.
А это не оверхэд? Ну то есть есть сервис и то как он работает. Команда разработки знает как он работает и код является документацией. Есть пользовательский путь, тесты. Зачем плодить документацию о том как когда-то кто-то что-то сделал?
А это не оверхэд? Ну то есть есть сервис и то как он работает. Команда разработки знает как он работает и код является документацией. Есть пользовательский путь, тесты. Зачем плодить документацию о том как когда-то кто-то что-то сделал?
Сейчас знает. А завтра свалит работать к другому дяде. И новая команда будет остужать пригорающую жопку, разбирая их код.
Сейчас знает. А завтра свалит работать к другому дяде. И новая команда будет остужать пригорающую жопку, разбирая их код.
1) И сам человек может призабыть через несколько месяцев-лет. Особенно, если работает стабильно и не заглядываешь туда каждый месяц. Потом нужно время для восстановления знаний. 2) Ещё зависит от качества кода и его документированности (комментарии и пр.)
1) И сам человек может призабыть через несколько месяцев-лет. Особенно, если работает стабильно и не заглядываешь туда каждый месяц. Потом нужно время для восстановления знаний. 2) Ещё зависит от качества кода и его документированности (комментарии и пр.)
а если его еще и без тебя дорабатывали, так вообще...
А это не оверхэд? Ну то есть есть сервис и то как он работает. Команда разработки знает как он работает и код является документацией. Есть пользовательский путь, тесты. Зачем плодить документацию о том как когда-то кто-то что-то сделал?
В заказной разработке при формате "жопа всегда должна быть прикрыта" и низкой процессной зрелости заказчика (карма меня кидает в основном на такие проекты), то вообще не оверхэд. Если говорить про стартап, внутреннюю разработку или требования с маленьким количеством конфликтов - то овэрхед
На этой неделе пришел разработчик с дефектом и вопросом как должно быть, при чем он сам делал это где то полтора года назад. Рассказал логику и услышал фразу - "Афигеть, код и логика совпадает!"
инфопотоки документируются в спецификациях каждая, все вместе в интеграционной архитектуре, при чем каждый инфопоток в двух спеках CRM - Шина и Шина - Внешняя система
функциональность в виде US+UC в том числе технические истории есть
+ эксплуатационная документация + руководство пользователя на 3к страниц + мануалы под сложный функционал отдельно + всякие тех. решения и бизнес подходы для сложных разработок