Мой совет: не поддавайтесь искушению довести дизайн или реализацию системы до совершенства! Ориентируйтесь на отметку «достаточно хорошо» и остановитесь, когда вы доберетесь до нее.

«Что именно означает „достаточно хорошо“?» — спросите вы. Это означает, что оставшиеся недочеты не оказывают сколько-нибудь заметного влияния на функциональность, удобство сопровождения или производительность системы. Архитектура и дизайн идут рука об руку. Реализованная система работает и соответствует требованиям к производительности. Программный код понятен, лаконичен и хорошо документирован. Можно ли сделать лучше? Конечно, но и так достаточно хорошо — поэтому остановитесь. Заявите о своей победе и переходите к следующей задаче.

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

Некоторые этюды в этой книге предостерегают проектировщиков от излишних абстракций и избыточной сложности. Почему мы не довольствуемся простыми решениями? Потому что мы стремимся к идеальному решению! Зачем еще архитектору вводить сложность в работоспособное решение, если не для устранения субъективных несовершенств в более простом варианте?

Помните, что разработка приложений — не конкурс красоты. Перестаньте выискивать недочеты и тратить время на поиски совершенства.

Грег Найберг (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), где данные — это информация, доставляемая потребителю в виде неструктурированного или слабо структурированного контента. Именно качество контента часто отличает актуальную систему от бесполезной.

Контент — король. Контент — сеть. Контент — интерфейс. В современном мире, пронизанном многочисленными информационными связями, качество контента все чаще определяет успех или неудачу. FaceBook против Orkut, Google против Cuil, NetFlix против BlockbusterOnline… список сражений, выигранных и проигранных на поле контента, можно продолжать до бесконечности. Кто-то может возразить, что аспекты, касающиеся контента, не относятся к проблематике архитектора ПО, но я считаю, что следующее десятилетие докажет обратное.

Оценка контента должна стать частью процесса проектирования новой системы. Простого проектирования эффективной модели предметной области/ объектов/данных недостаточно.

Проанализируйте весь доступный контент и оцените его значимость по следующим критериям:

• Достаточно ли доступного количества контента? Если нет, как получить «критическую массу»?

• Достаточно ли актуальна содержащаяся в нем информация? Если нет, как улучшить скорость поступления?

• Все ли возможные каналы распространения контента изучены? RSS-трансляции, электронная почта, бумажные бланки — все это является возможными каналами.

• Созданы ли эффективные входные потоки, упрощающие непрерывное поступление контента в систему? Одно дело — выявить ценный контент, и совсем другое — организовать его регулярное получение.

Несомненно, успех системы зависит от ее контента. Уделите в процессе проектирования достаточное внимание анализу ценности контента. Если результаты анализа окажутся неудовлетворительными, это тревожный признак, о котором следует посоветоваться с заинтересованными сторонами проекта. Я видел много систем, которые выполняли все обязательства по договору, соответствовали всем требованиям — но все равно потерпели неудачу, потому что этот очевидный аспект был проигнорирован. Хороший контент порождает хорошие системы.

Зубин Бадья (Zubin Wadia) — генеральный директор RedRock IT Solutions и технический директор ImageWork Technologies. Обладает разносторонней квалификацией в области программирования, владеет языками Basic, С, C++, Perl, Java, JSP, JSF, JavaScript, Erlang, Scala, Eiffel и Ruby. Специализируется на разработке решений из области автоматизации бизнес-процессов для компаний из списка Fortune Global 500 и правительственных учреждений США.

В карьере любого архитектора наступает момент, когда становится ясно, что многие вопросы, с которыми он имеет дело, уже встречались на его пути раньше. Сменяются проекты и области, но проблемы остаются прежними. На этой стадии мы можем опереться на свой опыт, чтобы создавать решения быстрее и оставлять максимум времени для более интересных задач. Мы уверены в своих решениях, мы выдаем их в полном соответствии со своими обещаниями. Наступает своего рода гомеостаз. Именно в такие моменты легко совершить огромную ошибку — решить, что вы знаете достаточно много для того, чтобы отныне говорить больше, чем слушать. Это ошибочное решение обычно сопровождается цинизмом, нетерпимостью и гневом по отношению к тем «низшим умам», которые смеют оспаривать ваше выдающееся понимание всех вопросов — технических и прочих.