Аура - звуковая атмосфера леса / полезное :: программа

Ну раз ты упомянул адаптивный дизайн и кровавый ынтерпрайз, то вот, что я скажу.
Страшилки про UI через код и адаптивный дизайн придумали такие же узколобые бездари, как и девопсы, которых самих надо автоматизировать, потом отцов и матерей, все их семьи автоматизировать, что бы не высирали кучи нерасширяемых и не поддерживаемых конфигов.
Дело не в том, что надо именно адаптивный дизайн, располагать элементы можно и абсолютным позиционированием, но если у тебя есть куча однотипных элементов, то их стоит группировать не только визуально, но и программно. Для этого нам богом даны типы с классами. И тогда там где тебе надо отобразить один элемент, труда не составит отобразить и 20. Дальше- больше. При необходимости можно отделить контейнеры от содержимого и их тасовать между собой, дописывая код для связок и всяких маппингов.
Если не понятно о чём я, то можешь представить UI в виде перевернутого дерева, где корневой элемент - это приложение, а от него расходятся формы, на каждой форме по группы элементов, а рядом схожее дерево(не обязательно идентичное, главное что бы они были изоморфными, ну т.е. одно дерево можно было преобразовать в другое) из того, чем ты по факту оперируешь - данными. Повышается переиспользование, а количества кода и багов понижается. И UI, и код становятся тоже более понятным, потому что опять же - они структурированы.
Причем т.к. это не статические структуры, то у них, в зависимости от состояния приложения могут меняться и целые ветки. Тут только остается определить детерминированные состояния между которыми могут скакать ветви дерева и отражать эти изменения хоть визуально, хоть в памяти. Это так же подразумевает довольно легкую замену любых подэлементов на произвольные любые другие - вчера эта форма отображала нередактируемые лейблы, потому что функционал сохранения не был разработан, а сегодня она уже содержит список редактируемых полей - потому что пофиг, что содержать. Вот это - гибкая разработка, когда ты безболезненно подменяешь устаревший функционал без переписывания всего, а не это их ковыряние в носу на ритуальных собраниях. Еще плюсы - если всё перескакивает только по тем инвариантам, которые ты практически явно сам определил, возможность непредвиденной ситуации КРАЙНЕ мала. Еще тестирование всякое облегается, т.к. всё и так очевидно из самой структуры объектов.
Тоже самое и про консольные утилиты - там ты тоже переходишь по дереву состояний, выполняя команды. Когда же ты вводишь команду посложней с параметрами, то путь по дереву состояния прокладывается за раз.
>>есть т.н. Developer Experiense специалисты
Ну таких я еще не встречал

Забыл добавить, что логика проектирования деревьев в общем-то базируется скорее на типах, чем на инстансах. Типы нужны, что бы выразить разветвления в логике выполнения и принять решение на основании типа объекта, а не его состояния. Тип может и не хранить состояния. Можно запросто же определить class C {} и всё - полноценный конструкт многих ЯП, используй как хочешь. Или же например, помню как-то про гендер заходил разговор, если есть гендер, то раньше мы бы его определили как два непересекающиеся подмножества - Мэ и Жо.Если формально: тип гендер - это ИЛИ Ж, ИЛИ М. Еще формальней: type Gender = | M | F. Времена изменились и теперь надо добавить новые классы гендера и сделать это можно так что бы не пришлось усираться пытаясь исправить все места в коде, не говоря про игры про угадывания какой пол в базе данных хотели выразить true, а какой - null'ом. Т.к. мы уже классифицировали гендер как или М, или Ж, то теперь можно спокойно добавить "строчный ИЛИ Свой".
Получаем type Gender = | M | F | Custom of string
Теперь можно навесить ярлык гендера на что-то, скорее всего на персону. Затем классифицировать, например для агрегации, промаркированные объекты как заблагорассудится. Вот тебе и полиморфизм - работаешь вроде бы с объектами произвольного типа, но если надо, то и на основании того гендера, который они содержат или промаркированы( с помощью универсальны типов, таких как туплы-кортежи, map'ы-словари) можешь изменить логику выполнения.
Это я к чему - что тяжело оперировать логикой только с помощью состояний. Надо еще добавлять поведения на основании класса объекта - всяко легче будет. Опять же для версионирования, истории или миграций удобно. Потому что конфигурация из типов должна соответствовать сохраненному состоянию в заданный момент времени. И потому если состояние устарело, а структура изменилась, то всегда можно сохранить предыдущие типы на какое-то, что бы был возможность их использовать для восстановления старого состояния и отправить на апдейт в соответствии с новой структурой.