Главная

Новости

Статьи и обзоры
  Горожанин
  Обнинск в Internet
  Web Design
  Hardware
  Software
  Безопасность
  Серфинг
  Игродром
  Relax
  Технологии
  Web-обзор
  Интернет-ликбез
  Опросник
  УП-Технологии
  ART.net

Ссылки

Архив

О нас

Контакты

Форумы

POPULAR.RU

нашел и рассказал Steel
автор - Безруков Н.Н.

Программирование сверху вниз наискосок

Это произведение еще около года тому назад было передано мне моим другом. Я не в курсе, где он его откопал, но автор предлагаемого труда все-таки известен - это Безруков Н.Н. Когда-то я опубликовал этот "пособие" у себя на HomePage, но навряд ли кто-нибудь из посетителей с ним успел ознакомиться. Теперь я предлагаю его вам. Произведение неновое, и, может быть, кто-нибудь из вас его уже читал. Адресовано оно тем, кто связан с творческим процессом под названием "Программирование", остальные же (кто даже не имеет представления о программировании) просто могут не понять прикола… Предупреждаю начинающих программистов: "Всё, что здесь приводится воспринимайте не как руководство к действию, а как вредные советы". Начнем…

Светлой памяти EC1022 посвящается

Может ли Господь Бог написать программу,
которую он не сможет отладить?

В последние годы на капиталистическом Западе как грибы после дождя разрабатываются всяческие "теории" программирования, призванные, якобы, облегчить написание, отладку и сопровождение больших программных комплексов. Очевидно, что будучи продуктом буржуазной идеологии и выражая интересы правящего класса, эти теории призваны отвлечь широкие массы программистов от их истинных интересов. К сожалению, у нас отдельные товарищи попали под тлетворное влияние теорий "структурного", "модульного", "нисходящего или восходящего" программирования, забывая, что чем дольше программист отлаживает программу, тем безошибочнее и эффективнее она когда-нибудь будет работать. Поэтому, давно назрела необходимость противопоставить этим лжетеориям нашу домашнюю, самодельную, выстраданную и вымученную методику программирования. Опыт такой методики и предлагается читателю. Мы назвали наш метод "Gloping Programming" или "Снизу вверх наискосок" (СВН). Основную идею метода СВН лучше всего передает древняя восточная мудрость: "Если что-нибудь можно сделать двумя способами, не пожалейте усилий и придумайте третий".

1. С чего начать
Многие западные программисты утверждают, что прежде чем начинать писать программу, необходимо время на обдумывание алгоритма, а некоторые даже призывают вникнуть в суть задачи, которую предстоит решать. Категорически не следует интересоваться постановкой задачи до момента получения объектного модуля программы. Помните, что программирование - это искусство, поэтому любые лишние знания только ограничивают вашу фантазию. Начинайте писать текст программы задолго до того, как вам сформулируют техническое задание (ТЗ), и вы получите прекрасную возможность сделать жизнь вашего руководителя (и свою) гораздо разнообразнее и интереснее. Например, в момент получения ТЗ вы можете возмутиться: "Представляете, сколько теперь придется переделывать?!". Никогда не составляйте заранее блок-схему программы. Во-первых, это проще и быстрее сделать, когда программа уже написана. Во-вторых, неосторожно оставленная на столе блок-схема даст вашим врагам и завистникам возможность понять, что вы собираетесь делать. Помните, что никто кроме вас не должен разбираться в вашей программе, и если вы никак не можете избавиться от дурной привычки рисовать блок-схемы, то зарубите у себя на носу: чем больше структура программы соответствует ее логике, тем меньше вы стоите как программист.

2. Стиль
Этому модному словечку многие западные адепты и апологеты придают особый, чуть ли не мистический смысл. Безусловно, каждый программист или, там, композитор имеет право писать в своей манере. Однако, учитывая объемы программных разработок, необходимо считаться с реальностью. Программирование должно быть экономным! Тратить до 50% перфокарт и объема листинга (слово-то какое!) на комментарии, пробелы, пустые операторы, звездочки и другие украшательства - совершенно недопустимая расточительность. Пишите со 2-ой по 71-ю позиции, всемерно избегая пробелов. Если комментария никак не избежать, стремитесь писать их как можно конкретнее. Например:

DО J=1 ТО N; /* cycl po N*/
IF J>0 ТНЕN GОТО М; /*perexod to М*/
ЕLSЕ GОТО L; /*perexod k L*/
Х=Х+1; /* pribavit` 1 k Х */
ЕND;
М: Х=Х-1; /* ТАК НАДО ФЕДЯ! */
IF А ТНЕN GОТО L;
L: Х=Х**2; /* ВОЗVЕSТY Х SТЕР. ДВА*/

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

/*PL1*/
IF КАТJА >= 18 ТНЕN DО
САLL GАSТRОNОМ;
САLL ТАХI;
GОТО ХАТА;
ЕND;
ЕLSЕ GОТО VЕRА;

/* АSSЕМВLЕR */
GLОРING СSЕСТ
...
МАRINА ЕQU DURА
...
L АН,МАRUSJА
SТ UН,АNJUТА
ВХLЕ LЕТS,IRINА,DRINК(АGDАМ)

поражают изяществом, остроумием и тонким вкусом. При внимательном рассмотрении легко обнаруживается, что буржуазные авторы книг, рассуждая о предмете, которые они называют "структурным программированием", тонут в собственных противоречиях. Например, [Д.Майерс стр.63]: "Скромные по целям работающие программы лучше неотлаженных грандиозных проектов". А нас стр.58 "Если незначительное добавление сделает вашу программу пригодной для другого случая, никогда не пренебрегайте этим". Мы готовы согласиться с последним утверждением, поскольку умелое его применение позволит вам затянуть разработку программы на любой мыслимый строк. Более того, тот же автор через несколько страниц вспоминает пресловутый принцип KISS (Keep It Simnple, Stupid - пер. с англ. "будь проще, дурачок"). Представляете, в один прекрасный день руководитель заявляет вам: "Что-то у вас очень уж просто всё получается!" Эти структурно-экстремистские тенденции в конце концов приводят к полному вырождению прогрммирования как творческой деятельности. Предельная степень деградации порождает методы типа Ашкрофта-Манны [Э.Йодан], сводящие деятельность программиста к работе Ч.Чаплина на конвейере в к/ф "Новые времена".

3. Go Тo
Проблема безусловных переходов, к счастью, еще не нашла окончательного решения. Среди программирующей западной молодежи распространено заблуждение, что использование оператора GOTO крайне нежелательно. Практика ведущих программистов нашей лаборатории показывает, что использование оператора безусловного перехода в сочетании с массивами меток повышает эффективность программ в среднем на 4.2% при увеличении времени отладки на 350-400% .

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

Все вставки в программу следует делать так: после последнего оператора ставьте новую метку, напишите текст вставки, увеличьте размерность массива меток на 2, передайте управление на эту метку из нужной точки(или откуда-нибудь еще), пометьте оператор, следующий за GOTO, новой меткой, смело измените значение переменной метки и вернитесь. Вообще говоря, на каком языке вы бы ни писали программы, лучше, если каждый оператор будет иметь свою метку (как это предусмотрено в ФОРТРАНЕ). Степень вашей квалификации, как программиста в стиле СВН, определяется соотношением:

N - число операторов,
V (i) - число передач управления на i-й оператор,
W (i) - число возможных переходов от i-го оператора.

При К < 0.5 вы, как программист, никуда не годитесь. Приемлемый коэффициент 3 - 4, а некоторые СУПЕР-программисты имеют К не ниже 12.

IV. Модульность
Никакой модульности ! ВООБЩЕ…

V. Эффективность
Споры по поводу того, что считать эффективной программой, не утихают с тех пор, когда в спортзале заработала ЭВМ М-20. В наши дни дело дошло до появления казуистических утверждений вроде: "Удобочитаемость программы существеннее ее эффективности" [Д. Майерс]. Мы считаем, что эффективность программы является совершенно объективной и количественно оцениваемой величиной. Не надо жалеть ни времени, ни усилий в борьбе за эффективность - когда ваша программа в конце концов заработает, все ваши затраты окупятся экономией 15 мкс и 0.073 кб! Чтобы программист мог заранее оценить эффективность своего продукта предлагается простая формула:

Э = Т/Т1 + I*Т/Т2                   (2)

T - время, необходимое для вывода на CPU заранее заготовленного текста, идентичного тому, который будет печатать ваша программа, когда выйдет на Go
Т1 - время, требуемое CPU для выполнения вашей программы (если программа еще не выходит на Go, то T1=T)
T2 - время, которое ваша программа будет выполняться, когда вы ее полностью отладите.

I = SQRТ (-1)

Эффективность программы, как видно, величина комплексная, что отражает системный подход к программированию, характерный для метода СВН Таким образом, как следует из выражения для (2), сроки написания и отладки программы никоим образом не влияют на ее эффективность. Многие программисты, по-видимому, интуитивно пришли к пониманию этого факта и годами улучшают свою программу, делая ее всё более эффективной за счет уменьшения параметра Т2. Кстати, один из апологетов "Структурного программирования" [Д. Майерс] позволил себе следующее: "Никто, будучи в здравом уме и твердой памяти, не станет программировать на Ассемблере". И это по поводу любимого языка сторонников СВН! Напротив, изучение Ассемблера - это прекрасный путь к вершинам познания ОС ЕС ЭВМ. Следуя тим путем, вы получите массу полезных знаний, которые помогут решить вам ряд важнейших проблемм:

1. Как, получив талончик на одну минутку в пакете, захватить в безраздельное пользование CPU по крайней мере на 1.5. часа, устранить задачи всех других пользователей (например, с кодом S422), застопорить очередь заданий, лишить оператора возможности снять ваше задание, беспрепятственно получить результаты (не взирая на установленный лимит расхода бумаги), и при этом - все претензии операторской службы ОВТ направить в сторону какой-нибудь кафедры факультета "Ф"?
2. Как испортить (не стирая) все чужие НД на вашем пакете 5050/5061, не оставляя следов в PrintLog?
3. Как стереть ядро? (или IPL)

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

VI. Снова модульность
По-прежнему, никакой модульности! Поскольку модульность нельзя понимать иначе, как наличие известной встроенной функции, то всё остальное - от лукавого. Считайте себя хуже других, если вы не в состоянии написать программу (если хотите, назовите ее модулем) длиной более 1000 операторов. Если по ряду объективных причин (они есть всегда) вам все-таки приходится сталкиваться с проблемой стыковки, то помните об одном единственном правиле метода СВН: Никаких соглашений о связях! В особенности, если приходится иметь дело с программистами противоположного пола. Согласно статье 94 процессуального уголовного кодекса, при разборе дел об установлении отцовства протокол соглашения о связях учитывается наравне с доказательствами совместного ведения хозяйства. Кроме того, как уже подчеркивалось, любые ограничения вашей фантазии, как программиста, не принесут ничего, кроме снижения сроков разработки проекта и, тем самым, уменьшения эффективности конечного продукта. Порадуйте своего руководителя, повесив над рабочим столом плакат: "Программирование - слишком сложная интеллектуальная деятельность, чтобы можно было надеяться навязать ее узы административной системы, которая душит всякую инициативу" [Ван Тассел]. Если реакция руководства окажется более сдержанной, чем вы ожидали, перекрасьте дверь вашей лаборатории зеленой краской самого ядовитого цвета и исчезнете на три дня, предварительно отключив домашний телефон [Б.Майер, Бодуен].

VII. Отладка
Первая заповедь программиста, успешно преодолевшего барьер синтаксического контроля - не торопиться. Помните, что плохо отлаженная программа всегда менее эффективна, чем совсем не отлаженная. Не выводите на печать более одной переменной за один прогон. Полученные листинги (распечатки) немедленно уничтожайте (во избежание …! см. V). С другой стороны, полезно хранить в единственном экземпляре протокол компилятора с наихудшим (это несложно) качеством печати с тем, чтобы при незапланированном появлении руководителя можно было сказать: "Вот видите, в каких условиях приходится работать!" Разумеется, диагностические сообщения следует отрезать, а лучше - неаккуратно оборвать (для тех, кто программирует на Фортране или Ассемблере, рекомендуем приобрести некоторые навыки работы с ножницами и клеем).

Если вы храните исходный текст на НМД, то никогда не проверяйте карт IЕВUРDТЕ, и чтобы не лишать себя приятных неожиданностей! Более того, проверять пробивку - дурной тон и признак гнусного неуважения к милым и очаровательным девушкам, тратящим лучшие годы юности на пробивание дырок в ваших перфокартах. Когда заканчивается отладка, начинается эксплуатация! Ни один уважающий себя программист не допусти, чтобы его любимое чадо, плод его многолетних трудов и страданий эксплуатировали какие-то посторонние люди.

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

Удачи!

#11/ 09.05.00