Самая коварная особенность «хороших идей» состоит в том, что они «хороши». «Плохую» идею распознает и отвергнет кто угодно в проект проникают именно «хорошие» идеи, раздувая его масштаб и повышая сложность, а также требуя лишних усилий на включение в приложение того, что не нужно для достижения бизнес-целей.
Вот несколько ключевых фраз, свидетельствующих об опасности:
«Разве не круто будет, если». На самом деле сигналом тревоги может быть любое предложение со словом «круто».
«Только что вышла версия XXX библиотеки YYY. Нам надо перейти на новую версию!»
«Знаешь, раз уж мы работаем над ZZZ, нам стоит заодно переработать XXX»
«XXX действительно мощная технология! Возможно, мы сможем применить ее в»
«Послушай, , я тут размышлял о дизайне нашей системы и мне пришла в голову мысль»
Хорошо, хорошо возможно, в последнем пункте я перегибаю палку. Но вы все равно должны остерегаться «хороших идей», которые способны убить ваш проект.
Биография, автора приведена на стр. 155.
Хороший контент порождает хорошие системы Зубин Вадья
Не применяйте при проектировании шаблоны, которые вы не использовали прежде. Не полагайтесь на инфраструктуры, с помощью которых вы никогда ничего не разрабатывали. Не используйте сервер, который вам не доводилось настраивать. Если архитектура зависит от элементов, с которыми вы никогда не имели дела лично, возникает целый ряд отрицательных побочных эффектов:
Вы не представляете себе кривую обучения, которую предстоит одолеть вашим разработчикам. Не зная, сколько времени потребуется для изучения новой технологии, вы не сможете достоверно оценить время реализации.
Вы не знаете, какие «ловушки» могут подстерегать вас при использовании этих элементов. На практике все обязательно пойдет не так гладко, как на демонстрации, которую проводил эксперт в этой технологии. Если прежде вы никогда не работали с технологией, вас неизбежно ждут неприятные сюрпризы.
Вы лишитесь доверия своих разработчиков. Если вы не можете уверенно ответить на вопросы, относящиеся к вашему дизайну, разработчики быстро перестанут доверять вам и вашим творениям.
Вы подвергаетесь излишнему риску; нехватка знаний ставит жирный вопросительный знак на ключевых элементах решения. Никто не захочет начинать проект, имея в багаже огромный ненужный риск.
Как же архитектор должен подходить к освоению новых инфраструктур, шаблонов и серверных платформ? Об этом вам расскажет этюд «Архитектор прежде всего разработчик».
Биография автора приведена ранее.
«Что значит имя?», или Как роза превращается в капусту Сэм Гардинер
К сожалению, еще не было точно известно, какие Классные Штуки она должна вытворять, поэтому архитекторы не знали, как ее назвать. Им пришлось затеять небольшой конкурс на лучшее имя. В подобный момент вы должны понять, что столкнулись с проблемой: если вы не знаете, как что-то назвать, то вы не знаете, что это такое. А если вы не знаете, что это такое, то вы не сможете сесть и написать программный код.
В нашем конкретном случае быстрый просмотр истории версий исходного кода выявил всю глубину проблемы. Конечно, в нем оказалось множество пустых «реализаций» интерфейсов! Но самое смешное, что даже без нормального кода имена уже менялись трижды. Сначала было выбрано имя ClientAPI (причем под «клиентом» имелся в виду заказчик, а не клиент в контексте модели «клиент-сервер»), а последняя версия называлась ClientBusinessObjects. Воистину замечательное имя: туманное, предельно широкое и сбивающее с толку.
Конечно, имя это всего-навсего указатель. Как только все участники будут знать, что имя это просто имя, а не архитектурная метафора, вы сможете двигаться дальше. Но если вы не можете договориться о выборе имени, которое было бы достаточно конкретным, чтобы вы сразу могли понять, подходит оно или нет, то
реализацию надежного механизма передачи сообщений, распределенные транзакции или повышение производительности за счет применения многопоточности (и даже низкоуровневых языков, например, ассемблерных вставок). Так как задача остается неизменной, вы можете сосредоточиться на совершенствовании реализации до того уровня, на котором качество станет отличительной чертой вашей системы.
Стабильность задачи позволяет вам создать систему со стабильным дизайном; стабильность дизайна позволяет создавать приложения высочайшего качества.
Биография автора приведена ранее.
Необходимо усердие Брайан Харт
Усердие идет рука об руку с практичностью. Успешная практическая работа архитектора во многом обыденна. Эффективные архитекторы часто ведут ежедневные и еженедельные контрольные списки, которые напоминают им то, что они и так знают теоретически, но еще не делают по привычке. Без таких контрольных списков и напоминаний проект может быстро застопориться, потому что нехватка усердия позволяет архитектору обойти или нарушить известные теоретические принципы. В ходе ретроспективного анализа неудачных проектов важно понять, что в большинстве случаев крах произошел не из-за некомпетентности, а из-за недостатка усердия и чувства срочности.
Кроме того, быть усердным означает для архитектора преуспеть в обманчиво простом деле принятия и выполнения обязательств. Такие обязательства часто оказываются весьма разнородными и охватывают широкий диапазон ограничений и ожиданий. Примеры: