Андрей Колесов

В начало статьи

Начнем с совета: задавайте технические вопросы в понятной форме

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

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

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

Общие рекомендации:

1. Письмо должно быть оформлено по всем правилам общения с незнакомыми людьми, которые возможно старше вас и наверное являются квалифицированными специалистами, знающими цену своего времени. Лично я стараюсь не поддерживать контакты, с неизвестными адресатами, которые забывают начать с приветствия (желательно именного) и закончить подписью. Хотя бы потому, что не знаешь — может быть письмо попало не по адресу. И как нужно обращаться к автору при ответе? Наличие знаков препинания и отсутствие жаргона также крайне желательно. Иначе создается впечатление, что человеку прежде чем заняться программированием, лучше сначала закончить неполную среднюю школу.

2. Крайне желательно, чтобы отправитель в нескольких фразах описал свой опыт разработки и какого класса задачи он решает сейчас. Это очень важно для ответа по существу, так как он обязательно должен быть привязан к конкретному человеку. При этом обязательно следует обозначить географическое положение отправителя. Например, пожелание "дойдите до ближайшего магазина и купите учебник", будет уместным в отношении москвича, но не подойдет для жителя села Поповка Архангельской области и даже столичной Риги.

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

Технические рекомендации:

1. Встретившись с непонятной ситуацией в реальном приложении, постарайтесь четко локализовать и создать небольшой тестовый пример, который показывает обнаруженную ошибку. Минимизируйте программный фрагмент, оставив только то, что необходимо для демонстрации. Вполне возможно, что такое "отсечение ненужного" позволит вам самостоятельно решить проблему: например, вы сможете неожиданно для себя обнаружить фрагмент программы (на который вы до этого не обращали внимания), который влияет на появление ошибки.

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

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

   
   Dim CC As String, d% ' CC — латинские буквы 
   сс = "File.txt" ' cc — русские буквы 
   ' d = Len(CC)  ' здесь получилось d = 0 
   d = 8 ' программист решил "исправить" проблему
   

   Мы уже писали о проблеме с путаницей идентификаторов, связанной с отсутствием режима Option Explicite (Совет 245). Программист, получив в третьей строке кода нулевую длину строки, решил, что "VB глючит" и подправил код, установив "нужное" значение переменной d. А реальная ошибка (cc и CC были в реальном коде написаны строчными буквами) осталась — использовались две разные переменные вместо одной.

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

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

5. Обязательно пишите подробные комментарии в программе, которые отражали бы ход ваших действий по идентификации ошибки: что вы собираетесь делать, что ожидает получить в данном месте программы и что получаете на самом деле.

6. В сопроводительном письме опишите суть вашей проблемы и последовательность действий с программным примером, которая позволяет выявить ошибку. Тут может быть уместным дополнительно указать небольшие фрагменты с "подозрительным" кодом.

7. Порой в письмах приводится такая фраза: "я делал все, как написано в книге". Гораздо лучше четко написать: в какой конкретно книге и на какой странице. Тогда эксперт сможет взять нужную книгу с полки и проделать то же самое.

В начало статьи

О пользе чтения книг по программированию

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

В этой связи, должен сказать, что мне очень повезло, что начало моей программисткой карьеры совпало с появлением ряда книг, которые оказали огромное влияние на мое формирование как разработчика. И среди них особенно хотелось бы выделить три, которые являются моими настольными книгами до сих пор:

1. Ф. Брукс "Как проектируются и создаются программные комплексы. Мифический человеко- месяц" / М.: "Наука", 1979.

2. Э. Дейкстра "Заметки по структурному программированию" (в составе сборника "Структурное программирование" / М.: "Мир", 1975.

3. Э. Йордан "Структурное проектирование и конструирование программ" / М.: "Мир", 1979.

(Хотелось бы еще упомянуть о более специализированных трудах Джеймса Мартина, в частности "Системный анализ передачи данных" и "Разработка систем реального времени".)

Со времени появления этих книг прошло четверть века, но я уверен, что их содержание почти на 100% актуально и сегодня. К сожалению, сегодня не видно аналогичный изданий, рассматривающих программирование на концептуальном уровне. И это при том, что упомянутые книги читаются столь же легко, как увлекательный детектив.

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

Современные программисты имели возможность убедиться в этом на примере книги Брукса, юбилейное издание которой вышло веcной нынешнего года в России (петербургское издательство "Символ-Плюс"). В ней в основном рассматриваются вопросы организации процесса разработки, в том числе групповой.

Небольшие по объему (менее ста страниц) "Заметки" классика программирования Э.Дейкстры посвящены в первую очередь обоснованию необходимости использования структурных методов программирования с точки зрения повышения надежности программ и снижения затрат на их отладку. Там же изучаются вопросы взаимосвязей таких ключевых характеристик программного проекта, как время разработки, использование ресурсов (в первую очередь памяти) и производительность. Так же излагаются принципы решения ключевой оптимизационной задачи реализации проекта — достижения заданной эффективности программы при минимальных трудозатратах.

Но среди перечисленных выше книг для меня "Номер 1" — блистательный труд Эдварда Йодана (в современной транскрипции его фамилию часто пишут как Йордан). В стиле свободной беседы с читателем, с юмором и небольшими лирическими отступлениями, автор последовательно рассматривает весь процесс разработки приложений, показывая необходимость использования эффективных методов программирования.

Итак, советую современным разработчикам сходить в библиотеку и попробовать найти упомянутые выше книги. Я же буду регулярно ссылать на них. Ведь новое — это хорошо забытое старое.

В начало статьи