2013-12-03
О таком нидерландском учёном, как Эдсгер Вибе Дейкстра, в русскоязычном интернет-пространстве незаслуженно забывают. Кое-кто из олдфагов, может быть, вспомнит, что он работал над Алголом, у него были непростые отношения с GOTO, и, наверное, кое-что знают об одноимённом алгоритме Дейкстра. Но мало кто знает, что он был и прекрасным публицистом, отстаивал научно-инженерный, а не прикладной подход к программированию. Это он выступал против традиционного подхода к написанию программ: «написать — протестировать — найти ошибки — исправить — протестировать — …», и здравствуй, бесконечный цикл. Это он настаивал на том, что программирование — это стройный математический процесс.
Для вас мы прилагаем достаточно вольное изложение одной из его рукописей под названием «Методология программирования, её цели и особенности». Вольное просто потому, что формат нашего ресурса не предполагает размещение крупных материалов, поэтому пришлось многое сократить. Однако, мы надеемся, что прочтение отрывка заставит вас прочитать и другие рукописи этого замечательного человека.
Давным-давно я побывал в крупной компании по производству ПО с выступлением о возможных техниках верификации программ. Выступление прошло ужасно. Аудитория не понимала тему моего выступления по тем причинам, которые они называли бизнес-подходом: с деловой точки зрения правильно написанное ПО оказалось для них совсем неважным. Для них гораздо важнее было сделать пользователя зависимым от плохо задокументированной продукции, полной ошибок — чтобы с ними заключили контракт на обслуживание.
Что удивительно, не только менеджеры той компании не поняли моей темы: программисты тоже. Они чувствовали, что я хочу лишить их дело романтической и волшебной ауры. Если я убеждал их в том, что программист обязан думать над каждым своим действием, они мне говорили о том, что профессиональный программист получает интеллектуальное удовлетворение от того, что он НЕ СОВСЕМ понимает, что он делает; что он вторгается в нечто непознанное, а там уж будь что будет… Они хотели, чтобы их ремесло оставалось чёрной магией.
Сперва я объяснил себе этот феномен тем, что стремление к неким магическим ритуалам — это бессознательная потребность человека в стремительно развивающемся современном мире. Однако потом, поразмыслив, я понял, что есть и другая причина.
Веками знания и навыки передавались от поколения к поколению двумя способами.
Первый — это различные «профессиональные гильдии» (артели, ремесленнические цеха, союзы, общины): те места, где подмастерье годами работает под надзором мастера, который передаёт ученику знания повседневно, интуитивно, бессистемно, — и так до тех пор, пока ученик не впитает в себя количество знаний, достаточное для того, чтобы самому стать мастеру. В таких профессиональных гильдиях знаниями обладали только участники, и хранились в секрете от внешнего мира.
Второй способ — это образование: то, с которым мы сталкиваемся в учебных заведениях. Здесь учителя стараются доставить знания напрямую, облекая их в форму слов и символов, а также сделать знания общественно доступными. Неудивительно, что рост количества образовательных учреждений совпал с возникновением книгопечатания.
Что происходит, когда мир гильдий сталкивается с миром университетов?
Когда участники образовательной системы пытаются сделать знаниями доступными широкой общественности, участники гильдий чувствуют нависшую угрозу. Как же? Их секретные знания хотят разгласить всем! Это же преступление!
Я понял, что именно это чувство возникало у тех программистов, которые не хотели меня слушать.
К счастью, мир состоит не только из этих программистов. Так называемый «кризис области разработки» стал настолько очевидным, что все участники процесса — и менеджеры, и программисты, — чувствуют, что давно пора что-то менять. Нам пора переходить от профессиональных гильдий к открытому образованию.
Долгое время в кризисе разработки винили менеджмент. Это можно понять: чем крупнее проект, тем больше в него вовлекается менеджеров. А какие проекты привлекают больше внимания? Конечно, крупные. Мы просто потеряли из вида значимую статистическую выборку из малых и средних проектов. Кроме того, многие были впечатлены космическими успехами США, которые, на первый взгляд, убедительно доказывают, что идеальным управлением можно достичь любой цели.
Так и родилась идея о том, что усовершенствованные инструменты управления решат все проблемы.
А потом оказалось, что техники, применяющиеся в традиционном менеджменте, абсолютно неприменимы к управлению проектами по созданию ПО. Возьмём простой пример: когда-то считалось, что продуктивность программиста можно измерить количеством строк кода, которые он пишет за день. А что? Работа программиста — это писать программы. Чем больше программ он напишет, тем он продуктивней, разве нет? Через некоторое время выяснилось, что задача программиста вовсе не в том, чтобы писать программы. Работа программиста состоит в поиске решений, а та программа, которую он пишет – лишь инструмент для реализации этого решения, и чем больше ненужных строк в его программе, тем хуже само решение. Количество строк кода как единица измерения продуктивности лишь стимулировало возникновение всё новых и новых дурных решений.
Сейчас действует золотое правило: «Не спеши приступать к написанию кода!». Сегодня каждый программист, работающий над проектом, будет долго обдумывать и согласовывать решения и алгоритмы, и вряд ли приступит к написанию программы без разрешения сверху.
И вновь всех ждало разочарование. Лучшие техники и методологии управления из существующих не смогли компенсировать другие недостатки. Если нам понятно, что без контроля качества невозможно выпустить хорошие продукты, так же должно быть понятно, что никакой контроль не может гарантировать качество продуктов, если мы неспособны их сделать в принципе. Именно тогда, когда люди задумались о программистских способностях, начали говорить о Методологии Программирования (да, именно так, два слова с большой буквы).
Нас стали волновать вопросы: «Почему программирование — это трудно?», «Как мы можем облегчить этот процесс?».
Нам пришлось обратить внимание на сам процесс программирования. Причин этому было несколько. Одна из самых значимых причин — всё более бросающаяся в глаза неэффективность дебаггинга. Более 50% времени люди проводят за поиском ошибок в программах, и всё равно на выходе мы получаем продукты с ошибками.
Возможно, стоит уделять больше внимания профилактике, а не лечению? Идти не по пути поиска ошибок, а по пути предварительной минимизации их наличия?
Это очень важный момент. Недостаточно просто создать программу, которая, как мы надеемся, удовлетворит всем требованиям. Нужно создавать такую программу, эффективность которой нам будет легко продемонстрировать. Программа должна строиться на предельно стройных математических алгоритмах, формально доказать которые будет очень просто.
С начала 60-х гг. прошлого века я участвовал во многих спорах об изящности программ, о средствах языков программирования и прочих дискуссиях, который возникали только по одной причине: не было в программировании ни одного общепринятого ориентира. Как только мы выбрали в качестве ориентира формальное доказательство корректности программы, сразу стали вырисовываться методологические подходы, специфические именно для программирования.
Скромная голова программиста не может обрабатывать огромное количество последовательностей, а также весьма ограничена в многозадачности. По этой причине действует принцип «Разделяй и властвуй»: когда логически и последовательно рассматриваются коммиты, когда абстрактными задачами занимаются не все сразу, когда задачи распределяются внутри команды.
Развитие методологий программирования — это нечто большее, чем просто стремление стать более компетентным программистом. Методология программирования — это и способность решать проблемы, и эффективное распоряжение ментальными ресурсами.
Возможно ли научиться этому? Способности манипулировать с числами мы учимся на многих уровнях: на уроках арифметики, потом алгебры, потом на парах по математическому анализу. Теперь нам было бы неплохо научиться не генерировать в своей голове лишние данные, которые нам потом придётся обрабатывать.
Конечно, здесь не поможет какой-нибудь курс «Как научиться мыслить за 10 простых уроков». Но кое-что мы можем сделать.
Во-первых, нужно самим учиться снижать количество ненужной мыслительной деятельности, отсекать лишнюю информацию, и, соответственно, освобождать себя от необходимости далее с ней работать.
Во-вторых, нам нужно научиться определять цели нашей деятельности, и в соответствии с ними ставить себе задачи. Не практиковаться наугад. Осмыслять свои действия. В конце концов, мы работаем с алгоритмами. Мы разговариваем с машиной, но не можем поговорить сами с собой и с другими людьми, полагаясь на какую-то мифическую магию.
Этому нужно учить в институтах. Студентам нужна практика и противостояние (то есть альтернативные варианты). Пусть студент четыре часа возится над созданием своей двухстраничной программы; ваша задача — показать ему потом решение той же задачи из восьми строк, которое можно написать за 15 минут. Если ему в институте не показать, как это делается, в реальной жизни он может потратить на решение годы. И очень редко вам встретится тот, кто сразу набросает вам эти 8 строк. Он потом и станет Сэнсэем.
Рукопись датируется 1969 г. Думаю, вы обратили внимание на прогрессивность мышления. Многие современные методологии управления проектами разработки базируются именно на его исследованиях и подходах.
Если вам интересно, существующие переводы некоторых рукописей Дейкстры можете почитать здесь.
Автор: Люся Ширшова.
