CHAP2-4 (1018803)

Просмтор этого файла доступен только зарегистрированным пользователям. Но у нас супер быстрая регистрация: достаточно только электронной почты!

Текст из файла

Глава

2

Общие проблемы разработки программ

Эта часть книги содержит общие правила для процесса разработки программ и не касается деталей собственно языков С и С++. Я сделаю это в последующих частях.

15. Прежде всего, не навреди.

Это правило касается сопровождения программ. Будучи ребенком, я читал научно-фантастический рассказ, в котором незадачливый путешественник во времени случайно наступает на доисторическую бабочку и, вернувшись в свое время, находит окружающий мир изменившимся ужасным образом. Это похоже на большие компьютерные программы, где тронь здесь что-то кажущееся незначительным - и где-то там вся программа перестает работать. Методы объектно-ориентированного проектирования существуют прежде всего для решения (или по крайней мере для облегчения решения) этой проблемы в будущем, но уже существуют миллионы строк старого кода, который сегодня нуждается в сопровождении.

Мне приходилось видеть людей, которые изменяют программу просто потому, что им не нравится, как она выглядит. Это не очень хорошая идея. Если вы не знаете всех частей программы, затрагиваемых изменением (а это почти невозможно), то не трогайте код. Вы можете вполне резонно возразить, что на самом деле ни одно из правил в этой книге не относится к сопровождению программ. Вы просто не можете менять существующий код в соответствии с каким-то методическом руководством (как бы вам этого не хотелось), не вызывая риска непоправимого вреда. Представленные здесь правила полезны лишь в том случае, когда вы начинаете программу с нуля.

16. Редактируйте свою программу.

17. Программа должна быть переписана не менее двух раз.

18. Нельзя измерять свою производительность числом строк.

Прежде, когда вы изучали английский в школе, то вам никогда не приходило в голову сдавать черновик письменного задания, если вы, конечно, рассчитывали на оценку выше тройки. Тем не менее, многие компьютерные программы являются просто черновиками и содержат столько же ошибок, сколько и черновики ваших сочинений. Все хорошие программы вначале написаны, а затем отредактированы с целью улучшения. (Конечно, я имею ввиду "редактировать" в смысле "исправлять".)

Имейте в виду, что редактирование должно быть сделано по окончании, потому что неотредактированный текст программы по сути невозможно сопровождать (точно также, как и ваше неотредактированное сочинение было невозможно читать). Создатели этой программы знакомы с ее текстом и могут выполнить редактирование более эффективно, чем программист, занимающийся сопровождением, который сначала должен ее расшифровать перед тем, как выполнить какую-либо реальную работу.

К сожалению, это очень похоже на театральное шоу, когда кто-то пишет программу быстро, но не думая о сопровождении или о элегантности. "Ого, она выдает в два раза больше кода вдвое быстрее". Учтите, что тот же бедный сопровождающий программист будет затем вынужден затратить в восемь раз больше времени, сокращая первоначальный размер программы наполовину и делая ее пригодной для использования. Число строк кода в день, как мера объема, не является мерилом производительности.

Если вам нужен другой, чем сопровождение, мотив, то имейте в виду, что редактирование может рассматриваться как процесс уменьшения чего-либо. Маленькие программы выполняются быстрее.

19. Вы не можете программировать в изоляции.

Классическая книга Джеральда Уэйнберга The Psychology of Computer Programming (New York, Van Nostrand Reinhold, 1971) содержит великолепную историю о автоматах с газированной водой. Администрация одного вычислительного центра решила, что слишком много времени растрачивается сотрудниками у автоматов с газированной водой. Люди создают много шума и ничего при этом не делают, поэтому автоматы убрали. Через несколько дней консультанты на местах были настолько перегружены работой, что к ним стало невозможно обратиться. Мораль состоит в том, что люди совсем не зря растрачивали время: оказывается, издавая весь этот шум, они помогали друг другу в решении проблем.

Изоляция может стать настоящей проблемой в группе объектно-ориентированного проектирования, которая по необходимости должна состоять из пользователей, проектировщиков, программистов, специалистов по документации и т.д., работающих совместно. Так как число программистов в этой группе часто меньше, чем в более традиционных проектных коллективах, то становится трудно найти кого-то, с кем можно обсудить проблемы; страдает производительность. Подумайте о еженедельных вечеринках в вашей фирме, как средстве повышения производительности.

20. Пустые потери времени.

Если вы не можете решить неподатливую проблему, то займитесь на некоторое время чем-либо другим. Программисты часто наиболее продуктивны, когда смотрят в окно, слоняются по коридорам с пустым выражением на своих лицах, сидят в кафе и пьют кофе с молоком, или иным способом "теряют время".

Я был студентом в те древние времена, когда персональным компьютером был Apple I, а серьезные студенты-программисты владели коробками S-100, которые вы программировали, вводя двоичные команды переключателями лицевой панели по одному байту за раз. (Если вы были счастливчик, то имели интерпретатор языка BASIC и терминал, сделанный из старого телевизора). Студенты делили PDP 11/70, работавшую под UNIX (которая отлично работала на 16-битовой машине с 64 Кбайт памяти - Боже! Как все с тех пор усовершенствовалось). О возможности использования персонального компьютера для выполнения домашних заданий не было и речи.

На среднем занятии по программированию присутствовало от 40 до 80 человек, и одновременно проводилось шесть и более занятий. Поэтому, когда на занятии раздавалось задание, то вы хватали бумагу с ним и буквально опрометью бросались вниз в терминальный зал, где приковывали себя к компьютеру и начинали яростно программировать до тех пор, пока не выполняли свое задание. Это могло продолжаться несколько дней. Если вы отрывались поесть или поспать, то ваш терминал занимал другой, и у вас появлялась весьма реальная перспектива не уложиться в срок, отведенный на задание. Некоторые люди все еще продолжают программировать подобным способом.

Такая обстановка, конечно, не способствовала хорошо продуманному проектированию программ, поэтому большинство из этих программ были в четыре раза больше, чем необходимо, и требовали в два раза больше времени на отладку, чем требовалось. К тому же, количество строк кода, написанное за час, сокращается пропорционально количеству часов, которые вы просидели, глядя на экран. (Это иллюзия - думать, что вы можете достичь большей производительности, работая 12 часов в день вместо 8).

Однажды, будучи на последнем курсе, я был так расстроен, пытаясь решить одну проблему, о которую бился головой в течение примерно четырех часов, что с чувством отвращения завершил сеанс и выскочил на улицу. Примерно три минуты спустя, когда я спускался по холму за порцией сосисок, искомое решение неожиданно всплыло в моей голове. Это было настоящим откровением: вы должны расслабиться, чтобы дать своему мозгу возможность работать. К сожалению, я не смог пробиться назад к компьютеру, поэтому я так никогда и не исправил свою ошибку, но, по крайней мере, понял, как должен работать этот процесс.

21. Пишите программу с учетом сопровождения - вы специалист по сопровождению.

Сопровождение начинается немедленно после завершения программы, а сопровождением на этой стадии обычно занимаетесь вы сами. Это хорошая мысль - осчастливить сопровождающего программиста. Поэтому ваша первая забота о том, чтобы программа легко читалась. Структура и назначение каждой строки должны быть избыточно ясны, и если это не так, то вам нужно добавить поясняющие комментарии.

Одной из причин того, что поиски математических доказательств корректности программ остаются донкихотством, заключается в том, что нет программ без ошибок. Каждая программа не только содержит ошибки, но и требования к ней меняются, как только программа начинает эксплуатироваться, и у пользователя появляются потребность в каких-то новых свойствах, что вызывает появление новых и усовершенствованных ошибок. Так как ошибки всегда с нами, то мы должны писать нашу программу так, чтобы их можно было легче искать.

Вы можете переформулировать настоящее правило таким образом: Не умничайте. Искусный код почти невозможно сопровождать.

21.1. Эффективность часто просто пугало.

Я потратил несколько часов, делая одну подпрограмму более "эффективной", и не останавливался, чтобы подумать о том, как часто эта подпрограмма будет вызываться, что является пустой потерей времени в том случае, когда программа вызывается лишь один или два раза. Ваша программа должна быть непременно настолько эффективной, насколько это возможно, но вашей первоочередной заботой является сопровождение, и вы не должны приносить читаемость в жертву на алтарь эффективности. Напишите программу сперва с учетом сопровождения, затем запустите профайлер для своей программы и определите, где на самом деле есть узкие места. Будучи вооружены реальной информацией, вы теперь знаете, где стоит обменять часть читаемости на скорость, и можете вернуться и сделать это изменение. Тем не менее, вы можете включить первоначальный текст в комментарий, чтобы не потерять его. Всегда имейте в виду, что любое количество подчисток на уровне текста программы не повысит эффективность так, как это сделает лучший алгоритм. Пузырьковая сортировка будет выполняться медленно вне зависимости от того, насколько хорошо она запрограммирована.

Глава

3

Форматирование и документация

Форматирование важно; тексты на С и С++ и так достаточно тяжело читаются, чтобы ухудшать ситуацию еще и плохим форматированием. Представьте, что вы пытаетесь прочесть книгу, текст которой не отформатирован: нет абзацных отступов, разделений абзацев пустой строкой, пробелов после знаков препинания и так далее. Сопровождение плохо отформатированной программы невозможно.

Я объединил правила форматирования и документации в одной части, потому что форматирование является одним из лучших инструментов документирования, имеющихся в вашем распоряжении. Под "документацией", рассматривающейся в этой части книги, понимается документирование программ (т.е. комментарии, а не документация уровня пользователя). Его зря не относят к программированию, ведь хороший комментарий для вас - в буквальном смысле нить Ариадны.

Я сознаю, что дискуссии по вопросам форматирования и документации часто достигают религиозного накала. Имейте в виду, что приводимые здесь мной правила - только те, которыми я пользуюсь сам. Имеются и другие совершенно разумные методы работы. С другой стороны, кто-то не особо умный мне однажды сказал, что "не важно, какой стиль форматирования вы применяете, если вы применяете его постоянно". Программа, которая постоянно форматируется плохо, хуже, чем понятная временами. Случайный просвет лучше, чем никакого.

22. Программа без комментариев ничего не стоит.

Программа, на написание которой затрачен год, может использоваться в течение 10 лет. Вам придется затратить на сопровождение гораздо больше денег, чем вы выделили на первоначальную разработку, а программа без комментариев несопровождаема. "Блестящий" программист, который втрое быстрее, чем другие, пишет короткий, элегантный, но некомментированный текст программы, вам обойдется дорого. Какому-то менее талантливому программисту придется затратить в 10 раз больше времени, чем нужно, устраняя неизбежные ошибки.

Программисты, которые не могут писать по-английски (или на том языке, на котором говорят в стране, где предполагается осуществлять сопровождение), изготовляют часовые бомбы, а не компьютерные программы. Так как хорошая документация столь необходима для процесса сопровождения, то важно, чтобы программисты были способны ее написать. По этой причине начинающие программисты, имеющие диплом по филологии, истории или другой гуманитарной дисциплине, часто являются более предпочтительными, чем люди с дипломами по естественным наукам (математике, физике и т.п.). Специалисты по естественным наукам редко знают как писать, а большинство из них также не знают как программировать; они обучены тому, как запрограммировать алгоритм, а не как написать пригодную для сопровождения компьютерную программу.

К счастью, писать можно легко научиться. Конечно, если вы придерживаетесь правила "Сделай сначала комментарии", то вам придется писать все свои комментарии до начала программирования.

23. Располагайте программу и документацию вместе.

Характеристики

Тип файла документ

Документы такого типа открываются такими программами, как Microsoft Office Word на компьютерах Windows, Apple Pages на компьютерах Mac, Open Office - бесплатная альтернатива на различных платформах, в том числе Linux. Наиболее простым и современным решением будут Google документы, так как открываются онлайн без скачивания прямо в браузере на любой платформе. Существуют российские качественные аналоги, например от Яндекса.

Будьте внимательны на мобильных устройствах, так как там используются упрощённый функционал даже в официальном приложении от Microsoft, поэтому для просмотра скачивайте PDF-версию. А если нужно редактировать файл, то используйте оригинальный файл.

Файлы такого типа обычно разбиты на страницы, а текст может быть форматированным (жирный, курсив, выбор шрифта, таблицы и т.п.), а также в него можно добавлять изображения. Формат идеально подходит для рефератов, докладов и РПЗ курсовых проектов, которые необходимо распечатать. Кстати перед печатью также сохраняйте файл в PDF, так как принтер может начудить со шрифтами.

Список файлов книги