вторник, 7 января 2014 г.

Ссылка. Кому нужен архитектор?

http://sergeyteplyakov.blogspot.ru/2013/11/blog-post.html

Цитата:

"Лакмусовая бумажка архитектурного решения
Я неоднократно писал о лакмусовой бумажке хорошего дизайна. Когда я рассматриваю дизайн класса или модуля, то стараюсь понять насколько он является цельным и слабосвязным (все те же low coupling и high cohesion) с помощью юнит-тестов. Если их написать невозможно или они будут невменяемыми, то это говорит мне, что с дизайном что-то не то.
А как определить качество архитектурного решения? Чтобы понять, как далеко некоторое решение проникло (или проникнет) в разные части системы, я задаю себе такой вопрос: «А что если я ошибся и мне придется изменить это решение в будущем? Какие будут последствия?». Если некоторое решение размазано ровным слоем по всему приложению, то стоимость его изменения будет огромной, а значит это решение является архитектурным."

2 комментария:

  1. Статья годная, о чём я отписался здесь https://plus.google.com/100903871335644471614/posts/BCz2Q92ZkRx
    Спасибо за ссылку.

    Но для меня, наиболее близким в ней было следующее:
    «ПРИМЕЧАНИЕ
    Дизайн – это постоянный поиск компромиссов. Если мы добавляем гибкость, то мы жертвуем чем-то другим – обычно стоимостью разработки и сопровождения. Аналогично тому, как нет особого смысла заниматься тюнингом производительности приложения на ранних стадиях, нет особого смысла закладывать чрезмерную гибкость каждого разрабатываемого компонента. Именно из-за своих накладных расходов на разработку и сопровождение, оптимизация производительности или гибкости должны производиться лишь тогда, когда мы четко знаем, что это действительно окупится!
    Обычно именно простота (помните о разнице между simple и easy ) является наиболее оптимальным фундаментом для будущего улучшения эффективности или изменения функционала.

    Мое сдержанное отношение к аспект-ориентированному программированию заключается в том, что у нас уже есть приличное количество хороших техник для выделения аспектов в приложении, которые мы не используем. Я не думаю, что мы решим реальную проблему путем использования более продвинутых техник разделения ответственностей. Мы просто не знаем, какие аспекты нужно выделять и не знаем, когда вообще стоит их выделять, а когда нет.

    ПРИМЕЧАНИЕ
    Аналогично тому, как Мартин Фаулер сдержано относится к AOP, я сдержано отношусь к IoC-контейнерам. Ведь в нашем арсенале есть огромное количество принципов борьбы со сложностью и обеспечения гибкости: неизменяемость и композиция помогает бороться со сложностью, а многие паттерны проектирования упрощают изменения определенных аспектов системы. Чрезмерное выделение интерфейсов (вначале выделим, а потом посмотрим, нужно ли это) делают систему гибкой и слабосвязной ценой увеличения сложности.
    Не делайте систему гибкой на всякий случай, делайте ее гибкой там, где это вам действительно необходимо.»
    -- у меня сдержанное отношение и к АОП и к IoC, хотя в той или иной степени/форме находят применение оба подхода. Хотя здесь уместнее говорить даже не о подходах, а о концепциях.

    ОтветитьУдалить
  2. Смешно кстати. Я раз 10-15 перечитывал FAQ Теплякова про C++11. И Всё время им ВОСХИЩАЛСЯ!!!
    Но при этом его блог я "только что заметил".. :-(

    ОтветитьУдалить