Как стать автором
Обновить

Комментарии 40

Если обратиться к примеру самых успешных технологических стартапов мира (Uber, Airbnb, Snapchat, Pinterest и прочие), мы не увидим сложных программных решений

Может статья и хорошая, но дальше читать не стал.
НЛО прилетело и опубликовало эту надпись здесь

Да, вот только в 80% проектов с eslint'ом и jscs используется пресет AirBnB, в плане контроля качества они очень сильно преуспели из-за своего фейла с backbone… но это уже совсем другая история.


Вот решения uber'a в плане QA не особо, да и сейчас из-за этого наблюдается плавный переход с node.js на java/go, их существующие решения очень сильно уступают по качеству тому же netflix'у.

Что за фэйл с Бэкбон? Можно поподробнее?

Начинали они с backbone, и переписывали пару раз из-за подтеканий и криворукости разработчиков. Оно переодически отваливалось… потом был вариант вообще без SPA, но он медленно и уверенно был портирован на React. В процессе портирования был разработан ряд подходов к контролю качества, учитывая предыдущий печальный опыт с backbone. В итоге допиливать и поддерживать решение на react'e получилось в ~6 раз дешевле, а по объёму кода оно было почти в 2 раза меньше первоначального.

Как в бэкбоне может что-то подтекать? Расскажите, мне действительно интересно. Там кода мышка наплакала, в котором разобраться и поправить если что нет так займет полчаса-час. Бэкбоне предоставляет только каркас по сути и базовые вещи типа роутинга и моделей. Честно не знаю где там что-то может течь.

Пример: частенько получается так что есть вложенные вьюшки, родительская внезапно удаляется, и вместо неё создаётся новая с таким же, или большим, количеством потомков, и так с довольно высокой частотой — GC просто не успеет собрать мусор. Да и если с одной вьюшки удалить родительскую другой вьюшки — тоже потечёт. Даже банальный jQuery UI в далёком 2009ом из-за криворукости мог довольно сильно подтекать ...


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

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

Вьюшки надо удалять каскадом, каждый родитель должен уметь удалять созданные им вьюхи. Бекбон сам этого не делает и никогда не обещал этого делать. Это криворукость разработчиков, бэкбон тут ни при чем. Пишешь вьюху — всегда делай в ней destroy метод. Создаешь вложенные вьюхи — удаляй их при дестрое. Подписываешься на события — отписывайся при дестрое. Бэкбон никогда не обещал делать этого за разраба, тем он и ценен, 100% гибкость решений, но надо все аккуратно кодить. Это не плохо и не хорошо, просто вот такая у него ниша.

Проще взять любой более зрелый фреймворк типа Angular2 / React / Ember и не заморачиваться с этим boilerplate'ом, что собственно и сделала AirBnB в своё время. Там тоже возможны утечки из-за криворукости, но и вероятность накосячить будет на много меньше.

Все зависит от задачи. При использовании Backbone и подобных мы делаем то, что мы хотим, а при использовании Angular2 / React / Ember мы делаем то, что нам разрешают сделать. Но холивар устраивать не стоит, это мое личное мнение.
НЛО прилетело и опубликовало эту надпись здесь

Использую уже более года, на ES6. Без тестов ничего не выкатываю из-за этих проблем обратной совместимости, но я не считаю что изменения API в бете слишком уж значительны. В плане архитектуры в бете уже ничего значительно меняться не будет.

НЛО прилетело и опубликовало эту надпись здесь

Был в пачке сфейляных американских стартапов, работал с airbnb soundcloud uber cloudflare netflix akamai ...


Могу подтвердить что действительно наукоёмкими задачами и оптимальными решениями никто не заморачивается, даже с учётом всех сверхоптимистических ожиданий о росте продукта, получается так что после релиза выходит куча хлама. Опосля, если разработчики успевают допилить этот "Минимально-Нежизнеспособный Продукт", что бы он мог расти и масштабироваться без ущерба для UX, и способны применить QoE практики, то и росту спроса можно соответствовать. В противном случае наблюдается острое недовольство клиентов и различные "параноидальные фьючеризмы" "грибной менеджмент" "говноштормы" "кластерфаки" ...


С психологической точки зрения, со старту самого проекта, можно наблюдать ряд распространённых когнитивных искажений из-за потребности веры в иллюзорные перспективы успеха… "Ореолы" "Бумеранги" и проч. А в попытках объяснения и предложений о принятии дальнейшего решения дальше "Проекций" и "Актуализации" дело не доходит.


В общем банальные амбиции и лень затмевают взор…
Вместо того что бы мерить и принимать решение, люди верят в иллюзорные перспективы абстрактного успеха.

Увы, но вывод каков — писать сразу все серьезно и спланировано на всех возможные варианты развития?

Точка «ой, у нас все плохо, мы этого не закладывали в архитектуру» всегда будет, вопрос, как ее встретить и что с ней делать. Бежать с нуля переписывать — отличный вариант, только надо не забывать о поддержании старой версии.

А с Netflix-ом я лично не знал, что начинали они с пиратской раздачи видео всем друзьям )))
Да — в основе любого бизнеса лежит простая идея — уговорить некую условную тетушку купитьза $10 нечто, о чем она 5 мин назад и не подозревала.
Если число тетушек растет с течением времени, то бизнес удачен, иначе это просто разводка
Как говорил один мой знакомый циничный предприниматель
Есть два способа продать ПО:
  1. соблазнить;
  2. напугать.
Печально, что менеджмент превалирует над техническим процессом. Понимаю, «белые воротнички» хотят покупать лексусы и катать гламурных див на дискотеки с мохито… Только какое отношение всё это имеет к производству программного продукта? Вопреки мнению автора, производство – это написание и отладка программного кода. Именно это и является продуктом, а остальное – не более чем схема его реализации. И сколь бы она не влияла на продажи, она не должна оказывать влияния на программистов, т.к. от симбиоза программиста и менеджера появляются недопрограммисты-недоменеджеры. Каждый должен заниматься своим делом. И хорошо бы эти кухни окончательно разделить. Нужен продукт? Заказывайте его разработку. А что до рисков… Ну вы же сами хотели капитализм? Получите, распишитесь! Только не надо скулить о том, что «весь мир так живёт». Уже давно пора наплевать на весь мир и жить своими реалиями, которые требуют весьма жёсткого и принципиального планирования, не считающегося с рыночными «реалиями» никак.
НЛО прилетело и опубликовало эту надпись здесь
В проектной деятельности код стоит на последнем месте, основной критерий это соответствие требованию заказчика, а с точки зрения кода оно абсолютно невзыскательное. Заказчик пишет ТЗ в стиле: «Нужен импорт данных из такой то системы», «Аналитика по таким то объектам», «Сбор данных из контроллера».
Проектный менеджер в такой ситуации — царь и бог, а остальные просто действуют под его указку, захочет сменит всю команду, главное добиться тех основных требований, что указаны в ТЗ. Дальнейшие баги и проблемы, являются лишь пунктом поддержки данного решения.

Для SaaS решений обратный подход.
«Печально, что менеджмент превалирует над техническим процессом.»

Единственный способ превалирования технического процесса — работать на себя. Бесплатно. Либо проинвестировать компанию из своего кошелька.

Не получится вот так просто придти в компанию, и сказать «платите мне среднюю месячную зарплату по стране каждую неделю, а я буду сам решать, будет релиз продукта в этом году или нет».

«Вопреки мнению автора, производство – это написание и отладка программного кода. Именно это и является продуктом, а остальное – не более чем схема его реализации.»

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

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

«А что до рисков… Ну вы же сами хотели капитализм? Получите, распишитесь!»

Предположим, вам предложили работать в компании за процент от прибыли. Компания получила большую прибыль — вы получаете миллионы. Компания понесла убытки — вам нужно продать квартиру и взять кредит, чтобы их покрыть. Вышла в ноль — все остаются при своих. Вы бы хотели такой капитализм?

Это естественно, что люди, берущие на себя риск, стараются его минимизировать. И инвесторы тут не исключение — потому им и нужно сначала убедиться, что «криво, быстро и на коленке» — хоть немного работает.

«Уже давно пора наплевать на весь мир и жить своими реалиями, которые требуют весьма жёсткого и принципиального планирования, не считающегося с рыночными «реалиями» никак.»

Вся статья выше как раз о том, реалии не требуют жёсткого и принципиального планирования. Реалии требуют гибкости и скорости.

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

«А давайте три года делать сервис с геолокацией, вот миллион, как закончится — просите ещё.»
«Надоела геолокация? Проект ещё не успели в третий раз переписать перед запуском, а конкуренты уже заняли весь рынок? Ну ладно, зато как хорошо посидели. Вот ещё миллион, давайте теперь big data поковыряем.»

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

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

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

Так что в идеале — программер должен понимать, зачем он делает ту или иную фичу, что она дает при маркетинге. А если программер не понимает ЦЕЛИ написания кода, не понимает, какие характеристики кода важны, а какие нет — хреновый получается код.

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

P.S. Я как раз программер, а не маркетолог. Но я хочу, чтобы наши изделия продавались, а не писать свой код «в стол».
Статья кидает из крайности в крайность, но как тема к размышлению — хороша.
По поводу MVP — путается прототип для тестирования спроса и 1-я версия уже добротно сваянного продукта (тоже с с минимум необходимых функций).
Ну, эти то по жизни стабильно путаются
Так это ж классика: «good marketing and sales always beat great technology» (хороший маркетинг и продажи всегда победят отличную технологию).

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


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

речь о конкурентной борьбе, а не о двух ветвях внутри одной компании
10.000 дорогостоящих высокоточных самонаводящихся ракет против миллиарда дешевых, хитрых и окопавшихся пехотинцев?
После прочтения почему-то сразу вспомнились pied piper и «коробка».
По данным CB Insights, только 5% стартапов прогорают по причине слабой технической реализации
Простите, а где там такое написано? Друг интересуется, я было обрадовался, смотри мол, пофиг на твой левел, главное — маркетинг. А по ссылке какой-то мутный перечень, без сводки. Запросил там отчет, получил сводку. В ней тоже нет 5%.

Поэтому резонный вопрос, откуда взята цифра? От верблюда?
Цифра взялась оттуда же, откуда и рейтинги ВУЗов…
По данным CB Insights, только 5% стартапов прогорают по причине слабой технической реализации. Большинство провалов случается в результате неверного позиционирования продукта, отсутствия грамотной маркетинговой стратегии, плохих специалистов по продажам, неверной бизнес-модели. Наличие или отсутствие высококвалифицированных инженеров практически не играет никакой роли, делают вывод исследователи.


Ну все верно, обычно я исхожу из того, что на успех проекта инженерная составляющая влияет примерно на 30%, но время идет, создается больше удобных инструментов, фактически продукты производить легче и роль инженеров-программистов в успехе продукта постоянно падает.
я всё удивляюсь, при таком количестве заготовок кода в базах гугла и гитхабов, где нейросеть-программист, которая предложит лучший по качеству код, сама его реплицирует и заставит самосовершенствоваться?
по сути, стиральная машинка, девальвировавшая ценность труда прачки.
и все эти годы учебы программированию следующим поколением землян будут восприниматься как архаичная и бесполезная трата времени, вроде просмотра тв. если нейросеть-программист оставит землян в живых.
«Если обратиться к примеру самых успешных технологических стартапов мира (Uber, Airbnb, Snapchat, Pinterest и прочие), мы не увидим сложных программных решений.»

Да ладно не увидим?

Uber Engineering Blog:https://eng.uber.com/

Пост #1 о том как Uber слез с PostgreSQL 9.2 на новый мускуль, плакаются что репликации нет и хранилище не эффективное — ну конечно, сидеть на ископаемой винрарщине и плакаться на MVCC, мягко говоря, не серьёзно.
Пост #2 о том как хорошо интернам в Убере менять мир к лучшему, т.е. вброс.
Пост #3 о том как они используют PCA (метод главных компонент) для предотвращения фрода. PCA, Карл! PCA против мошенничества.
Пост #4 о том как они сглаживают ускорения логистической регрессией, т.е. тролейбус с батона.
Пост #5 про абстрактный деплой микросервисов в вакууме, без консенсусов, CRDT и прочих умных штук, просто потому что они магическим образом могут без этой заумной ерунды обойтись.


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

Всю статью можно свести к одной фразе:
Лучше сначала надо что-то продать, а потом начать разрабатывать, чем сначала разработать, а потом пытаться продать.
это же классическая история про двух программистов, когда один пилил продукт несколько лет до идеала, а второй каждые полгода сыровяленную требуху апдейтил. когда первый свой продукт явил миру, оказалось, что он никому не нужен.
ибо: у всех стоит продукт второго программиста, им нравится, что он постоянно обновляется и поддерживается, а главное — в нем уже появилось то новое, что в «идеальный продукт» первого не вкрячишь никак — только заново писать всё.
финита.
//это было краткое содержание статьи методом «притчи»
К сожалению, выигрывает тот, кто первый вышел на рынок. По этому метод разработки «хуяк-хуяк и в продакшен» всегда будет самым востребованным, несмотря на высокие риски. Есть слабая надежда на хорошие статически типизированные языки, типа Haskell или Rust, но что бы их применение не замедляло разработку, требуются очень опытные программисты.

Понимаете, не важно, какие у тебя программисты, главное — какие продавцы!

Зарегистрируйтесь на Хабре, чтобы оставить комментарий

Публикации

Истории