Comments 8
Что-то мне это напоминает старое доброе разбиение на слои абстракций.
Боюсь, похожие мысли были сформулированы ещё в классической работе David Parnas: "On the Criteria To Be Used in Decomposing Systems into Modules".
Выделю:
We propose instead that one begins with a list of difficult design decisions or design decisions which are likely to change. Each module is then designed to hide such a decision from the others.
50 лет назад написано, на минуточку!
Подход действительно правильный, и он действительно работает. Вот только другая беда: практически все его игнорируют. Что в 70-х, что в 90-х, что в 20-х. Может быть, гораздо более интригующий и интересный вопрос - почему так происходит?
Потому что такой анализ требует широкого кругозора от проектировщика. Увидеть функции не сложно, придумать какую-то объектную модель - запросто. Представить как будут меняться требования - вам скажут, что это бесполезно и есть agile. По факту вполне можно, но нужно очень хорошо понимать в бизнесе. А этого понимания как раз и нет у проектировщика.
Ну да, вполне возможно. А в динамике, когда уже видны тенденции, что более и что менее изменчиво, другая напасть. Можно было бы порефакторить, но на рефакторинг то времени нет, то вообще непонятно, с какого конца развязывать все зависимости, то ещё что.
соглашусь
Тоже согласен. Изживает себя специалист, который смотрит по сторонам и имеет обширный кругозор. Всё вокруг вроде как бы упрощается. Только, для того, чтобы упростить бизнес процессы, нужна комплексная архитектура, друг на друга выстроенные модули и интерфейсы. Но ожидание упрощения проникает и за кулисы. И начинаются workaround за workaround(ом)... и конца этому нет.
А Вы можете дать свой собственный перевод всего абзаца? Чтобы рассуждать в одних и тех же терминах и, заодно, проверить свой сильно запущенны английский.
Для любителей программной инженерии