Ссылку на Хабровскую статью "Haskell в продакте: Отчёт менеджера проекта" нашел в ЖЖ ув.тов.grundik. В том же ЖЖ у меня состоялся очередной спор с тов.thesz. А уже в процессе спора оформились претензии к тексту Хабровской статьи, которые я решил оформить в виде отдельного поста.
Итак, изложенное ниже является не критикой использования Хаскеля. А критикой описания этого использования. Написанной с точки зрения человека, который имел отношение к управлению разработкой, формированию команд, выбору инструментов, выпуску релизов продуктов и получению/раздече пендалей после обнаружения проблем в запущенном в эксплуатацию софте. Именно этот опыт и позволил мне взять слово менеджер в кавычки в заголовке поста. Поскольку хабравская статья была явно написана не ПМом. Тим-лидом, может быть. Начальником отдела разработки, возможно. Но не ПМом. А именно ПМовского взгляда на произошедшее и не хватало.
Ну а теперь пойдем по-порядку.
Во-первых, в статье не указан объем и характер задачи, размер и состав проектной команды. Для чего применялся Хаскель? Для проекта, который в течении двух лет писала команда из 50 человек? Или для мелких утилит, которые три человека время от времени клепали по просьбе сисадминов? Какова важность этой разработки для компании? Насколько жесткие дедлайны для релизов? Каковы последствия от дефектов в ПО после его запуска в эксплуатацию?
Ничего этого в тексте статьи сказано не было. Какие-то намеки были сделаны в комментариях к ней. Но, только намеки. Поскольку я совершенно не в теме проблем управления группами серверов, то краткие упоминания названий задач мне ни о чем не говорят. Кроме того, если для получения этой информации нужно вычитывать срач в камментах на сотню сообщений, то это не есть правильно.
Во-вторых, в статье не говорится о целях, которые ставились перед новой разработкой на Хаскеле. Т.е. из статьи следует, что какую-то из ранее написанных на Питоне систему переписали на Хаскеле. Но зачем, почему? Это не праздные вопросы для ПМа и руководства. Ведь в предыдущую версию было вложено время и деньги компании. Сейчас требуется повторное вложение денег. Чем оно обосновывается? Были ли какие-нибудь альтернативы? Делались ли какие-то прикидки по срокам/трудозатратам различных вариантов (сопровождение версии на Питоне против разработки новой версии на Хаскеле)? Если делались, то какие еще параметры рассматривались в сравнении? Учитывались ли какие-нибудь риски и если да, то какие?
Если здесь попробовать сложить озвученные выше "во-первых" и "во-вторых", то версию о том, что на Хаскеле стали писать что-то большое и важное, можно отбросить сразу. Поскольку я не могу себе представить, как разработку, в которую было вложено, скажем, 100 человеколет (т.к. 2 года работы команды из 50 человек) просто так взяли и стали переписывать на Хаскеле. При всем моем скептическом отношении к профессионализму российских ТОП-менеджеров, я слабо себе представляю, как кто-нибудь из ТОП-ов пошел бы на перечеркивание предыдущих затрат и новые инвестиции в разработку в таком же объеме.
Следовательно, речь идет о неких мелких приложениях/утилитах, и совсем небольшой проектной команде. Косвенно подтверждение этому можно найти в комментариях, где приведены сравнительные размеры реализаций одного из приложений на Хаскель и Питоне: 212 против 263 строк.
Эта информация очень важна для руководителей проектов и проектных команд. Т.к. она позволяет таким читателям спроецировать опыт автора статьи на свою ситуацию. И если мне, скажем, нужно управлять разработкой компонента в 300KLOC то выводы из статьи я сделаю несколько другие, чем если бы мне приходилось управлять разработкой нескольких утилит, по 5KLOC каждая.
В-третьих, в статье не говорится не только о целях, которые преследовала новая разработка на Хаскеле, но ничего не сказано о том, что получилось в итоге. Были ли цели достигнуты? Результаты превысили все ожидания? Или же заявленных целей достичь не удалось вовсе?
Когда нет четкого представления о тех целях, которые руководитель разработки ставил перед командой, приведенный в статье перечень сравнений Хаскеля с другими языками/платформами, лично мной воспринимается не очень хорошо, с преобладанием нецензурных выражений :) Могу расписать это подробнее.
Скорость исполнения. Блин, кто в здравом уме будет сравнивать скорость исполнения компилирующегося в нативный код Хаскеля с Питоном?!!! В ваших задачах нужна производительность? Так с какого хера там Питон (да еще без C/C++ных вставок для самых ресурсоемких операций)? А если скорость работы ваших Питоновых компонентов вас устраивает, то зачем тогда приводить сравнение производительности с Хаскелем?
Про указанные в статье проблемы с многопоточностью Питона и его GIL-ом ничего сказать не могу. Имхо, тот, кто на языках вроде Питон или Руби начитает серьезно использовать многопоточность для увеличения производительности (нет, серьезно, производительности на Питоне/Руби?!), тот сам себе...
Отдельно доставила часть фразы "Быстрее Erlang/Java (и других vm-based языков)". Уровнять Эрланг и Джаву по производительности, это сильно.
Использование памяти. Вообще смешно. В качестве примера приводится потребление памяти написанным на C демоном -- 0.15Mb. При этом их устраивает расход памяти Питоновских и Хаскелевских демонов -- от 9 до 20Mb. Ребята, да вам расход памяти вообще пох! Зачем же вы об этом пишете?
Настоящие исполняемые файлы. Во-первых, у автора статьи по этому поводу, похоже, какой-то пунктик. Во-вторых, если бы это действительно было важно, дальше C/C++ у них бы дело никогда и не пошло бы. А так у них, похоже, и Джава, и Эрланг, и Питон жили, живут и будут жить без проблем. Значит нифига этот параметр не важен, вычеркиваем ;)
Качество кода. Тут какой-то детский сад. Сравнение динамической типизации со статической (да еще и очень строгой статической типизацией). Кто-то ожидал какого-то другого итога?
Вообще, когда якобы ПМ начинает говорить, что в выпущенном в продакшен Питоновском коде вылазят ошибки типизации или отсутствие обработки каких-то ситуаций, то этот ПМ сам расписывается в собственной неспособности управлять разработкой. Да, в языках с динамической типизацией есть такая особенность. ПМ этого не знал? Не знал того, что единственным способом борьбы с этим явлением является тестирование: unit-тесты в обязательном порядке (возможно с автоматическим контролем за процентом покрытия кода тестами), функциональное тестирование, прогоны на имитационных стендах. Плюс тестированием должна заниматься команда тестировщиков, независимая от команды разработчиков.
Не, тут меня занесло. Обычные ПМы, которые знакомы только с MS Project-ом и способны разве что сроки задач в диаграммах Ганта передвигать, а таковых в нерезиновой туева хуча, совершенно точно не будут знать об особенностях разработки на динамически типизированных языках программирования. Прошу прощения, мы тут в себя в провинции привыкли работать иначе, подотошнее, тащетельнее ;)
А где, интересно, количественные показатели изменения качества кода при переходе с Питона на Хаскель? Наверняка в разработке не использовались системы баг-трекинга, поэтому статистику по дефектам в Питоновском и Хаскелевском вариантах вряд ли можно вообще озвучить. Но вот хотя бы показатели количества строк в приложениях/библиотеках и тестах можно было представить. Мол, на Питоне столько-то строк прикладного кода и столько-то строк в тестах, а в Хаскеле столько-то и столько-то. Почему этих показателей нет? Сильно подозреваю потому, что как такового процесса тестирования не было организовано вовсе. И это прямая вина ПМа.
Тут, кстати, можно еще раз вернуться к теме причины перехода с Питона на Хаскель. Если одной из причин было количество дефектов в Питоновской версии, но нормального процесса тестирования не было, то это вина ПМа. И, следовательно, ПМ виноват в том, что компания еще раз тратит деньги на разработку того же самого, но на другой технологии.
Сложность сопровождения. Выше я уже задавал риторический вопрос об оценке рисков. Вот это и есть воплощение одного из рисков. "Поиск программистов является проблемой, как бы апологеты Хаскеля и не говорили об обратном. Даже вариант «переучить» является проблемой, потому что под функциональное программирование, особенно с «комонадами» и template haskell, нужно сильно мозги повернуть." Это ПМу проекта стало очевидно только в процессе разработки проекта? А до старта проекта это как-то учитывалось? И, что более важно, как эту проблему собираются решать в будущем?
Скорость разработки. Тут, признаюсь, я в сильном замешательстве. У меня сложилось впечатление, что проектом на Хаскеле занимались те же люди, что и проектом на Питоне. Т.е. не опытные Хаскель-разработчики. А раз так, то неизбежно должно было тратится время на накопление опыта, овладение инструментом, привыкание к несколько иным подходам к проектированию программ. Это не могло не сказаться на скорости разработки. Поэтому, с одной стороны, я не удивлен тому, что время разработке на Хаскеле не лучше, чем на Питоне (серебрянной пули нет и нет инструментов, которые бы увеличили скорость разработки на порядок). С другой стороны, явно в последующих разработках сроки должны быть лучше в пользу Хаскеля.
Если резюмировать, то у меня сложилось такое впечатление. Есть небольшая компания, в которой есть небольшая группа разработчиков, пишущих какие-то небольшие внутренние приблуды. Может групп разработчиков там больше, но конкретно та группа, которая занималась описанной в статье разработкой, маленькая, полагаю, 3-5 человек. Эта команда работает в довольно неформальной обстановке. У них прямое и неформализованное общение с бизнес-подразделениями, а так же с техническими службами/сисадминами. Задачи на разработку вряд ли формализуются в виде документов, заверяемых подписями представителей всех заинтересованных подразделений. Возможно, зачастую задачи спонтанно возникают в результате общения руководителя сисадминов с тим-лидом и кем-то из бизнеса. Какой-то более-менее "взрослый" процесс разработки проектов (со стадиями написания и согласования ТЗ, проектирования, реализации, документирования, тестирования, прохождения приемо-сдаточных испытаний) отсутствует как класс. Как отсутствует и использование соответствующего инструментария (Project, Bug-Tracking, Continous Integration, репозиторий документов). В принципе, для небольших сплоченных коллективов это нормально и естественно.
Так что если прочитавший данную статью ПМ или тим-лид работает в похожих условиях, то он может ожидать чего-то подобного и у себя, если его разработчики захотят использовать Хаскель. И главный недостаток статьи как раз в том, что для действующих или потенциальных руководителей программных проектов она дает слишком мало информации об реальных условиях и последствиях проведенного эксперимента.
Ну а начинающим программистам, в особенности, любителям Хаскеля, статья должна понравится. Ну как же, Хаскель был успешно применен в продакшене! :)
