Совершенный код. Совершенный код. Мастер-класс. Стив Макконнелл. Руководство по стилю программирования и конструированию по
 Скачать 5.88 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 20 ЧАСТЬ 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 22 ЧАСТЬ 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). 24 ЧАСТЬ 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 Самый веский аргумент в пользу выполнения предварительных условий перед началом конструирования Допустим, вы уже забрались на гору определения проблемы, прошли милю по пути выработки требований, сбросили грязную одежду у фонтана архитектуры и ис# купались в чистых водах подготовленности. Следовательно, вы знаете, что перед реализацией системы нужно понимать, что и как она будет делать. Один из аспектов профессии разработчика — посвящение профанов в осо# бенности процесса разработки ПО. Этот раздел поможет вам в общении с менеджерами и руководителями, еще блуждающих во тьме. В нем под# робно описан веский аргумент в пользу адекватного определения требований и проектирования архитектуры до начала кодирования, тестирования и отладки. Изу# чите его, сядьте перед начальником и поговорите о процессе программирования по душам. Обращение к логике Подготовка к проекту — одно из главных условий эффективного программирова# ния, и это логично. Объем планирования зависит от масштаба проекта. С управ# ленческой точки зрения, планирование подразумевает определение сроков, числа людей и компьютеров, необходимых для выполнения работ. С технической — пла# нирование подразумевает получение представления о создаваемой системе, позво# ляющего не истратить деньги на создание неверной системы. Иногда пользовате# ли не четко знают, что желают получить, и для определения их требований может понадобиться больше усилий, чем хотелось бы. Как бы то ни было, это дешевле, чем создать не то, что нужно, похерить результат и начать все заново. До начала создания системы не менее важно подумать и о том, как вы собирае# тесь ее создавать. Никому не хочется тратить время и деньги на бесплодные блуж# дания по лабиринту. Обращение к аналогии Создание программной системы похоже на любой другой проект, требующий людских и финансовых ресурсов. Возведение дома начинается не с забивания гвоздей, а с создания, анализа и утверждения чертежей. При разработке ПО на# личие технического плана означает не меньше. Никто не наряжает новогоднюю елку, не установив ее. Никто не разводит огонь, не открыв дымоход. Никто не отправляется в долгий путь с пустым бензобаком. Никто не принимает душ в одежде и не надевает носки после обуви. И т. д., и т. п. Программисты — последнее звено пищевой цепи разработки ПО. Архитекторы поглощают требования, проектировщики потребляют архитектуру, а программи# сты — проект приложения. Сравните пищевую цепь разработки ПО с реальной пищевой цепью. В экологи# чески чистой среде водные жучки служат пищей рыбам, которыми в свою оче# редь питаются чайки. Это здоровая пищевая цепь. Если на каждом этапе разра# ботки ПО у вас будет здоровая пища, результатом станет здоровый код, написан# ный довольными программистами. 26 ЧАСТЬ 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): |