Н. И. Лобачевского Факультет Вычислительной Математики и Кибернетики Кафедра иисгео Язык программирования Си Курс лекций
| Вид материала | Курс лекций |
- Н. И. Лобачевского Факультет Вычислительной математики и кибернетики Кафедра Математического, 169.45kb.
- Н. И. Лобачевского Факультет Вычислительной математики и кибернетики Кафедра Математического, 172.6kb.
- Н. И. Лобачевского Факультет Вычислительной математики и кибернетики Кафедра Математического, 123.69kb.
- Н. И. Лобачевского Факультет Вычислительной математики и кибернетики Кафедра Математического, 132.68kb.
- М. В. Ломоносова Факультет вычислительной математики и кибернетики Кафедра математической, 6.81kb.
- Методы интеллектуального анализа данных и некоторые их приложения, 29.22kb.
- М. В. Ломоносова Факультет Вычислительной Математики и Кибернетики Кафедра Системного, 124.67kb.
- Н. И. Лобачевского факультет вычислительной математики и кибернетики лаборатория «информационные, 1555.24kb.
- И кибернетики факультет вычислительной математики и кибернетики, 138.38kb.
- М. В. Ломоносова факультет Вычислительной математики и кибернетики Кафедра «Математических, 39.24kb.
3.15. Прежде всего, не навреди
Это правило касается сопровождения программ. Известно, что в больших компьютерных программах стоит тронуть что-то, кажущееся маловажным, и сразу же весь ее код перестает работать. Объектно-ориентированные методы разработки программ прежде всего служат для решения (или по крайней мере для облегчения решения) этой проблемы в будущем, но ведь есть уже миллионы строк старых кодов, которые сегодня требуют сопровождения.
Иногда программисты изменяют части программ лишь только потому, что им не нравится как выглядит ее код. Это плохо. Если вы не знаете всех частей программы, затрагиваемых изменением (а это почти невозможно), то не трогайте код. Вы можете вполне резонно возразить, что на самом деле ни одно из, изложенных выше, не относится к сопровождению программ. Вы просто не сможете изменить существующий код программы в соответствии с каким-то методическим руководством (как бы вам этого ни хотелось), без риска нанести ей непоправимый ущерб. Предлагаемые здесь правила полезны лишь только тогда, когда y вас есть блестящая возможность начать программу с нуля.
^
3.16. Отредактируйте свой код
3.17. Программа должна писаться не менее двух раз
3.18. Нельзя измерять свою производительность числом строк
Раньше, когда вы изучали в школе литературу, вам никогда не приходило в голову сдавать черновик письменного задания, если вы, конечно, рассчитывали на оценку выше тройки. Тем не менее, многие компьютерные программы являются просто черновиками и содержат столько же ошибок сколько и черновики ваших сочинений. Хороший код программы сначала написан, а затем отредактирован в целях улучшения. (Конечно, я имею в виду «редактировать» в смысле «исправлять».)
Учтите, что редактирование должно быть сделано своевременно, потому что неотредактированный текст программы по сути невозможно сопровождать (точно также, как и ваше неотредактированное сочинение было бы невозможно прочесть). Авторы программы знакомы с ее кодом и могут выполнить редактирование более эффективно, чем программист, занимающийся сопровождением, который сначала должен ее расшифровать, прежде чем окажется возможным выполнить какую-либо реальную работу.
К сожалению, в отчетных документах это выглядит впечатляюще, когда кто-то пишет программу быстро, но не думает при этом о ее сопровождении или элегантности. «Ого, она выдает в два раза больше кода вдвое быстрее». Учтите, что какой-то несчастный программист, сопровождающий задачу, будет затем вынужден потратить в восемь раз больше времени, сокращая первоначальный размер программы наполовину и делая ее пригодной для использования. Число строк кода в день, как мера объема, не является мерилом производительности.
^
3.19. Вы не можете программировать в изоляции
В классической книге Джеральда Уэйнберга Психология программирования для компьютеров (The Psychology of Computer Programming, New York, Van Nostrand Reinhold, 1971) приводится прелестная история об автоматах с газированной водой. Администрация одного вычислительного центра решила, что сотрудники тратят массу времени у автоматов с газированной водой. Люди создают много шума и ничего при этом не делают, поэтому автоматы убрали. Через несколько дней консультанты на местах были настолько перегружены работой, что к ним стало невозможно обратиться. Мораль в том, что люди вовсе не зря тратили время; оказывается, издавая весь этот шум, они помогали друг другу в решении проблем. Изоляция может стать настоящей проблемой в группе объектно-ориентированного проектирования, которая обязательно должна состоять из пользователей, проектировщиковпрограммистов, специалистов по документации и т.д., работающих совместно. Так как число программистов в этой группе зачастую меньше, чем в более традиционных проектных коллективах, то становится трудно найти кого-то, с кем можно обсудить проблемы; производительность страдает. Подумайте о еженедельных дружеских вечеринках, как средстве повышения производительности.
^
3.20. Прочь глупости
Если вы не можете решить трудную задачу, займитесь на некоторое время чем-либо другим. Программисты зачастую наиболее производительны, когда смотрят в окно, слоняются по коридорам с пустым выражением лица, сидят в кафе и пьют кофе с молоком, или как-то еще «теряют время».
^
3.21. Пишите программу с учетом сопровождения — сопровождаюшим программистом являетесь вы сами
Сопровождение начинается немедленно после написания кода программы, а сопровождением на этой стадии обычно занимаетесь вы сами. Это хорошая мысль — осчастливить сопровождающего программиста. Поэтому ваша первая забота состоит в том, чтобы программа легко читалась. Структура и назначение каждой строки должны быть всеобъемлюще ясны, а если это не так, то следует добавить поясняющие комментарии.
Одной из причин того, что математические доказательства корректности программ остаются донкихотством, является то, что программ – без ошибок не бывает. Каждая программа не только содержит ошибки, но и требования к ней меняются сразу же с момента ее эксплуатации и у пользователя появляются потребность в каких-то новых свойствах, что вызывает появление новых и усовершенствованных ошибок. Так как ошибки всегда с нами, то мы должны писать наш программный код так, чтобы ошибки всегда можно было легко искать. Вы можете переформулировать это правило: Не умничайте. Изощренный код никогда нельзя сопровождать. Очевидно, что ваша программа непременно должна быть максимально эффективной, но первая из ваших задач — сопровождение, и вы не должны приносить читабельность на алтарь эффективности. Сначала напишите программу с учетом сопровождения, затем запустите отладчик для своей программы и определите ее узкие места. Вооруженные реальной информацией, вы уже знаете, где подменить читаемость скоростью, и можете вернуться и внести изменения.Сохраняйте первоначальный текст в комментариях, либо весь модуль до изменения, чтобы, в случае необходимости, можно было бы вернуться назад. Всегда помните, что любые манипуляции с текстом программы не повысят эффектиность в той мере, как это сделает лучший алгоритм. Простой пример пузырьковая сортировка идет медленно, вне зависимости от того, насколько хорошо написан код.