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

Рейнвотер Дж.Ханк

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

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

Почему я говорю «предсказатель», а не, скажем, «прогнозист»? Объясняется это следующим образом. Термин «предсказатель» (prognosticator) образуется из двух греческих корней: pro, что

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

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

Этапы проектирования 1, 2, 3, 2, 1, 4…

Итак, вы готовы запустить маховик проектирования. Теперь дела должны пойти в гору. То есть, я имею в виду, с горы. Да, я полон противоречий. Но ведь и процесс проектирования, как и жизнь, похож на американские горки. Попытайтесь получить удовольствие от поездки, смакуйте азарт и не забудьте вернуться живым. Мне кажется, процесс проектирования в его лучшем понимании правомерно сравнить с катанием на винтообразной (в противоположность круговой) трассе. В ней есть начало и конец, но в то же время вашему взору регулярно открываются одни и те же виды. А теперь сравните это удовольствие с падением с водопада, когда вас несет вниз по реке, потом вы оказываетесь в свободном полете и, наконец, шлепаетесь пятой точкой об воду, рассчитывая при этом остаться в живых. Такое впечатление, что вы работаете в парке аттракционов, не так ли?

Нет, тут я неправ; слово «развлечение» (amusement), опять же, образуется из двух греческих составляющих: а, что означает «нет», и muse в значении «думать». Я, равно как и ваш начальник, все-таки надеюсь, что в процессе проектирования вы думаете. В данный момент я пытаюсь доходчиво объяснить различия между устаревшим водопадным циклом разработки и разрекламированным в последнее время итеративным циклом. Я убежденный сторонник последнего – несмотря даже на то, что иногда он кажется бесконечным. Как бы там ни было, если вы стремитесь к эффективному проектированию, необходимо неизменно придерживаться архитектурного плана. Существует множество книг, проводится множество семинаров, на которых нас учат «правильным» методам проектирования. Некоторые из них действительно очень полезны. Лучшим же методом проектирования мне представляется тот, которым вы и ваши подчиненные уже привыкли пользоваться, и заключается он в решении корпоративных задач. Если вы еще не достигли в этом отношении больших успехов, не стоит себя корить. Наша работа не обходится без трудностей. Некоторые из нас совершенствуются, иные же через пару лет просто исчезают из поля зрения. Это жестокий мир, так что крепитесь и стремитесь к совершенствованию своих методов.

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

других концепциях из области эволюционной биологии, в частности об адаптации. В настоящее время зарождается новый подход к адаптации. Предлагают его те исследователи, которые занимаются вопросами поведения сложных систем и принципами самоорганизации в таких системах. Стюарт Кауфман (Stuart Kauffman), один из ведущих специалистов в этой области, утверждает, что «…как биологическая, так и технологическая эволюция представляет собой процессы, направленный на оптимизацию систем с конфликтующими ограничениями» [66] . Для более осмысленного освещения вопросов выживания организмов и их существования в хаосе сложных систем Кауфман предлагает выражение «поступление сильнейших». Вооружившись его видением проблемы, исследователи привязали его выводы к процессы разработки программных продуктов.

66

Stuart Kauffman, At Home in the Universe (New York: Oxford University Press, 1995), p. 179.

Прекрасный образец применения теории сложных систем в области разработки программного обеспечения являет собой книга Джеймса Хайсмита (James Highsmith) под названием «Адаптивная разработка программных средств». Хайсмит предлагает вниманию читателя итеративный цикл, который он называет «жизненным циклом адаптивной разработки». В нем три основных компонента: сотрудничество, размышление и обучение. С его точки зрения, у этого цикла есть ряд преимуществ [67] :

67

James A. Highsmith III, Adaptive Software Development (New York: Dorset House Publishing, 2000), p. 40.

• реагируя на периодические отзывы, приложения эволюционируют, приближаясь тем самым к предъявляемым заказчиками требованиям;

• упрощается адаптация к изменяющимся бизнес-требованиям;

• процесс разработки подгоняется под заданный для данного продукта профиль качества;

• преимущества от применения продукта заказчик получает раньше, чем обычно, – хотя бы за счет того, что приложение поставляется ему быстрее, а значит, он раньше начинает получать доход;

• заказчики раньше, чем обычно, начинают испытывать доверие к проекту.

Какое отношение все это имеет к проектированию? В любом случае в вашей компании применяется какой-то метод проектирования – он либо адекватен, либо требует усовершенствования, либо не годится для решения поставленных задач. Возможно, требуется его немедленная замена. Решение за вами. Я считаю, вы должны проявить инициативу, проанализировать применяемые в компании методы проектирования и подогнать их под заведомо работоспособные образцы.

Теперь пора спуститься с теоретических высот (а теория эта весьма достойна) и обратиться в следующем разделе к практическим методам разработки программных продуктов, которые, по моему опыту, дают хороший результат. Мне кажется, что они носят довольно общий характер и, следовательно, могут применяться любой группой разработчиков вне зависимости от используемого ими языка программирования.

Принципы проектирования

Коль скоро мы придерживаемся принципа органической архитектуры, нам нужны органические компоненты. Как появляется программный объект? Естественно, в результате написания кода – как это ни прискорбно, если, мы нашепчем, компьютеру через микрофон идею объекта, он не появится. Собственно говоря, в такой идее нет ничего плохого – в особенности если в ней заключены принципы кодирования, подобные следующим.

• Следование стандартам программирования, принятым для данного языка [68] . Это обеспечивает единообразие методик конструирования объектов, применяемых разными программистами. (В этом контексте имеет полное право на существование метафора строительства.)

68

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