nekhill

философия, дайвинг и программирование

Previous Entry Share Next Entry
Размышления об изобретении велосипедов
nekhill


Однажды я услышал или прочитал замечательное высказывание: "Плохой стандарт лучше, чем свой". В очередной раз задумался над этим высказыванием в свете поддержки xml в MS SQL Server.

Вот смотрите. Когда xml только начинали использовать, многие программисты могли посчитать его "слишком длинным", "слишком многословным" и т.п. и продолжать использовать свою родную проприетарную бинарщину, csv-щину, whatever. Ну да, в некоторых случаях xml теперь заменяют на json как раз из-за многословности (ну и удобства разбора, например). Но вот представьте: вы когда-то перешли на xml и используете для хранения xml-ей MS SQL Server. Тут вам и индексы по xml, и всяко-разная довольно эффективная манипуляция xml-ем в запросах, и куча всяких разных других плюшек. Включая заведомо готовые транзакционность, многопоточность, кучу способов доступа, разделение прав, ...

Представляете, сколько времени вы бы поддерживали всё это для своего проприетарного бинарного формата? Какой была бы документация по нему, если этот формат не является непосредственно тем, за что вам платят деньги? Сколько вы платили бы последнему оставшемуся программисту команды, который шарит во всём этом коде? И как боялись бы его ухода?

Разработчики Facebook на одной из недавних конференций YaC говорили: "У нас есть ядро кода, которое составляет наш value, и которое мы никогда никому не дадим. Для всех остальных (инфраструктурных и т.п.) задач мы используем открытые и бесплатные решения. При этом мы не только берём из open source community - мы ещё и отдаём обратно".

Andrew Ng, который вёл курс Machine Learning на Coursera, постоянно подчёркивает: "Решайте ту задачу, за которую вам платят деньги. Не надо самостоятельно реализовывать библиотеки, если вам за них не платят. Оставьте это тем, кто на этом специализируется, просто используйте чужие решения".

Помните времена, когда в интернете были распространены самописные "гостевые книги" на perl? Которые отличались друг от друга, как помидор от грузовика, но при этом имели одинаково убогий интерфейс, одинаковый и убогий набор фич и т.п. А что, спрашивается, на тот момент было доступно разработчику таких поделок? Apache и интерпретатор Perl через CGI-интерфейс.  Я лично довольно много раз начинал программу со строчек:



#!/usr/local/bin/perl 

print "Content-Type: text/html\n\n";

print "<html><body>Hello world!</body></html>";



Представьте современный веб-стартап, который начинает с того, что пишет свой слой хранения данных, свой вебсервер и свою jQuery с блэкджеком и гимназистками. Что будет с этим стартапом, если его миссия совсем сильно отличается от "Delivering completely new dynamic web app development and (cloud) hosting paradigm"? Лесом он пойдёт, вот что. А если миссия будет ровно такой, тогда что ж, может и повезёт.

Что делает современный веб-стартап? Он берёт пачку готовых открытых библиотек для фронтенда - 10, 20, ... сколько нужно, включая как известные "большие" решения типа jQuery, так и какие-то отдельные скриптики со странички отдельного разработчика на github-е. Для бэкенда - RoR, Django, ASP.NET MVC, опять же с кучей всего готового. Для хранения - опять же, пожалуйста, выбирайте: MySQL, Postgres, MS SQL, все виды NoSQL-я. Из всего этого зоопарка как-то строятся современные веб-сервисы. Да и эта парадигма, по большому счёту, уже устаревает, когда у вас под рукой Amazon EC2+S3, Azure, Google Cloud Platform..

Веб вообще очень способствует подходу "концентрируйся на том, за что получаешь деньги". Никому, в сущности, не важно, какая ОС и какие библиотеки стоят на ваших серверах в датацентре и насколько они лицензионные. Можете использовать любое free software, снабжённое любой лицензией - вы ведь не продаёте код, а оказываете услугу! За услугу на массовом рынке (домашних, мелких и средних корпоративных пользователей) гораздо проще брать деньги, чем за код: код можно украсть, спиратить, закатать на болванки и продавать, а с услугой так поступить нельзя. Работая в вебе, не нужно поддерживать инфраструктуру изготовления дистрибутивов, нарезки их на диски, изготовления коробок, организовывать каналы продаж коробок. Цикл разработки можно сократить до недели и меньше, а с пользователем общаться напрямую - поставить запись действий пользователя на сайте на видео (ВебВизор Яндекса) и смотреть, что пользователи делают и какие кнопочки жмут.

При этом, к сожалению, по-прежнему существуют компании, поражённые Not Invented Here-синдромом. Этот синдром заставляет использовать только свои собственные решения любых, даже самых типовых задач, полагаться только на свои силы в разработке и быть совершенно не в курсе происходящего вокруг. Разработчики в таких компаниях продолжают поддерживать бородатые форматы данных, огромные кучи плоходокументированного legacy-кода и т.п. Многое из ныне поддерживаемых решений имеет историю в годы, а то и десятки лет. Через многие такие продукты прошли десятки людей, каждый из которых оставил в них свой след.

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

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

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

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

Хотелось бы обратиться к коллегам-разработчикам и коллегам-менеджерам. Товарищи, пожалуйста, постарайтесь сделать так, чтобы нам приходилось как можно реже вникать в очередную ad-hoc реализацию куска функциональности типичной СУБД, системы организации распределённых вычислений, самопальную реализацию SVM или какого-нибудь очередного сериализатора чего-нибудь в какой-нибудь формат. Чем меньше кода вы пишете - тем лучше. А ещё лучше - пишите тот код, который либо сокращает расходы компании на ведение основной деятельности, либо непосредственно за который компания получает деньги, и при этом вам действительно не удалось найти подходящих готовых аналогов.

По иронии судьбы картинка к посту взята с текста про очередной велосипед: Ещё один велосипед, или пишем свой поисковый движок

  • 1

О изобретении велосипедов


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

Когда ваши бойцы пишут код с нуля, то обычно требования не меняются, код сразу эффективен и не тормозит, красивости наводить не надо?

Если так - окей, пишите. Но вам повезло)

Своим бойцам я могу выписать пиздюлинку, если надо будет. А так можно сделать review, подсказать, подправить. С чужим кодом такой фокус не получается. С библиотеками всё усложняется тем что маловероятно найти такую которая удовлетворяет исходным требованиям. И хорошо если весь код ограничится склейкой или подготовкой данных, но зачастую приходится лезть внутрь и дописывать. И это заставляет задуматься в целесобразности использования этих самых библиотек, ведь поддерживать свой код внутри чужого кому-то нужно, о нём нужно помнить и всё такое.

Окей, уточню. В качестве велосипедов доводилось видеть:
1. Регэкспы
2. Хранилище документов с индексами (многопоточность ещё толком не успели сделать вроде бы)
3. Несколько разных библиотек сериализации C++-объектов в XML в рамках одной компании без каких-либо специфических требований и со множеством багов
4. Юнит-тесты
5. Логи

В этих областях действительно маловероятно найти библиотеку, удовлетворяющую исходным требованиям?


ну это действительно треш, угар и содомия. Я думал разговор о высоких материях, а не о базовых вещах.

Угу, вот и до меня в процессе разговора дошло, что он на самом деле о базовых вещах))

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

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

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

Не говоря уже о чём-то сложнее.

Edited at 2013-08-19 07:02 am (UTC)

Весь мой профессиональный опыт говорит, что это чушь что вы тут написали.

Ну и отлично, чо.

Почему чушь? Вполне разумно, в т.ч. с точки зрения бизнеса. Безусловно, всегда нужно включать мозг.

Глупо переписывать готовые решения если они рабоатют, и при этом работают правильно. Но обычно интернет забит сырыми фреймворками, которые собирались решать широчайший спектр задач, но заваливают самые элементарные.

Плюс при переходе на следующую версию всё летит нафиг.

Именно бизнеса. Чтобы уделать всех, нужен новый движок.

С днем рождения!

C Днем рождения!
Удачи во всем! :)

С днем рождения! :)

С ДНЕМ РОЖДЕНИЯ!

Добавила в друзья
Буду читать )

  • 1
?

Log in