97 этюдов для архитекторов программных систем
Шрифт:
Я считаю, что стремление к идеальному дизайну и идеальной реализации приводит к излишне усложненным и запутанным решениям, которые в конечном итоге затрудняют сопровождение системы.
Некоторые этюды в этой книге предостерегают проектировщиков от излишних абстракций и избыточной сложности. Почему мы не довольствуемся простыми решениями? Потому что мы стремимся к идеальному решению! Зачем еще архитектору вводить сложность в работоспособное решение, если не для устранения субъективных несовершенств в более простом варианте?
Помните, что разработка приложений — не конкурс красоты. Перестаньте выискивать
Грег Найберг (Greg Nyberg) — независимый консультант в области J2EE с 18-летним опытом проектирования, построения, тестирования и развертывания крупномасштабных транзакционных приложений, таких как системы оформления предварительных заказов, центры приема звонков и потребительские веб-сайты. Является, автором справочника «WebLogic 6.1 Server Workbook for Enterprise JavaBeans, 3-е издание» (O’Reilly) и ведущим автором книги «Mastering WebLogic Server» (Wiley).
Остерегайтесь «хороших идей»
Грег Найберг
Хорошие идеи убивают проекты. Иногда смерть наступает быстро, но чаще это медленное, мучительное умирание, причиной которого служат сорванные сроки и лавины программных ошибок.
Вы знаете, о каких хороших идеях я говорю: соблазнительные, очевидные, абсолютно безвредные на первый взгляд — «ничего-страшного-не-будет-если-мы-попробуем». Обычно они приходят в голову кому-либо в команде где-то в середине жизненного цикла проекта, когда все вроде бы идет хорошо. Работа движется в бодром темпе, начальное тестирование проходит как положено, дата выпуска выглядит непоколебимой — жизнь прекрасна.
Тут у кого-то появляется «хорошая идея», вы с ней соглашаетесь — и вот вы уже переделываете проект под свежую версию Hibernate, чтобы воспользоваться ее новейшими возможностями, или используете AJAX на некоторых веб-страницах, потому что разработчик показал пользователям, как круто это смотрится, или пересматриваете архитектуру базы данных, чтобы задействовать те возможности по работе с XML, которые предлагает СУБД. Вы говорите руководителю проекта, что для реализации этой «хорошей идеи» понадобится еще несколько недель, однако изменения затрагивают больший объем кода, чем предполагалось, и график начинает трещать по швам. Вдобавок, приняв первую «хорошую идею», вы, как в поговорке, «выпустили джинна из бутылки»: вскоре на свет появляются новые «хорошие идеи», а вам уже гораздо труднее отказать (а джинн тем временем уже выглядывает из всех щелей).
Самая коварная особенность «хороших идей» состоит в том, что они «хороши». «Плохую» идею распознает и отвергнет кто угодно — в проект проникают именно «хорошие» идеи, раздувая его масштаб и повышая сложность, а также требуя лишних усилий на включение в приложение того, что не нужно для достижения бизнес-целей.
Вот несколько ключевых фраз, свидетельствующих об опасности:
• «Разве не круто будет, если…». На самом деле сигналом тревоги может быть любое предложение со словом «круто».
• «Только что вышла версия XXX библиотеки YYY. Нам надо перейти на новую версию!»
•
• «XXX — действительно мощная технология! Возможно, мы сможем применить ее в…»
• «Послушай, <здесь_ваше_имя>, я тут размышлял о дизайне нашей системы — и мне пришла в голову мысль…»
Хорошо, хорошо — возможно, в последнем пункте я перегибаю палку. Но вы все равно должны остерегаться «хороших идей», которые способны убить ваш проект.
Биография, автора приведена на стр. 155.
Хороший контент порождает хорошие системы
Зубин Вадья
Я видел великое множество инициатив, в которых внимание было сосредоточено на требованиях, дизайне, разработке, безопасности, сопровождении, но только не на сущности системы — данных. Такая ситуация особенно часто встречается в контентных системах (content-based systems), где данные — это информация, доставляемая потребителю в виде неструктурированного или слабо структурированного контента. Именно качество контента часто отличает актуальную систему от бесполезной.
Контент — король. Контент — сеть. Контент — интерфейс. В современном мире, пронизанном многочисленными информационными связями, качество контента все чаще определяет успех или неудачу. FaceBook против Orkut, Google против Cuil, NetFlix против BlockbusterOnline… список сражений, выигранных и проигранных на поле контента, можно продолжать до бесконечности. Кто-то может возразить, что аспекты, касающиеся контента, не относятся к проблематике архитектора ПО, но я считаю, что следующее десятилетие докажет обратное.
Оценка контента должна стать частью процесса проектирования новой системы. Простого проектирования эффективной модели предметной области/ объектов/данных недостаточно.
Проанализируйте весь доступный контент и оцените его значимость по следующим критериям:
• Достаточно ли доступного количества контента? Если нет, как получить «критическую массу»?
• Достаточно ли актуальна содержащаяся в нем информация? Если нет, как улучшить скорость поступления?
• Все ли возможные каналы распространения контента изучены? RSS-трансляции, электронная почта, бумажные бланки — все это является возможными каналами.
• Созданы ли эффективные входные потоки, упрощающие непрерывное поступление контента в систему? Одно дело — выявить ценный контент, и совсем другое — организовать его регулярное получение.
Несомненно, успех системы зависит от ее контента. Уделите в процессе проектирования достаточное внимание анализу ценности контента. Если результаты анализа окажутся неудовлетворительными, это тревожный признак, о котором следует посоветоваться с заинтересованными сторонами проекта. Я видел много систем, которые выполняли все обязательства по договору, соответствовали всем требованиям — но все равно потерпели неудачу, потому что этот очевидный аспект был проигнорирован. Хороший контент порождает хорошие системы.