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