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

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

    Серебряная пуля есть. Она, пуля, оказалась композитной и состоит из трех частей., но, к сожалению, эта серебряная пуля – не то чудодейственное средство, которое дается даром: вышеприведенные выводы кажутся совершенно очевидными, но, к сожалению, большинство продолжает пытаться отыскать решение проблем преимущественно в применении чудодейственных средств.
    • 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 →
    Все так.
    Только мечтания не ноздревские, а маниловские.
    А, точно.
    Всё правильно. Зря не отправил.
    Так это ж практика любого успешного программирования. А не только функционального.

    Но какой слог, однако :)

    Deleted comment

    Да ФП тут вообще не причем и ПФП тоже. Основные проблемы - см. выше.
    Да, согласен по всем пунктам. Есть много других факторов, конечно, но написанное верно.
    >> продукта на Java, которым бы кто-то добровольно пользовался в неслужебных целях.

    yEd, CmapTools, PersonalBrain.

    Но вообще да, у меня тоже такое впечатление :)
    Eclipse? он вроде на яве написан.

    dph

    7 years ago

    alll

    7 years ago

    wizzard0

    7 years ago

    kika

    7 years ago

    plumqqz

    7 years ago

    alll

    7 years ago

    plumqqz

    7 years ago

    flammar

    6 years ago

    kmmbvnr

    7 years ago

    vitus_wagner

    6 years ago

    Я вот подумаю, подумаю, да к себе твой пост утащу. С комментариями. Потому что твоя "серебряная пуля" - она не только программазма касается, на самом деле.
    О это гениально.
    и не знает ни одного продукта на Java, которым бы кто-то добровольно пользовался в неслужебных целях.
    Какой-то там торрент-клиент, опять забыл как зовут :)
    Ну и JetBrains IDEA, хотя не знаю на сколько IDE можно вообще использовать в неслужебых целях. Но его выбирают вполне добровольно среди сонма других.

    tretiy3

    7 years ago

    Полно видел случаев, когда люди делали победные отчёты по применению совершенно незнакомых технологий. Так что "знающие" я б заменил на "умнее и мотивированнее обычных"

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

    Обладая соответствующими навыками - можно даже и по дохлому или вообще нереализованному, тут Вы абсолютно правы.
    Что, на джаве не пишут? Да вот откройте андроид. Там что ни апликашка, то джава. Откройте блакбери. Там вообще кроме джавы никакой язык не дозволяется.
    Да вот откройте андроид. Там что ни апликашка, то джава.

    У меня нет девайсов с андроидом (и не планируется).

    Откройте блакбери. Там вообще кроме джавы никакой язык не дозволяется.

    - А чего это у нас ослик лежит?
    - Мухоморов объелся.
    - А чего морда в крови?
    - Да есть не хотел.

    Замечательную Вы иллюстрацию подобрали, спасибо. Кстати, блекбери у меня тоже нет и тоже не планируется.

    d_m_

    7 years ago

    plumqqz

    7 years ago

    d_m_

    7 years ago

    plumqqz

    7 years ago

    wakes_up

    7 years ago

    juan_gandhi

    7 years ago

    Всё так
    По основным пунктам согласен (успешность инструмента определяется в первую очередь вменяемостью команды, которая этот инструмент использует).
    И слог хорош.

    Единственное с чем я не согласен, это что на Java всё-таки пишут и добровольно.
    Хотя лично я -- не пишу. И на Perl+Oracle не пишу. Но считаю их все хорошими инструментами. Которые вполне взаимозаменяемы с моими инструментами (SQL Server & .NET).
    С макетами часто плоха-плоха. В случае если заказчик не знает чего он хочет и если он согласен, то хорошо работает так называемая водопадная модель с постепенным наращиванием функционала в каждой версии. Но это требует от ПО легкость изменений и слабую связность иначе все плохо :)
    Обычно заказчик даже не знает, что он не знает. Водопадная модель - это, в общем, хорошо и правильно, но часто малореализуемо. ("Целый час мы репетируем. Ради этого я позволил изуродовать свой собственный сарай. И никакого толку.") Дать, скажем, супермаркет на недельку поотлаживаться довольно сложно.

    norguhtar

    7 years ago

    Есть еще такая вещь, как собственный фреймворк. Ощущение уверенности, т.к. свой. Если он давно заморожен и используется, то наверное так оно и есть. Но бывает, что он на момент постановки задачи еще не дописан. И это почти труба, как мне кажется, особенно если в добавок к прочему.
    А уж если там внутре свой ORM...

    flammar

    6 years ago

    На джаве есть еще опен-офис, которым пользуются многие, включая и меня.
    Я вас огорчу, но он прекрасно работает и без java :) И написан он не на java.

    blacklion

    7 years ago

    ionial

    7 years ago

    alexott

    7 years ago

    ionial

    7 years ago

    Anonymous

    7 years ago

    thedeemon

    7 years ago

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

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

    Собственно, даже удивительно, что вы Java в таком ключе упомянули -- ведь основной пойнт вашей записи как раз в том, что серебряная пуля software engineering не в конкретных технологиях, языках и т.д., а в (см. три пункта).
    Это же классическая дискуссия -- да, популярные десктопные Java-приложения можно по пальцам пересчитать, и половина из них ориентированы на программистов. Зато на серверной стороне вполне есть хорошие примеры популярных сервисов, которыми люди добровольно пользуются не в служебных целях.

    В богоспасаемом отечестве на жабе написан только один популярный веб-сервис - одноклассники. Есть еще мнение, что и яндекс-директ (но есть мнение, что жаба там постольку поскольку). Что касается бусурманских стран - судить не берусь.

    Зато жаба, как мне показалось - это удивительно удобный инструмент для занятий тырингом и спиздингом.

    svv

    7 years ago

    plumqqz

    7 years ago

    fantaseour

    7 years ago

    Deleted comment

    svv

    7 years ago

    Deleted comment

    flammar

    6 years ago

    Deleted comment

    flammar

    6 years ago

    Deleted comment

    plumqqz

    6 years ago

    Deleted comment

    ok_its_the_last

    7 years ago

    vitus_wagner

    7 years ago

    plumqqz

    7 years ago

    vitus_wagner

    7 years ago

    plumqqz

    7 years ago

    norguhtar

    7 years ago

    svv

    7 years ago

    "было бы неудивительно, если бы дело обстояло иначе" -> "было бы удивительно, если бы дело обстояло иначе"
    Спасибо за замечание, конечно же, Вы правы.

    svv

    7 years ago

    Какая хорошая статья, вах! С добротным таким, годным троллингом (а первейшее качество хорошего троллинга - это истинность содержащихся в нём утверждений).
    Троллинга-то нет. Общее место излагается. Некому спорить.
    хорошо!
    Давайте всё на Си писать или на Жабе.
    А почему не на старовавилонском?

    ok_its_the_last

    7 years ago

    plumqqz

    7 years ago

    rainman_rocks

    7 years ago

    ok_its_the_last

    7 years ago

    rainman_rocks

    7 years ago

    ok_its_the_last

    7 years ago

    rainman_rocks

    7 years ago

    alll

    7 years ago

    os80

    5 years ago

    отличный текст. напечатай-таки.
    Ну написали бы что виноваты заказчики и менеджмент, а программисту просто надо знать свой инструмент.
    Ну и хорошо разбираться в предметной области.

    Ну да, так оно и есть. Собственно, я в, так сказать, вступлении и привожу самоочевидность выводов как причину неотправки.

    beskov

    6 years ago

    > «кошмаре и ужасе сложных sql-запросов и непонятности подзапросов» и «совершенно непредсказуемых и безумных планах, выбираемых оптимизатором СУБД»
    ...
    Понятно, что автор, в отличие от его оппонентов, инструментом владел.


    Да оппоненты, разумеется, владеют инструментом не хуже "автора".
    Просто вы немножко переврали их слова.
    Никто не говорит, что ВСЕ запросы сложные или что планировщик ВСЕГДА чудит.
    Такие случаи просто случаются ИНОГДА. И этого тоже бывает вполне достаточно.

    Ну а тот факт, что поведение планировщика НЕЛЬЗЯ ГАРАНТИРОВАТЬ и в случае сложного запроса ТРУДНО ГАРАНТИРОВАННО ПРЕДСКАЗАТЬ ПРОИЗВОДИТЕЛЬНОСТЬ - он попросту неоспорим.
    Просто вы немножко переврали их слова.

    Приятно видеть человека, умеющего читать мысли по переписке. Одно только непонятно - если Вы умеете читать мысли, то почему решили, что это написано про Вас?

    rainman_rocks

    7 years ago

    plumqqz

    7 years ago

    rainman_rocks

    7 years ago

    plumqqz

    7 years ago

    rainman_rocks

    7 years ago

    > Наверное, в силу этого автор знает достаточно людей, пишущих на Java и не знает ни одного продукта на Java, которым бы кто-то добровольно пользовался в неслужебных целях.
    Я тебе сейчас цельный класс назову продуктов, где применяется Java и прочая ересь, типа ерланга - jabber-серверы. Из всего зверинца серверов где-то в дебрях jabber.org самые популярные, насколько я могу судить по интернетам - openfire (java), jabberd (с/с++), jabberd2 (новая генерация предыдущего, написано, наверно также на С/С++, я не проверял), ejabberd(Erlang).
    Сколько сталкивался в интернетах с вопросом выбора jabber-сервера, неважно, для каких целей: openfire, ejabberd, jabberd2 - примерно вот в таком порядке по убыванию популярности.
    http://xmpp.org/software/servers.shtml - список jabber-серверов, однако

    Bloatware

    norguhtar

    7 years ago

    plumqqz

    7 years ago

    Previous
    ← Ctrl ← Alt
    Next
    Ctrl → Alt →