Совершенный код. Совершенный код. Мастер-класс. Стив Макконнелл. Руководство по стилю программирования и конструированию по
 Скачать 5.88 Mb.
|
|
ГЛАВА 4 Основные решения, которые приходится принимать при конструировании 65 лишь мечтать. Производители часто выпускают новые версии компиляторов, при этом каждая новая версия отказывается поддерживать значительные части ваше# го кода. Инструменты не интегрированы, из#за чего UI, модули работы с БД, со# ставления отчетов и бизнес#логики приходится разрабатывать при помощи раз# ных средств. Из#за плохой совместимости инструментов и частого появления новых компиляторов и библиотек программисты тратят много усилий только на под# держание работоспособности имеющейся инфраструктуры. При возникновении проблем в Интернете можно найти кое#какую документацию, но она не отлича# ется достоверностью и полнотой. Вам может показаться, что я рекомендую избегать программирования в ранних средах, но это не так. В ранних средах были разработаны программы, давшие начало некоторым из самых инновационных приложений, такие как Turbo Pascal, Lotus 123, Microsoft Word и браузер Mosaic. Я просто хочу сказать, что от стадии развития технологии зависит то, как будет протекать ваша работа. В зрелой сре# де вы можете посвящать большую часть дня постепенной реализации новой функ# циональности. Работая в ранней среде, исходите из того, что вам придется тра# тить много времени на выяснение недокументированных возможностей выбран# ного языка программирования, отладку ошибок, которые в итоге окажутся дефек# тами библиотек, проверку того, что написанный код будет работать с новой вер# сией библиотеки какого#нибудь производителя и т. д. При работе в примитивной среде методики программирования, описанные в этой книге, могут оказаться еще более полезными, чем в зрелых средах. Как сказал Дэвид Грайс (Gries, 1981), подход к программированию не должен определяться исполь# зуемыми инструментами. В связи с этим он проводит различие между програм# мированием на языке (programming in language) и программированием с исполь% зованием языка (programming into language). Разработчики, программирующие «на» языке, ограничивают свое мышление конструкциями, непосредственно поддер# живаемых языком. Если предоставляемые языком средства примитивны, мысли программистов будут столь же примитивными. Разработчики, программирующие «с использованием» языка, сначала решают, какие мысли они хотят выразить, после чего определяют, как выразить их при помощи конкретного языка. Пример программирования с использованием языка Разрабатывая программу на Visual Basic, который тогда находился на раннем эта# пе развития, я с огорчением обнаружил, что язык не поддерживает встроенных способов разделения бизнес#логики, кода GUI и кода работы с БД. Я знал, что, если буду невнимателен, со временем некоторые из моих «форм» Visual Basic включат в себя код бизнес#логики, другие — код доступа к БД, а остальные не будут содер# жать ни того, ни другого — в итоге я не смогу вспомнить, какая форма за что отвечает. Я только что завершил работу над проектом C++, в котором разделение кода было выполнено плохо, и не хотел еще раз наступать на те же грабли. Поэтому я принял конвенцию, в соответствии с которой файлам .frm (файлам формы) дозволялось только извлекать данные из БД и сохранять их обратно, но не передавать эти данные другим частям программы. Все формы поддерживали 66 ЧАСТЬ I Основы разработки ПО метод IsFormCompleted(), который сообщал вызвавшему его методу, сохранила ли активная форма свои данные. IsFormCompleted() был единственным открытым методом, который могли иметь формы. Код форм также не мог включать никакой бизнес#логики. Весь остальной код, в том числе проверяющий корректность вво# димых в форму данных, должен был содержаться в ассоциированном файле .bas. Visual Basic не поощрял такого подхода. Он поощрял программистов включать в файл .frm максимальный объем кода, и это отнюдь не облегчало реализацию вза# имодействия межу файлами .frm и .bas. Принятая мной конвенция была очень проста, но по мере развития проекта я обнаружил, что она помогла мне избежать многих случаев, в которых мне при# шлось бы писать неестественный код. Так, мне пришлось бы загружать формы, но держать их скрытыми, чтобы можно было вызвать реализованные в них методы проверки корректности данных, или мне пришлось бы копировать код форм в другие места программы и сопровождать этот параллельный код. Кроме того, конвенция IsFormCompleted() позволила все упростить. Все формы работали оди# наково, поэтому я мог не предполагать семантику IsFormCompleted() — вызовы этого метода всегда имели одинаковый смысл. Visual Basic не поддерживал такой подход непосредственно, но простая конвен# ция программирования — программирование с использованием языка — позво# лила мне реализовать отсутствующую в то время структуру языка и помогла упростить проект до приемлемого уровня. Понимание различия между программированием на языке и програм ми рованием с использованием языка — важнейшее условие понима# ния этой книги. Большинство важных принципов программирования зависит не от конкретных языков, а от способа их использования. Если язык не поддерживает нужные конструкции или имеет другие недостатки, попробуйте их компенсировать. Создайте свои конвенции кодирования, стандарты, библио# теки классов и другие средства. 4.4. Выбор основных методик конструирования При подготовке к конструированию следует решить, какие из доступных эффек# тивных методик вы будете использовать. Некоторые проекты предусматривают пар# ное программирование и предварительное создание тестов, тогда как другие — индивидуальное программирование и проведение формальных инспекций. Обе комбинации методик могут быть удачными, но при их выборе следует учитывать специфические особенности проекта. Специфические методики конструирования, которые должны быть осознанно приняты или отвергнуты, указаны ниже. В оставшейся части книги эти методики будут описаны подробнее. ГЛАВА 4 Основные решения, которые приходится принимать при конструировании 67 Контрольный список: основные методики конструирования Кодирование Решили ли вы, какая часть проекта приложения будет разработана предва- рительно, а какая во время написания кода? Выбрали ли вы конвенции именования программных элементов, оформле- ния комментариев и форматирования кода? Выбрали ли вы специфические методики кодирования, определяемые архи- тектурой приложения? Определили ли вы, как будут обрабатываться ошиб- ки, как будут решаться проблемы, связанные с безопасностью, какие конвенции будут использоваться при разработке интерфейсов классов, каким стандар- там должен будет отвечать повторно используемый код, сколько внимания нужно будет уделять быстродействию приложения при кодировании и т. д.? Определили ли вы стадию развития используемой технологии и адаптиро- вали ли к ней свой подход? Если это необходимо, определились ли вы с тем, как будете программировать с использованием языка, вместо того чтобы ограничиваться программированием на нем? Работа в группе Определили ли вы процедуру интеграции? Иначе говоря, какие специфи- ческие действия программист должен будет выполнить перед включением своего кода в исходный код всего проекта? Будут ли программисты программировать парами, индивидуально или эти подходы будут скомбинированы? Гарантия качества Должны ли будут программисты разработать тесты для своего кода до написания самого кода? Должны ли будут программисты разработать блочные тесты для своего кода? Должны ли будут программисты перед включением своего кода в исходный код всего проекта проанализировать его в отладчике? Должны ли будут программисты выполнить интеграционное тестирование своего кода до его включения в исходный код проекта? Будут ли программисты выполнять взаимные обзоры или инспекцию кода? Инструменты Выбрали ли вы инструмент управления версиями? Выбрали ли вы язык, версию языка и версию компиля- тора? Выбрали ли вы платформу программирования (такую как J2EE или Microsoft .NET) или явно решили не использовать ее? Приняли ли вы решение о том, можно ли будет использовать нестандарт- ные возможности языка? Определили ли вы другие средства, которые будете применять: редактор, инструмент рефакторинга, платформу для тестирования, модуль проверки синтаксиса и т. д.? Приобрели ли вы их? http://cc2e.com/0496 Перекрестная ссылка Гарантия качества рассматривается в гла- ве 20. Перекрестная ссылка Об инст- рументах программирования см. главу 30. 68 ЧАСТЬ I Основы разработки ПО Ключевые моменты Каждый язык программирования имеет достоинства и недостатки. Вы долж# ны знать отдельные достоинства и недостатки используемого языка. Определите конвенции программирования до начала программирования. Позднее адаптировать к ним код станет почти невозможно. Методик конструирования слишком много, чтобы использовать все в одном проекте. Тщательно выбирайте методики, наиболее подходящие для вашего про# екта. Спросите себя, являются ли используемые вами методики программирования ответом на выбранный язык программирования или их выбор был определен языком. Помните, что программировать следует с использованием языка, а не на языке. Эффективность конкретных подходов и даже возможность их применения за# висит от стадии развития соответствующей технологии. Определите стадию раз# вития используемой технологии и адаптируйте к ней свои планы и ожидания. ГЛАВА 4 Основные решения, которые приходится принимать при конструировании 69 Часть II ВЫСОКОКАЧЕСТВЕННЫЙ КОД Глава 5. Проектирование при конструировании Глава 6. Классы Глава 7. Высококачественные методы Глава 8. Защитное программирование Глава 9. Процесс программирования с псевдокодом CC2_Part2_ch5_2010.indd 69 22.06.2010 12:31:11 70 ЧАСТЬ II Высококачественный код Г Л А В А 5 Проектирование при конструировании Содержание 5.1. Проблемы, связанные с проектированием ПО 5.2. Основные концепции проектирования 5.3. Компоненты проектирования: эвристические принципы 5.4. Методики проектирования 5.5. Комментарии по поводу популярных методологий Связанные темы Разработка архитектуры ПО: раздел 3.5 Классы: глава 6 Характеристики высококачественных методов: глава 7 Защитное программирование: глава 8 Рефакторинг: глава 24 Зависимость конструирования от объема программы: глава 27 Некоторые программисты могут заявить, что проектирование не связано с кон- струированием, но при работе над небольшими проектами конструирование часто включает другие процессы, в том числе проектирование. В некоторых бо- лее крупных проектах формальная архитектура может давать ответы только на во#просы системного уровня, при этом значительная часть проектирования может быть намеренно оставлена на этап конструирования. В других крупных проектах проектирование может быть проведено в таком объеме, что кодирование стано- вится почти механическим, однако это случается редко — официально или нет, программисты обычно сами проектируют некоторые фрагменты программы. В случае небольших неформальных проектов значительная часть проектирования выполняется за клавиатурой. «Про- ектирование» может выражаться в простом написании ин- терфейса класса на псевдокоде до разработки его деталей. Оно может выражаться в рисовании диаграмм отношений http://cc2e.com/0578 Перекрестная ссылка Об уров- нях формальности, требуемой при работе над крупными и не- большими проектами, см. гла- ву 27. CC2_Part2_ch5_2010.indd 70 22.06.2010 12:31:31 ГЛАВА 5 Проектирование при конструировании 71 нескольких классов перед написанием их кода. Оно может выражаться в обсужде- нии оптимального шаблона проектирования вместе с коллегой. Какую бы форму проектирование ни принимало, от тщательного его выполнения выигрывают проекты любого масштаба, и, рассматривая проектирование как явный процесс, вы извлечете из него максимальную выгоду. Проектирование — очень обширная тема, поэтому в данной главе мы рассмотрим только несколько ее аспектов. Эффективность проектирования классов или ме- тодов во многом определяется архитектурой системы, поэтому убедитесь, что вы выполнили предварительные условия, связанные с разработкой архитектуры (см. раздел 3.5). Еще больший объем проектирования выполняется на уровне отдельных классов и методов, что мы обсудим в главах 6 и 7. Если вы уже хорошо знакомы с проектированием ПО, можете только бегло про- смотреть основные моменты раздела 5.1, посвященного проблемам проектиро- вания, и раздела 5.3, в котором обсуждаются основные эвристические принципы проектирования. 5.1. Проблемы, связанные с проектированием ПО Под «проектированием ПО» понимают разработку или изо- бретение схемы преобразования спецификации приложения в готовое приложение. Проектирование — это тот процесс, который связывает выработку требований с кодированием и отладкой. Структура удачного высокоуровневого проекта приложения может успешно охватывать целый ряд более низкоуровневых проектов. Хорошее проектирование полезно при работе над не- большими приложениями и просто необходимо при работе над крупными. Однако с проектированием связано множество проблем — их#то мы и обсудим. Проектирование — «грязная» проблема Хорст Риттел и Мелвин Веббер определили «грязную» про- блему как проблему, которую можно ясно определить только путем полного или частичного решения (Rittel and Webber, 1973). По сути данный парадокс подразумевает, что про- блему нужно «решить» один раз, чтобы получить ее ясное определение, а затем еще раз для создания работоспособного решения. Этот процесс уже несколько десятилетий нераз- рывно связан с разработкой ПО (Peters and Tripp, 1976). Одним драматическим примером подобной грязной про- блемы является проектирование первого варианта моста Tacoma Narrows. В то время главным соображением при проектировании мостов было обеспечение прочности, адек- ватной планируемой нагрузке. В случае моста Tacoma Nar- rows оказалось, что ветер вызывает непредвиденные вол- нообразные гармонические колебания моста из стороны в Перекрестная ссылка О разли- чии между эвристическим и де- терминированным процессами см. главу 2. Образ разработчика, проекти- рующего программу рациональ- ным безошибочным способом на основе ясно сформулиро- ванных требований, совершенно нереалистичен. Никакая система так никогда не разрабатывалась и, наверное, не будет разраба- тываться. Даже примеры раз- работки небольших программ, встречающиеся в учебниках, нереалистичны. Авторы пере- проверяют и улучшают их до тех пор, пока не продемонстрируют нам то, что они хотели бы по- лучить, а не то, что получается на самом деле. Дэвид Парнас и Пол Кле- ментс (David Parnas and Paul Clements) CC2_Part2_ch5_2010.indd 71 22.06.2010 12:31:31 72 ЧАСТЬ II Высококачественный код сторону. В один ветреный день 1940 г. колебания неконтролируемо усилились, и часть моста обрушилась (рис. 5#1). Это наглядный пример грязной проблемы: до разрушения моста инженеры не знали, что аэродинамика играет такую большую роль. Только построив мост (ре- шив проблему), они смогли обнаружить дополнительный аспект проблемы, что позволило им возвести новый мост, действующий и поныне. Рис. 5'1. Мост Tacoma Narrows — пример грязной проблемы Одно из главных отличий программ, которые вы разрабатывали в институте, от программ, которые разрабатываете теперь, став профессиональным программи- стом, в том, что проблемы проектирования, решаемые институтскими про- граммами, редко бывают грязными, если вообще бывают таковыми. В институте задания по программированию составлены так, чтобы вы по кратчайшему пути двигались от начала решения к его результату. Преподавателя, который дает студентам задания и свободно изменяет их по завершении проектирования и даже перед сдачей готовых программ, вероятно, облили бы дегтем и вываляли в перьях. Однако в мире профессионального программирования такие изменения происходят ежедневно. Проектирование — неряшливый процесс (даже если оно приводит к аккуратному результату) Завершенный проект приложения должен выглядеть хорошо организованным и ясным, но процесс разработки этого проекта далеко не так аккуратен, как конеч- ный результат. CC2_Part2_ch5_2010.indd 72 22.06.2010 12:31:31 ГЛАВА 5 Проектирование при конструировании 73 Проектирование неряшливо потому, что вы выполняете много неверных действий и попадаете во множество ту- пиков, т. е. совершаете массу ошибок. В действительности ошибки являются сутью проектирования: дешевле допустить ошибки и исправить проект программы, чем найти их после кодирования и исправлять готовый код. Проектирование неряшливо потому, что удачное решение часто лишь чуть#чуть отличается от неудачного. Проектирование неряшливо еще и потому, что трудно узнать, когда проект «достаточно хорош». Какого уровня детализации достаточно? Какую часть проектирования вы- полнить с использованием формальной нотации, а какую — прямо за клавиатурой? Когда проектирование считать завершенным? Улучшать проект программы можно посто- янно, поэтому чаще всего на последний вопрос отвечают: «Когда у вас вышло время». Проектирование связано с определением компромиссов и приоритетов В идеальном мире все системы обладали бы бесконечным быстродействием, не предъявляли никаких требований к подсистеме хранения данных, давали нулевую нагрузку на сеть, никогда не содержали никаких ошибок и создавались без всяких затрат. Однако в реальном мире один из важнейших аспектов работы проекти- ровщика — анализ конкурирующих характеристик проекта и достижение баланса между ними. Если быстрота отклика системы важнее, чем минимизация времени разработки, проектировщик выберет один вариант. Если во главе угла быстрота разработки, оптимальным может оказаться другой вариант проекта. |