Правильная ссылка на эту страницу
http://az-design.ru/Projects/AzBook/src/005/02YE002.shtml

ПРЕДИСЛОВИЕ

Посвящается Дженни

  Мы строим системы так же, как братья Райт строили свои самолеты: создаем всю систему целиком, запускаем ее — пусть она развалится!— и начинаем все сначала.
  проф. Грехем Software Engineering, p.17.
  Безусловно, 99% вычислительных машин работают вполне сносно, это правда. Существуют тысячи солидных вычислительных систем ориентированных на использование Фортрана и включающих множество различных ЭВМ, существует масса систем обработки данных, функционирующих очень надежно; все это так! Вопрос, которым мы озабочены, имеет огромное значение и касается предельных возможностей наших взаимоотношений с ЭВМ.
  проф. Бакстон Software Engineering, p.119.
  Я думаю, это неизбежно, что люди программируют плохо и что так будет и впредь. Обучение не приведет к заметному улучшению дела. Использование специализированных языков не поможет, так как люди всегда нарушают их правила. Нам придется просто привыкнуть к этому.
  проф. Перлис Software Engineering Techniques, p. 33.
  Существует глубокая пропасть между притязаниями и реальными достижениями в области математического обеспечения. Эта пропасть ощущается в разных плоскостях: между обещаниями пользователям и характеристиками математического обеспечения, между тем, что принципиально достижимо, и тем, что мы можем получить сегодня, между оценками стоимости математического обеспечения и фактическими затратами на него. И эта пропасть углубляется в такое время, когда последствия отказов математического обеспечения становятся во всех отношениях все более и более серьезными. Особенно тревожит кажущаяся неизбежной ненадежность больших систем математического обеспечения в связи с тем, что отказы в таких усовершенствованных системах могут иметь жизненно важное значение не только для отдельных индивидуумов, но и для безопасности транспортных средств с сотнями людей и в конечном счете для безопасности целых наций.
  д-р Давид, Фрэзер Software Engineering, p. 120.
  *) Цитаты, служащие своеобразным эпиграфом, взяты из сборника Software Engineering (ред. Наур и Ренделл), сектор научных исследований НАТО, Брюссель 39, Бельгия, январь 1969 г., и сборника Software Engineering Techniques (ред. Бакстон и Ренделл), сектор научных исследований НАТО, Брюссель 39, Бельгия, апрель 1970 г.

* * *

       В начале 1970г. я допустил большую ошибку, написав серию заметок для семинара, который назывался СОВРЕМЕННЫЕ МЕТОДЫ ПРОГРАММИРОВАНИЯ. Я говорю “ошибку”, так как вскоре установил, что я почти ничего не знаю о современном состоянии того колдовства, которое мы называем программированием, несмотря на то, что в этой области мне охотно предоставляли работу уже в течение нескольких лет. Но я не отступил: 80 страниц почти бессвязной писанины, пройдя через десять значительных переработок, разрослись до 900 машинописных страниц. Иногда во время этой работы здравый смысл подсказывал мне, чтобы я выбросил все десять вариантов рукописи и перестал навязывать учащимся свои идеи; к сожалению, гордость и обыкновенное самолюбие взяли верх. Бедные слушатели, которым пришлось обучаться в этот период! Почти 3000 программистов из 12 стран прощали мне мои ошибки в программах и не придавали значения некоторым из моих серьезных заблуждений, и важно то, что все они прилежно сообщали, что знали о программировании сами — доверие, которое нужно прочувствовать, чтобы оценить по достоинству.
       В этот период меня особенно интересовали перемены, которые наблюдались в области вычислительных средств. Появление таких выдающихся авторитетов, как Дейкстра, Вирт и Вейнберг, вселяло надежду, что наступит время, когда программистов будут обучать написанию хороших программ с самого начала.
       Если эти надежды оправдаются, то некоторые предосторожности и соображения, обсуждаемые в этой книге, могут оказаться ненужными. Свои семинары и эту книгу я строю исходя из того предположения, что обучающийся обладает некоторыми основами знаний в области программирования, но совершенно не знаком с идеями “хорошего” программирования. Я считаю такое предположение вполне оправданным, имея в виду подавляющее большинство программистов, работающих в промышленности. До тех пор, пока в основных курсах программирования наибольшее внимание уделяется правилам кодирования на том или; ином алгоритмическом языке (как это обычно наблюдается на курсах Фортрана и Кобола), такое предположение остается справедливым. Очень обнадеживает то, что в настоящее время заметна тенденция включать в университетские курсы для студентов основы искусства хорошего программирования.
       Итак, предметом изучения настоящей книги является хорошее программирование. Как подсказывает мой опыт, бывает очень трудно объяснить человеку, как писать хорошую программу, если он (или она) упорно отрицает мой взгляд на то, что называть хорошей программой. Поэтому гл.1 книги посвящена обсуждению характерных особенностей хорошей программы. Должен признать, что эта глава адресована опытному программисту; первокурсник колледжа вряд ли имеет ясное представление об относительной важности таких свойств программы, как простота сопровождения, гибкость и эффективность.
       Далее логически следует вопрос: как проектировать хорошие программы? В гл.2 ответ на этот вопрос дается изложением идеологии нисходящего проектирования, или проектирования сверху вниз. Кажется несколько противоречивым тот порядок, в котором рассматриваются эти разделы. Многие считают, что сначала следует изложить основные идеи структурного программирования, после чего программист будет подготовлен к восприятию принципов нисходящего проектирования. Возможно что это и так; я сам, сталкиваясь с группой слишком нетерпеливых программистов, считаю полезным начать семинар с конкретных понятий структурного программирования, переходя далее к более абстрактным идеям нисходящего проектирования. И тем не менее с логической точки зрения представляется более разумным изучать сначала проектирование программ, а затем — правила их написания.
       Гл.3 посвящена обсуждению модульного программирования. Она служит естественным переходом от абстрактных представлений нисходящего проектирования к более подробному обсуждению структурного программирования. Очень многим кажется, что модульное программирование явилось предвестником весьма модного в наше время структурного программирования. Я нахожу занятным то, что в 1970 г., когда я начинал писать эти заметки, многие программисты считали модульное программирование радикально новым направлением; в наше время структурного программирования модульное программирование уже относят к прошлому. Как ни странно, но весьма вероятно, что именно эта область применения принципов модульности будет характеризоваться наибольшими успехами в ближайшие несколько лет, Возможно, что статья Кон-стентайна “Структурное проектирование” в майском номере журнала IBM Systems Journal за 1974 г. возродит интерес к модульному программированию и сыграет ту же роль, какую в свое время в области структурного программирования сыграла статья Бейкера в январском номере этого журнала за 1972 г.
       Безусловно, всякий современный учебник программирования должен содержать обстоятельное изложение методов структурного программирования; гл.4 посвящена подробному обсуждению этих вопросов. Один из разделов этой главы заслуживает особого упоминания: в разд. 4.3.3 обсуждаются методы преобразования неструктурированных программ в структурированные программы. Многие считают преувеличенным то внимание, которое я уделяю этим методам, но я беру на себя смелость утверждать, что полезность материала этого раздела зависит от индивидуального опыта обучающегося. Новичок, еще не успевший приобрести привычку запутывать свои программы многочисленными передачами управления по оператору GO TO, вероятно, совсем не нуждается в методах, излагаемых в разд.4.3.3; знакомство с ними могло бы оказаться для него даже вредным! Опытному же программисту эти методы крайне необходимы, поскольку они помогают обратить неструктурное мышление в структурное. Довольно наивно ссылаться на то, что сейчас в университетах с самого начала обучают структурному программированию. Эта аргументация аналогична логике, требующей немедленно отказаться от программирования на Фортране только потому, что в нем не предусмотрены форматы, необходимые для удобного представления структурированных программ. В жизни все обстоит иначе. Хорошо это или плохо, но еще несколько лет люди будут по-прежнему программировать на Фортране, пока мы не сможем предложить им более развитые языки. А до того времени с практической точки зрения весьма важно обучить программистов приближенной реализации идей структурного программирования в пределах возможностей Фортрана. Кроме того, сегодня в мире насчитываются сотни тысяч опытных программистов, и каждый из них, если ему не доведется познакомиться с методами преобразования неструктурированных программ в структированные, еще двадцать лет будет писать свои запутанные программы. Если мы будем ждать обученных по-новому выпускников университетов, которые придут и поправят дело чудодейственным средством структурного программирования, большинство существующих вычислительных систем придет в упадок.
       Должен признаться, что после трех глав проповеди на тему структурного программирования я на какое-то время выдохся. Гл. 5 и 6, посвященные рассмотрению вопросов стиля и выбора надежных схем программирования, заслуживают, по-видимому, большего внимания. В качестве оправдания могу высказать следующее: если программист последовательно придерживается принципов, изложенных в гл.14, то по здравому смыслу он логически приходит к положениям, содержащимся в гл. 5 и 6. Более веским доводом может служить то, что подробному анализу вопросов стиля в программировании следовало бы посвятить отдельную книгу. Я настоятельно рекомендую в этой связи две книги: Schneiderman, Kreitzberg, The Elements of FORTRAN Style, Harcourt, Brace, Jovanovich, 1971 и Kernighan, Plauger, The Elements of Programming Style, McGraw-Hill, 1974.
       По нескольким причинам мне стало ясно, что обсуждение методов нисходящего проектирования, а также модульного и структурного программирования необходимо связать с вопросами тестирования и отладки. Так появились гл. 7 и 8. Я и теперь настаиваю на том, что следует делать различие между тестированием и отладкой, хотя многие из моих слушателей считают, что я усложняю дело. Должен сознаться, что, закончив главу, посвященную тестировав нию, я испытал некоторое чувство безнадежности: мне кажется, что большинство программистов в действительности не представляют, как нужно тестировать программы. Большинство ученых, работающих в области программирования, вероятно, согласятся с тем, что прежде, чем мы достигнем в тестировании того уровня упорядоченности, который мы имеем в структурном программировании, предстоит сделать еще очень многое. Может быть, нам потребуется “структурное тестирование”?
       Если можно говорить о структурном тестировании, то почему бы не сказать о структурной отладке? Основная цель гл.8 состоит в описании некоторых стратегий отладки программ, весьма отличающихся от традиционных методов трассировки и дампинга. Я всегда считал, что эти стратегии предполагают определенное искусство отладки, и если программист затрудняется в их применении, то причину следует искать в отсутствии некоторых врожденных способностей, присущих тонким аналитикам программ. Может быть, это слишком простое объяснение: как мне рассказали друзья из мельбурнской фирмы Shell Oil, в этой организации программистам читаются общие курсы из области принятия решения, имеющие целью повышение их мастерства в отладке программ. Возможно, это и есть начало структурной отладки.
       В конце этой книги я поместил четыре больших упражнения по программированию, на которых могут быть опробованы основные принципы проектирования программ. Задачи, помещенные в приложениях А и Б, предназначаются для решения группой программистов, оптимальный состав группы три-четыре программиста. Задачи приложений В и Г не так громоздки и могут быть решены каждым программистом индивидуально.

* * *

       Не забывая тысяч слушателей, прочитавших рукопись этой книги и внесших свои улучшения и исправления, я хотел бы выразить особую благодарность Кернигану из фирмы Bell Laboratories и Ниили из Канзасского университета за рецензирование книги. Я благодарен также своим коллегам: Плогеру, Сарсону и Эбботу, которые использовали материал Книги в своих курсах и высказали рекомендации по улучшению текста рукописи. Готовя книгу к выпуску, Линн Садковски не теряя самообладания, неизменно разыскивал меня в отдаленном районе земного шара, чтобы я успел просмотреть критические места в гранках; Уэнди Икин оказала мне неоценимую помощь в редактировании рукописи и чтении корректур, добившись того, что текст обрел черты сносного английского языка.
       Наконец, появлением этой книги я обязан Сэму, который верил в меня больше других.




<<< Пред. Оглавление
Начало раздела
След. >>>

Дата последнего изменения:
Thursday, 21-Aug-2014 09:10:56 MSK


Постоянный адрес статьи:
http://az-design.ru/Projects/AzBook/src/005/02YE002.shtml