История:
Принципы создания программ на ZX SpectrumЭти принципы были изложены Спектрум-кодером более 20-ти лет назад, но и сегодня не перестают быть актуальными.
Немного информации предоставленной ресурсом speccy.info:
-
Oberon — электронный журнал, выпускавшийся группой
Stars of Keladan (Самара) с апреля 1996 по ноябрь 1998 года.
-
Stars of Keladan - творческая группа из Самары.
-
Paul Atrides (Евгений Милун, группа
Stars of Keladan) - код
http://zxpress.ru/article.php?id=11846Oberon #02
31 октября 1996
Программирование
Ликбез - немного поговорим о программировании,
вернее о жизненных этапах любой программы. Cегодня давайте немного поговорим о
программировании, вернее о жизненных эта-
пах любой программы. Любители "компьютер-
ной попсы" могут смело перелистнуть эту
рубрику. На этот раз мой рассказ будет не-
долгим, но в следующий раз...
Как я уже говорил вам при нашей первой
встрече ("OБEPOН" No1). программистами не
рождаются, это диагноз после пятилетних
мучений в ВУ3е. Одним из важных моментов
обучения программиста является вдалблива-
ние ему тех стадий, которые ОБЯ3АТЕЛbНО
должна пройти его программа.
Всего таких стадий или жизненных этапов
программы восемь.
1. Oпределение неoбхoдимых технических
требoваний к кoнфигурации системы.
На этой стадии определяются (обычно за-
казчиком) технические требования к аппара-
туре,на которой и с которой будет работать
программа. Если заказчика нет, то эти тре-
бования определяет сам программист. Вся
дальнейшая разработка будет производиться
в соответствии с ними.
Для SPECTRUM вы, начиная разработку
своей программы должны определить:
- необходимо-ли наличие дисковода для ра-
боты программы:
- версию и тип ДОC (Is-DOS, TR-DOS, CP/M):
- минимальный размер памяти для работы:
старайтесь уложиться в 48К, если нет, то в
128К и уж в самом пре-самом крайнем случае
больше 128К, при этом нужно определить
тип компьютера с этими "больше 128К"
(SCORPION, ATM-TURBO, PROFI, а еще лучше
все сразу):
- наличие музыкального сопроцессора:
- вопросы совместимости: использовать ли
мифический #FD порт, или нормальный #7FFD:
использовать-ли порт атрибутов #FF (если
можно, лучше обойтись без него): использо-
вать ли для 2-го режима прерываний таблицу
векторов (для работы на всех компьютерах),
или задавать вектор двумя байтами (будет
работать только на компьютерах со ста-
бильной шиной данных).
2. Пoстанoвка задачи.
По идее этим должен заниматься не прог-
раммист, а постановщик задач (должность
такая на ВЦ), но все чаще и чаще этим за-
нимаются сами программисты. На этом этапе
фраза типа: "мне нужна программа для учета
заработной платы работников", переводится
во фразы: "создать программу, позволяющую
(а) заполнять информацию о работниках, (б)
удалять информацию о работниках, (в) кор-
ректировать информацию о работниках, (г)
просматривать информацию, (д) производить
поиск информации по заданным критериям".
Одним словом - на этом этапе начинают вы-
рисовываться возможности и функции будущей
программы.
3. Coздание кoнцептуальнoй мoдели.
Один из самых ответственных этапов. В
начале вы должны ответить на один щекотли-
вый, но обязательный вопрос: А НУЖНА ЛИ
ПОЛb3ОВАТЕЛЯМ ваша программа, выполняющая
функции,определенные на предыдущем этапе ?
И если нет (не нужна), то либо от дальней-
шей работы над этой программой отказывают-
ся, либо заново проходят пункты 1,2. Если
же программа признается необходимой, то
создается концептуальная модель поведения
будущей программы - что и когда она будет
делать, какую информацию и когда вводить и
выводить, ... 3десь же определяется струк-
тура и тип управления и контроля за ее ра-
ботой (клавиши управления, системы и ие-
рархии меню, типы и количество вводимой и
выводимой информации, одним словом -
пользовательский интерфейс). Определяется
критичность по времени всей программы и
отдельных модулей.
Для игр здесь определяются правила и за-
коны игры, все персонажи, участвующие в
игре, их поведение, взаимодействие друг с
другом, ... Определяется и создается опи-
сание каждого персонажа, для того, чтобы в
дальнейшем программа по нему управляла
этим персонажем.
По завершению этого этапа у вас должна
получиться сбалансированная модель прог-
раммы, представление о ситуациях, которые
могут возникнуть во время работы программы
и пути выхода из них.
4. Coздание алгoритма.
Учитывая результаты пунктов 1 - 3, про-
изводится создание алгоритма программы.
Cоздается как общий алгоритм (что какая
процедура делает и с какими связана), так
и алгоритм каждой процедуры.
Очень удобно и полезно нарисовать схемы
алгоритмов (то, что на жаргоне называется
блок-схемами).
5. Bыбoр языка и прoграммирoвание алгoрит-
ма.
Как вы уже наверное заметили, до сих пор
не было написано ни строчки программы !!
До сих пор еще даже не ясно, на каком язы-
ке будет написана программа !!
Теперь, имея алгоритм, вы должны решить
на каком же языке писать ? И решать это
надо не по принципу "какoй язык знаю луч-
ше. на тoм и пишу". а по принципу "какoй
язык пoзвoлит эффективнo реализoвать алгo-
ритм". Выбрав язык, можно приступать к
программированию и отладке программы.
Как легко видеть,это пятый,а не первый и
единственный пункт !!! Кивки на опытных
программистов - "они, мол, сразу начинают
программировать" не соответствуют действи-
тельности. Несмотря ни на что, даже быва-
лый программист не может программировать,
не имея алгоритма ! Другое дело, что он
придумывает его на ходу и берет сразу из
головы. Но ведь на то он и бывалый.
Также как опытный механик по шуму дви-
гателя может поставить "диагноз", так и
опытный программист производит многое из
выше перечисленного "в уме" (но ведь про-
изводит !), лишь в самых запутанных и
сложных местах прибегая к помощи листка
бумаги и ручки. А когда он был малоопытным
и "начинающим", он все зарисовывал и запи-
сывал на бумаге. И ничего в этом нет "при-
нижающего" - человек, в уме вычисляющий
сложные интегралы, когда-то не знал даже
простейшей таблицы умножения.
И не беда, если он начал программировать
не имея нарисованного алгоритма - он его
нарисует позже (хотя бы для проверки пра-
вильности программы и для ее отладки).
6. Дoскoнальнoе тестирoвание прoграммы
(другoе название - прoбная эксплуатация).
В результате которого, по возможности вы-
являются и исправляются ошибки, которые
неизбежно содержатся в любой программе
(старая "программерская" аксиома: в любoй
прoграмме. как бы oна ни была хoрoшo прo-
думана. сoдержатся пo крайней мере две
серьезные oшибки. кoтoрые мoжнo выявить
тoлькo при эксплуатации). Вот именно этот
этап многие очень любят либо вообще про-
пускать,либо проходить поверхностно,а зря.
7. Coздание сoпрoвoдительнoй дoкументации.
3аключительный этап, во время которого
вы должны расписать то, как работает ваша
программа, как работать с ней и на каких
компьютерах она должна работать, может ра-
ботать, ...
8. Началo распрoстранения.
Теперь, и только теперь, программа со-
ответственно оформлена и оттестирована, и
можно начинать ее распространение.
Не побоюсь повториться и сказать, что
ЛЮБАЯ программа должна пройти через эти
стадии, даже если это хаккерская версия !
Если она не прошла хоть одну стадию, или
эта стадия оказалась "скомканной", то это
означает одно из двух:
1. Это программа для "чисто домашнего ис-
пользования в кругу семьи" и выпуск ее в
продажу является актом глубокого неуваже-
ний к пользователям (т.е. к тем, кто ее
купит). Лично у меня есть несколько таких
моих программ, они не имеют хорошего ин-
терфейса (а зачем мне делать их нарядыми,
если кроме меня их никто не увидит ?),
рассчитаны на работу в основном только на
SCORPION'е с теневым сервис-монитором
(вот я еще для себя не делал "глючные"
алгоритмы работы с диском, когда они уже
"зашиты" в П3У моего SCORPION !), не имеют
практически никакой документации (я и так
помню, зачем я их делал и как с ними рабо-
тать).
А теперь представьте, что одну из этих
программ я начал распространять !!! Ваши
эмоции по этому поводу ? А вот "начинающие
программисты", "ИНФОРКОМ" (да и
"SPECTROFON" кажется тоже) считают само
сабой разумеющимся распространение таких
программ.
2. Это, всеж-таки, коммерческая программа,
но страшно ущербная, если вообще работаю-
щая. Примеры ? Да их множество. Игры VIRUS
и VIRUS-2: множественные "недодумки" на
этапе 3 (сoздание кoнцептуальнoй мoдели).
в результате чего - неправильная обработка
вирусов, непонятные правила изменения по-
ведения вируса при изменении его парамет-
ров, этап 7 (сoздание сoпрoвoдительнoй дo-
кументации) - то количество информации,
которое сообщает нам автор, нельзя назвать
просто приемлемым, не то что достаточным.
Игра "Cтрана Мифов": программа, которую
вполне можно было реализовать на 128К
(пусть и с подгрузками, не впервой) рабо-
тает только на 256К (этап 1, аппаратные
требoвания). армия все время деградирует и
ни о каком поиске Рунного Посоха речи быть
не может (этап 3, сoздание кoнцепту-
альнoй мoдели).
Игра "SOLDIER OF THE FUTURE": в начале
битвы роботы должны располагаться друг от
друга (причем, либо все снаружи здания,
либо все внутри одного здания) не дальше
определенного расстояния, иначе у них не
хватит энергии найти друг друга (этап 3),
расстановка роботов перед битвой проходит
"вслепую" т.к. карта выведется на экран
уже позже (тот же этап 3). Надеюсь, дальше
продолжать не стоит.
Так что, уважаемые разработчики прог-
рамм, пожалуйста, распространяйте только
те программы, которые сделаны "по-науке".
Уважайте покупателя (он же пользователь).
На сегодня пока все, сначала "перевари-
те" эту информацию, а потом я вам
"скормлю" и другую. А если серьезно, то
уже совсем скоро (но не раньше чем вы пой-
мете, что программирование - один из видов
искусства, с добавлением математической
логики) мы с вами подойдем к описанию
Ассемблера и приемам программирования
на нем.
До новых встреч.
(C) PAUL ATRIDES
══════════════════════════════════════════
* * *
