Серебряная пуля есть.
В прошлом номере журнала было опубликовано несколько историй о том, каких замечательных успехов удалось добиться в некоторых случаях путем применения функционального программирования. Сознаюсь, что слишком уж внимательно я эти истории не читал – вообще success stories жанр довольно типичный и, пожалуй, по единству своей структуры навевающий мысли не столько о computer science, сколько о «Морфологии волшебной сказки» Проппа. В самом деле, трудно найти что-то новое и увлекательное в очередном повествовании о том, что-де жила-была некоторая система, и всем она устраивала заказчиков, да только вот все равно плоха была. Быть плохой она могла быть по-разному, от недостатка производительности до совсем уже туманных и странных грехов типа «возможной затруднительности потенциальных модификаций в неожиданном направлении», но, так или иначе, приходили добры-молодцы-авторы и переписывали систему надлежащим образом. Переписывали, разумеется, чрезвычайно удачно, по крайней мере в представлении авторов статей – деваться некуда, таковы законы жанра. Гораздо более интересные истории о том, как не получались проекты, которые должны были получиться, встречаются гораздо реже – сходу могу вспомнить разве что нежно любимые «Старые платья императора» Хоара (или, наверное, Bitter EJB, прочитать который все никак не получается).
Обычно такие истории о радостном повержении змия приводятся для демонстрации чудодейственной силы пропагандируемых инструментов. Инструмент, в сущности, может быть любой – функциональные языки, как в предыдущем номере, какие-нибудь уникальные IDE, Java, Smalltalk, Python, Perl, PHP, COBOL – хотя последний лично мне не попадался, но, думаю, если посидеть в библиотеках, можно найти и великолепные образцы демонстрации его превосходства над, скажем, фортраном. Или наоборот. Интересно и то, что повергаемая в прах система может быть написана на чем угодно – на том же COBOL’е или на Erlang’e. Думаю, недолго осталось ждать рассказов о том, как Erlang был триумфально заменен OCaml’ом. Или OCaml Erlang’ом, что, в сущности, ничего не меняет. Собственно, все success stories инвариантны относительно инструмента – ему достаточно быть более-менее работоспособным.
Совсем необязательно эти инструменты могут быть языками программирования – есть методики, типа Agile или общие подходы – чтобы далеко не ходить, тот же функциональный, или столь популярный – объектно-ориентированный. Последний хоть и несколько сдал к настоящему времени, но все же продолжает оставаться наиболее чудодейственным.
Должен сказать, что изначально автор к описываем историям не питал особого интереса – все уже сто раз сказано и прочитано, но несколько позже меня в них заинтересовала пара аспектов, на которые авторы, словно сговорясь, практически никогда не обращали внимания. Первый – это то, что почти все удачные примеры применения всегда имели готовый прототип, который в общем более-менее устраивал, но по каким-то причинам не подходил, однако, повторюсь, в любом случае разработчики имели готовый образец и разумный минимум примечаний к нему: было понятно, что и как делать. Кроме того, в большинстве случаев разработчики новой версии были или разработчиками предыдущей, или по крайней мере опытными пользователями. Все, что им оставалось – это повторить готовую систему, избежав ее ошибок. Прямо скажем, нет ничего удивительного в том, что это получалось – было бы удивительно, если бы дело обстояло иначе. Надо сказать, что автор данной статьи и сам принимал участие не в одном проекте подобного рода. Что интересно, в одном случае в силу субъективных причин практически отсутствовал какой-либо контроль заказчика – все приходилось делать по образцу старой версии и обратить внимание на те места, которые, по опыту работы, оказывались наиболее неприятными, а сам автор, надо сказать, будучи руководителем проекта, несколько упустил задачи управления разработкой. Тем не менее, несмотря на посредственные качества имеющихся разработчиков, проект был сдан с минимальным опозданием, и в настоящее время успешно эксплуатируется (и автор при этом не делает выводов о необычайной всепобеждающей силе Perl’а и Oracle).
Итак, одним из факторов успеха является наличие готового образца и опыт работы с ним.
Другой фактор, надо сказать, самоочевиден – во всех случаях разработчики были ярыми сторонниками пропагандируемого ими инструмента, и, следовательно, владели или желали овладеть им на высоком уровне. Так, автор данной статьи имел многолетний опыт работы как с Oracle, так и с другими СУБД; собственный уровень знания Perl он тоже оценивает как высокий. В силу этого никаких проблем с использованием как одного, так и другого инструмента не возникало, а возникающие сложности у других разработчиков могли быть устранены в минимальное время.
И, наконец, третий фактор – единоначалие. Практически во всех случаях success stories замена платформы была связана с некоторым риском – то есть автор предложения всю ответственность брал на себя, то есть, прошу прощения за тавтологию, всегда было одно лицо или узкая группа, которое в случае неполадок было добровольно виновато во всем, как Чубайс. Современная практика с независимыми эксплуатационными группами, независимыми отделами Q&A, независимыми отделами разработчиков – да еще не одним! прекрасно подходит для размывания ответственности – разработчики всегда могут свалить ошибки в интерфейсе на Q&A, ошибки в демонах – на отдел администраторов или эксплуатационный, а те, в свою очередь, могут вдоволь винить во всем криворуких программистов. Тестирование не всегда возможно, а когда возможно, позволяет протестировать далеко не все случаи – тем более что тривиальные случаи прекрасно ловятся как самими разработчиками, так и Q&A. Нетривиальные не ловятся никем и в силу традиционной забюрократизированности исправляются крайне медленно, только если они не критические.
Применение популярных методик и технологий позволяет, кроме сваливания ответственности на другие отделы, сваливать и вину с себя – мы, дескать, применяем передовые технологии – сварку взрывом и сборку трезвым, то есть какие-нибудь Agile и Design Patterns, так что вопросом к нам быть не может и вообще разработка ПО – дело долгое и чреватое ошибками, сами знаете, так что все нормально. Наверное, в силу этого автор знает достаточно людей, пишущих на Java и не знает ни одного продукта на Java, которым бы кто-то добровольно пользовался в неслужебных целях.
Какие же выводы можно сделать из вышесказанного? Самые радужные: серебряная пуля есть. Вот она:
Хотелось бы отдельно рассмотреть эти пункты.
1. Необходимо иметь либо работающий макет приложения, который устраивает заказчика, либо глубоко разбираться в предметной области и знать, что же требуется, а еще лучше – и то, и другое.
При реализации какого-либо проекта с нуля обычно основной проблемой является неясность, невнятность осознания проблемы самим заказчиком или постановщиком задачи. С одной стороны, он является верховным судьей (кто платит – тот и заказывает музыку), с другой он обычно даже не осознает, чем он обладает и что ему требуется. В большинстве случаев (по всей видимости, автор иных не видел) все происходит на уровне, близком к маниловским мечтаниям – «хорошо бы поставить такой мост, чтобы на нем купцы сидели и всяким товаром торговали». Через что ставить мост, где брать купцов (а они будут брать товар), какой товар и кому они будут его продавать – неизвестно. Нередко бывает даже, что купцы есть, товар есть, покупатели есть, даже мост присутствует – да вот не продают на нем никакого товара. С одной стороны, почему не продают, с другой – а может, если по-хорошему, пусть и дальше не продают? Так, например, автор как-то интересовался, исходя из каких цен надо начислять комиссионные агенту – на момент проведения агентской операции или на момент заключения сделки – и не смог получить ответа! Менеджмент сам не имел внятного представления, как именно начисляются комиссионные.
Есть и проблемы иного рода: неудержимое творчество масс. Как говорил, кажется, Гоголь, «упаси Бог служить по научной части -- всякий лезет с советом, всякий хочет показать, что он тоже умный человек». Заказчик нередко имеет неудежимое стремление бесконечно переделывать жестами и голосом как внешний вид приложения, так и его логику, причем нередко в ситуациях, когда ни то, ни другое им самим толком не продумано. С одной стороны, если он оплачивает свое странное хобби – то и пусть с ним, с другой – необходимы постоянные обсуждения оплаты этих работ, и, наконец, с третьей – всегда можно ожидать претензий «вы столько долго колупаетесь и все еще ничего толком не сделано». Нередко бывает, что заказчик имеет свою идею-фикс, причем у каждого она своя, с завихреньицем – кто-то неровно дышит на гугло-карты, кто-то не видит своего существования без полнотекстового поиска, третий начинает и заканчивает обсуждения с вопросов выгрузки и загрузки в Excel, четвертый спит и видит интеграцию с 1C-Бухгалтерией, встроенный пасьянс или видеоролики об автозапчастях. Нередко все это является основной проблемой при разработке. Т.е. проблемы можно описать как:
В случае работающего прототипа или предшествующей версии все эти проблемы обычно снимаются – накапливается большой опыт работы, и заказчик обычно уже очень ясно
представляет, что же ему требуется.
Второй пункт – хорошее знание инструмента, который используется при реализации – на первый взгляд представляется чуть ли не самоочевидным. Это, разумеется, так, однако нередки случаи, когда при реализации какого-либо проекта приходится сталкиваться именно с незнанием и, более того, с нежеланием знать инструмент, которым приходится пользоваться. Так, например, автору в ходе дискуссий в блогах приходилось сталкиваться с утверждением о «кошмаре и ужасе сложных sql-запросов и непонятности подзапросов» и «совершенно непредсказуемых и безумных планах, выбираемых оптимизатором СУБД». С одной стороны, автору типичный запрос не кажется безумно сложным (а подзапросы – так вообще крайне простой сущностью), с другой – оптимизатор практически всегда, на его взгляд выбирал если не оптимальный, то по крайней мере обоснованный план. Понятно, что автор, в отличие от его оппонентов, инструментом владел. Не менее понятно, хотя и менее очевидно, что его оппоненты при реализации некоторых проектов инструментом не владели. Более того, некоторые из оппонентов делали, с точки зрения автора, совсем уж безумные вещи – например, чуть ли не разбор запроса и замена подзапросов на соединения. Это дополнительный код – то есть дополнительные сроки и дполнительные ошибки.
Как видно из вышеприведенного, ситуации, в ходе которых инструмент рассматривается не как инструмент-продолжение собственной руки, о котором при разработке просто не приходится задумываться, как автору, для которого русский является родным языком, не приходится задумываться о падежных согласованиях, а как нечто недружелюбное, сложное, опасное, непредсказуемое. Понятно, что владея (или, скорее не владея) инструментом на таком уровне не приходится ожидать сколько-нибудь впечатляющих результатов.
Наконец, третий пункт – единоначалие. Понятно, что должно быть одно ответственное лицо (или небольшая группа лиц). В реальности нередко оказывается так, что каждый реализует свой участок работ, совершенно не интересуясь тем, что производится на других, и основной своей задачей видит не качественную реализацию, а как бы поскорей спихнуть. Вместе с менеджментом, который нередко сам смутно представляет себе требования и, кроме того, занят вопросами политического и иного толка, это ведет к, скажем так, слабопрогнозируемым результатам.
Серебряная пуля есть. Она, пуля, оказалась композитной и состоит из трех частей., но, к сожалению, эта серебряная пуля – не то чудодейственное средство, которое дается даром: вышеприведенные выводы кажутся совершенно очевидными, но, к сожалению, большинство продолжает пытаться отыскать решение проблем преимущественно в применении чудодейственных средств.
