О программировании. Размышления бывшего программиста
Начнем с совета: задавайте технические вопросы в понятной форме
О пользе чтения книг по программированию
Техасский рейнджер никогда
не уходит в отставку.
Крутой Уокер
В силу обстоятельств за последние девять лет (началось это после публикации моей первой статьи по программированию под названием «QuickBasic — это то, что вам нужно!», см. КомпьютерПресс 3’91) мне достаточно часто приходилось контактировать с разработчиками приложений. При этом, хотя речь обычно идет о конкретных системах программирования (QB, VB, VBA, Fortran), у меня уже давно сложилось убеждение, что часто создание программ упирается не столько в технические, сколько в общеметодические проблемы.
Эти вопросы затрагиваются в рубрике «Советы для тех, кто программирует на Visual Basic», которую мы с Ольгой Павловой ведем в течение четырех с половиной лет. Однако мы подумали, что, возможно, было бы полезно выделить тему об общих принципах разработки программ в самостоятельную рубрику. Так возникла идея опубликовать некоторые соображения для «тех, кто программирует на чем-нибудь».
Уточнение «бывшего программиста» в заголовке объясняется очень просто: пять лет назад я закончил свою программистскую карьеру и перешел к писательской. Так что мои публикации о программировании — это точная реализация известного афоризма: «Кто не умеет делать сам, тот учит других, как это нужно делать».
Не уверен, что у меня это получается удачно, поэтому готов выслушать любые отзывы о целесообразности продолжения «Размышлений…». Пишите: akolesov@online.ru.
Начнем с совета: задавайте технические вопросы в понятной форме
Довольно часто приходится слышать сетования программистов на то, что их вопросы, размещенные в телеконференциях или отправленные каким-либо экспертам напрямую (например, в службы технической поддержки), остаются без ответов. Однако, как мне кажется, причиной этого зачастую является неверная форма самого обращения, которая либо затрудняет работу эксперта, либо вообще делает вопрос совершенно непонятным.
Мы тоже периодически получаем подобные запросы от читателей и, к сожалению, должны констатировать, что чаще всего формулировка проблем и форма их подачи оставляют желать лучшего. Сокращая собственные затраты времени, авторы вопросов перекладывают свою работу на плечи экспертов, чем справедливо вызывают негативную реакцию последних.
В связи с этим я хочу дать несколько советов, как лучше формулировать свои вопросы при обращении к экспертам. Следование этим советам, конечно, не гарантирует получение позитивного ответа, но существенно повышает его вероятность.
 |
|
Общие рекомендации
- Письмо должно быть оформлено по всем правилам общения с незнакомыми людьми, которые, возможно, старше вас и скорее всего являются квалифицированными специалистами, знающими цену своему времени. Лично я стараюсь неподдерживать контакты с неизвестными адресатами, которые забывают начать с приветствия (желательно именного) изакончить указанием своего имени и фамилии. Это нужно хотя бы потому, что письмо может попасть не по адресу.Наличие знаков препинания и отсутствие жаргонных слов и выражений также крайне желательно. Иначе создается впечатление, что человеку, прежде чем заняться программированием, лучше сначала окончить неполную среднюю школу.
- Также хотелось бы, чтобы отправитель в нескольких фразах описал свой опыт в области разработки и то, какого класса задачи он решает сейчас. Это очень важно для персонифицированного ответа по существу. При этом обязательно следует указать, где вы проживаете. Например, пожелание «дойдите до ближайшего магазина и купите учебник», будет уместным в отношении москвича, но не подойдет для жителя села Поповка Архангельской области и даже для столичной Риги.
- Ни в коем случае не ссылайтесь на отсутствие времени, если эксперт в ответ посоветует вам прочитать соответствующую книгу или просто понятнее изложить проблему. В этом случае общение сразу прекращается, так как у эксперта свободного времени еще меньше. Если вы действительно хотите сэкономить время, то приготовьте деньги...
|
|
Технические рекомендации
- Встретившись с непонятной ситуацией в реальном приложении, постарайтесь
четко локализовать ее и создать небольшой тестовый пример, который демонстрирует
обнаруженную ошибку. Минимизируйте программный фрагмент, оставив только то,
что необходимо для демонстрации. Вполне возможно, что такое «отсечение ненужного»
позволит вам самостоятельно решить проблему: например, вы сможете неожиданно
для себя обнаружить фрагмент программы (на который вы до этого не обращали
внимания), влияющий на появление ошибки.
В большинстве своем подобный тест может уложиться в десяток строк кода с использованием простой формы с парой элементов управления. Старайтесь придерживаться этих объемов.
Например, если у вас проблема с перекодировкой символьных данных, то скорее всего нужно создать тест для обработки одного символа, исключив ненужные в данном случае циклы перебора байтов и пр. - Если у вас проявились две или более ошибок в программе, то исправляйте их по очереди в два слова, сконцентрировавшись на первой: возможно, вторая является ее следствием. К сожалению, довольно часто, встретившись в программе с непонятной ситуацией, программисты как бы маскируют ее и двигаются дальше, например:
Dim CC As String, d% ‘ CC — латинские буквы сс = «File.txt» ‘ cc — русские буквы ‘ d = Len(CC) ‘ ‘ здесь получилось d = 0 d = 8 ‘ программист решил «исправить» проблему.
Мы уже писали о проблеме, связанной с путаницей идентификаторов, вызванной отсутствием режима Option Explicite (Совет 245). Программист, получив в третьей строке кода нулевую длину строки, решил, что «VB глючит» и подправил код, установив «нужное» значение переменной d. А реальная ошибка (cc и CC были в реальном коде написаны строчными буквами) осталась: использовались две разные переменные вместо одной.
- Отправляя послание, не нужно писать текст программы в письме— лучше отправьте в качестве приложения готовый проект с тестом и со всеми необходимыми файлами исходных данных. Разумеется, предпочтительнее сделать приложение к письму в виде одного архивного файла. Напишите краткую инструкцию по установке примера на диск и по его запуску. Предварительно проверьте, чтобы ваш проект и исходные данные могли запускаться на выполнение из любого каталога. Если имеется привязка к конкретным именам каталогов, укажите это в инструкции по установке.
- Если для демонстрации вашей программы необходим ввод исходных данных с дискового файла, то лучше сделать пример с использованием простого текстового формата. Во-первых, тогда легко посмотреть, какие данные реально вводятся. Во-вторых, возможно, для тестирования придется варьировать данные, что в текстовом файле осуществить на порядок проще, чем при работе с двоичными форматами и базами данных.
- Обязательно пишите подробные комментарии в программе, отражающие ход ваших действий по идентификации ошибки: что вы собираетесь делать, что ожидаете получить в данном месте программы и что получаете на самом деле.
- 6. В сопроводительном письме опишите суть вашей проблемы и последовательность действий с программным примером, который позволяет выявить ошибку. Тут может быть уместно дополнительно указать небольшие фрагменты с «подозрительным» кодом.
- Порой в письмах приводится такая фраза: «Я делал все, как написано в книге». Гораздо лучше четко указать, в какой конкретно книге и на какой странице. Тогда эксперт сможет взять нужную книгу с полки и повторить ваши действия.
|
|
О пользе чтения книг по программированию
Казалось бы сегодня разработчики не могут пожаловаться на информационный голод, в частности на отсутствие книг. Но, приглядевшись повнимательнее, легко обнаружить, что абсолютное большинство изданий чаще всего представляют собой некоторый вариант руководства по использованию некоторого конкретного инструмента. Результатом этого зачастую является ситуация, аналогичная той, что можно было наблюдать и двадцать лет назад: студенты тщательно изучали, например, Фортран, сдавали по нему зачеты, но, как с его помощью написать сколь-нибудь серьезную программу, для большинства оставалось загадкой. Причина проста — студентов учили языку, а не технологии программирования на примере одного из языков.
В связи с этим я должен сказать, что мне очень повезло, что начало моей программистской карьеры совпало с появлением ряда книг, которые оказали огромное влияние на мое формирование как разработчика. И среди них особенно хотелось бы выделить три, которые являются моими настольными книгами до сих пор:
- Брукс Ф. Как проектируются и создаются программные комплексы. Мифический человеко-месяц — М.: Наука, 1979;
- Дейкстра Э. Заметки по структурному программированию (в составе сборника «Структурное программирование» — М.: Мир, 1975;
- Йодан Э. Структурное проектирование и конструирование программ — М.: Мир, 1979.
(Хотелось бы еще упомянуть более специализированные труды Джеймса Мартина, в частности «Системный анализ передачи данных» и «Разработка систем реального времени».) Со времени появления этих книг прошло четверть века, но я уверен, что их содержание почти на 100% актуально и сегодня. К сожалению, в настоящее время что-то не видно аналогичных изданий, рассматривающих программирование на концептуальном уровне. И это при том, что упомянутые книги читаются столь же легко, как увлекательный детектив.
Большое впечатление от прочтения этих книг во многом объяснялось тем, что в них я и мои коллеги нашли систематическое изложение идей и подходов, к которым мы и сами уже пришли путем проб и ошибок. Разумеется, наряду с этим мы почерпнули из них много нового и полезного.
Современные программисты имели возможность убедиться в этом на примере книги Брукса, юбилейное издание которой вышло весной нынешнего года в России (петербургское издательство «Символ-Плюс»). В ней в основном рассматриваются вопросы организации процесса разработки, в том числе групповой (подробнее об этом см. КомпьютерПресс 4’2000, с. 167).
Небольшие по объему (менее ста страниц) «Заметки» классика программирования Э.Дейкстры посвящены в первую очередь обоснованию необходимости использования структурных методов программирования с точки зрения повышения надежности программ и снижения затрат на их отладку. Помимо этого изучаются вопросы взаимосвязей таких ключевых характеристик программного проекта, как время разработки, использование ресурсов (в первую очередь памяти) и производительность. Также излагаются принципы решения ключевой оптимизационной задачи реализации проекта — достижения заданной эффективности программы при минимальных трудозатратах.
Однако среди всех вышеперечисленных книг «номером один» для меня является блистательный труд Эдварда Йодана (в современной транскрипции его фамилию часто пишут как Йордан). В стиле свободной беседы с читателем, с юмором и небольшими лирическими отступлениями, автор последовательно рассматривает весь процесс разработки приложений, доказывая необходимость использования эффективных методов программирования.
Итак, советую современным разработчикам сходить в библиотеку и попытаться найти упомянутые выше книги. Я же буду регулярно ссылаться на них. Ведь новое — это хорошо забытое старое.
КомпьютерПресс 9'2000
