Книга: Как пасти котов. Наставление для программистов, руководящих другими программистами

Нулевой этап проектирования

Нулевой этап проектирования

Итак, имея на руках грандиозную архитектуру, вы готовы приступить к проектированию компонентов. Прекрасно. Мобилизуйте все свои объектно-ориентированные навыки. В первую очередь вам предстоит проверить архитектуру, имея в виду подчеркнуть приоритет этого этапа (я называю его «нулевым») в контексте процесса проектирования. Другими словами, вы должны провести макетирование архитектуры, но не совсем так, как это делается обычно. Вместо обширного графического пользовательского интерфейса сконструируйте ряд низкоуровневых компонентов, снабдите их интерфейсами-заглушками и возвращаемыми значениями – это позволит убедиться в работоспособности системы в вертикальной проекции. Конструируемые на этом этапе графические пользовательские интерфейсы должны лишь подавать сигналы и запускать те или иные процессы – больше от них ничего не требуется. Ведь ни один человек не выживет, если его мозг не будет взаимодействовать с сердцем, так? Именно поэтому, кстати, косметические операции проводятся исключительно по желанию пациента, а вот при проведении операции на головном мозге его согласия не требуют. Я полностью убежден – проверять архитектуру необходимо. На это, скорее всего, уйдет больше времени, чем можно было бы ожидать, но не сомневайтесь – усилия стоят того. С соблазном сразу перейти к разработке реальных компонентов системы нужно бороться – будет очень неприятно, если, подключив все компоненты, вы обнаружите, что они не стыкуются или не работают.

Первое, что нужно сделать в процессе проектирования, – это проверить архитектуру.

Подробности процесса «проверки концепции» я, пожалуй, опущу – благо литературы, посвященной архитектуре и проектированию, предостаточно. Только вот не стоит перекладывать обязанности по проверке архитектуры на кого-то другого – и не дай вам Боже отложить этот процесс до бета-тестирования. Эта обязанность ложится на вас и ваших подчиненных, а основная идея, которую я стремлюсь до вас донести, ясна и понятна – нельзя уклоняться от выполнения своих обязанностей. Ваша первоочередная задача в процессе проектирования заключается как раз в том, чтобы проверить архитектуру на предмет ее применимости – вот почему речь идет о «нулевом», то есть о приоритетном, этапе. Если на все нижеследующие вопросы вам удастся ответить положительно, значит, вы наверняка на правильном пути.

• Предполагает ли архитектура возможность идентификации подсистем функций и предотвращает ли она их взаимозависимость с другими подсистемами? Удалось ли вам сконструировать объекты, способные функционировать сравнительно независимо при помощи ограниченного числа вспомогательных объектов?

• Насколько доходчиво «перспективное представление» системы – сможет ли, скажем, продавец, прослушав краткий инструктаж, объяснить потенциальным клиентам, как работает программный продукт, который они намереваются приобрести?

• Исключается ли жесткое кодирование параметров конфигурации системы? К примеру, потребуется ли повторная компиляция программы при переименовании сервера или домена, или редактирования конфигурационного файла будет достаточно?

Обратите внимание на слово «наверняка», выделенное курсивом в последнем предложении абзаца, предшествующего списку. Почему я употребил именно это слово? Дело в том, что вы должны учитывать все факторы воздействия на систему на 1–2 года вперед. Невозможно выстроить надежный план действий, не зная коммерческой конъюнктуры. С другой стороны, разбираясь в тонкостях бизнеса, вы имеете все шансы стать предсказателем будущего своих программных продуктов.

Почему я говорю «предсказатель», а не, скажем, «прогнозист»? Объясняется это следующим образом. Термин «предсказатель» (prognosticator) образуется из двух греческих корней: pro, что в переводе означает «до», и gnosis, то есть «знание». Нельзя точно знать, что произойдет в будущем, однако, как и специалисты, составляющие прогнозы погоды, чем больше мы практикуемся по части предсказаний, тем лучшие результаты получаем. Не стоит также забывать, что создание программных продуктов – это искусство, которое постепенно приобретает очертания науки. Любая наука начинается с исследования явлений (феноменологии). В контексте разработки программных средств эта деятельность сводится к документированию всех явлений, наблюдаемых в ходе процесса, и построению эталонов. По мере исполнения этой миссии начинают выкристаллизовываться закономерности, согласно которым у нас что-то получается или, наоборот, не получается. В конце концов нам удается сформулировать принципы кодирования. Когда кому-нибудь это удается, он присваивает новому принципу свое имя, публикует книгу и наслаждается признанием. Именно этим в последнее десятилетие занимались разработчики концепции позитивных (pattern) и негативных (antipattern) эталонов, в связи с чем ваши шансы на славу теперь минимальны.

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

Оглавление книги