Comments 3
К сожалению, до сих пор не существует идеального способа хранить требования, трассировать их до кода и обратно. А может, его и не может существовать вовсе.
Бинго. Конечно не может существовать. Сама идея что можно получить требования и по ним написать что-то полезное - абсурдна. Так можно написать только то, что уже было написано. А это и нейронка (с)может.
Мне нравится старая классическая формулировка.
Задача программиста состоит в исследовании предметной области и записи результатов в виде, доступном для понимания как человеку, так и машине.
Какие требования если область не исследована и зачем требования когда она исследована?
И, думаю, каждый из вас на своей шкуре замечал, что кривая оргструктура может создавать куда более разрушительные последствия, чем плохо написанный код.
Естественно. А оргструктура выполняет какие либо функции окромя услаждения да ублажения слуг правящего класса?
Это ровно та же сложность, с которой сталкивается любой бизнес
И это верно. А что есть бизнес как не совокупность чего угодно имеющая одного владельца?
чтобы всё это разнообразие продолжало работать как единое целое.
Как пример того, кто так может, Человечество в целом. Хотя, скорее могло. Изменилась плотность взаимодействия элитных группировок, перерождение в бизнес пошло.
Почему так выходит, что новые технологии не только не помогают, но иногда даже мешают нам писать качественные программы? Почему, когда мы стараемся делать хорошо — получается плохо?И главное — что с этим делать?
Потому, что программы создаются для рынка, а рынок слишком быстро стал массовым и, согласно закону 80/20, стал принимать такое, какое ему сейчас скармливают.
Прямо сейчас не нужно делать ничего, кроме как помнить. Потому что когда кризис неизбежен, его оттягивание, так называемые «добрые дела», уничтожает ресурсы для выхода. Идти вместе с потоком - решать задачу не как сделать хорошо, а как заработать больше.
Вот когда задумаются - а что строить на руинах миропорядка будем, кто-то должен будет вспомнить, встать (взлететь? вынырнуть? сунуть жвалы в астрал?) и спросить - э, стоп, а код то как будем писать? И суметь убедительно ответить на аргумент что до этого ещё далеко.
Поэтому я иногда мечтаю о простом языке описания системных требований на базе Markdown — с минимальной валидацией, автокомплитом и всем прочим.
Не совсем голый маркдаун, а ещё немного магии Obsidian Dataview. Я примерно это сделал для своей продуктовой команды. В пике трекали 390 требований. Мапили на них истории, критерии приемки и версии продукта.
https://github.com/dimonier/Obsidian-Requirements-Management
Был такой продукт давно
Rational requisite pro с требованиями, которые мапились друг с другом и с управлением изменениями в clear quest
Что с ними стало?
Управление изменениями переехало в Jira, управление кодом в git, но управление требованиями потерялось
Компрессия требований, распад бизнес-логики. Разбираемся, почему архитектура не спасает от эрозии смыслов