Osteolaemus tetraspis (plumqqz) wrote,
Osteolaemus tetraspis
plumqqz

Серебряная пуля есть

Как-то не так давно (но и не так уж недавно) меня просили что-то написать в нашумевший журнал Вопросы разведения коз зааненской породы "Практика функционального программирования". Я это что-то написал, но так как написанное лично у меня вызывало стойкие ассоциации с пионерским детством, когда буквально все - от происков мирового империализма на Гренаде до исследований Венеры автоматическими станциями имело следствие в том, что нам, пионерам, в первую очередь необходимо хорошо учиться и слушаться старших, то отправлять я ее туда не стал. Однако ж не пропадать же добру? Пусть тут будет.

Серебряная пуля есть.



В прошлом номере журнала было опубликовано несколько историй о том, каких замечательных успехов удалось добиться в некоторых случаях путем применения функционального программирования. Сознаюсь, что слишком уж внимательно я эти истории не читал – вообще 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-запросов и непонятности подзапросов» и «совершенно непредсказуемых и безумных планах, выбираемых оптимизатором СУБД». С одной стороны, автору типичный запрос не кажется безумно сложным (а подзапросы – так вообще крайне простой сущностью), с другой – оптимизатор практически всегда, на его взгляд выбирал если не оптимальный, то по крайней мере обоснованный план. Понятно, что автор, в отличие от его оппонентов, инструментом владел. Не менее понятно, хотя и менее очевидно, что его оппоненты при реализации некоторых проектов инструментом не владели. Более того, некоторые из оппонентов делали, с точки зрения автора, совсем уж безумные вещи – например, чуть ли не разбор запроса и замена подзапросов на соединения. Это дополнительный код – то есть дополнительные сроки и дполнительные ошибки.
    Как видно из вышеприведенного, ситуации, в ходе которых инструмент рассматривается не как инструмент-продолжение собственной руки, о котором при разработке просто не приходится задумываться, как автору, для которого русский является родным языком, не приходится задумываться о падежных согласованиях, а как нечто недружелюбное, сложное, опасное, непредсказуемое. Понятно, что владея (или, скорее не владея) инструментом на таком уровне не приходится ожидать сколько-нибудь впечатляющих результатов.

    Наконец, третий пункт – единоначалие. Понятно, что должно быть одно ответственное лицо (или небольшая группа лиц). В реальности нередко оказывается так, что каждый реализует свой участок работ, совершенно не интересуясь тем, что производится на других, и основной своей задачей видит не качественную реализацию, а как бы поскорей спихнуть. Вместе с менеджментом, который нередко сам смутно представляет себе требования и, кроме того, занят вопросами политического и иного толка, это ведет к, скажем так, слабопрогнозируемым результатам.

    Серебряная пуля есть. Она, пуля, оказалась композитной и состоит из трех частей., но, к сожалению, эта серебряная пуля – не то чудодейственное средство, которое дается даром: вышеприведенные выводы кажутся совершенно очевидными, но, к сожалению, большинство продолжает пытаться отыскать решение проблем преимущественно в применении чудодейственных средств.
  • Subscribe
    • Post a new comment

      Error

      Anonymous comments are disabled in this journal

      default userpic

      Your reply will be screened

    • 131 comments
    Previous
    ← Ctrl ← Alt
    Next
    Ctrl → Alt →
    Previous
    ← Ctrl ← Alt
    Next
    Ctrl → Alt →