«Разработчик – эксперт предметной области»
📛
Один инженер сказал недавно:

«Я скучаю по временам, когда разработчики разбирались в том, что проектирует от и до. Сейчас много Spring программистов»

Разбираться в предметной области для меня всегда было нормой.

Собрал этапы трансформации походов к проектированию.

- 70-ые Разработчик – разбирается в предметной области.
- 80-ые Разработчик пишет код, который соответствует постановке. (водопад)
- 2003 Разработчик – эксперт предметной области

В индустрии трансформация происходит с лагом. В 201X корпорации начинают меняться. Одни немного раньше, другие только сейчас в 2000х.

Эффективное цифровое производство – актуальная тема.

Цитата:
Domain-Driven Design: The First 15 Years. 172. Enhancing DDD — Prof. David West

В начале 1970-х годов идеи и методы «структурированного анализа и проектирования» (SAD) доминировали в практике разработки программного обеспечения. SAD пропагандировал:
• Шаг первый: смоделируйте предметную область
• Шаг второй: определите, какие изменения вы хотели бы улучшить или исправить проблемы в предметной области.
• Шаг третий: проведите мозговой штурм нескольких способов, которыми изменения могут быть затронуты.
• Шаг четвертый: проанализируйте, какое «решение» является оптимальным.
• Шаг пятый: смоделируйте выбранное решение, включая модуляризацию программного обеспечения.
• Шаг шестой: внедрите модель.
• Шаг седьмой: разверните и оцените внедренное решение и его влияние на предметную область

Редко, если вообще когда-либо, шаги с первого по четвертый фактически выполнялись. Отчасти потому, что руководство бизнеса не видело ценности и не поощряло или запрещало их как «пустую трату времени».

К середине 1970-х годов предметная область умерла.

В те же годы набирал свои обороты Водопад 🔥
Цитаты из https://en.wikipedia.org/wiki/Waterfall_model

«Хотя термин «водопад» не используется в статье, первая формальная подробная схема процесса, позже известная как «водопадная модель», часто[7] цитируется как статья Уинстона В. Ройса 1970 года.[8][9][10]»

Ройс никогда не рекомендовал и не описывал каскадную модель,[16] он критикует жесткое соблюдение следующих фаз:

- Требования к системе и программному обеспечению: зафиксированы в документе с требованиями к продукту
- Анализ: приводит к моделям, схеме и бизнес-правилам
- Проектирование: приводит к архитектуре программного обеспечения
- Кодирование: разработка, проверка и интеграция программного обеспечения
- Тестирование: систематическое обнаружение и устранение дефектов
- Операции: установка, миграция, поддержка и обслуживание полных систем

Сложно. Дорого. Не везде уместно. В армии Да. За большие деньги тоже можно. (нет)

В 2003 году Эрик Эванс поднял важную тему и прекрасно описал ее в книге в первых главах.
Почитай.
На мой взгляд разработчики упускают именно эту важную идею DDD в погоне за паттернами, принципами, кодописью и фрэйм мать их ворками.

Цитата из эссе Prof. David West:

Удивительная вещь в DDD была не в шаблонах или практиках, а в том, как тихо она опровергала основные принципы разработки программного обеспечения: ложь о том, что программистам не нужно было понимать предметные области, что все, что им нужно было знать, было набором требований, которым код должен удовлетворять!

Domain-Driven Design: The First 15 Years. 172. Enhancing DDD — Prof. David West

Эрик Эванс четко написал, что если разработчик не проектирует процесс, не понимает процесс целиком, он не способен предложить эффективную архитектуру и код.
Вот почему учиться проектировать нужно начинать с джунства и приглашать на сессии проектирования мидлов, джунов и рассказывать им почему одни решения хороши своей простой, другие нет. Простоте тоже нужно обучать и обучаться.

💬 Женя Четвериков наш Head Of Professions DevOps рассказал сегодня про
Quality Gates и сервис QGaaS на DevOops
Поговорили про то как мы внедряем инженерные практики.

Ситуация:
Приехал поддержать, посмотреть. А вписался в движ:
Быть экспертом, вопросы задать, зачитать.

ПС
На фото суфлёр в который смотрит спикер на сцене и видит:
- Слайд
- Оставшееся время до конца выступления и Q&A сессии

#конфа #devops

Я очень много токсичных текстов написал в стол. 😏

На новой позиции впитал много интересного токсичного фарша.
🔪😟

#log