Прошлым летом мы с пацанами рассказали про свою либу, которую наш заказчик не принял и выкинул на помойку. Мы бомбили, потому что верили в свое решение, и рассказали о нем сообществу — уж обычные-то разрабы точно заценят и не будут размениваться на всякую чушь.
Ну конечно. Нас буквально смыло волной критики. Там было много людей, которым не нравится мое самомнение и я лично — это ок, с ними у меня нет проблем. Меня взбесили вроде бы умные люди, которые даже не захотели смотреть в код и вникать в контекст, потому что с порога заявили: «Вы, парни, сделали велосипед». И все подхватили — изобретать велосипеды плохо, ужасно, кошмарно, недопустимо, позор, казнить их, линчевать. Ведь, только идиот будет разрабатывать новый инструмент для задачи, которую кто-то уже решил.
Меня поражает насколько быстро разрабы ведутся на эту уловку. Я спрашивал даже самых критичных и глубоко думающих людей — “изобретать велосипеды плохо?”. Они отвечают “да” меньше чем через секунду.
Ну нет, мужики, так не пойдет. Давайте-ка остановимся здесь, посмотрим вокруг и обстоятельно порассуждаем.
Однажды я довольно долго делал фронтенд приложение дома. Я использовал реакт, но не брал либы для управления состоянием — у меня не было такой проблемы. Потом проблема появилась, и я начал делать «свой велосипед». Умные дяди сказали мне, что я идиот, и надо брать Redux. Я взял.
Через два месяца большая часть кода проекта была адаптацией редакса к моей архитектуре. Этот инструмент создал мне намного больше проблем, чем решил. Не потому что редакс плохой — он просто не подходил.
Человек из большой корпорации сделал решение для работы с состоянием веб приложения большой корпорации. Редакс решает кучу проблем, которые стоят перед таким приложением, и делает это хорошо. И что делает индустрия? Индустрия говорит — Дэн Абрамов дал нам путь. Теперь мой сайтик на две формы будет использовать редакс для работы с состоянием.
Друг, редакс сделан для работы с состоянием — но не с твоим состоянием. Тебе блин не нужен персистентный чейн всех слайсов стейта приложения, ты не передаешь экшны по сети и не делаешь ещё много чего такого, что должен автоматизировать редакс. При этом, использовать редакс непросто. Тебе придется нагородить сто километров кода на то, чтобы объяснить редаксу, какое у тебя состояние, где и как оно обновляется, какие изменения значимые, а какие нет. Чтобы редакс автоматизировал тебе проблему, которой у тебя не было. Серьезно, вы видели хотя бы одну вакансию на реакт, но без редакса? Я нет.
Есть аналоги — но они такие же громоздкие. Иногда самый дешевый способ решить проблему — не взять инструмент для всего, а написать доменное решение, которое хорошо подходит именно тебе. Мой бог, typescript достаточно мощный ЯП, чтобы за пару часов написать себе базовый мввм, мвц, или вообще любой мв, который ты хочешь — так, чтобы он решал только те проблемы, которые у тебя есть. Сделать его выйдет дешевле и быстрее. И возможно, твое решение сработает круто, вырастет вместе с проектом, и станет стандартом.
Но это запрещено — потому что другие разрабы тебе сказали: “парень, не изобретай велосипед. Просто возьми самое популярное на рынке”.
В моем проекте, например, больше подходил MobX, но тоже не супер. Лучше всего у меня бы сработал именно изобретенный мной велосипед. Но у меня как будто отняли право принимать хорошее решение, ведь что бы я ни сделал — никто даже не стал бы слушать. Никто не готов поверить, что получится лучше и дешевле.
Это порождает замкнутый круг. Если все будут использовать только изобретенное до них, то прогресс в разработке остановится. Тебе скажут, хочешь сделать лучше, чем в готовом — делай дома в свободное время. Ты говоришь ок, начинаешь работать ночами, доделываешь, идешь рассказывать о своем решении людям, но никто не готов даже смотреть ему под капот — “это же велосипед”.
А на самом деле все, что мы делаем — это изобретаем велосипеды. “Велосипед” — это просто вредная риторическая уловка, чтобы оправдать свою лень или самоутвердится в споре с другим разрабом.
Создатели редакса, реакта и мобикса — они ведь тоже «делали свой велосипед». Ну а что, разве к моменту появления ангуляра у нас не было библиотеки для работы с браузерным UI? JQuery, Knockout? Это тоже велики, кстати. Ведь всегда был ванила js и браузерное API. Так зачем эти идиоты решали решённую проблему?
Дуглас Крокфорд изобрёл JSON. Некомпетентный болван похоже не знал, что у нас уже есть XML. Программисты задолго до него изобрели способ обмена данными, кем он там себя возомнил вообще?
Плохие примеры? Ну конечно. Ведь в ваших головах люди из больших корпораций имеют право изобретать велосипеды. Они имеют, а я и вы нет.
Самое энтерпрайзное ИТ в РФ — это банки. И если вы посмотрите на технические продукты всяких Сберов, Тиньковых или Альф, увидете — у них у всех одни и те же приложения с примерно одним и тем же дизайном. Это почти одинаковые системы. Одинаковые для пользователя, они сделаны по-разному, на разных стеках, разными людьми. У всех этих банков свои уникальные подходы к разработке. У мировых ИТ гигантов так же очень много одинаковых продуктов. Когда большие банкиры собираются и решают, что им нужны цифровые продукты, они нанимают армию разрабов и заставляют их делать все то же, что уже делали другие банки, в сотый раз — но по-новому.
Это всё — велосипеды.
В каждом проекте, над которым я работал были долгоживущие проблемы, потому что что-то не было автоматизировано. Потому что когда-то кому-то сказали — не изобретай велосипед, просто закрой тикет. Да, бизнес ждёт своих тикетов, и ему нужно их скармливать, но давайте по-честному — я отлично знаю, что у нас всегда больше бюджета, чем думает бизнес.
У меня все просто с деньгами бизнеса, которые я на это трачу. У большого бизнеса много денег, и он их вбухивает в разработку. Эту огромную кучу денег могут потратить разработчики, которые решают задачи, и при этом ведут какие-то исследования. А могут потратить менеджеры, но менеджеры потратят их чтобы оплатить наше бессмысленное сидение на миллионах никому не нужных совещаний. Бизнес уже потратил деньги на разработку, и если ты их не превратишь в программирование, то бизнесовые прихвостни потратят их на свои дурацкие процессы, которые не нужны никому кроме них самих.
Я достаточно насмотрелся на чуваков, которые «работают» по 18 часов в сутки. И я хорошо знаю, если ты просидел в офисе 18 часов, реально работать ты будешь столько же, как если бы сидел 8.
Наша коллективная манера обманывать бизнес объясняется очень просто — он не шарит. Бизнес не понимает, почемы мы должны две недели не делать фичи, а приводить в порядок легаси. Это нормально, и мы умеем это резолвить. Ты полдня работаешь на бизнес, а полдня работаешь на проект. Пришёл на работу, закрыл дневную норму — всё, у тебя картбланш на исследования.
Пока мы решаем практические, сиюминутные хотелки бизнеса — он готов нам оплачивать настоящую работу. На самом деле настоящая разработка начинается там, где есть программирование ради программирования. Когда ты упиваешься чистой механикой ради гребаного ничего, сиюминутного щелчка и инженерного восторга, потому что только так раздвигаются границы, появляются новые способы и инструменты, чтобы снова решать практические задачи, только лучше.
Когда я что-то разрабатываю, что-то такое, что уже сделано, я не перепридумываю это точь-в-точь как у них. Я придумываю свой подход. Он всегда чем-то лучше, всегда чем-то хуже. И это всегда изобретение. Подавляющее большинство моих изобретений отправиться на свалку истории, но всегда есть шанс, что я изобрету что-то действительно крутое. Пусть даже мимоходом, пусть я сам не придам этому значения — не важно. Кто-то увидит, заюзает где-то ещё, индустрия получит новый стандарт, который начнёт решать наши проблемы. Только эта идея двигает меня на написание кода.
В опенсорсе тоже много одинаковых проектов. Таких, которые решают одну и ту же проблему. Вы готовы сказать, что все кто их делает — дураки? Я не готов. Когда я хочу заюзать либу для сериализации, я получаю пять-шесть топовых решений, каждое из которых имеет уникальные преимущества. Иногда одно из этих преимуществ для меня критично, в такие моменты я полон благодарности парням, которые решили сделать этот «велосипед».
Когда мне говорят, что в разработке всё уже изобретено, я спрашиваю: «а что, разве у нас не осталось проблем?».
Разве не мы пишем бойлерплейт изо дня в день? Разве не мы раз за разом не вывозим автоматизацию, когда наполняем свои файлы однотипным кодом? Мы всё ещё делаем очень много того, что уже сейчас могла бы делать машина. И делаем это потому, что ещё не изобрели подходов, потому что вечно вставляем палки в колеса велосипедов.
Смотрите мой подкаст
miraage
Я не понял смысл поста. Просто пожаловаться, что не дали воткнуть велосипед, который, я уверен, имеет далеко не самый хороший API? А потом как это поддерживать? Учитывая, что React из коробки имеет просто отличный state management, заточенный под React…
pnovikov
Смотрит разработчик на код и спрашивает — "а кааак это поддерживать?".
Тонны редакс-быдлокода, написанные в режиме "главное завалить а там ногами запинаем" мы не спрашиваем как поддерживать. А небольшой, но свой стейт-менеджмент в 500 строк кода суммарно — всё, проблема проблем! Мы не знаем что делать кроме как рыдать "спаситипамагити мамочка тут велосипед!", "да, мы видим его код, мы знаем буквы которыми он написан, мы знаем язык на котором он написан но ОООО УЖАС КАК ЖЕ ЭТО ПОДДЕРЖИВАТЬ?!".
И действительно. Неподвластная человеческому уму задача.
P.S: а вы часто смотрите в код пакетов, которые вы используете? А количество открытых issues? А когда был последний коммит — тоже проверяете? А документацию на сайте с API сопоставляете (вдруг там не всё описано)? А как вы будете поддерживать своё приложение если завтра автора вашего, конечно же, не-велосипедного пакета из npm собьёт автобус вы часто спрашиваете?
nin-jin
У меня есть история на эту тему. Прикручивал я mobx к angular. Взял mobx-angular, который использовал недокументированное апи, чтобы подцепиться к ангуляру. Ни у кого вопросов не возникло, ведь это сторонний пакет.
Но решил я его улучшить, добавив поддержку SuspenseAPI, поэтому форкнул, чуть упростил и добавил эту фичу. Кода там с гулькин нос. То теперь это (о ужас!) использование недокументированного апи в нашем репозитории. В результате этот пулреквест пришлось откатить и написать кучу бойлерплейта из-за отсутствия SuspenseAPI.
Hvorovk
Надо было свой форк как сторонний пакет сделать:D
nin-jin
Ага, в нерабочее время. Да и в любом случае бы зарубили ибо "слишком мало звёзд на гитхабе".
eternum
А мы часто решаем проблемы от сторонних решений. Процентов 70 головной боли именно от сторонних библиотек. И решение, зачастую, приходит из таких же болей разрабов на ближайшем stack overflow. Соответственно если мы используем библиотеку которую написал и использовал один средний Столман, то и проблему решать мы будем исключительно в две головы. В случае кончины автора — в одну.
1c80
Если за систему баксуют как положено или проект мой, то конечно все это делается и все репы клонируются к себе, а если оплата далека от ожидаемой, то мне пофигу какой там пакет и что он там, забью костыль и потом соскочу при первой возможности, это обще принятая практика, в большинстве случаев по коду видно, когда кончилось бабло или что то случилось в менеджменте.
Carduelis
На самом деле, довольно просто: если компания энтерпрайз, может быть текучка, то, конечно, любой говнокод на редаксе лучше, чем на велосипеде. Learning Curve, там.
Но на практике, есть разработчики, которые не могут разобраться даже в Redux. Для них middleware — это магия высшего порядка, код, написанный сеньерами для лидов.
Dependency Injection? Conversion of control? Вы што?
Поэтому да, если уж хреновый код написан на популярной библиотеке (а этого, к сожалению, не избежать), разгребать его будет проще, чем хреновый код на неизвестном велосипеде.
nin-jin
Конверсия контроля? Вы што?
eternum
Это когда зависимости не только не приносят проблем, но ещё и приносят доход! Святой грааль разработки.
nin-jin
Коллеги рекомендуют чаще сливаться со стволом, чтобы избежать проблем с зависимостями.
Calc
Когда времени мало и нужно решить какую либо фундаментальную проблему, то можно отдать приоритет велосипеду.
Из примера
Есть Андроид с его фрагментами и идиостким апи перехода:
взять активити, достать фрагмент менеджера, создать фрагмент, сказать фрагмент менеджеру возьми этот фрегмент пихни во вью, пихни в стек, дай ему тег, если надо.
А если в верстке есть косяк или дизайн что то требует (показать тул бар, скрыть таббар) при переходе в фрагменты, то нужно дотягиваться до активити при переходе. Кто с этим работал, тот видел весь этот говнокод смены фрагментов в чужих проектах (вызов этого апи из адаптеров списков, например) :)
Жуть.
Есть библиотеки состояний с развитым апи, там текста инструкций больше чем надо кода.
Определить интерфейс сможет и джун: Вперед, назад, назад в корень, заменить.
Навесить пару паттернов состояний (forward/bacward):
И вот за час рождается библа, которая с 2016 (создана 2016?11?24) года поменяла поменяла только положение переменных в вызове какого то метода.
Т.е. на создание такого велосипеда ушло меньше времени чем на изучение и внедрение существующих и данная либа ушла проектов в 20-30.
А вот вся эта мишура с развитым апи, гибкостью и другими штуками очень часто не нужна.