Начало любого, более-менее сложного программного проекта похоже на проект архитектурный. Радуют глаз четкие линии, яркие акценты, равно и лёгкие многозначительные штрихи, за которыми угадывается будущее великолепие. Вслед за архитектором приходит конструктор, а затем строитель. Это они материализуют архитектурную мысль сначала в чертежи, а затем - в нечто осязаемое, вещественное. А вначале было слово...

   С программами же, всё и проще и сложнее одновременно. Здесь нет столь явной границы между проектом и воплощением, как в строительстве. Возможно поэтому, сложные программы имеют одно гнусное свойство: всё время норовят выскользнуть из-под контроля и попортить кровь своему создателю. Выглядит сие свойство досадно лишь с нашей, человеческой точки зрения, потому как человек сам переживает похожий этап в жизни. Подростковый возраст, помните? Бурный рост, руки-ноги внезапно выросли, а мозг еще не умеет обращаться со всем этим счастьем, неожиданно свалившимся на его голову. В крови такой коктейль гормонов, что на одном месте не усидишь. Кто хоть раз побывал в роли учителя, подтвердит: в подростковом классе амбре, как в спортивной раздевалке после тренировки. Ну и стремление к самостоятельности во всем, начиная от суждений и заканчивая поступками. Родители тоже в растерянности: еще вчера собственный ребенок был им знаком до кончиков волос. И вот пожалуйста: малознакомый, как им теперь кажется субъект, да еще с гонором.

   Я множество раз наблюдал у программистов нервозное и слегка пришибленное состояние, словно у родителей после очередной попытки поговорить по душам со своим акселератом-переростком. Вчера ещё все ладилось, спорилось, и вдруг... Нет, не вдруг. Это жареный петух прокукарекал неожиданно, но ситуация-то зрела постепенно. А у матушки-природы всё расписано, всё идёт, как по нотам: эмбрион ведь тоже кардинально перестраивается множество раз в процессе развития. Зато всё гармонично, какую стадию развития будущего организма не возьми.

   Был в моей практике такой интересный случай. Двум нашим внештатным разработчикам как-то была поставлена задача, которую они успешно реализовали. Потом задачка эта потребовала небольшого усовершенствования. И снова ребятам сопутствовал успех. Все остались довольны, включая заказчика, что случается, поверьте, не каждый день. Потом потребовалось дополнить продукт целым рядом расширений. Каждое из них в отдельности не представляло собой ничего эпохального. Самими разработчиками был озвучен вполне вменяемый срок: примерно три месяца. В общем, через четыре с половиной месяца двое нервных, издёрганных программистов показали обновленный продукт. Во-первых, результат был, мягко говоря, сырой. Во-вторых, они попросили еще месяц, чтобы закончить порученную работу. И снова сорвали срок, что не прибавило им оптимизма и уверенности в завтрашнем дне.

   А у заказчика выводов оказалось всего два: либо наши проверенные, надёжные разработчики - болваны те еще, или... В общем, представитель заказчика всё время норовил разобраться с исполнителями, наказать, оштрафовать. И его можно понять: срок реализации обновлённого продукта - существенная часть его планов и потраченные деньги. Не свои, кстати. Да только наказанием, какое бы оно ни было, лёгкое или суровое, ситуацию не исправишь. Философ, либо тот, кто получал образование в советские времена, по этому поводу сказал бы: произошёл переход количества в качество. Диалектика! И это правда, перед разработчиками возникла проблема смены масштаба, решить которую они не сумели. А и вправду, как быть в таком случае?

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

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

   Можно, например, привлечь к проекту новых людей. Хорошее решение, но делать это надо было заранее, поскольку свежий человек, каким бы способным он ни был, должен вникнуть в суть проекта. Для этого нужно время, которого к описанному моменту не хватает уже катастрофически. Можно подстраховаться: требовать от исполнителей писать подробные комментарии к своему коду. Всем же известно, что в хорошо написанной программе должно быть много комментариев. Враньё. Комментарии - это как запоздалые извинения. Звучат они примерно так. Дорогой друг! Мы должны были нанять вас еще два месяца назад, но у нас не было финансирования. Хотя на самом деле, это недобор. Фраза должна быть другой: простите, что обращаемся к вам, сами мы - не местные... Тфу, не так: заказчика одолел приступ жлобства, а переубедить его мы не смогли. И это правда, поскольку действенный аргумент здесь один - появление существенных рисков. Впору вспомнить народную мудрость: скупой платит дважды. Как раз про такой случай сказано. Вообще-то эта пословица лейтмотив всего риск-менеджмента. Или рискуй, или плати.

   Еще пара слов о наболевшем. Мне приходилось читать множество исходников. В самых лёгких для понимания, было по пять-десять строчек комментариев в самом начале файла. А код всё равно понятен! Возможно, не с первого раза, но вполне понятный! Попадались и такие, что аж в глазах рябило от витиеватостей текста, сопровождающего код. И чем больше читаешь, тем настойчивее одолевает подленькая мыслишка: чем чужое читать, легче самому написать.

   Вот еще один случай. Был у нас один очень грамотный разработчик. Владел великим множеством тонкостей программирования. Читать его исходники было одно удовольствие. Правда, лишь на самом раннем этапе работы над проектом. Чем дальше двигалась работа, тем острее возникало желание оторваться от чтения и дать ему в морду. Человек умудрялся на каждом ровном месте выстраивать иерархию классов, не иначе, как в стиле барокко. Если сравнить результат такого творчества с природой, представьте: в процессе развития эмбриона лёгкие не заменяют целиком жабры, а формируются, как своеобразная надстройка над ними.

   Его желание предусмотреть любую возможность развития проекта всякий раз приводило к точному попаданию пальцем в небо. Отточенный академизм и безудержная фантазия поражали воображение. Кристально чистый объектно-ориентированный подход к решению задач любой сложности в сочетании с завидной работоспособностью довольно быстро привёл нас к знакомству с мудрёным термином - рефакторинг. Говоря простыми словами, переделке тех самых нагромождений барокко-ориентированного кода. Если вы подумали, что после рефакторинга код становился проще и понятнее - вы большой оптимист.

   Мастерство, которое требуется от программиста, в проектах сложнее, чем студенческая лабораторная работа заключается отнюдь не в умении применять разнообразные конструкции языков программирования, и даже не в строгом следовании академическим парадигмам. Программисту нужен вкус художника, умение и решительность скульптора. Чтобы отсечь лишнее. Не помешал бы ещё дар предвидения, который есть суть способность видеть, слышать и делать выводы.

   Сколько же стоят подобные качества? Они бесценны. Здесь, как в двоичной логике: ноль и единица. Талант - что деньги: есть - есть, нет - нет. Слова эти принадлежат, кажется, Исааку Бабелю, писателю. Потому что успех программного продукта невозможен наполовину. Спросите у любого мало-мальски опытного инвестора, что хуже всего в больших проектах? Неопределенность. И преодолеть её может только специалист.