Учебное пособие по курсу «Технология программирования»
| Вид материала | Учебное пособие |
- Курсовой проект по курсу «Технология программирования», 147.33kb.
- Учебное пособие для студентов специальности 260202 «Технология хлеба, кондитерских, 1941.61kb.
- О. М. Мышалова общая технология мясной отрасли учебное пособие, 1355.07kb.
- Учебное пособие Иркутск 2006 Рецензент, 2159.1kb.
- Учебное пособие Иркутск 2006 Рецензент, 2160.36kb.
- Учебное пособие Кемерово 2004 удк, 1366.77kb.
- Учебное пособие Тамбов 2009 удк 339. 138, 1882.57kb.
- А. Ю. Просеков С. Ю. Юрьева технология молочных продуктов детского питания учебное, 4980.6kb.
- А. Н. Петров А. Г. Галстян А. Ю. Просеков С. Ю. Юрьева технология продуктов детского, 2728.08kb.
- Учебное пособие Йошкар-Ола, 2008 ббк п6 удк 631. 145+636: 612. 014., 7797.37kb.
Введение
Учебное пособие по курсу «Технология программирования» написано на основе одноимённого курса лекций читаемых автором в Ухтинском Государственном Техническом Университете. Следует отметить, что, несмотря на огромное количество книг по программированию, руководства посвящённого именно технологии программирования нет. С одной стороны, элементы курса есть в любой программисткой литературе, с другой стороны, множество вопросов, взаимосвязей и особенностей программирования именно в свете технологии нигде не освещается и каждый программист по мере развития вновь находит всё множество приёмов и методов. Это хорошо, когда он попал в крепкую команду программистов, где есть чему и у кого учиться, но гораздо чаще, начинающий специалист оказывается в положении человека обучаемого плаванию «методом бросания в холодную воду».
Всякий, кто пытался на Basic реализовать серьёзную задачу, а не одноразовую программу, понимает к чему приводит подобное обучение.
Технология появляется тогда, когда появляется производство. Производство находится где-то между искусством и ремеслом. Ремесло не обладает технологией в силу ограниченности решаемых задач, хотя имеет множество способов и приёмов. Искусство не обладает технологией в силу уникальности каждой решаемой задачи, а потому набор способов и методов решения поставленной задачи часто точно также уникален и малоприменим, нередко совершенно не применим, при решении другой задачи. Однако, в искусстве там, где оно смыкается с наукой, происходит появление и оттачивание новых технологий и в этом смысле искусство стоит на плечах технологии производства.
Для большинства термин «производство программ» (программного обеспечения) звучит достаточно дико, хотя никто не возражает против «производства кино», например. Тем не менее, существует процесс производства программ. Автор ещё раз подчёркивает, что это именно производство. Раз существует процесс производства, то существует и его технология. Таким образом, «технология программирования» изучает методы, способы, приемы, используемые при производстве программ или программного обеспечения. Можно и по-другому: технология программирования изучает процесс производства программного обеспечения.
Таким образом, к производству программ применимо множество производственных терминов таких, как трудоёмкость и производительность труда, технические, стоимостные и человеческие ресурсы и т.д. Но в программировании содержание этих терминов, их значения, выраженные в числах, существенно зависят от такого ресурса как личность программиста. Все курсы программирования, в силу того, что это именно курсы программирования, не рассматривают программиста, как существенное звено, при написании программ. Иначе и быть не может, поскольку это вопросы технологии программирования. Только в технологии программирования могут быть рассмотрены вопросы влияния тех или иных ресурсов на конечный результат программирования – программу.
У вдумчивого программиста уже при изучении программирования возникает много вопросов: почему это сделано именно так, а не иначе? Можно ли выполнить это по другому и к чему это приведёт? Большинство подобных вопросов рассматриваются в технологии производства. Можно ли в одиночку реализовать большой комплекс программного обеспечения? Можно! (?) К чему это приведёт? Чем отличается подобный комплекс от комплекса ПО реализованного коллективом программистов? Случайны ли эти отличия или так неотвратимо будет всегда? С одной стороны, ответ лежит на поверхности: все знают отличия кустарного продукта от промышленного. С другой стороны, любому специалисту приходится делать выбор между собственной реализацией поставленной проблемы и приобретением готового программного продукта. Заметим, что окончательный ответ на этот вопрос лежит скорее в области этики программирования, а не технологии, однако, ответы на многие вопросы этики программиста тесно связаны с технологией программирования.
За время своего существования, шестидесятые годы XX века – начало XXI века, программирование сильно изменилось. Автор имеет в своём активе программу, написанную в коде ЭВМ «Минск-22». Сравните программирование в коде с программированием в Visual C++ (или C++ Builder) под Windows. Так ли существенно изменилась сама методология программирования? Неужели автору приходилось учиться «с нуля» каждые десять лет? Если все эти вопросы рассмотреть в контексте технологии программирования, то мы с удивлением обнаружим, что сама основа, распределение в памяти машины и на внешних устройствах ЭВМ команд и данных, осталась, хотя теперь, средний программист стоит значительно дальше от этого процесса, чем раньше. Такая отстранённость программиста от процесса «технической сборки программы» создаёт иллюзию ненужности знания «технических деталей», не говоря уже о понимании сути происходящего. Автор достаточно далёк от позиции обязательного требования досконального знания всех технических деталей. Сегодня это вряд ли возможно. Это в добрые семидесятые прошлого века программисты могли позволить себе быть универсалами. Однако, автор считает, что только понимание сути процесса создания программы позволяет «не знать» некоторых технических деталей. Процесс же изучается только в технологии и нигде более.
Вообще в программировании на сегодня (начало XXI века) сложилась парадоксальная ситуация. Само по себе программирование стало существенно сложнее (ООП – объектно-ориентированное программирование и многокомпонентное программирование), но, благодаря визуальным средствам программирования (а они приходят и в Unix), создалась иллюзия простоты и доступности. Подобная ситуация приводит к широкому появлению «эникейщиков» (press any key) и «программистов», работающих на уровне чуда! Частично такая ситуация создалась стараниями рекламных агентств, представляющих продаваемое ПО, частично фирмами его производящих, сознательно полностью не документирующих производимое ПО. Но в основном, ситуация сложилась стараниями самих программистов предельно упрощающих себе работу и перекладывающих рутинные функции на машину. Увы, прогресс имеет и оборотную сторону. С одной стороны, программист пишет машинно-независимую программу, но с другой стороны, он становится дальше от машины. С одной стороны, программист мыслит в терминах объектов, их свойств и методов, с другой стороны, его программа становится более длинной и менее оптимальной. За всё надо чем-то платить.
Грамотный программист ясно представляет издержки новых операционных систем и методов программирования. Он понимает, что программа, написанная в парадигме ООП может быть более длинной и возможно менее оптимальной, чем обычная процедурная программа, но сдаст программист такую программу значительно быстрее, да и отладит лучше. К тому же, как оказывается, пользуясь ООП можно отлаживать значительно более длинные программы, чем при обычном процедурном программировании. Вот это «быстрее и лучше» и определяет появление новых методов в программировании. Если новшество увеличивает производительность труда программиста, то оно останется, как бы и кем бы оно ни было охаяно. Время – самый дорогой ресурс в программировании.
Всё развитие технологии программирования можно и нужно рассматривать с точки зрения увеличения производительности труда, как отдельных программистов, так и коллективов программистов. Только тогда, когда происходило увеличение производительности труда, новые методы вытесняли старые. Не следует забывать, что увеличивать можно производительность труда, как программиста, так и пользователя. Последнее сделал купец Билл Гейтс, выпустив свой Office и Windows. Теперь, как бы ни ругали программисты Windows и Office, но фактическим стандартом у чиновников является Word, Excel и Windows. Можно, конечно, ссылаться на безграмотность чиновников (в программировании), но отрицать увеличение производительности труда чиновника невозможно. От себя заметим, что плохо не то, что Microsoft выпустила вышеуказанные продукты, плохо то, что Билл Гейтс их начал продавать полусырыми. Кстати, почти одновременно с указанными событиями в машиностроительном и проектном черчении прошло победное шествие такой программы как AutoCad фирмы AutoDesk и, заметьте, почти полное отсутствие нареканий!
Автор считает, что для студента второкурсника технология программирования трудный предмет. Как правило, у студента нет ни одного реализованного проекта, понимание сути программирования либо отсутствует, либо ещё неразвито. Поэтому многие утверждения и понятия технологии для студента второкурсника достаточно абстрактны. Как это ни парадоксально, но именно технологию программирования, предмет, наполненный эмпирикой, студенты воспринимают как нечто оторванное от жизни. Многие требования технологии совершенно непонятны, тем более, что современные средства программирования позволяют всё делать как раз наоборот. Конечно, лучше всего читать технологию на четвёртом курсе, когда у нормального студента за спиной три – четыре курсовых проекта. На всё это автор напоминает старую истину: «Умные люди учатся на ошибках других». Безусловно, мы сделаем не одну свою ошибку, но давайте стремится следовать этому утверждению.
Существует и прямо противоположное заблуждение: рассматривать технологию программирования как некий свод волшебных правил и заклинаний, применив которые любой получит работоспособную программу. Увы. В математике, литературе, программировании, да и вообще в любой отрасли, конечно же, существуют свои методы и приёмы, а также условия их применения. Достаточно открыть, например, книгу Д.Пойа “Математическое открытие” (1978г.). Однако, прочитав эту замечательную книгу, мы не увидим в ней рецепта математического открытия, по той простой причине, что такого рецепта не существует в реальности. Нет волшебных пассов, слов заклинаний или приёмов позволяющих делать математические открытия. Точно также нет их и в программировании. Какие методы и приёмы использовать при написании конкретной программы решает такой неформализованный ресурс, как программист. Только от его знаний, умения, предпочтений и способностей зависят характеристики программы. Методы технологии могут существенно облегчить и ускорить разработку программы, но сами по себе эти методы не приводят к появлению «правильных» программ.
Автор предполагает, что студент уже знает хотя бы один язык программирования и умеет писать на нём, пусть небольшие, но работающие программы. Невозможно давать технологию программирования без связи с конкретными языками. Наибольшее число ссылок приведено на языках “C” и “C++”. Во-первых, эти языки, де-факто, стали стандартом. Во-вторых, наиболее последовательно идеи объектно-ориентированного программирования (ООП) проводятся именно в “C++”, а без ООП нет совремённой технологии.
В завершении может быть сделана только одна рекомендация:
программист – программируй!
Ничего не может заменить собственного опыта. Но если этот опыт не будет обдуман, пропущен через призму теории, то он не даст новых знаний и понимания. Такой опыт скорее есть набор ремесленных способов и приёмчиков, где уж тут говорить о производстве.