Здравствуйте, scf, Вы писали:
scf>Эти идеи уже в прошлом. На практике программные системы настолько сложны, что их детальное проектирование и верификация неподъемны.
Здесь дело не только в обучении, но и в недокументируемых особенностях. Да, системы сложны, только вот когда программисты над ними думают, то прорабатывают множество вариантов. Одни отбрасываются, другие наоборот становятся основными. Но из кода мы никогда не узнаем почему было сделано так, а не иначе.
Более того, простой алгоритм может быть завёрнут в сложную мультипарадигмальную абстракцию. Здесь было бы уместнее говорить, что данный алгоритм просто адаптирован под конкретную архитектуру. Даже если у программиста есть время на разбор программы, то всё равно желательно иметь какой-то вспомогательный инструмент для
сравнения,
анализа и
синтеза.
Да и опять же, почему бы и нет. Хотя на эту тему я больше нахожу статьи на английском. Идея как бы не нова, но реализация тоже играет существенную роль. Как-то читал какую-то книгу по программированию, так автор там хвалил некую систему документации, что он смог всё сверстать благодаря ей. Я не помню, может это
LaTex, может ещё что, но важен принцип разделения и сборки. В моём примере я использовал
AsciiDoctor.
Опять же с документацией у программистов точно такая же проблема, как и с тестированием. Не набрал сразу, потом просто лень это делать. Про устаревание я слышал лишь, что
водопадная модель разработки представляет проблему, так как требует заканчивать этап до перехода к следующему. Взамен ему пришла
итеративная модель разработки. Сам процесс документирования никто не отменял, а я и нигде не говорил, что нужно сначала абсолютно всё задокументировать, а потом кодировать.
Речь лишь о том, чтобы программист мог получить исчерпывающую информацию при просмотре документации, включая полный исходный код, сравнение разных фрагментов кода, объединение его по функционалу, отображение бизнес моделей, требований, архитектуры и даже логи юнит тестов и бенчмарков, если надо.
