…или размышления местечкового философа по мотивам RSDN-овских войн.
На протяжении нескольких лет я был активным участником RSDN-овских форумов. Последние года полтора я пытаюсь избавится от этой пагубной привычки, иногда даже с некоторыми положительными результатами. Но временами все-таки оказываюсь втянутым в очередную разборку. На днях влез в обсуждение совершенно феерического результата острого приступа графомании под претенциозным названием Кайрофобы vs отрасль.
Поскольку блог мой, то сдерживаться в своих оценках я не буду. Упомянутый “литературный труд” – фигня полная. Почему-то автор решил, что среди компьютерщиков количество кайрофобов больше, чем в других областях (кайрофобия – это боязнь новых ситуаций, незнакомого места). Но самое важное – автор утверждает, что именно окопавшиеся в индустрии кайрофобы являются главным тормозом прогресса отрасли. Некоторый закос под объективность. По ходу дискуссии автор отрицает факт обвинения кайрофобов в торможении прогресса. Хотя внятного краткого описания идеи своего длинного текста он так нигде и не привел. Поэтому я остаюсь при своем мнении.
Ну да не суть. Изначально был написан бред, по ходу обсуждения автор вообще повел себя как неспособный воспринимать критику непризнанный гений. Посему остается только убедится в правильности пословицы “не тронь говно – вонять не будет” и посоветовать вышеозначенный опус не читать.
Но по ходу обсуждения был затронут интересный вопрос о том, почему в области разработки ПО прогресс идет значительно медленнее, чем в области разработки аппаратной части компьютеров. Действительно, закон Мура до сих пор выполняется и количество транзисторов в процессорах продолжает удваиваться каждые полтора года. При сохранении очень низкого количества дефектов в результирующем изделии. Я не могу себе представить, чтобы в области разработки ПО, сравнимые по сложности и стоимости проекты развивались такими же темпами (т.е. чтобы количество строк в каком-либо программном продукте удваивалось через полтора года с сохранением минимального количества дефектов). Если бы это было возможно, то, к примеру, новые версии Windows выходили бы раз в полтора года, если не чаще. Естественно, все аналогии использованы здесь только для иллюстрации, но не в качестве доказательства.
Означает ли это, что в области разработки ПО прогресса вообще нет? Отнюдь. Прогресс есть. Но вот как его оценивать?
Если судить об информационном шуме, который регулярно поднимается вокруг чего-то нового или основательно подзабытого, то может сложиться впечатление, что прогресс существенен. Вот что я могу вспомнить из больших информационных всплесков за последние годы? .Net, Scala, Erlang, Ruby-on-Rails, SOAP и Web-сервисы, RESTful-сервисы, Domain Specific Languages, функциональное программирование и Haskell, multicore-процессоры. Лет пятнадцать назад были какие-то CASE-системы, 4GL, Пролог. Чуть позже – технологии клиент-сервер, потом Java, затем UML, XML, паттерны проектирования и экстремальное программирование.
Ну а если не брать рекламно-информационный шум, то что из всего этого реально сказалось на лично моей продуктивности? А одна очень маленькая и простая идейка из экстремального программирования: автоматизированные unit-тесты. Ну еще за уши можно притянуть более широкое использование константных данных (навеянное функциональным программированием), хотя оно и так в C++ имеет очень давние корни. Итого: за пятнадцать лет профессиональной деятельности программиста (и девятнадцатилетнего увлечения программированием) я столкнулся только с одним(!) реальным проявлением прогресса в области разработки ПО. Все остальное уже было придумано до того, как я вообще написал свою первую программу (ассемблер, языки высокого уровня, грамматики и принципы синтаксического разбора, структурное программирование, метапрограммирование, объектно-ориентированное программирование, функциональное программирование, оптимизированные компиляторы, сборка мусора, виртуальные машины и байт-код, интегрированные среды разработки, системы управления версиями, системы управления базами данных, …)!
Т.е. прогресс в области разработки идет, но идет не очень быстро. Хорошо, что идет. Впрочем, выбора у него все равно нет – хочешь, не хочешь, а идти придется :)
Ну а теперь начинаются, собственно, размышлизмы. Что нужно развивать для того, чтобы производительность программиста повышалась?
Первое направление самое простое. Именно оно и развивается все эти годы. И именно оно обеспечивает прогресс всей отрасли разработки ПО. Это – развитие инструментальных средств разработки. Всего спектра этих средств. Языки программирования (более выразительные и, в тоже время, более однозначные, легко поддающиеся верификации), компиляторы и линкеры, еще более умные IDE (для тех, кому собственных мозгов не хватает), системы тестирования, системы управления версиями и т.д. и т.п. Ни одно из этих средств не способно, на мой взгляд, дать прирост производительности больший 50% на широком спектре задач. Хотя, по совокупности, переход на более продвинутые и удобные инструменты, особенно сильно адаптированные под конкретные задачи, способно повысить “выхлоп” конкретного программиста в разы (но вряд ли на порядок).
А вот второе направление гораздо более важное и сложное. И здесь прогресс нужно выискивать, если не с микроскопом, то уж с увеличительным стеклом точно. Это – совершенствование мыслительных процессов программиста и его мотивации.
Почему это направление важнее первого? А потому, что по мере сокращения времени, уходящего на набор текста программы, его компиляцию и тестирование, доля времени, требующегося на проектирование, все время увеличивается. И это время, в количественном отношении, не уменьшается (насколько я могу судить). А не уменьшается оно потому, что мы, т.е. люди, не способны думать быстрее, чем мы можем. Когда нам попадается задача, нам требуется время на то, чтобы осознать эту задачу, обдумать разные варианты ее решения, представить сценарий ее воплощения в жизнь (в программном коде, наборе тестов и методике тестирования, проверочных сценариях и тестовых данных). Причем дефекты, допущенные и упущенные именно на этих стадиях разработки, являются самыми тяжелыми и дорогими в устранении. И я не знаю никаких действенных способов увеличения производительности труда на данной стадии кроме обучения.
Но и оно ничего не гарантирует. Т.к. в процессе проектирования программ в дело вступают различные особенности психики человека. Например, невнимательность или забывчивость. Приведу совсем свежий пример на эту тему. Последние две недели я занимаюсь проектированием некоторого программного продукта. Который, по моему замыслу, должен состоять из трех компонентов, два из которых называются inout_door и cp_service. Итак, после двух недель размышлений и набросков, я уже представлял себе, как inout_door и cp_service будут обмениваться между собой информацией, как inout_door будет взаимодействовать с внешним миром, что и как он будет хранить в своей оперативной БД, в каком режиме он будет работать. Уже даже были сделаны небольшие наброски интерфейса, за которым будут скрываться операции с БД. Фактически, я уже был готов начать кодирование inout_door. И вот тут я вдруг понял, что мной не был учтен один маловероятный, но все равно реальный и очень неприятный сценарий обмена данными между inout_door и cp_service. При котором часть данных будет потеряна. И эта потеря не будет должным образом обработана. Что приведет к генерации ошибочных отчетов в inout_door. Для устранения этой проблемы пришлось переработать и протокол обмена между inout_door с cp_service (вместо двухфазного он стал трехфазным), и состав информации в оперативной БД inout_door, и состав выполняемых inout_door действий.
А из-за чего такая ошибка была мной допущена? Фиг знает. Я думаю, что мне не хватило скрупулезности, чтобы сразу расписать все возможные сценарии обменов inout_door. А может и невнимательность – ведь сразу я почему-то этот проблемный случай не разглядел.
Так вот, данный пример, на мой взгляд, демонстрирует, что без каких-то улучшений мыслительных процессов программистов, прогресс в области разработки ПО будет медленным, т.к. он будет определяться исключительно техническими достижениями.
Еще во втором направлении развития я упомянул мотивацию. Это, что называется, из наболевшего. Поскольку в последние месяцы я занимаюсь проектами, которые лично мне не интересны. Но они нужны и важны. Плюс, успешная работа над ними премируется. Однако, я сам прекрасно чувствую, что будь я в них более заинтересован, то и скорость их выполнения, и их качество отличалось бы в лучшую сторону (уж не знаю насколько). Так вот, если бы методы мотивации разработчиков развились бы до такой степени, чтобы меня в моей нынешней ситуации очень сильно заинтересовать моими текущими проектами… Тогда бы прогресс в разработке ПО так же не заставил себя ждать :)
Наверное, есть еще и третье направление – это совершенствование средств и методов командной разработки. Поскольку, с увеличением количества разработчиков, объем времени, затрачиваемого на коммуникацию между ними, стремительно растет. Но здесь я пока полный профан, поэтому от комментирования воздержусь.
Вот как-то так.
Ну и небольшой бонус для тех, кто дочитал до этого места. В RSDN-овском флейме дали ссылку на электронную версию интересной книги Роберта Гласса “Факты и заблуждения профессионального программирования”.
Ну и еще напоследок :) Случайно попал в форум “Компьютерные священные войны” на RSDN. И увидел там совсем свежий, громадных размеров флейм на тему “За что я не люблю С++”. Просто офигел. Годы идут, а ничего не меняется :)) А говорят – прогресс, прогресс… ;)
