Архитектура приложений — горячие точки

http://blogs.msdn.com/jmeier/archive/2008/09/22/architecture-frame.aspx
  • Перевод
Как часть нашего проекта, мы свели вместе информацию об общих подходах к разработке архитектуры приложений.

Общие подходы представяют собой набор «горячих точек» (hot spots). Однако это не просто горячие точки. Эти горячие точки преставляют собой ключевые вопросы, проблемы и рекомендации. Все вместе они помогают вырабатывать более эффективные с технической точки зрения архитектуры. Этот список является частью более общей структуры App Arch Meta Frame. Думайте о нём, как о важной ветке большого дерева.

Категории

Следующие категории являются горячими точками в архитектуре приложения:
  • Аутентификация и авторизация (Authentication and Authorization)
  • Кэширование и состояние (Caching and State)
  • Взаимодействие (Communication)
  • Композиция (Composition)
  • Параллельные вычисления и транзакции (Concurrency and Transactions)
  • Управление конфигурацией (Configuration Management)
  • Связанность и сцепление (Coupling and Cohesion)
  • Доступ к данным (Data Access)
  • Работа с исключениями (Exception Management)
  • Ведение логов и мониторинг (Logging and Instrumentation)
  • Взаимодействие с пользователем (User Experience)
  • Проверка данных (Validation)
  • Поток операций (Workflow)

Горячие точки соответствуют разным сквозным функциональностям, использующимся при создании приложений и, соответственно, разным наборам паттернов и практик. Например, Enterprise Library обычно включает блоки, отвечающие за кэширование, управление исключениями, ведение логов, валидацию и т.д. Категориям также соответствуют разнообразные анти-паттерны, самый плохой из которых — это анти-паттерн «переделать заново» («do over»). :)

Ключевые вопросы

Эта таблица перечисляет ключевые вопросы для каждой горячей точки:

Категория
Ключевые вопросы
Аутентификация и авторизация
  • Как хранить идентификационные данные зарегистрированных пользователей?
  • Как аутентифицировать запросы?
  • Как авторизовывать запросы?
  • Как передавать идентификационные данные пользователей между слоями приложения?

Кэширование и состояние
  • Как выбрать эффективную стратегию кэширования?
  • Как увеличить производительность с помощью кэширования?
  • Как улучшить безопасность с помощью кэширования?
  • Как улучшить стабильность с помощью кэширования?
  • Как поддерживать кэш в актуальном состоянии?
  • Как определить когда и каким образом использовать специализированный кэш?
  • Как определить какие данные кэшировать?
  • Как определить куда кэшировать данные?
  • Как определить правила удаления данных из кэша из-за устаревания или переполнения?
  • Как загружать данные кэша?
  • Как следить за кэшем?
  • Как синхронизовать между собой множественные кэши?
  • Как определить какой способ кэширования даёт наибольшую производительность и масштабируемость для определённого сценария и конфигурации.
  • Как определить какая технология кэшировния удовлетворяет требованиям приложения насчёт безопасности, лёгкости управления и
    мониторинга.

Взаимодействие
  • Как передавать информацию между слоями приложения?
  • Как совершать асинхронные операции?
  • Как передавать секретные данные?

Композиция
  • Как спроектировать структуру приложения?
  • Как спроектировать слабую связанность между модулями?
  • Как работать с зависимостями в слабосвязанном режиме?

Параллельные вычисления и транзакции
(прим. переводчика): Тут автор продублировал предыдущую категорию. Если ошибка будет исправлена в оригинале, то исправлю и перевод.
Управление конфигурацией
  • Как определить какая информация подлежит конфигурированию?
  • Как определить где и каким образом сохранять конфигурационную информацию?
  • Как работать с секретной информацией?
  • Как работать с конфигурационной информацией в кластере?

Связанность и сцепление
  • Как разделить функцональности?
  • Как структурировать приложение?
  • Как выбрать подходящее разбиение на слои?
  • Как задать границы между частями системы?

Доступ к данным
  • Как управлять соединениями БД?
  • Как управлять исключениями?
  • Как улучшить производительность?
  • Как улучшить управляемость?
  • Как работать с бинарными данными (BLOBs)?
  • Как использовать пейджинг (paging) для записей?
  • Как управлять транзакциями?

Работа с исключениями
  • Как обрабатывать исключения?
  • Как сохранять информацию об исключениях?

Ведение логов и мониторинг
  • Как определить какую информацию писать в лог?
  • Как сделать запись в лог настраиваемой?

Взаимодействие с пользователем
  • Как повысить эффективность выполнения задач?
  • Как улучшить отзывчивость интерфейса?
  • Как улучшить возможности приложения для пользователя?
  • Как улучшить внешний вид приложения?

Проверка данных
  • Как определить где и когда проводить валидацию данных?
  • Как проверять длину, диапазон, формат и тип данных?
  • Как ограничить вводимые данные и сообщать о неправильных значениях?
  • Как обезопасить (sanitize) выводимые данные?

Поток операций
  • Как решать проблемы параллельных вычислений в потоке операций?
  • Как обрабатывать ошибки в потоке операций?
  • Как координировать процессы в потоке операций?


Ключевые проблемы

Эта таблица сводит вместе ключевые проблемы для каждой горячей точки:
Категория
Ключевая проблема
Аутентификация и авторизация
  • Хранение идентификацонных данных в открытом виде в файлах.
  • Передача идентификационных данных в открытом виде по сети.
  • Аккаунты с излишними привилегиями.
  • Долгоживущие сессии.
  • Смешивание персонализации и аутентификации.
  • Использование единственного контроллера доступа (gatekeeper).
  • Отсутствие ограничений на доступ к системным ресурсам для приложения.
  • Отсутствие ограничений на доступ к БД кроме определённых хранимых процедур (stored procedures).
  • Неадекватное разделение прав доступа.

Кэширование и состояние
  • Промахи кэша.
  • Отсутствие устаревания (expiration) данных в кэше.
  • Плохая архитектура кэша.
  • Отсутствие синхронизации кэша, необходимого для хорошего масштабирования системы.

Взаимодействие
  • Повышенный сетевой трафик и задержки из-за «тяжёлых» сообщений межу слоями.
  • Неудачные транспортные протоколы и форматы сообщений.
  • Слишком большие объёмы данных в сетях ограниченной пропускной способности.

Композиция
  • Тесно связанные модули
  • Дублированный код

Параллельные вычисления и транзакции
  • Блокирующие вызовы.
  • Негранулированная блокировка данных (nongranular locks).
  • Неправильная работа с потоками.
  • Слишком долгое удержание блокировки данных.
  • Неправильные уровни изоляции БД.

Управление конфигурацией
  • Небезопасные интерфейсы администрирования.
  • Небезопасные конфигурационные хранилища.
  • Хранение конфигурационных данных в открытом виде.
  • Слишком много администраторов в системе.
  • Слишком много привилегий для аккаунтов служб и процессов.

Связанность и сцепление
  • Ограниченная масштабируемость из-за тесной привязанности к серверу и ресурсам.
  • Смешивание уровней презентации и бизнес-логики, ограничивающее возможни масштабирования.
  • Проблемы с дальнейшей поддержкой из-за излишней связанности.

Доступ к данным
  • Использование отдельного логина/пароля для каждого пользователя когда в этом нет необходимости.
  • «Тяжёлые» запросы к БД.
  • Рассеянная по классам бизнес-логика.

Работа с исключениями
  • Оставление системы/приложения в нестабильном состоянии.
  • Открытие секретной информации конечным пользователям.
  • Использование исключений для работы логики.
  • Запись в логи недостаточной информации об исключении.

Ведение логов и мониторинг
  • Отсутствие логов и мониторинга.
  • Слишком высокая детализация логов и мониторинга.
  • Отсутствие настроек логов и мониторинга во время исполнения (run-time).
  • Отстуствие логов для критических бизнес-операций.

Взаимодействие с пользователем
  • Неэффективная поддержка задач пользователя.
  • Плохое время отклика.
  • Игнорирование пользователей с ограниченными возможностями.

Проверка данных
  • Фильтрация ошибочных данных лишь на уровне приложения.
  • Небезопасный вывод данных в HTML.
  • Небезопасное вставление данных в SQL.
  • Проверка данных лишь на стороне пользователя.
  • Использование имён файлов, URLов или имен пользователей для принятия решений насчёт безопасности.

Поток операций
  • Сильная связанность.
  • Негибкие процессы.
  • Проблемы с приоритетами и взаимными блокировками (race and deadlock issues).


Ключевые рекомендации

Эта таблица приводит ключевые рекомендации для каждой горячей точки:
Категория Ключевые рекомендации
Аутентификация и авторизация
  • Подумайте над требованиям к регистрации.
  • Разделите открытые всем и закрытые зоны.
  • Используйте политики блокировки аккаунтов конечных пользователей (например при множественных ошибках в пароле).
  • Поддерживайте настраиваемый срок действия пароля.
  • Обеспечьте возможность отключения (disable) аккаунтов администратором.
  • Не храните пароли.
  • Требуйте «сильных» паролей.
  • Не пересылайте паролей в открытом виде по сети.
  • Защищайте cookies c идентификационными данными.
  • Используйте несколько контроллеров доступа (gatekeepers).
  • Ограничьте доступ пользователей к системным ресурсам.
  • Подумайте над степенью детализации прав доступа.

Кэширование и состояние
  • Старайтесь не кэшировать создаваемые лишь для одного пользователя данные.
  • Не кэшируйте данные, которые должны точно предоставляться пользователю и обновляться в реальном времени.
  • Кэшируйте данные, которые меняются не очень часто или полностью статичны.
  • Не кэшируйте очень «тяжёлые» ресурсы.
  • Кэшируйте данные после преобразований, учитывая актуальность информации, на которой они основаны.
  • Сравните применимость дизайнов с хранением состояния (stateful) и без такового (stateless).
  • Обдумайте варианты хранения состояния.
  • Минимизируйте размер данных в сессии.
  • Освобождайте ресурсы сессии как можно быстрее.
  • Старайтесь не запрашивать данные сессии из бизнес-логики.

Взаимодействие
  • Выберите подходящий механизм удалённого взаимодействия.
  • Делайте компактные и удобные внешние интерфейсы.
  • Подумайте над тем, как передавать данные между слоями.
  • Минимизируйте объём данных, передаваемых по сети.
  • Используйте пакеты задач (batch work) для уменьшения количества вызовов по сети.
  • Избегайте транзакций, работающих между границами частей системы.
  • Обдумайте возможность асинхронного взаимодействия.
  • Изучите возможность использования очередей сообщений.
  • Оцените применимость подхода «выстрелил и забыл».
  • Укорачивайте цепочки обработки вызовов с помощью кэширования. Это улучшит масштабируемость.
  • Переместите асинхронность ближе к пользователю, интерфейсам служб и служебным агентам для обеспечения изоляции сервиса от внешних зависимостей.
  • Если вы вынуждены сделать какую-то функциональность синхронной, то подумайте, можно ли внутри сделать асинхронной её часть.

Композиция
  • Избегайте использования динамических представлений (layouts), которые сложно загружать и поддерживать.
  • Будьте осторожны с зависимостями между компонентами. Используйте паттерны абстракции при первой возможности для уменьшения потенциальных проблем с поддержкой системы в будущем.
  • Постарайтесь использовать шаблоны с возможностью вставки данных (placeholders). Например, используйте паттерн Template View для создания динамических веб-страниц, обеспечивающих повторное использование и единообразие.
  • Расмотрите возможность создания представлений из повторно используемых модулей. Например, используйте паттерн Composite View для создания множества элементарных частей, работающих как готовые модули.
  • Используйте хорошо известные паттерны для создания составных интерфейсов, содержащих отдельные модули пользовательских контролов.
  • Модулям не следует прямо ссылаться друг на друга или на приложение, которое их загружает.
  • Для взаимодействия с другими модулями и самим приложением надо использовать службы.
  • Модули не должны отвечать за управление своими зависимостями.
  • Желательно поддерживать добавление и удаление модулей как плагинов.

Параллельные вычисления и транзакции
  • Относитесь к потоку (thread) как общему ресурсу.
  • Создавайте пулы общих ресурсов или ресурсов, которых слишком мало.
  • Запрашивайте ресурс как можно позднее, освобождайте как можно раньше.
  • Изучите эффективность создания и уничтожения объектов.
  • Рассмотрите управление пропускной способностью ресурсов.
  • Снижайте возможные задержки путём минимизации времени блокировки ресурса.
  • Соблюдайте баланс между высокоуровневыми (coarse) и низкоуровневыми (fine) блокировками.
  • Выберите подходящий уровень изоляции.
  • Избегайте выполняющихся долго атомарных транзакций.

Управление конфигурацией
  • Защищайте интерфейсы администрирования системы.
  • Защищайте своё конфигурационное хранилище.
  • Разграничивайте административные полномочия.
  • Используйте минимально возможноые привилегии для аккаунтов процессов и служб.

Связанность и сцепление
  • Разбейте приложение на логические слои (layers/tiers).
  • Правильно выберите расположение для частей приложения в зависимости от требований к надёжности, производительности и масштабируемости.
  • С самого начала проектируйте систему со слабой связанностью.
  • Проектируйте систему с сильным сцеплением.
  • Используйте раннее связывание (early binding) где это возможно.
  • Оцените сходство ресурсов (resource affinity).

Доступ к данным
  • Если ваше приложение использует единственную БД, то используйте специализированный провайдер вместо универсального для большего быстродействия.
  • Если вы поддерживаете несколько видов БД, то вам необходим специальный уровень абстракции, который можно легко настроить под конкретное окружение.
  • Попробуйте управлять пропускной способностью ресурсов.
  • Изучите передачу в БД идентификаторов пользователей.
  • Разделяйте запросы «только для чтения» и транзакционные.
  • Не возвращайте данные, которые не будут использоваться.

Работа с исключениями
  • Не показывайте пользователям данные, которые раскрывают внутренности системы.
  • Не используйте исключения для управления потоком выполнения приложения.
  • Используйте коды ошибок вместо исключений, где это возможно.
  • Не перехватывайте исключения, которые вы не можете обработать.
  • Учтите, что повторное бросание исключения (rethrowing) — дорогая операция.
  • Сохраняйте как можно больше диагностической информации в ваших обработчиках исключений.

Ведение логов и мониторинг
  • Постоянно ведите мониторинг.
  • Сделайте логи настраиваемыми.

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

Проверка данных
  • Проверяйте данные на длину, диапазон, формат и тип.
  • Ограничивайте вводимые данные и сообщайте об ошибках.
  • Обезопасьте вводимые данные.
  • Не полагайтесь на проверку на стороне клиента.

Поток операций
  • Определите требования к управлению потоками операций. Если ими должен управлять бизнес-пользователь, то обеспечьте ему понятный интерфейс.
  • Определите как будут обрабатываться исключения в потоке операций.
  • Когда вы имеете с потоком операций, относящимся к людям, не забывайте о неопределённости человеческой натуры. Нельзя полагаться на то, что какая-то задача будет выполнена в какой-то срок и будет выполнена полностью.
  • Используйте интерфейсы служб для работы с внешними провайдерами потоков операций.
  • Используйте визуальные редакторы и метаданные для разаботки потоков операций вместо кода, если это возможно.


От переводчика: Люблю сжатый аналитический подход, поэтому и перевожу. :) И вообще рекомендую блог автора. Там много приятных для мозга списков и таблиц. Разумные поправки к переводу терминов приветствуются. Обсуждение спорных пунктов — тоже.
Метки:
Поделиться публикацией
Похожие публикации
Комментарии 31
  • +2
    Очень позновательно, сохранил линк, прочитаю внимательно чуть позже :)
    • +1
      В избранное, так же позже переварю головой…

      Но уже есть вопрос, Списки в правой колонки выставлены по важности или в разброс, мне кажеться в разброс…
      • 0
        Насколько я понял, автор считает все эти пункты обязательными, так что порядок не играет роли.

        А вообще, т.к. я не избалован кучей теории и практики в проектировании приложений (я могу спроектировать, но исходя из опыта и потребностей, а не как аналитик), было бы неплохо если бы автор мог бы каждый пункт в левой колонке описать отдельно что это такое, привести примеры, задать те же вопросы и на них ответить в виде пары примеров. Теоретик с меня к сожалению плохой, зато отличный практик и часто правильные решения я вывожу сам, делаю, а потом где-то читаю что это хорошая практика. Так что правка мозгов в нужное русло мне бы очень не помешала :)
        • 0
          я недавно обнаружил, что у меня статей на «переварю позже» собралось больше 40 за месяц)
          надо как-то решать проблему…
          • 0
            Ну все подряд наверное не имеет смысла переваривать, а только то, что жестко интересно, что аж не оторваться. Остальное можно оставить до момента, когда оно потребуется или станет жестко интересно :) Главное чтобы найти было возможно потом.
      • НЛО прилетело и опубликовало эту надпись здесь
        • НЛО прилетело и опубликовало эту надпись здесь
          • +7
            Напоминает лекции в университете. Все на столько хорошо структурированно, насколько оно же бесполезно.
            • +1
              Практической пользы может быть и немного, но я лично всегда с уважением относился к структурированию информации. Хорошо, когда в голове все инструменты аккуратно помечены и лежат на полочках. С этой точки зрения пробежаться по пунктам полезно.
              • +1
                почему бесполезно? такие наброски позволяют заранее обозначить множество проблем, которые непосредственно влияют на проектирование. если не учитывать их сразу, потом вполне может возникнуть ситуация с необходимостью переделать какую-нибудь логику, и это может привести даже к глобальным изменениям в архитектуре.
                часто мы не можем заранее учесть все потребности системы, но следует сразу продумать как можно больше потенциальных проблем, особенно это актуально для распределяемых приложений
                • 0
                  Да я как бэ не спорю. Но скажите честно, как вам поможет в этом пункт, например, «Промахи кэша» в категории «Кэширование и состояние». Какую информацию он вам принес?
                  • 0
                    Для новичка это действительно мало что скажет. Разве что фразу для Гугла. А знающий человек поднимет в памяти знакомые рецепты.
                    • 0
                      Информация — промахи кэша существуют, вероятно для оптимизации нужно с ними бороться :-)

                      Часто достаточно показать существование пути.
                      Методы решения меняются, вопросы остаются.
                • 0
                  В проектировании привык называть Workflow потоком операций, как-то ближе оно мне, учитывая, что актором и инициатором потока может выступать не только бизнес-пользователь.
                  • +1
                    Ваш вариант мне нравится больше. Принимаю к сведению. :)
                  • +1
                    >>Ключевые решения

                    >>Эта таблица перечисляет ключевые решения для каждой горячей точки:

                    Может я не верно понимаю, но как то странно звучит слово «решения» в этом контексте… по моему правильнее было бы слово «задачи»… все-таки в таблице задаются вопросы плана «как это сделать», а не ответы на них… возможно я и ошибаюсь.
                    • –2
                      Информация изложена ужасно!
                      • НЛО прилетело и опубликовало эту надпись здесь
                      • +2
                        Майкрософт во всей своей красе, с табличками, буллет-пойнтами и ответами на все случаи жизни.

                        So you wanna be a great programmer, do ya? All you have to do is follow these seven easy bullet points:

                        1. Stop reading bullet points!
                        2. You heard me, stop reading these stupid bullet points!
                        3. They're not helping, you know.
                        4. They are often just fluffy platitudes.
                        5. Still reading? I thought you'd get wise by now?
                        6. It just shows how useless bullet points actually are…

                        theprogrammersparadox.blogspot.com/2008/09/7-fabulous-ways-to-great-programming.html — интересный пост по поводу такого рода информационного фастфуда, рекомендуется к прочтению
                        • 0
                          Почему-то представилось грустное выражение лица начинающего программиста «Я всего лишь хотел сделать сайт :)». А так очень позновательно, браво.
                          • 0
                            Очень интересный текст. Никогда мне не удавалось всё это учесть, к сожалению — что и приводит к проблемам через несколько лет эксплуатации системы.
                            • 0
                              Честно говоря у нас в системе, если не учитывать это, то к проблемам начинает приводить почти сразу. Но в большей степени данные «точки» относятся к крупным распределенным системам, чем к обычным Web сайтам и любительским приложениям. Так что их можно взять на заметку, если пишешь такую большую систему, но в тоже время следовать всему что тут написано я бы не стал. Если прочитать все существующие стандарты и рекомендации, то время больше убьешь на их запоминание и понимание, чем на разработку такой системы, и не знай еще что у тебя после всех этих «знаний» получится. Я лично предпочитаю делать в таком русле: если есть технология, которая решает мою проблему (или задачу, не важно) самым оптимальным для меня образом и без проблем применяется в «мире» — я ее и применяю, нету такой технологии, приходится изобретать самому :)
                              • +1
                                Стандарты говорят о том, что если их использовать, то изменение требований к проекту в будущем не потребует серьёзных перестроек, и проект сможет взаимодействовать с другими проектами, поддерживающими стандарты.

                                Если же пользоваться своими изобретениями, то полечается в конце концов вещь в себе, которую проще переделать чем развивать.
                            • –3
                              Блин, это бред, но трудно объяснить почему. Попробую с помощью притчи:

                              Приносят Вам колеса от грузовика, мотор от запорожца, кузов от X5 и подвеску от Субару Легаси. И говорят — вот смотри каждая из этих фигней крайне эффективна. Смотри — мотор от запорожца экономичный до жути! Кузов X5 эффективнейшим образом создан в плане жесткости и безопасности. Колеса от грузовика ваще супер эффективны — их можно не накачивать.

                              Сделай теперь мне из этих суперэффективных деталей небольшой семейный автомобиль, работающий на водороде.

                              И?
                              Намек понятен?
                              • 0
                                Понятно что Вы не поняли о чём писал автор. А писал он о пунктах контроля качества разрабатываемого проекта. И не требовал применять их все к разработке сайта-визитки. А вот для разработки сайта, который должен 10-20 лет работать и развиваться, при этом не падая под мегабайтами старого неподдерживаемого кода — это совершенно незаменимые пункты.
                                • 0
                                  Просто есть люди, которые думают, что если они не понимают, как что-то сделать, значит никто больше не в состоянии в этом разобраться. Особенно удручающе, если это сочетается с проблемами в самооценке, такой эскулап на высоких должностях обычно не дает проходу практически никаким свежим идеям.
                                • –2
                                  Еще раз повторяю — не существует универсальных советов. Эффективность не существует в вакууме, она служит определенным целям. Поэтому общие положения являются ерундой. На каждый пункт списка этого якобы качества я за секунду могу придумать контрпример. Вот беру по одному из каждого:

                                  «Используйте политики блокировки аккаунтов конечных пользователей (например при множественных ошибках в пароле).»

                                  … что позволит хакерам без особых сложностей блокировать нужные им аккаунты.

                                  «Кэшируйте данные, которые меняются не очень часто или полностью статичны.»

                                  Торговая система, данные из шлюза обновляются редко, пользователь грузит конфигурацию и видит пустой экран вместо текущего состояния рынка.

                                  «Минимизируйте объём данных, передаваемых по сети.»

                                  Например для Вашего проекта цифрового телевидения вместо картинки передавайте текстовое описание того, что происходит на экране?

                                  «Будьте осторожны с зависимостями между компонентами. Используйте паттерны абстракции при первой возможности для уменьшения потенциальных проблем с поддержкой системы в будущем.»

                                  Между связностью системы и стоимостью ее поддержания не существует прямой связи. Наоборот может оказаться, что сильно связанная система (использующая прямое обращение к MS SQL) окажется намного проще слабо связанной (использующей распределенные компоненты, слои доступа, DCOM, CORBA и прочее) и поддерживать ее будет легче.

                                  «Избегайте выполняющихся долго атомарных транзакций»

                                  Неатомарных транзакций вроде как и не бывает. Транзакция она по определению атомарна.

                                  «С самого начала проектируйте систему со слабой связанностью.
                                  Проектируйте систему с сильным сцеплением.»

                                  Гы гы гы. У меня стоит задача написать Тетрис и я вот думаю — как бы мне его слабо связать и сильно сцепить. :)))

                                  «Если вы поддерживаете несколько видов БД, то вам необходим специальный уровень абстракции, который можно легко настроить под конкретное окружение.»

                                  Угу я вот использую timestamp из MS SQL, а в ORACLE его и нет. В какую бы мне это абстракцию засунуть?..

                                  «Не перехватывайте исключения, которые вы не можете обработать.»

                                  Позвольте им обрушить Ваше приложение!!! Это ведь прикольно и понравится пользователям!!!

                                  Это ваще супер-совет! Совет дня! Надо на стенку его прибить!..
                                  Все, надоело… Пускай теперь воинствующее невежство минусует меня…

                                • 0
                                  «самый плохой из которых — это анти-паттерн «переделать заново» («do over»)» — к сожалению с этим вынужден не согласиться. Все еще существуют системы, которые выполнены не в соответствии с принципами, приведенными в топике, и их проще переделать, чем рефакторить. Да и тов. Брукс писал, что первая система всегда разрабатывается на выброс, так что даже следование данным правилам, не факт, что приведет к желаемому результату, но Очень сильно поможет направить проект в нужное русло, если развитие пошло криво. Вообщем контент в заклады. Каждый архитект должен иметь подобный чеклист под рукой.
                                  • 0
                                    Тот же Брукс ещё писал, что вторую систему разработать вообще невозможно :)
                                  • –1
                                    Не подскажите какую-нибудь дитературу, которая может помочь понять все вышеперечисленные проблемы?
                                    Пишу потихоньку cms, улучшаю, удаляю, исправляю, хотелось бы почитать что-нибудь на эту тему.
                                    • –1
                                      Такие статьи очень сложно воспринимать — терминология может использоваться по разному.
                                      Например:
                                      — кэширование js, css, cookies на стороне клиента
                                      — или кэширование jsp-сервлетов на j2ee-сервере
                                      — или кэширование хранимых процедур в БД
                                      -и т.д.
                                      … как понять?

                                      Так что в зависимости от архитектуры, данные термины могут иметь абсолютно разные значения.

                                      Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.