Главная страница Visual 2000 · Общий список статей
Поговорим о программировании.Андрей Колесов
© Андрей Колесов, 2000В силу обстоятельств в течение последних девяти лет...
В силу обстоятельств в течение последних девяти лет (это началось с момента публикации моей первой статьи по программированию под название "QuickBasic — это то, что вам нужно!" в "КомпьютерПресс" N 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 были в реальном коде написаны строчными буквами) осталась — использовались две разные переменные вместо одной.
О пользе чтения книг по программированию
Казалось бы сегодня разработчики не могут пожаловаться на информационный голов, в частности на отсутствие книг. Но приглядевшись повнимательней легко обнаружить, что абсолютное большинство изданий чаще всего является некоторым вариантом руководства по использованию некоторого конкретного инструмента. Результатом этого зачастую является ситуация, аналогичная той, что можно было наблюдать и двадцать лет назад: студенты тщательно изучали, например, Фортран, сдавали зачеты по нему, но, как с его помощью написать сколь-нибудь серьезную программу, — это оставалось загадкой для большинства. Причина этого проста — студентов учили языку, а не технологии программирования на примере одного из языков.
В этой связи, должен сказать, что мне очень повезло, что начало моей программисткой карьеры совпало с появлением ряда книг, которые оказали огромное влияние на мое формирование как разработчика. И среди них особенно хотелось бы выделить три, которые являются моими настольными книгами до сих пор:
(Хотелось бы еще упомянуть о более специализированных трудах Джеймса Мартина, в частности "Системный анализ передачи данных" и "Разработка систем реального времени".)
Со времени появления этих книг прошло четверть века, но я уверен, что их содержание почти на 100% актуально и сегодня. К сожалению, сегодня не видно аналогичный изданий, рассматривающих программирование на концептуальном уровне. И это при том, что упомянутые книги читаются столь же легко, как увлекательный детектив.
Сильное впечатление от этих прочтения этих книг во многом объяснялось тем, в них я и мои коллеги нашли систематическое изложение идей и подходов, к которым мы и сами подошли путем проб и ошибок. Разумеется, почерпнув, из них много нового и полезного.
Современные программисты имели возможность убедиться в этом на примере книги Брукса, юбилейное издание которой вышло веcной нынешнего года в России (петербургское издательство "Символ-Плюс"). В ней в основном рассматриваются вопросы организации процесса разработки, в том числе групповой.
Небольшие по объему (менее ста страниц) "Заметки" классика программирования Э.Дейкстры посвящены в первую очередь обоснованию необходимости использования структурных методов программирования с точки зрения повышения надежности программ и снижения затрат на их отладку. Там же изучаются вопросы взаимосвязей таких ключевых характеристик программного проекта, как время разработки, использование ресурсов (в первую очередь памяти) и производительность. Так же излагаются принципы решения ключевой оптимизационной задачи реализации проекта — достижения заданной эффективности программы при минимальных трудозатратах.
Но среди перечисленных выше книг для меня "Номер 1" — блистательный труд Эдварда Йодана (в современной транскрипции его фамилию часто пишут как Йордан). В стиле свободной беседы с читателем, с юмором и небольшими лирическими отступлениями, автор последовательно рассматривает весь процесс разработки приложений, показывая необходимость использования эффективных методов программирования.
Итак, советую современным разработчикам сходить в библиотеку и попробовать найти упомянутые выше книги. Я же буду регулярно ссылать на них. Ведь новое — это хорошо забытое старое.