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. Нам надо перейти на новую версию!»

• «Знаешь, раз уж мы работаем над ZZZ, нам стоит заодно переработать XXX…»

• «XXX — действительно мощная технология! Возможно, мы сможем применить ее в…»

• «Послушай, <здесь_ваше_имя>, я тут размышлял о дизайне нашей системы — и мне пришла в голову мысль…»

Хорошо, хорошо — возможно, в последнем пункте я перегибаю палку. Но вы все равно должны остерегаться «хороших идей», которые способны убить ваш проект.

Биография, автора приведена на стр. 155.

Хороший контент порождает хорошие системы Зубин Вадья

Я видел великое множество инициатив, в которых внимание было сосредоточено на требованиях, дизайне, разработке, безопасности, сопровождении, но только не на сущности системы — данных. Такая ситуация особенно часто встречается в контентных системах (content-based systems), где данные — это информация, доставляемая потребителю в виде неструктурированного или слабо структурированного контента. Именно качество контента часто отличает актуальную систему от бесполезной.