Руководство по стилю программирования и конструированию по
 Скачать 7.6 Mb.
|
|
ГЛАВА 2 Метафоры, позволяющие лучше понять разработку ПО 19 Применение методов разработки ПО: интеллектуальный инструментарий Люди, эффективно разрабатывающие высококачественное ПО, многие годы посвятили сбору методов, хитростей и магических заклинаний. Эти методы — не правила, а аналитические инструменты. Хороший рабочий знает предназначение каждого инструмента и умеет эффективно его использовать. Программисты не исключение. Чем больше вы узнаете о программировании, тем больше аналитических инструментов и знаний об их своевременном и правиль- ном использовании накапливается в вашем интеллектуальном инструментарии. Консультанты по вопросам разработки ПО иногда совету- ют программистам придерживаться одних методов разра- ботки ПО в ущерб другим. Это печально, потому что, если вы станете использовать только одну методологию, вы уви- дите весь мир в терминах этой методологии. В некоторых случаях это сделает недоступными для вас другие методы, лучше подходящие для решения текущей проблемы. Метафора инструментария поможет вам держать все методы, способы и хитрости в пределах досягаемости и применять их в уместных обстоятельствах. Комбинирование метафор Метафоры имеют эвристическую, а не алгоритмическую природу, поэтому они не исключают друг друга. Вы можете использовать и метафору ак- креции, и метафору конструирования. Если хотите, можете представлять разработку ПО как написание письма, комбинируя эту метафору с вождением автомобиля, охотой на оборотней или образом динозавра, увязшего в смоляной луже. Используйте любые метафоры или их комбинации, которые стимулируют ваше мышление или помогают общаться с другими членами группы. Использование метафор — дело тонкое. Чтобы метафора привела вас к ценным эвристическим догадкам, вы должны ее расширить. Но если ее расширить черес- чур или в неверном направлении, она может ввести в заблуждение. Как и любой мощный инструмент, метафоры можно использовать неверным образом, однако благодаря своей мощи они могут стать ценным компонентом вашего интеллек- туального инструментария. Дополнительные ресурсы Среди книг общего плана, посвященных метафорам, моде- лям и парадигмам, главное место занимает «The Structure of Scientific Revolutions» (3d ed. Chicago, IL: The University of Chicago Press, 1996) Томаса Куна (Thomas S. Kuhn). В своей книге, увидевшей свет в 1962 г., Кун рассказывает о возникновении, развитии и смене теорий. Этот труд, вызвавший множество споров по вопросам философии науки, отличается яснос- тью, лаконичностью и включает массу интересных примеров взлетов и падений научных метафор, моделей и парадигм. Перекрестная ссылка О выбо- ре методов проектирования и их комбинировании см. раздел 5.3. http://cc2e.com/0285 2 0 ЧАСТЬ I Основы разработки ПО Статья «The Paradigms of Programming». 1978 Turing Award Lecture («Communications of the ACM», August 1979, pp. 455–60) Роберта У. Флойда (Robert W. Floyd) пред- ставляет собой увлекательное обсуждение использования моделей при разработ- ке ПО; некоторые аспекты рассматриваются в ней в контексте идей Томаса Куна. Ключевые моменты 쐽 Метафоры являются по природе эвристическими, а не алгоритмическими, поэтому зачастую они немного небрежны. 쐽 Метафоры помогают понять процесс разработки ПО, сопоставляя его с дру- гими, более знакомыми процессами. 쐽 Некоторые метафоры лучше, чем другие. 쐽 Сравнение конструирования ПО с возведением здания указывает на необхо- димость тщательной подготовки к проекту и проясняет различие между круп- ными и небольшими проектами. 쐽 Аналогия между методами разработки ПО и инструментами в интеллектуаль- ном инструментарии программиста наводит на мысль, что в распоряжении программистов имеется множество разных инструментов и что ни один ин- струмент не является универсальным. Выбор правильного инструмента — одно из условий эффективного программирования. 쐽 Метафоры не исключают друг друга. Используйте комбинацию метафор, наи- более эффективную в вашем случае. ГЛАВА 2 Метафоры, позволяющие лучше понять разработку ПО 21 Г Л А В А 3 Семь раз отмерь, один раз отрежь: предварительные условия Содержание 쐽 3.1. Важность выполнения предварительных условий 쐽 3.2. Определите тип ПО, над которым работаете 쐽 3.3. Предварительные условия, связанные с определением проблемы 쐽 3.4. Предварительные условия, связанные с выработкой требований 쐽 3.5. Предварительные условия, связанные с разработкой архитектуры 쐽 3.6. Сколько времени посвятить выполнению предварительных условий? Связанные темы 쐽 Основные решения, которые приходится принимать при конструировании: глава 4 쐽 Влияние размера проекта на предварительные условия и процесс конструи- рования ПО: глава 27 쐽 Связь между качеством ПО и аспектами его конструирования: глава 20 쐽 Управление конструированием ПО: глава 28 쐽 Проектирование ПО: глава 5 Перед началом конструирования дома строители просматривают чертежи, про- веряют, все ли разрешения получены, и исследуют фундамент. К сооружению небоскреба, жилого дома и собачьей конуры строители готовились бы по-разно- му, но, каким бы ни был проект, перед началом конструирования они провели бы добросовестную подготовку с учетом всех особенностей проекта. В этой главе мы рассмотрим компоненты подготовки к конструированию ПО. Как и в строительстве, конечный успех программного проекта во многом определя- ется до начала конструирования. Если фундамент ненадежен или планирование выполнено небрежно, на этапе конструирования вы в лучшем случае сможете только свести вред к минимуму. http://cc2e.com/0309 2 2 ЧАСТЬ I Основы разработки ПО Популярная у плотников поговорка «семь раз отмерь, один раз отрежь» очень актуальна на этапе конструирования ПО, затраты на который иногда составляют аж 65% от общего бюджета проекта. В неудачных программных проектах конст- руирование иногда приходится выполнять дважды, трижды и даже больше. Как и в любой другой отрасли, повторение самой дорогостоящей части программного проекта ни к чему хорошему привести не может. Хотя чтение этой главы является залогом успешного конструирования ПО, само конструирование в ней не обсуждается. Если вы уже хорошо разбираетесь в цик- ле разработки ПО или вам не терпится добраться до обсуждения конструирова- ния, можете перейти к главе 5. Если вам не нравится идея выполнения предвари- тельных условий конструирования, просмотрите раздел 3.2, чтобы узнать, какую роль они играют в вашем случае, а затем вернитесь к разделу 3.1, в котором опи- сываются расходы, связанные с их невыполнением. 3.1. Важность выполнения предварительных условий Общей чертой всех программистов, создающих высокока- чественное ПО, является использование высококачествен- ных методов, ставящих ударение на качестве ПО в самом начале, середине и конце проекта. Если вы подчеркиваете качество в конце проекта, это при- ходится на этап тестирования системы. Именно о тестиро- вании думают многие люди, представляя процесс гарантии качества ПО, но тести- рование — только один из компонентов стратегии гарантии качества, и не самый важный. Тестирование не позволяет обнаружить такие ошибки, как создание не того приложения или создание нужного приложения не тем образом; эти ошибки дол- жны быть определены и устранены раньше — до начала конструирования. Если вы уделяете повышенное внимание качеству в середине работы над проектом, вы подчеркиваете методы конструирования, которым и посвя- щена большая часть этой книги. Если вы подчеркиваете качество в начале проекта, вы качественно выполняете пла- нирование, определение требований и проектирование. Если вы спроектирова- ли автомобиль «Понтиак Ацтек», то сколько бы вы его ни тестировали, он никог- да не превратится в «Роллс-Ройс». Вы можете создать самый лучший «Ацтек», но если вам нужен «Роллс-Ройс», это нужно планировать с самого начала. При раз- работке ПО такому планированию соответствуют определение проблемы и определение и проектирование решения. Конструирование — средний этап работы, поэтому ко времени начала конструи- рования успех проекта уже частично предопределен. И все же во время констру- ирования вы хотя бы должны быть в состоянии определить, насколько благопо- лучна ваша ситуация, и вернуться назад, если на горизонте показались черные тучи неудачи. В оставшейся части этой главы я подробно расскажу, почему адекватная подготовка к конструированию так важна и как определить, действительно ли вы готовы перейти к нему. Перекрестная ссылка Повыше- ние внимания к качеству ПО — самый эффективный способ повышения производительнос- ти труда программистов. (см. раздел 20.5). ГЛАВА 3 Семь раз отмерь, один раз отрежь: предварительные условия 23 Актуальны ли предварительные условия для современных программных проектов? Порой говорят, что предварительные действия, такие как разработка архитектуры, проектирование и планирование проекта, в современных условиях бесполезны. Такие заяв- ления не подтверждаются ни прошлыми, ни современны- ми исследованиями (подробности см. ниже). Оппоненты предварительных условий обычно приводят примеры не- удачного выполнения предварительных условий и делают вывод, что такая работа неэффективна. Тем не менее под- готовку к конструированию можно выполнить успешно, и данные, накопленные с 1970-х, свидетельствуют о том, что в таких случаях работа над проектом оказывается эффективнее. Общая цель подготовки — снижение риска: адекватное планирование позволяет исключить главные аспекты риска на самых ранних стадиях работы, чтобы основную часть проекта можно было выполнить макси- мально эффективно. Безусловно, главные факторы риска в создании ПО — неудач- ная выработка требований и плохое планирование проекта, поэтому подготовка направлена в первую очередь на оптимизацию этих этапов. Так как подготовка к конструированию не является точной наукой, специфиче- ский подход к снижению риска будет в значительной степени определяться осо- бенностями проекта (см. раздел 3.2). Причины неполной подготовки Возможно, вам кажется, что все профессионалы знают о важности подготовки и всегда до начала конструирования проверяют выполнение предварительных ус- ловий. Увы, это не так. Зачастую причина неполной подготовки к конструированию ПО объясняется тем, что отвечающие за нее разработчики не имеют нужного опыта. Для планирования проекта, созда- ния адекватной бизнес-модели, разработки полных и точ- ных требований и высококачественной архитектуры нуж- но обладать далеко не тривиальными навыками, однако большинство разработчиков этому не обучены. Если разра- ботчики не знают, как выполнять предварительную работу, рекомендация «выполнять больше такой работы» не имеет смысла: если работа изначально выполняется некачествен- но, ее выполнение в больших объемах не принесет никакой пользы! Объяснение выполнения этих действий не является предметом данной книги, однако в разде- ле «Дополнительные ресурсы» в конце главы я привел массу источников, позво- ляющих получить такой опыт. Некоторые программисты умеют готовиться к конструированию, но пренебрега- ют подготовкой, потому что не могут устоять перед искушением пораньше при- ступить к кодированию. Если вы принадлежите к их числу, могу дать два совета. Первый: прочитайте следующий раздел. Возможно, у вас откроются глаза на не- Выбор методологии не должен быть невежественным. Она дол- жна быть основана на самом но- вом и эффективном и дополне- на старым и заслуживающим доверия. Харлан Миллз (Harlan Mills) http://cc2e.com/0316 Дополнительные сведения О про- фессиональной программе разра- ботки ПО, поощряющей приме- нение этих навыков, см. главу 16 книги «Professional Software Deve- lopment» (McConnell, 2004). 2 4 ЧАСТЬ I Основы разработки ПО которые вещи. Второй: уделяйте внимание проблемам, с которыми сталкиваетесь. Поработав над несколькими крупными программами, вы прекрасно поймете пользу заблаговременного планирования. Положитесь на свой опыт. Наконец, еще одна причина пренебрежения подготовкой к конструированию со- стоит в том, что менеджеры прохладно относятся к программистам, которые тра- тят на это время. Это довольно странно: такие люди, как Барри Бом (Barry Boehm), Гради Буч (Grady Booch) и Карл Вигерс (Karl Wiegers), отстаивают важность выра- ботки требований и проектирования уже 25 лет, и менеджеры, казалось бы, уже должны понимать, что разработка ПО не ограничивается кодированием, но... Несколько лет назад я работал над проектом Минобороны, и как-то на этапе выработки требований нас посетил кура- тор проекта — генерал. Мы сказали ему, что работаем над требованиями: большей частью общаемся с клиентами, определяем их потребности и разрабатываем проект при- ложения. Он, однако, настаивал на том, чтобы увидеть код. Мы сказали, что у нас нет кода, и тогда он отправился в ра- бочий отдел, намереваясь хоть кого-нибудь из 100 человек поймать за програм- мированием. Огорченный тем, что почти все из них находились не за своими ком- пьютерами, этот крупный человек наконец указал на инженера рядом со мной и проревел: «А он что делает? Он ведь пишет код!» Вообще-то этот инженер рабо- тал над утилитой форматирования документов, но генерал хотел увидеть код, нашел что-то похожее на него и хотел, чтобы хоть кто-то писал код, так что мы сказали ему, что он прав: это код. Этот феномен известен как синдром WISCA или WIMP: «Why Isn’t Sam Coding Anything? (Почему Сэм не пишет код?)» или «Why Isn’t Mary Programming (Почему Мэри не программирует)?» Если менеджер проекта претендует на роль бригадного генерала и приказывает вам немедленно начать программировать, вы можете с легкостью ответить: «Есть, сэр!» (И впрямь, какое вам дело? Умудренные опытом ветераны должны отвечать за свои слова.) Это плохой ответ, и у вас есть несколько лучших вариантов. Во- первых, вы можете решительно отвергнуть неэффективную методику работы. Если у вас нормальные отношения с начальником и все в порядке с банковским сче- том, это может сработать. Во-вторых, вы можете притвориться, что работаете над кодом. Разложите на сто- ле листинги старой программы и продолжайте работать над требованиями и ар- хитектурой как ни в чем не бывало. Так вы выполните проект быстрее и качествен- нее. Порой этот подход находят неэтичным, но начальник-то останется доволен! В-третьих, вы можете посвятить руководителя в нюансы технических проектов. Это хороший подход, потому что он увеличивает число грамотных руководите- лей в мире. В следующем подразделе приведено подробное обоснование важно- сти выполнения предварительных условий до начала конструирования. Наконец, вы можете найти другую работу. Независимо от экономических подъе- мов и спадов хороших программистов всегда не хватает (BLS, 2002), а жизнь слиш- ком коротка, чтобы тратить ее на работу в отсталом учреждении при наличии множества лучших вариантов. Дополнительные сведения Ряд интересных вариаций на эту тему см. в классическом труде Джеральда Вайнберга «The Psy- chology of Computer Program- ming» (Weinberg, 1998). ГЛАВА 3 Семь раз отмерь, один раз отрежь: предварительные условия 25 Самый веский аргумент в пользу выполнения предварительных условий перед началом конструирования Допустим, вы уже забрались на гору определения проблемы, прошли милю по пути выработки требований, сбросили грязную одежду у фонтана архитектуры и ис- купались в чистых водах подготовленности. Следовательно, вы знаете, что перед реализацией системы нужно понимать, что и как она будет делать. Один из аспектов профессии разработчика — посвящение профанов в осо- бенности процесса разработки ПО. Этот раздел поможет вам в общении с менеджерами и руководителями, еще блуждающих во тьме. В нем под- робно описан веский аргумент в пользу адекватного определения требований и проектирования архитектуры до начала кодирования, тестирования и отладки. Изу- чите его, сядьте перед начальником и поговорите о процессе программирования по душам. Обращение к логике Подготовка к проекту — одно из главных условий эффективного программирова- ния, и это логично. Объем планирования зависит от масштаба проекта. С управ- ленческой точки зрения, планирование подразумевает определение сроков, числа людей и компьютеров, необходимых для выполнения работ. С технической — пла- нирование подразумевает получение представления о создаваемой системе, позво- ляющего не истратить деньги на создание неверной системы. Иногда пользовате- ли не четко знают, что желают получить, и для определения их требований может понадобиться больше усилий, чем хотелось бы. Как бы то ни было, это дешевле, чем создать не то, что нужно, похерить результат и начать все заново. До начала создания системы не менее важно подумать и о том, как вы собирае- тесь ее создавать. Никому не хочется тратить время и деньги на бесплодные блуж- дания по лабиринту. Обращение к аналогии Создание программной системы похоже на любой другой проект, требующий людских и финансовых ресурсов. Возведение дома начинается не с забивания гвоздей, а с создания, анализа и утверждения чертежей. При разработке ПО на- личие технического плана означает не меньше. Никто не наряжает новогоднюю елку, не установив ее. Никто не разводит огонь, не открыв дымоход. Никто не отправляется в долгий путь с пустым бензобаком. Никто не принимает душ в одежде и не надевает носки после обуви. И т. д., и т. п. Программисты — последнее звено пищевой цепи разработки ПО. Архитекторы поглощают требования, проектировщики потребляют архитектуру, а программи- сты — проект приложения. Сравните пищевую цепь разработки ПО с реальной пищевой цепью. В экологи- чески чистой среде водные жучки служат пищей рыбам, которыми в свою оче- редь питаются чайки. Это здоровая пищевая цепь. Если на каждом этапе разра- ботки ПО у вас будет здоровая пища, результатом станет здоровый код, написан- ный довольными программистами. 2 6 ЧАСТЬ I Основы разработки ПО Если среда загрязнена, жучки плавают в ядерных отходах, а рыба плещется в неф- тяных пятнах. Чайкам не повезло больше всего: находясь в конце пищевой цепи, они травятся и нефтью, и ядерными отходами. Если ваши требования неудачны, они отравляют архитектуру, которая в свою очередь травит процесс конструиро- вания. Результат? Раздражительные программисты и полное изъянов ПО. При планировании в высокой степени итеративного проекта вы до начала кон- струирования должны определить важнейшие требования и архитектурные эле- менты, влияющие на каждый конструируемый фрагмент программы. Строителям, собирающимся строить поселок, не нужна полная информация о каждом доме до начала возведения первого дома, однако они должны исследовать место, соста- вить план канализации и электрических линий и т. д. Если строители плохо под- готовятся, канализационные трубы, возможно, придется проводить в уже постро- енный дом. Обращение к данным Исследования последних 25 лет убедительно доказали выгоду правильного выпол- нения проектов с первого раза и дороговизну внесения изменений, которых можно было избежать. Ученые из компаний Hewlett-Packard, IBM, Hughes Aircraft, TRW и других организаций обнаружили, что исправление ошибки к началу конструи- рования обходится в 10–100 раз дешевле, чем ее устранение в конце ра- боты над проектом, во время тестирования приложения или после его выпуска (Fagan, 1976; Humphrey, Snyder, and Willis, 1991; Leffingwell 1997; Willis et al., 1998; Grady, 1999; Shull et al., 2002; Boehm and Turner, 2004). Общий принцип прост: исправлять ошибки нужно как можно раньше. Чем доль- ше дефект сохраняется в пищевой цепи разработки ПО, тем больше вреда он приносит на следующих этапах. Так как раньше всего вырабатываются требова- ния, ошибки, допущенные на этом этапе, присутствуют в системе дольше и обхо- дятся дороже. Кроме того, дефекты, внесенные в систему раньше, оказывают бо- лее широкое влияние, чем дефекты, внесенные позднее. Это также повышает цену более ранних дефектов. Вот данные об относительной дороговизне исправления дефектов в за- висимости от этапов их внесения и обнаружения (табл. 3-1): |