Как пасти котов. Наставление для программистов, руководящих другими программистами
Шрифт:
Процесс конструирования программных продуктов можно сравнить с марафоном, но уж никак не со спринтом. Темп, предусматривающий долговечность конечного результата, есть необходимое условие достижения качества в производстве.
Как же, отказавшись от синтетического подхода в пользу органического и от быстрой разработки с неудовлетворительным результатом, создать стройную архитектуру? Мыслить органично вам поможет свежий взгляд на принципы проектирования и очередность этапов фазы разработки.
Свежий взгляд на проектирование
Как отличить проектное решение от архитектуры? Представьте себя божком, собирающимся сотворить живое и разумное существо, обладающее, к тому же, способностью к адаптации. Надеюсь, для вас это не проблема (кстати, если так, придется вам внимательно ознакомиться со следующей главой, посвященной темной стороне лидерства).
64
Ах, какой я молодец, что подобрал анатомическую метафору!
О чем вы говорите? Я предпочитаю VB и собираюсь писать на нем все программы [65] . Вы так считаете? Подумайте еще раз. Задачи, которые вам предстоит решать, – не гвозди; их нельзя вбивать одним молотком. Да, я опять обращаюсь к метафоре строительства, но, по-моему, в этом контексте она как нельзя более кстати. Не забывайте, впрочем, что метафоры и аналогии выполняют исключительно иллюстративную функцию – они как луч света в темной комнате, освещающий очертания меблировки. Иначе говоря, иллюстрация и реальный объект не идентичны; между иллюстрацией и проблемной областью нет точного соответствия. Аналогичным образом проектные решения можно принимать только при наличии утвержденной архитектуры.
65
Лично я пользуюсь VB, начиная с версии 1.0, поэтому никаких предрассудков против этого языка не питаю. Всем интересующимся проблемами создания архитектуры и проектирования средствами VB рекомендую ознакомиться с работой Billy S. Hollis, Visual Basic 6 Design, Specification and Objects (Upper Saddle River, NJ: Prentice Hall, 1999).
В последующих разделах мы поговорим о том, как довести грамотно выращенный продукт до стадии сбора урожая. Вопрос заключается в следующем: является ли этот процесс многоступенчатым?
Нулевой этап проектирования
Итак, имея на руках грандиозную архитектуру, вы готовы приступить к проектированию компонентов. Прекрасно. Мобилизуйте все свои объектно-ориентированные навыки. В первую очередь вам предстоит проверить архитектуру, имея в виду подчеркнуть приоритет этого этапа (я называю его «нулевым») в контексте процесса проектирования. Другими словами, вы должны провести макетирование архитектуры, но не совсем так, как это делается обычно. Вместо обширного графического пользовательского интерфейса сконструируйте ряд низкоуровневых компонентов, снабдите их интерфейсами-заглушками и возвращаемыми значениями – это позволит убедиться в работоспособности системы в вертикальной проекции. Конструируемые на этом этапе графические пользовательские интерфейсы должны лишь подавать сигналы и запускать те или иные процессы – больше от них ничего не требуется. Ведь ни один человек не выживет, если его мозг не будет взаимодействовать с сердцем, так? Именно поэтому, кстати, косметические операции проводятся исключительно по желанию пациента, а вот при проведении операции на головном мозге его согласия не требуют. Я полностью убежден – проверять архитектуру необходимо. На это, скорее всего, уйдет больше времени, чем можно было бы ожидать, но не сомневайтесь – усилия стоят того. С соблазном сразу перейти к разработке реальных компонентов системы нужно бороться – будет очень неприятно, если, подключив все компоненты, вы обнаружите, что они не стыкуются или не работают.
Первое, что нужно сделать в процессе проектирования, – это проверить архитектуру.
Подробности процесса «проверки концепции» я, пожалуй, опущу – благо литературы, посвященной архитектуре и проектированию, предостаточно. Только вот не стоит перекладывать обязанности по проверке архитектуры на кого-то другого – и не дай вам Боже отложить этот процесс до бета-тестирования. Эта обязанность ложится на вас и ваших подчиненных, а основная идея, которую я стремлюсь до вас донести, ясна и понятна – нельзя уклоняться от выполнения своих обязанностей. Ваша первоочередная задача в процессе проектирования заключается как раз в том, чтобы проверить архитектуру на предмет ее применимости – вот почему речь идет о «нулевом», то есть о приоритетном, этапе. Если на все нижеследующие вопросы вам удастся ответить
положительно, значит, вы наверняка на правильном пути.• Предполагает ли архитектура возможность идентификации подсистем функций и предотвращает ли она их взаимозависимость с другими подсистемами? Удалось ли вам сконструировать объекты, способные функционировать сравнительно независимо при помощи ограниченного числа вспомогательных объектов?
• Насколько доходчиво «перспективное представление» системы – сможет ли, скажем, продавец, прослушав краткий инструктаж, объяснить потенциальным клиентам, как работает программный продукт, который они намереваются приобрести?
• Исключается ли жесткое кодирование параметров конфигурации системы? К примеру, потребуется ли повторная компиляция программы при переименовании сервера или домена, или редактирования конфигурационного файла будет достаточно?
Обратите внимание на слово «наверняка», выделенное курсивом в последнем предложении абзаца, предшествующего списку. Почему я употребил именно это слово? Дело в том, что вы должны учитывать все факторы воздействия на систему на 1–2 года вперед. Невозможно выстроить надежный план действий, не зная коммерческой конъюнктуры. С другой стороны, разбираясь в тонкостях бизнеса, вы имеете все шансы стать предсказателем будущего своих программных продуктов.
Почему я говорю «предсказатель», а не, скажем, «прогнозист»? Объясняется это следующим образом. Термин «предсказатель» (prognosticator) образуется из двух греческих корней: pro, что в переводе означает «до», и gnosis, то есть «знание». Нельзя точно знать, что произойдет в будущем, однако, как и специалисты, составляющие прогнозы погоды, чем больше мы практикуемся по части предсказаний, тем лучшие результаты получаем. Не стоит также забывать, что создание программных продуктов – это искусство, которое постепенно приобретает очертания науки. Любая наука начинается с исследования явлений (феноменологии). В контексте разработки программных средств эта деятельность сводится к документированию всех явлений, наблюдаемых в ходе процесса, и построению эталонов. По мере исполнения этой миссии начинают выкристаллизовываться закономерности, согласно которым у нас что-то получается или, наоборот, не получается. В конце концов нам удается сформулировать принципы кодирования. Когда кому-нибудь это удается, он присваивает новому принципу свое имя, публикует книгу и наслаждается признанием. Именно этим в последнее десятилетие занимались разработчики концепции позитивных (pattern) и негативных (antipattern) эталонов, в связи с чем ваши шансы на славу теперь минимальны.
На самом деле, если вам удастся найти в цепочке производства прибыльных программных продуктов слабое звено, быть может, вы и не получите международного признания, но рост престижа среди сотрудников собственной компании вам обеспечен. Не исключено также, что ваша компания не испытывает подобных проблем. Что ж, тем больше перед вами открывается возможностей. Впрочем, большинство представителей нашей профессии еще только на пути к программной нирване и поэтому без посторонней помощи обойтись не могут. И у вас как у технического лидера есть все возможности помогать окружающим.
Этапы проектирования 1, 2, 3, 2, 1, 4…
Итак, вы готовы запустить маховик проектирования. Теперь дела должны пойти в гору. То есть, я имею в виду, с горы. Да, я полон противоречий. Но ведь и процесс проектирования, как и жизнь, похож на американские горки. Попытайтесь получить удовольствие от поездки, смакуйте азарт и не забудьте вернуться живым. Мне кажется, процесс проектирования в его лучшем понимании правомерно сравнить с катанием на винтообразной (в противоположность круговой) трассе. В ней есть начало и конец, но в то же время вашему взору регулярно открываются одни и те же виды. А теперь сравните это удовольствие с падением с водопада, когда вас несет вниз по реке, потом вы оказываетесь в свободном полете и, наконец, шлепаетесь пятой точкой об воду, рассчитывая при этом остаться в живых. Такое впечатление, что вы работаете в парке аттракционов, не так ли?
Нет, тут я неправ; слово «развлечение» (amusement), опять же, образуется из двух греческих составляющих: а, что означает «нет», и muse в значении «думать». Я, равно как и ваш начальник, все-таки надеюсь, что в процессе проектирования вы думаете. В данный момент я пытаюсь доходчиво объяснить различия между устаревшим водопадным циклом разработки и разрекламированным в последнее время итеративным циклом. Я убежденный сторонник последнего – несмотря даже на то, что иногда он кажется бесконечным. Как бы там ни было, если вы стремитесь к эффективному проектированию, необходимо неизменно придерживаться архитектурного плана. Существует множество книг, проводится множество семинаров, на которых нас учат «правильным» методам проектирования. Некоторые из них действительно очень полезны. Лучшим же методом проектирования мне представляется тот, которым вы и ваши подчиненные уже привыкли пользоваться, и заключается он в решении корпоративных задач. Если вы еще не достигли в этом отношении больших успехов, не стоит себя корить. Наша работа не обходится без трудностей. Некоторые из нас совершенствуются, иные же через пару лет просто исчезают из поля зрения. Это жестокий мир, так что крепитесь и стремитесь к совершенствованию своих методов.