Info Guide #07 31 мая 2005

Программирование

For Coderz - О дисциплине при создании больших проектов.

                    1.

        Программируем "по-крупному"
 

            ...Непременный атрибут процесса
            создания  программ. Первая "г",
            последняя "й". Восемь букв.
            - Геморрой...
           - Гм... подходит!..
 

           Из разговора двух программеров.

   Тема,  вынесенная  в  заголовок  данной
статьи (в заголовок,а не эпиграф!),на пер─
вый  взгляд, не очень ясна и понятна. "Что
значит по-крупному?! Мы по мелочам не раз─ 
мениваемся! У нас что ни проект,то шедевр! 
Дискеты с исходниками скоро солить будем!" 
Ну и далее в таком же духе. Именно о боль─
ших (в прямом  смысле) проектах и шедеврах
кодерской мысли сегодня пойдет разговор.
   Как не утонуть в большом исходнике, как
не  потерять плоды многомесячного труда по
вине какой-то плохо читающейся дискеты,как
сделать свои исходники хотя бы немного бо─
лее  понимаемыми другими людьми - обо всем
этом будет рассказано в этой  статье. Мно─
гие  вещи  могут  показаться  очевидными и
элементарными. Но всего на свете знать не─
льзя, а опыт приходит со временем. Поэтому
искренне надеюсь, что каждый почерпнет для
себя  хоть  что-то новое и полезное. Итак,
начнем.

   С  чего начинается процесс обучения ас─
семблеру? Сначала  из книжки после долгого
пыхтения набирается какой-нибудь здоровен─
ный исходник (размер его обратно пропорци─
онален лени и прямо пропорционален желанию
научиться программить).Потом делаются (за─
частую  безуспешные)  попытки разобраться,
как же все-таки оно работает. Разобравшись
с грехом пополам в одной процедуре,начина─
ющий  программист далее идет одним из двух
путей. Первый: "Да  ну  его  нафиг. Сложно
сильно. Не для меня". И второй: "Ёлки-пал─ 
ки! Да тут же делать нечего!Я не хуже могу 
написать, а то и лучше!" Мысленно попроща─ 
емся  с  последователями  первого  пути  и
опять-таки  мысленно похвалим представите─
лей  второго. И  что  дальше? А дальше наш
гипотетический программист начинает мучить
эту  несчастную  процедуру, постепенно  её
наворачивая,оптимизируя,сокращая. Наконец,
это ему надоедает,и процедура находит свое
успокоение на одной из множества дискет, а
то и на бумаге.Постепенно таких вот проце─
дур  накапливается довольно много и, нако─
нец,накапливается критическая масса, после
которой наступает моральная готовность на─
писать Настоящий Большой Проект. Появивше─
еся было желание написать все "с нуля" ку─
да-то быстро испаряется,и возникает другое
желание - взять свои старые процедуры, ко─
торые "не  так  уж и плохи". Замечательно,
программист  берет, собирает  процедуры по
куче исходников в один исходник, запускает
компиляцию, и... получает  кучу  сообщений
типа:

Label METKA is already used. 

   Ну  да, никто ж не думал, что всем этим
процедурам  придется когда-нибудь работать
вместе, поэтому  не позаботились об уника─
льности меток.Начинаем делать "уникальную"
работу - исправлять  метки  так, чтобы они
отличались  в  разных процедурах (пока наш
программист  вовсю старается и гнет пальцы
об   клавиатуру,  счастливые  пользователи
Alasm делают финт ушами,пишут нечто вроде: 

 Procedure1: 
        LOCAL
 metka:  ... 
         ...
        ENDL

 Procedure2: 
        LOCAL
metka:  ... 
 @MyGlobalMetka: 
         ...
        ENDL

   И спокойненько плюют в потолок).

   Ура! Программа собрана в один исходник,
все  нужные процедуры собраны, есть костяк
программы,все даже и работает. Тут начина─
ется  самое интересное: программа  изрядно
разбухает, перестает  влезать  в один файл
исходника, и  ее опять приходится "пилять"
на части (разумеется, это  касается только
тех  ассемблеров, которые поддерживают та─
кую  возможность). Тут  можно  также пойти
двумя путями - разделять на куски по прин─
ципу  "сколько  влезет и чтоб с запасом" и
разделение  по  функциональному признаку -
файловые операции, операции с устройствами
ввода,графические операции и т.д.Очевидно,
что последний вариант предпочтительней как
в плане написания, так и в плане сопровож─
дения кода.

   В  процессе разработки программы раз за
разом в текст вносятся изменения, часть из
которых  довольно рискованная (было "хоро─
шо", пытаемся  делать "ещё лучше", вопреки
правилу "лучшее - враг хорошего").
   Хотелось бы иметь возможность вернуться
к старой версии текста, если что-то пойдет
не так. Так мы подошли к проблеме хранения
исходников  и контроля версий. Для отдель─
ных текстов можно предусмотреть сохранение
резервных  копий (обычно 1-2 бывает вполне
достаточно)  с несколькими  отличительными
символами в именах файлов, чтобы сразу оп─
ределить первоисточник.На более глобальном
уровне  можно выполнять архивирование всех
исходных  файлов проекта. Для хранения ар─
хивов  отвести  один-два диска на проект и
использовать  даты в качестве имён файлов.
Также  можно  поместить  в архив текстовый
файл с кратким описанием проекта,изменений
относительно прошлой версии и т.д.Для эму─
ляторщиков  представляется  дополнительное
удобство - можно не морочить голову, а ар─
хивировать целиком образы дискет,не рискуя
забыть поместить в архив тот или иной нуж─
ный файл.Также крайне рекомендую регулярно
распространять  свои  архивы по знакомым и
сайтам ( opensourcezx.narod.ru именно  для
этих  целей  и создан) чтобы в случае чего
не  остаться на бобах. Тот факт, что после
потери  последней версии можем остаться со
старой, в которой не реализовано много ве─
щей,не должен являться проблемой.Как гово─
рит  мой учитель (и я с ним полностью сог─
ласен), хорошая программа пишется дважды,а
то и трижды.

   Если  планируется  распространять прог─
рамму с открытым кодом, или разработка ос─
тановилась, но планируется вернуться к ней
позже, необходимо обеспечить удобство про─
чтения кода, особенно другими людьми (хотя
лично  я терпеть не могу разбираться в чу─
жих  исходниках  и  программах, легче свое
написать). На  эту  тему  можно предложить
 несколько замечаний.
  1) Каждый файл исходника предварять "ша-
пкой" с кратким описанием файла, возможно, 
списком функций и историей изменений (осо─ 
бенно актуально при коллективной разработ─ 
 ке), прочими данными (дата, автор). 
  2) Использовать  по  возможности  единый
стиль  оформления исходных текстов - с от─ 
делением операндов пробелами или табуляци─ 
ями (например, мои исходники, набранные на 
реале, разделены табуляцией,в то время как 
более  поздние, созданные  под эмулятором, 
разделены пробелами, потому что до Break'а 
 сложно дотянуться %)). 
  3) Применять визуальные комментарии-раз─
делители, например: 
;------- близкие по функциональности блоки 
;======= менее близкие 
;******* "шапки", описания и т.д. 
 ;\\\ ну и так далее %) 
  4) Можно  делать  описания для функций -
что делает, какие входные параметры, какие 
выходные, какие  регистры и память портит, 
прочие замечания. 
   К вопросу оформления меток. Так уж сло─
жилось,что на спектруме прижился Unix-овс─
кий стиль оформления меток - один регистр,
а  слова  разделены  знаком  подчеркивания
(людипомогитенеработаетпробелчтоделать?! - 
настоящие_кодеры_пробелом_не_пользуются!). 
Для  тех ассемблеров, которые по умолчанию
используют нижний регистр букв,можно испо─
льзовать  написание меток с использованием
больших  букв. Тут  тоже  есть два стиля -
Pascal (каждое слово  в словосочетании пи─ 
шется слитно и с большой буквы, т.н. "дву─
горбый  верблюд": OpenFile )  и  Java (все
слова,  кроме  первого,  пишутся слитно  и
с  большой  буквы,  "одногорбый  верблюд":
openFile ). Также  весьма  удобным выходом 
иногда  служит  использование  "венгерской
записи". Она  применяется только для пере─
менных, в начало имени которых добавляется
небольшой  префикс, определяющий  тип  пе─
ременной: b - byte, w - word, sz - string,
p - pointer etc. Взглянув один раз на наз─ 
вание  переменной, можно без особого труда
определить (предсказать?) ее тип.
   Если файл  состоит из какого-то ограни─
ченного  набора процедур, внутренние метки
в этих  процедурах  можно  формировать как
сокращенное  название процедуры + порядко─
вый номер, например:

PRINTLINE 
        ...
PL0     ... 
        ...
 PL1     ... 
        RET

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

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

Vitamin 

                    2.

       Дисциплина программирования.

   Хочется  и со своей стороны дать неско─
лько опробованных временем советов.
   Убедите себя в том,что любое творчество
важнее потребления.Это станет ключом к по─
ниманию логики выше- и нижесказанного.Всё,
что вы создаёте, нужно,кто бы вам не твер─
дил обратное. Ответственность за сделанное
вторична,но и она существует. Надо её лишь
чувствовать - и по отношению к откровенной
халтуре, и к программе,которая грозит пор─
тить людей.
   Всякую программу можно улучшить.Бойтесь
соблазна "последних версий".Не прекращайте
проект только из принципа,и уж тем более -
не  стирайте  исходники. Будет  лучше ВАШЕ
исправление  через месяц, чем исправление,
неаккуратно сделанное хакером спустя год.
   Берегите  исходники и всегда дублируйте
их. Так же относитесь к сопутствующим фай─
лам. Не доверяйте "жёстким дискам".Коробка
дискет  служит  дольше  и  отнюдь не имеет
обыкновения портиться целиком и без шансов
на  восстановление. Ещё  лучше  копировать
исходники  друзьям. Не бойтесь, что кто-то
выпустит вашу программу под чужим именем:)
   Храните  старые версии исходников - это
помогает исправлять ошибки в программе.
   Оптимизацию следует проводить самостоя─
тельно,слепо не следуя каким-либо методам.
Большинство  таких методов не универсально
и пасует  в половине случаев перед другими
методами. (Я  опишу  несколько  методов  в
другой статье.)
   Программу  большого размера стоит опти─
мизировать  по  размеру.  Иногда  сокраще─
ние размера программы  может сильно упрос─
тить  её структуру, освободив какую-нибудь
область памяти.
   Программу,скорость или время работы ко─
торой  можно  измерить в секундах или гер─
цах, имеет смысл ускорить. Как правило,это
процесс поэтапный и конца ему не видно,что
бы ни утверждали о десяти процентах приве─
рженцы языков высокого уровня (ЯВУ).
   (Вразрез с вышесказанным:)
   Программу, которую  хорошо бы выпустить
в некий срок,стоит успеть выпустить в этот
срок. Часто  для  этого можно пожертвовать
оптимизацией и уж наверняка - парой пропу─
щенных телефильмов. Желательно оставить за
собой право доработки после.
   Если вам не удаётся ничего, кроме отде─
льных  процедур, и те плохо, и при этом вы
не можете довести до сборки ни одной заду─
манной крупной программы,не отчаивайтесь -
просто пишите, пишите, пишите до победного
конца! Программы  на деревьях не растут, а
программисты  с  небес не падают - если не
лениться, то всё получится, и, конечно же,
с каждым разом легче!
   Вы  можете программировать эффективнее,
чем вы сейчас программируете. Вам кажется,
что это невозможно?

A. Coder