Дьявол Гуд Бай

котенок на елке

Учитель: У тебя есть 4 яблока, половину ты отдал другу. Сколько у тебя осталось?

Ученик: Три с половиной

Я уже писал о “дьяволе в деталях”. В той заметке. я сделал вывод: чтобы не было дьявола в деталях, нужно продумывать устройство (структуру, архитектуру) — ангел в устройстве. Но я не переставал об этом думать, да и фраза достаточно часто звучит в ИТ-кругах. 

Фраза меня задевала, потому что обычно она звучит как “универсальная отмазка” — это не мы виноваты, это, он, гад, залез в детали. 

Давайте отбросим эмоции (которые всегда есть в этой фразе) и посмотрим в суть. О чем собственно речь: о том, что есть некая “деталь”, обычно не замеченная изначально, которая существенно влияет на решение задачи.

Вспомнив, что все мы, хотя бы немного, математики, назовем правильно эту “деталь” — это часть условия задачи. Не знаю, как вы, а я в этом месте вздыхаю с облегчением. Так вот в чем дело, просто в ходе работы изменилось условие задачи. Очевидно, что если условие задачи изменилось, то и решение должно измениться. 

Как правило, мы решаем задачи с неполными, нечеткими, неверно понятыми (см. эпиграф) или меняющимися по ходу условиями (см. фото). Полагаю, что это следствие “детского возраста” ИТ (“детские болезни”). Может быть, отрасль повзрослеет, но пока мы живем в условиях меняющихся условий :). 

Как в них жить? Так как мы всегда заранее знаем, что условие задачи будет меняться по ходу разработки, мы должны быть к этому готовыми. Способы нам известны:

  • прототипирование
  • гибкая архитектура
  • точки расширения
  • компоненты
  • гибкие процессы
  • и так далее

Главное, что теперь, я точно знаю как переводится фраза “дьявол в деталях”: “мы облажались, потому что заранее не подумали о том, как будет меняется наша система при изменении условий”.

3 комментария


  1. Есть два прямо противоположных параметра: жёсткость и гибкость.
    Жёсткость определяется числом зацеплений компонентов.
    Гибкость определяется как мало придётся затронуть связей, чтобы отцепить один компонент и прицепить другой.
    В этом смысле динамические языки не обладают жёсткостью, а статические — гибкостью.

    Но! Есть КОП!)) Абсолютно жёсткие кирпичики с неизменяемым интерфейсом, но кирпичиков много, кирпичики легко изменять и тестировать в силу их малого размера))

    Практически идеальный пример КОП (имхо) — Компонентный Паскаль))

    Ответить

    1. Не очень понимаю, какое отношение имеет «жесткость и гибкость» к моему тексту…

      Но вот Компонентный Паскаль, на мой взгляд, имеет очень малое отношение к (нужному мне) сборочному программированию и к повторному использованию (reuse). И основная причина — жесткость связей между модулями и иерархия (наследование). Впрочем, я об этом уже несколько раз писал.

      Ответить

      1. Эммм… Жёсткость связей не такая уж и большая. Например, базовый кирпичик — если расширяет интерфейс, но не трогает существующий — ничего страшного не произойдёт. Что касается наследования, то здесь рецепт прост, и я соглашусь, что Go — уже что-то похожее на правду (ведь прямой предок Оберон). Его система интерфейсов и утиная типизация — делают своё дело в больших системах. В этом смысле, Компонентный Паскаль не запрещает наследоваться от полностью абстрактного типа с описанными и зафиксированными методами. Что, по сути — и есть общий базовый универсальный интерфейс)) Строго говоря, Именно наследование всех от абстрактного класса и композиция, а не наследование — официальные рекомендации по построению программных систем в КП.

        Ответить

Добавить комментарий

Ваш e-mail не будет опубликован. Обязательные поля помечены *