Руководство по стилю программирования и конструированию по
 Скачать 7.6 Mb.
|
|
ГЛАВА 30 Инструменты программирования 703 Препроцессоры Препроцессоры и препроцессорные макросы помогают при отладке, поскольку упрощают процесс переключения меж- ду отладочной и промышленной версиями кода. Если во вре- мя разработки вы хотите проверять фрагментацию памяти в начале каждого метода, то можете разместить там макро- сы. В промышленной версии вы, возможно, не захотите ос- тавлять эти проверки — тогда можно переопределить эти макросы так, что они вообще не будут генерировать кода. По похожим причинам макросы препроцес- сора подходят для написания кода, предназначенного для компиляции на несколь- ких различных платформах — например, и в Windows, и в Linux. Используя язык с примитивными управляющими конструкциями, например ас- семблер, вы можете написать препроцессор управляющей логики, чтобы эмули- ровать в языке такие структурированные конструкции, как if-then-else и циклы while. Если в вашем языке нет препроцессора, вы можете задей- ствовать его автономный вариант как составляющую про- цесса сборки. Один из препроцессоров — M4 — доступен по адресу www.gnu.org/software/m4/. Отладка Следующие средства оказывают помощь при отладке: 쐽 предупреждающие сообщения компилятора; 쐽 тестовые леса; 쐽 инструменты для сравнения (позволяющие сравнивать различные версии ис- ходных файлов); 쐽 средства профилирования; 쐽 мониторы трассировки; 쐽 интерактивные отладчики — как программные, так и аппаратные. Средства тестирования, обсуждаемые далее, имеют отношение и к отладке. Тестирование Следующие инструменты помогут вам провести эффектив- ное тестирование: 쐽 автоматизированные системы тестирования, такие как JUnit, NUnit, CppUnit и пр.; 쐽 автоматизированные генераторы тестов; 쐽 утилиты для записи и воспроизведения тестовых примеров; 쐽 мониторы покрытия (анализаторы логики и средства профилирования); 쐽 символьные отладчики; 쐽 программы для стрессового тестирования (заполняющие оперативную память, перемешивающие содержимое памяти, генерирующие ошибки при выбороч- ных обращениях к памяти, проверяющие доступ к памяти); 쐽 средства сравнения (сравнивающие файлы данных, результаты работы програм- мы и экранные изображения); Перекрестная ссылка О добав- лении в код и удалении из кода отладочных средств см. подраз- дел «Запланируйте удаление от- ладочных средств» раздела 8.6. http://cc2e.com/3091 Перекрестная ссылка Об этих инструментах см. раздел 23.5. Перекрестная ссылка Об этих инструментах см. раздел 22.5. 704 ЧАСТЬ VI Системные вопросы 쐽 тестовые леса; 쐽 инструменты для внесения дефектов; 쐽 ПО для отслеживания дефектов. Оптимизация кода Эти инструменты помогут вам при тонкой настройке кода. Средства профилирования Профилировщик следит за работой кода и сообщает, сколько раз выполнялся каж- дый оператор или сколько времени программа затратила на выполнение отдель- ных выражений или исполняемых ветвей. Профилирование кода во время выпол- нения действует, как доктор, который приставляет стетоскоп к вашей груди и про- сит вас покашлять. Профилировщик дает вам понимание того, как работает ваша программа, где находятся узкие места и где нужно настроить код. Ассемблерные листинги и дизассемблеры Однажды вам захочется взглянуть на ассемблерный код, генерируемый вашим языком высокого уровня. Некоторые компиляторы могут генерировать ассемблерные лис- тинги. Другие — нет, и вам придется использовать дизассемблер, чтобы заново создать ассемблерный текст из машинного кода, сгенерированного компилятором. Анализ ассемблерного кода, создаваемого компилятором, показывает, насколько эффективно ваш компилятор преобразует код на языке высокого уровня в машинный код. Он может объяснить, почему высокоуровневый код, кажущийся быстродействующим, выполняется медленно. В главе 26 я приводил несколько примеров эталонных те- стов, результаты которых были нелогичны. При испытаниях этого кода я часто обращался к ассемблерному листингу, чтобы лучше понять результаты, не объяс- нимые при анализе программы на языке высокого уровня. Если вы плохо знакомы с языком ассемблера и хотите пройти вводный курс, то нет ничего лучше, чем сравнение каждого оператора языка высокого уровня с соответствующими ассемблерными командами, генерируемыми компилятором. Первое обращение к ассемблеру часто бывает настоящим открытием. Когда вы увидите, как много кода создает компилятор — насколько больше, чем нужно, — вы уже не сможете смотреть на свой компилятор так, как прежде. И наоборот, в некоторых средах компилятор должен генерировать исключитель- но сложный код. Изучение результатов его работы помогает по достоинству оце- нить те усилия, которые потребовалось бы приложить при программировании на языке более низкого уровня. 30.4. Инструменты и среды Некоторые платформы считаются более подходящими для работы с инструмен- тами, чем другие. Платформа UNIX известна своей коллекцией небольших утилит со смешными именами, которые хорошо работают вместе: grep, diff, sort, make, crypt, tar, lint, ctags, sed, awk, vi и другие. Языки C и C++, тесно связанные с UNIX, воплощают ту же ГЛАВА 30 Инструменты программирования 705 философию: стандартная библиотека C++ состоит из небольших функций, из которых легко сформировать более сложные функции, потому что все они хоро- шо работают в связке. Некоторые программисты настолько продуктивно работа- ют в UNIX, что не хотят с ней расставаться. Они использу- ют свои любимые UNIX-подобные средства в Windows и других средах. Свой вклад в успех парадигмы UNIX внесла доступность инстру- ментов, которые можно применять на других машинах. Так, cygwin предоставля- ет UNIX-подобный инструментарий для работы под Windows ( www.cygwin.com). Книга Эрика Реймонда (Eric Raymond) «The Art of Unix Programming» (2004) со- держит углубленное обсуждение культуры программирования под UNIX. 30.5. Создание собственного программного инструментария Допустим, вам дано пять часов на выполнение работы, и у вас есть выбор: 쐽 спокойно выполнить работу за пять часов; 쐽 потратить 4 часа и 45 минут, лихорадочно создавая утилиту для выполнения работы, а затем за 15 минут сделать работу с помощью этой утилиты. Большинство выберет первый вариант в одном случае из миллиона, а второй — во всех остальных случаях. Создание инструментария — это один из столпов программирования. Практически все большие организации (т. е. такие, в которых работает не менее 1000 программистов) имеют группы для разработки и поддерж- ки собственных инструментов. Во многих из них создан свой инструментарий для работы с требованиями и проектированием, превосходящий предлагаемые на рынке аналоги (Jones, 2000). Вы можете сами написать большую часть из перечисленных в этой главе инстру- ментов. Возможно, это и нерентабельно, но особых технических препятствий к этому нет. Инструментальные средства для отдельного проекта Большинству средних и больших проектов требуются специальные инструмен- ты, уникальные для этого проекта. Так, вам может понадобиться средство для ге- нерации специальных видов тестовых данных, чтобы проверить качество файлов данных, или программа для эмуляции аппаратной части, которой пока нет в на- личии. Ниже приведено несколько примеров поддержки в проектах специализи- рованных средств. 쐽 Аэрокосмическая команда отвечала за разработку ПО контроля инфракрасного датчика и анализа его показаний. Для проверки производительности программы записывающее устройство документировало действия, выполняемые програм- мой во время полета. Инженеры написали собственные средства анализа дан- ных с целью оценить производительность полетных систем. http://cc2e.com/3026 706 ЧАСТЬ VI Системные вопросы 쐽 Microsoft планировала включить новую технологию работы со шрифтами в графическую среду Windows. Поскольку и файлы с информацией о шрифтах, и ПО для отображения этих шрифтов были новыми, ошибки могли возникать как в данных, так и в программе. Разработчики Microsoft написали несколько специализированных утилит, которые проверяли наличие ошибок в файлах данных, что позволило проще различать места возникновения ошибок: в файлах данных или в ПО. 쐽 Страховая компания разработала большую систему для расчета повышений ставок. Поскольку система была сложной, а к точности предъявлялись повы- шенные требования, сотни рассчитанных ставок необходимо было тщатель- но проверить, хотя вычисление одной ставки вручную занимало несколько минут. Компания написала отдельное программное средство для расчета од- ной ставки, позволяющее делать это за несколько секунд и проверить ставки, полученные из основной программы гораздо быстрее, чем при проверке ста- вок вручную. Планируя проект, необходимо подумать об инструментах, которые могут пона- добиться, и выделить время для их создания. Сценарии Сценарий — это инструмент автоматизации повторяющихся рутинных операций. В некоторых системах сценариями называются командные файлы или макросы. Сценарии могут быть простыми и сложными, а наиболее полезные из них очень легко написать. Например, я веду дневник и для защиты конфиденциальной ин- формации всегда держу его в зашифрованном виде, кроме тех моментов, когда делаю в нем записи. Чтобы быть уверенным, что я всегда шифрую и дешифрую его надлежащим образом, я использую сценарий, который дешифрует мой днев- ник, запускает текстовый процессор, а затем шифрует дневник снова. Сценарий может выглядеть так: crypto c:\word\journal.* %1 /d /Es /s word c:\word\journal.doc crypto c:\word\journal.* %1 /Es /s Поле %1 предназначено для пароля, который по понятным причинам в сценарии не записан. Сценарий делает за меня работу (причем без ошибок) по вводу всех параметров и гарантирует, что я всегда выполню все операции, причем в правиль- ном порядке. Если вы обнаружите, что набираете строку длиннее пяти символов по многу раз в день, то эта процедура — хороший кандидат для использования в сценарии или командном файле. В качестве примеров можно привести последовательности компиляции/компоновки, команды резервного копирования и любые команды с большим количеством параметров. ГЛАВА 30 Инструменты программирования 707 30.6. Волшебная страна инструментальных средств Десятилетиями поставщики инструментария и ученые мужи обещают, что создание средств, которые позволят отказаться от программирования, не за горами. Первым и, кажется, самым забавным случаем присвоения этого ярлыка, был язык Fortran. Fortran (Formula Translation Language, язык преоб- разований формул) задумывался как средство, которое даст ученым и инженерам возможность просто набирать формулы и, таким образом, обойтись без помощи программистов. Fortran действительно позволил ученым и инженерам писать программы, но с сегодняшней точки зрения он выглядит сравнительно низкоуровневым языком про- граммирования. Он едва ли позволил обойтись без программистов, а опыт, полу- ченный при работе с Fortran, послужил прогрессу отрасли ПО в целом. Индустрия ПО постоянно разрабатывает новые инструменты, которые уменьша- ют влияние (или совсем исключают) некоторых наиболее утомительных аспек- тов программирования: деталей размещения операторов исходного кода; шагов, предпринимаемых для редактирования, компиляции, компоновки и выполнения программы; работы по поиску несогласованных скобок; действий по созданию стандартных текстовых сообщений и т. д. Поскольку каждое из этих новых средств начинает демонстрировать выигрыш в производительности, ученые мужи экст- раполируют этот выигрыш до бесконечности, предполагая, что благодаря ему в конце концов «исчезнет необходимость в программировании». Но на самом деле каждая инновация содержит некоторые изъяны. С течением времени изъяны ис- правляются, и потенциал инновации реализуется полностью. Однако после реа- лизации фундаментальной концепции инструмента дальнейший выигрыш дости- гается путем удаления случайных трудностей, возникших в качестве побочного эффекта при создании нового инструмента. Устранение этих случайных проблем по сути не увеличивает производительность, а просто исключает «шаг назад» из типичного уравнения «два шага вперед, один шаг назад». За последние десятилетия программисты видели массу инструментов, которые предположительно должны были устранить необходимость программирования. Сначала это были языки третьего поколения, потом — четвертого. Потом — авто- матическое программирование. Потом — CASE-средства. Потом — визуальное программирование. Каждое из этих достижений привносило значительные улуч- шения, и общими усилиями они сделали программирование абсолютно неузна- ваемым для тех, кто изучал его до этих нововведений. Но ни одна из этих инно- ваций не устранила программирования как такового. Причина в том, что программирование — принципиально сложный процесс даже при наличии хорошего инструментария. Дело не в инстру- ментах — программистам приходится бороться с несовер- шенством реального мира; нам нужно досконально проду- мывать последовательности, зависимости и исключения, иметь дело с конечными пользователями, которые никак не могут ничего решить. Нам всегда придется бороться с пло- Перекрестная ссылка Доступ- ность инструментария зависит от степени развития технологи- ческой среды (см. раздел 4.3). Перекрестная ссылка О причи- нах сложности программирова- ния см. подраздел «Существен- ные и несущественные пробле- мы» раздела 5.2. 708 ЧАСТЬ VI Системные вопросы хо определенными интерфейсами с другими программными и аппаратными сред- ствам и всегда принимать во внимание инструкции, бизнес-правила и другие источники сложных проблем, возникающие вне мира программирования. Нам всегда будут нужны люди, способные заполнить брешь между задачей реаль- ного мира, которую нужно решить, и компьютером, предназначенным для реше- ния этой задачи. Эти люди будут называться программистами независимо от того, манипулируют они машинными регистрами на ассемблере или диалоговыми ок- нами в Microsoft Visual Basic. Пока у нас есть компьютеры, нам будут нужны люди, которые говорят компьютерам, чтó делать, и эта деятельность будет называться программированием. Когда вы слышите заявления о том, что «новый инструментарий устранит необ- ходимость компьютерного программирования», бегите! Или хотя бы посмейтесь про себя над этим наивным оптимизмом. Дополнительные ресурсы Дополнительную информацию о программном инструментарии содержат следу- ющие источники. www.sdmagazine.com/jolts. Web-сайт, посвященный ежегодной премии Jolt Productivity журнала «Software Development Maga- zine», — хороший источник информации о лучших на се- годняшний день инструментах. Hunt, Andrew and David Thomas. The Pragmatic Programmer. Boston, MA: Addison-Wesley, 2000. Раздел 3 этой книги содержит всестороннее исследование программного инструментария, включая редакторы, кодогенераторы, отладчики, системы управления версиями и другие аналогичные инструменты. Vaughn-Nichols, Steven. «Building Better Software with Better Tools», IEEE Computer, September 2003, pp. 12–14. В этой статье приводится обзор инициатив в области разработки инст- рументальных средств, выдвинутых IBM, Microsoft Research и Sun Research. Glass, Robert L. Software Conflict: Essays on the Art and Science of Software Engineering. Englewood Cliffs, NJ: Yourdon Press, 1991. В главе «Recommended: A Minimum Standard Software Toolset» в противовес мнению о том, что чем больше инструментов, тем лучше, автор ратует за определение минимального набора инструментов, кото- рый должен быть доступен каждому разработчику и предлагаться в виде старто- вого комплекта. Jones, Capers. Estimating Software Costs. New York, NY: McGraw-Hill, 1998. Boehm, Barry, et al. Software Cost Estimation with Cocomo II. Reading, MA: Addison-Wesley, 2000. Книги Джонса и Бома содержат разделы, посвященные влиянию инструмен- тальных средств на производительность. http://cc2e.com/3098 http://cc2e.com/3005 http://cc2e.com/3012 ГЛАВА 30 Инструменты программирования 709 Контрольный список: программный инструментарий Используете ли вы эффективную IDE? Поддерживает ли ваша IDE интеграцию с системой управления исходным кодом, средствами компоновки, тестирования и отладки и другую полезную функциональность? Есть ли у вас инструменты для автоматизации часто выполняемого рефак- торинга? Используете ли вы систему управления версиями для управления исходным кодом, содержанием, требованиями, результатами проектирования, плана- ми работ и другими элементами проекта? Используете ли вы при работе над очень большим проектом словарь дан- ных или другой центральный репозиторий, содержащий официальное опи- сание каждого класса, пирменяемого в системе? Рассматривался ли вопрос использования библиотек кода в качестве аль- тернативы написанию собственного кода там, где это возможно? Пользуетесь ли вы интерактивным отладчиком? Используете ли вы make или другое ПО для контроля зависимостей, чтобы создавать программы эффективно и надежно? Содержит ли ваша среда тестирования инструменты для автоматического тестирования, генераторы тестов, мониторы покрытия, средства для стрес- сового тестирования, инструменты для сравнения и ПО для отслеживания дефектов? Создаете ли вы специальные средства, способные помочь в поддержке специальных нужд проекта, особенно инструменты, автоматизирующие по- вторяющиеся задания? Получает ли ваша среда преимущества от применения надлежащего инст- рументария? Ключевые моменты 쐽 Хороший инструментарий может значительно облегчить вам жизнь. 쐽 Можно легко приобрести инструменты для редактирования, анализа качества кода, рефакторинга, управления версиями, отладки, тестирования и настрой- ки кода. 쐽 Вы можете создать множество инструментов специального назначения. 쐽 Хорошие инструменты могут упростить наиболее утомительные аспекты раз- работки ПО, но они не могут исключить необходимость программирования, хотя и способствуют эволюции того понятия, которое мы вкладываем в слово «программирование». http://cc2e.com/3019 |