Поговорим о программировании. Размышления бывшего программиста
Выдержки из писем — откликов на публикацию первой части «Размышлений»
Но хочу добавить к списку настольных книг, приведенному в статье, парочку своих, с которыми не расстаюсь на протяжении многих лет. Даже свою дочь заставил прочитать — и это ей помогло на экзаменах, хотя она учится по «некомпьютерной» специальности. Вот эти книги:
Гленфорд Майерс. Надежность программного обеспечения — М.: Мир, 1980.
Эдсжер Дейкстра. Дисциплина программирования — M.: Мир, 1978
Майерса я бы заставил изучать всех программистов в обязательном порядке даже сегодня. Что же касается Дейкстры (моего самого уважаемого патриарха), то эта маленькая книга — его непревзойденный шедевр. Она написана уже после того, как он изобрел параллельное программирование с семафорами, а затем структурное программирование. Это эссе представляет собой скорее поэтическое произведение, где Дейкстра свел программирование к трем командам и двум конструкциям, с помощью которых решаются исключительно сложные задачи. Кстати сказать, ни один современный язык программирования не дотягивает до «дейкстровской» модели «того» еще времени.
Справедливости ради следует отметить еще одно достижение, которое в статье я не заметил. Это — объектно-ориентированное программирование, вторая революция после структурного программирования. Если научиться мыслить категориями ООП, то можно добиться больших успехов в программировании, пример тому — современные разработки Microsoft (в отличие от Netscape).
Виталий Сизов, Эстония
Несколько последних лет в основном занимался коммерческими вопросами в компьютерной фирме. Но в последний год у меня появилась возможность вернуться к программированию, на сей раз в качестве руководителя ряда software-проектов и соответствующего отдела. Благо Интернет дал возможность организовать работу в режиме удаленной работы с теми, кто готов платить, — западными заказчиками.
Пришлось срочно наверстывать, смотреть, что же нового произошло и появилось за это время. Это, конечно, тема отдельного разговора, но, похоже, принципиально нового — почти ничего. Как говорят, все новое — это хорошо забытое старое, или точ
нее, развитие идет по спирали — так нас с Вами учили классики. Очень много «крутых» разговоров, надувания щек, а новых идей-то почти нет. Все упирается в инструментарий.
Даже «навороченные» среды разработчика — это в общем-то «продвинутые» инструменты, с родословной, восходящей к Borland TurboPascal. Java, c ее «переносимостью», корнями уходит в p-код Николаса Вирта, а ActiveX — красиво «запакованные» старые добрые подпрограммы2 и т.д. В общем, в основном это скорее маркетинг. В итоге, посмотрите любое резюме: люди гордятся знанием конкретного инструмента, а не умением решать задачу с помощью инструмента.
Но главное, на что мне хотелось бы обратить Ваше внимание: действительно, появившаяся новая психология нового поколения программистов.
Вспомните, как работали мы. Час в день (в лучшем случае) доступа к ЭВМ и остальные семь — подготовка к этому «счастливому мгновению». И просчитывались все варианты, последствия, побочные эффекты и т.д. В итоге у этого поколения сформировалась идеология «сначала думай, потом делай».
Для тех же, кто начал программировать в конце 80-х и сразу на PC и постоянно имел «полный» доступ к компьютеру, гораздо проще было сначала попробовать, а затем посмотреть, что же получилось. Это сформировало их стиль работы. Так они (как правило) работают, и менять этот стиль им очень трудно.
Нельзя сказать, что второй вариант лучше или хуже первого: они разные. И в различных ситуациях каждый из них может оказаться лучшим. Например, в малых программистских группах (два-три человека), для малых программ, в случае когда скорость выполнения работы превыше всего, второй стиль явно превосходит первый. Но попробуйте его применить при создании действительно сложных программных комплексов, при работе большой группы разработчиков и т.д.!
Как правило, в коллективе действительно нужны люди обоих стилей. Одни — для того, что бы работать в роли «ледокола», быстро и «начерно» решать задачи. Другие — для скрупулезной доводки программного продукта. Более того, я заметил (не только у нас, но и на примере нескольких западных софтверных компаний), что успех разработки, как правило, там, где руководитель проекта работает (либо изначально, либо сумев перестроиться) именно по принципу «сначала думай, потом делай». Почему так? Думаю, потому, что такой стиль переносит основной аспект на методологию, а не на технологию, учит программированию как творческой активности, а не как ремеслу.
К сожалению, внимательно присмотревшись к рынку литературы и Интернет-источникам, я так и не смог найти практически ничего, что учило бы именно программированию, а не использованию конкретных средств. Я думаю, что цикл статей, который вы анонсировали, мог бы хоть как-то восполнить этот пробел. Поэтому удачи Вам в вашем начинании.
С уважением, Дмитрий Шарадкин,
RQL-Украина, коммерческий директор
Я начал работать программистом в 1987 году, трудился в НИЦЭВТ, позже в компании — разработчике систем автоматизации масштаба предприятия. Всегда старался соблюсти золотую середину между теоретической основой и практическими навыками. Языков старался не менять без надобности и без необходимости не прыгать туда-сюда.
Сейчас наш коллектив заканчивает один из проектов B2C3 на базе ASP, что для меня как в прошлом Си-программиста с точки зрения технической было просто, но с психологической — совсем наоборот. Неожиданно для меня оказалось, что ребята, которые моложе меня лет на десять, абсолютно не знают теории, совсем как в вашем примере о программисте из Риги, хотя есть ребята не только с высшим образованием, но и аспиранты.
Как раз за неделю до получения журнала с вашей статьей у нас была дискуссия практически по всем пунктам статьи на вкладке. Я был как упомянутый здесь «суперпрограммист», который больше мешает, чем помогает своими знаниями, хотя, конечно, это все несколько утрировано.
С уважением, Вадим Уваров