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

ОглавлениеДобавить в закладки К обложке

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

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

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

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

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

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

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

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

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


-= 116 =-
Регистрация.
Забыли пароль?
Логин
Пароль
Запомнить меня