|
|
Создание любой нетривиальной программной системы - сложная и часто
выматывающая задача. Даже для отдельного программиста собственно запись
операторов программы есть только часть всей работы. Обычно анализ всей
задачи, проектирование программы в целом, документация, тестирование,
сопровождение и управление всем этим затмевает задачу написания и
отладки отдельных частей программы. Конечно, можно все эти виды
деятельности обозначить как "программирование" и затем вполне
обоснованно утверждать: "Я не проектирую, я только программирую".
Но как бы не назывались отдельные виды деятельности, бывает иногда важно
сосредоточиться на них по отдельности, так же как иногда бывает важно
рассмотреть весь процесс в целом. Стремясь поскорее довести систему
до поставки, нельзя упускать из вида ни детали, ни картину в целом,
хотя довольно часто происходит именно это.
Эта глава сосредоточена на тех частях процесса развития программы,
которые не связаны с написанием и отладкой отдельных программных
фрагментов. Обсуждение здесь менее точное и детальное, чем во всех
остальных частях книги, где рассматриваются конкретные черты языка
или определенные приемы программирования. Это неизбежно, поскольку нет
готовых рецептов создания хороших программ. Детальные рецепты "как"
могут существовать только для определенных, хорошо разработанных областей
применения, но не для достаточно широких областей приложения. В
программировании не существует заменителей разума, опыта и вкуса.
Следовательно, в этой главе вы найдете только общие рекомендации,
альтернативные подходы и осторожные выводы.
Сложность данной тематики связана с абстрактной природой программ
и тем фактом, что приемы, применимые для небольших проектов (скажем,
программа в 10000 строк, созданная одним или двумя людьми), не
распространяются на средние или большие проекты. По этой причине иногда
мы приводим примеры из менее абстрактных инженерных дисциплин, а не
только из программирования. Не преминем напомнить, что "доказательство по
аналогии" является мошенничеством, и аналогии служат здесь только в
качестве примера. Понятия проектирования, формулируемые
с помощью определенных конструкций С++, и поясняемые примерами, мы
будем обсуждать в главах 12 и 13. Предложенные в этой главе рекомендации,
отражаются как в самом языке С++, так и в решении конкретных программных
задач по всей книге.
Снова напомним, что в силу чрезвычайного разнообразия областей
применения, программистов и среды, в которой развивается программная
система, нельзя ожидать, что каждый вывод, сделанный здесь, будет
прямо применим для вашей задачи. Эти выводы применимы
во многих самых разных случаях, но их нельзя считать универсальными
законами. Смотрите на них со здоровой долей скептицизма.
Язык С++ можно просто использовать как лучший вариант С. Однако,
поступая так, мы не используем наиболее мощные возможности С++ и
определенные приемы программирования на нем, так что реализуем лишь
малую долю потенциальных достоинств С++. В этой главе излагается такой
подход к проектированию, который позволяет полностью использовать
возможности абстрактных данных и средства объектного программирования С++.
Такой подход обычно называют объектно-ориентированным проектированием.
В главе 12 обсуждаются основные приемы программирования на С++, там же
содержится предостережение от сомнительных идей, что есть только один
"правильный" способ использования С++, и что для получения
максимального выигрыша следует всякое средство С++
применять в любой программе ($$12.1).
Укажем некоторые основные принципы, рассматриваемые в этой главе:
Недооценить любой из этих принципов очень легко, но обычно накладно.
В то же время трудно воплотить эти абстрактные идеи на практике.
Здесь необходим определенный опыт. Подобно построению лодки, езде на
велосипеде или программированию проектирование - это искусство, которым
нельзя овладеть только с помощью теоретических занятий.
Может быть все эти емкие принципы можно сжать в один:
проектирование и программирование - виды человеческой деятельности;
забудь про это - и все пропало.
Слишком часто мы забываем про это и рассматриваем процесс развития
программного обеспечения просто как "последовательность хорошо
определенных шагов, на каждом из которых по заданным правилам
производятся некоторые действия над входными данными, чтобы получить
требуемый результат". Сам стиль предыдущего предложения выдает
присутствие человеческой природы!
Эта глава относится к проектам, которые можно считать честолюбивыми,
если учитывать ресурсы и опыт людей, создающих систему. Похоже, это в
природе как индивидуума, так и организации - браться за проекты на
пределе своих возможностей. Если задача не содержит определенный вызов,
нет смысла уделять особое внимание ее проектированию. Такие задачи
решаются в рамках уже устоявшейся структуры, которую не следует разрушать.
Только если замахиваются на что-то амбициозное, появляется потребность
в новых, более мощных средствах и приемах. Кроме того, существует
тенденция у тех, кто "знает как делать", перепоручать проект новичкам,
которые не имеют таких знаний.
Не существует "единственного правильного способа" для
проектирования и создания всей системы. Я бы считал веру в "единственный
правильный способ" детской болезнью, если бы этой болезнью слишком
часто не заболевали и опытные программисты. Напомним еще раз: только
по той причине, что прием успешно использовался в течение года для
одного проекта, не следует, что он без всяких изменений окажется
столь же полезен для другого человека или другой задачи. Всегда важно
не иметь предубеждений.
Убеждение в том, что нет единственно верного решения, пронизывает
весь проект языка С++, и, в основном, по этой причине в первом издании
книги не было раздела, посвященного проектированию: я не хотел, чтобы
его рассматривали как "манифест" моих личных симпатий. По этой же
причине здесь, как и в главах 12 и 13, нет четко определенного взгляда на
процесс развития программного обеспечения, скорее здесь просто дается
обсуждение определенного круга, часто возникающих, вопросов и
предлагаются некоторые решения, оказавшиеся полезными в определенных
условиях.
За этим введением следует краткое обсуждение целей и средств
развития программного обеспечения в $$11.2, а дальше глава распадается
на две основных части:
Взаимосвязь между проектированием и языком программирования обсуждается
в главе 12, а глава 13 посвящена вопросам проектирования библиотек для
С++.
Очевидно, большая часть рассуждений относится к программным проектам
большого объема. Читатели, которые не участвуют в таких разработках,
могут сидеть спокойно и радоваться, что все эти ужасы их миновали,
или же они могут выбрать вопросы, касающиеся только их интересов. Нет
нижней границы размера программы, начиная с которой имеет смысл заняться
проектированием прежде, чем начать писать программу. Однако все-таки есть нижняя
граница, начиная с которой можно использовать какие-либо методы
проектирования. Вопросы, связанные с размером, обсуждаются в $$11.4.2.
Труднее всего в программных проектах бороться с их сложностью.
Есть только один общий способ борьбы со сложностью: разделяй и
властвуй. Если задачу удалось разделить на две подзадачи, которые можно
решать в отдельности, то можно считать ее решенной за счет разделения
более, чем наполовину. Этот простой принцип применим для удивительно
большого числа ситуаций. В частности, использование модулей или классов
при разработке программных систем позволяет разбить программу на две
части: часть реализации и часть, открытую пользователю - которые
связаны между собой (в идеале) вполне определенным интерфейсом. Это
основной, внутренне присущий программированию, принцип борьбы со
сложностью.
Подобно этому и процесс проектирования программы можно разбить на
отдельные виды деятельности с четко определенным (в идеале)
взаимодействием между людьми, участвующими в них. Это основной,
внутренне присущий проектированию, принцип борьбы со сложностью и
подход к управлению людьми,занятыми в проекте.
В обоих случаях выделение частей и определение интерфейса между
частями - это то место, где требуется максимум опыта и чутья. Такое
выделение не является чисто механическим процессом, обычно оно требует
проницательности, которая может появиться только в результате доско-
нального понимания системы на различных уровнях абстракции (см.
$$11.3.3, $$12.2.1 и $$13.3). Близорукий взгляд на программу или на
процесс разработки программного обеспечения часто приводит к дефектной
системе. Отметим, что как программы, так и программистов разделить
просто. Труднее достигнуть эффективного взаимодействия между участниками
по обе стороны границы, не нарушая ее и не делая взаимодействие слишком
жестким.
Здесь предложен определенный подход к проектированию, а не полное
формальное описание метода проектирования. Такое описание выходит за
предметную область книги. Подход, предложенный здесь, можно применять
с различной степенью формализации, и он может служить базой для различных
формальных спецификаций. В тоже время нельзя считать эту главу
рефератом, и здесь не делается попытка рассмотреть каждую тему,
относящуюся к процессу разработки программ или изложить каждую точку
зрения. Это тоже выходит за предметную область книги. Реферат по этой
тематике можно найти в [2]. В этой книге используется достаточно
общая и традиционная терминология. Самые "интересные" термины, как:
проектирование, прототип, программист - имеют в литературе несколько
определений, часто противоречащих друг другу, поэтому предостерегаем вас
от того, чтобы, исходя из принятых в вашем окружении определений терминов,
вы не вынесли из книги то, на что автор совершенно не рассчитывал.
| |
|
