Комментарии 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 в своё время. Там тоже возможны утечки из-за криворукости, но и вероятность накосячить будет на много меньше.
Был в пачке сфейляных американских стартапов, работал с airbnb soundcloud uber cloudflare netflix akamai ...
Могу подтвердить что действительно наукоёмкими задачами и оптимальными решениями никто не заморачивается, даже с учётом всех сверхоптимистических ожиданий о росте продукта, получается так что после релиза выходит куча хлама. Опосля, если разработчики успевают допилить этот "Минимально-Нежизнеспособный Продукт", что бы он мог расти и масштабироваться без ущерба для UX, и способны применить QoE практики, то и росту спроса можно соответствовать. В противном случае наблюдается острое недовольство клиентов и различные "параноидальные фьючеризмы" "грибной менеджмент" "говноштормы" "кластерфаки" ...
С психологической точки зрения, со старту самого проекта, можно наблюдать ряд распространённых когнитивных искажений из-за потребности веры в иллюзорные перспективы успеха… "Ореолы" "Бумеранги" и проч. А в попытках объяснения и предложений о принятии дальнейшего решения дальше "Проекций" и "Актуализации" дело не доходит.
В общем банальные амбиции и лень затмевают взор…
Вместо того что бы мерить и принимать решение, люди верят в иллюзорные перспективы абстрактного успеха.
Точка «ой, у нас все плохо, мы этого не закладывали в архитектуру» всегда будет, вопрос, как ее встретить и что с ней делать. Бежать с нуля переписывать — отличный вариант, только надо не забывать о поддержании старой версии.
А с Netflix-ом я лично не знал, что начинали они с пиратской раздачи видео всем друзьям )))
Если число тетушек растет с течением времени, то бизнес удачен, иначе это просто разводка
Проектный менеджер в такой ситуации — царь и бог, а остальные просто действуют под его указку, захочет сменит всю команду, главное добиться тех основных требований, что указаны в ТЗ. Дальнейшие баги и проблемы, являются лишь пунктом поддержки данного решения.
Для SaaS решений обратный подход.
Единственный способ превалирования технического процесса — работать на себя. Бесплатно. Либо проинвестировать компанию из своего кошелька.
Не получится вот так просто придти в компанию, и сказать «платите мне среднюю месячную зарплату по стране каждую неделю, а я буду сам решать, будет релиз продукта в этом году или нет».
«Вопреки мнению автора, производство – это написание и отладка программного кода. Именно это и является продуктом, а остальное – не более чем схема его реализации.»
Зависит от бизнеса. В большинстве стартапов, даже чисто технологических это совсем не так. Часто продуктом являются просмотры пользователей, которые продаются рекламодателям. А пользователей ведёт маркетинг, а не качество реализации (см. фейсбук, ранние дни твиттера (картинка с китом)).
Но даже в тех компаниях, где качество продукта чего-то стоит, менеджмент и маркетинг не являются лишь «обслуживающим персоналом единственных работающих людей — программистов». Они выполняют работы и принимают решения, в основном стремясь к тому, чтобы компания выжила, а не ради соблюдения «ритуала техпроцесса».
«А что до рисков… Ну вы же сами хотели капитализм? Получите, распишитесь!»
Предположим, вам предложили работать в компании за процент от прибыли. Компания получила большую прибыль — вы получаете миллионы. Компания понесла убытки — вам нужно продать квартиру и взять кредит, чтобы их покрыть. Вышла в ноль — все остаются при своих. Вы бы хотели такой капитализм?
Это естественно, что люди, берущие на себя риск, стараются его минимизировать. И инвесторы тут не исключение — потому им и нужно сначала убедиться, что «криво, быстро и на коленке» — хоть немного работает.
«Уже давно пора наплевать на весь мир и жить своими реалиями, которые требуют весьма жёсткого и принципиального планирования, не считающегося с рыночными «реалиями» никак.»
Вся статья выше как раз о том, реалии не требуют жёсткого и принципиального планирования. Реалии требуют гибкости и скорости.
Не поймите меня неправильно, я бы тоже был рад если бы все эти «жадные» инвесторы перестали уже трястись над своими деньгами, перестраховываясь и ожидая возврата, а просто раздавали бы их стартапам для развлечения.
«А давайте три года делать сервис с геолокацией, вот миллион, как закончится — просите ещё.»
«Надоела геолокация? Проект ещё не успели в третий раз переписать перед запуском, а конкуренты уже заняли весь рынок? Ну ладно, зато как хорошо посидели. Вот ещё миллион, давайте теперь big data поковыряем.»
Но так уж лучше было бы помечтать, что мне просто в карман деньги сразу положат, без всей этой имитации бурной деятельности.
Производство — лишь малая часть работы. Равно как и беготня по клиентам с просьбами купить вашу рельсу, то есть продажи.
А в основе… в основе менеджмент. Бизнес-идея. Удовлетворения потребностей заказчиков. Ну скажем чугунная рельса, по которой поезд едет тихо.
Так что в идеале — программер должен понимать, зачем он делает ту или иную фичу, что она дает при маркетинге. А если программер не понимает ЦЕЛИ написания кода, не понимает, какие характеристики кода важны, а какие нет — хреновый получается код.
При выборе между памятью и скоростью, между универсальностью и эффективность, между отлаженностью и скоростью разработки, важнее всего понимать маркетинг.
P.S. Я как раз программер, а не маркетолог. Но я хочу, чтобы наши изделия продавались, а не писать свой код «в стол».
Аминь.
По поводу MVP — путается прототип для тестирования спроса и 1-я версия уже добротно сваянного продукта (тоже с с минимум необходимых функций).
Прям "Перспективный маркетинг бесперспективных продуктов" решает все проблемы бизнеса...
Вы уверены что "хороший маркетинг" должен бороться с "отличной технологией"?
Может он в результате пытается бороться с отлаженным и жизнеспособным процессом разработки в угоду иллюзорной прибыли в краткосрочных перспективах ?
По данным CB Insights, только 5% стартапов прогорают по причине слабой технической реализацииПростите, а где там такое написано? Друг интересуется, я было обрадовался, смотри мол, пофиг на твой левел, главное — маркетинг. А по ссылке какой-то мутный перечень, без сводки. Запросил там отчет, получил сводку. В ней тоже нет 5%.
Поэтому резонный вопрос, откуда взята цифра? От верблюда?
По данным CB Insights, только 5% стартапов прогорают по причине слабой технической реализации. Большинство провалов случается в результате неверного позиционирования продукта, отсутствия грамотной маркетинговой стратегии, плохих специалистов по продажам, неверной бизнес-модели. Наличие или отсутствие высококвалифицированных инженеров практически не играет никакой роли, делают вывод исследователи.
Ну все верно, обычно я исхожу из того, что на успех проекта инженерная составляющая влияет примерно на 30%, но время идет, создается больше удобных инструментов, фактически продукты производить легче и роль инженеров-программистов в успехе продукта постоянно падает.
по сути, стиральная машинка, девальвировавшая ценность труда прачки.
и все эти годы учебы программированию следующим поколением землян будут восприниматься как архаичная и бесполезная трата времени, вроде просмотра тв. если нейросеть-программист оставит землян в живых.
Да ладно не увидим?
Uber Engineering Blog:https://eng.uber.com/
Пост #1 о том как Uber слез с PostgreSQL 9.2 на новый мускуль, плакаются что репликации нет и хранилище не эффективное — ну конечно, сидеть на ископаемой винрарщине и плакаться на MVCC, мягко говоря, не серьёзно.
Пост #2 о том как хорошо интернам в Убере менять мир к лучшему, т.е. вброс.
Пост #3 о том как они используют PCA (метод главных компонент) для предотвращения фрода. PCA, Карл! PCA против мошенничества.
Пост #4 о том как они сглаживают ускорения логистической регрессией, т.е. тролейбус с батона.
Пост #5 про абстрактный деплой микросервисов в вакууме, без консенсусов, CRDT и прочих умных штук, просто потому что они магическим образом могут без этой заумной ерунды обойтись.
Прям очень таки познавательные, наукоёмкие и высокотехнологические статьи...
Лучше сначала надо что-то продать, а потом начать разрабатывать, чем сначала разработать, а потом пытаться продать.
ибо: у всех стоит продукт второго программиста, им нравится, что он постоянно обновляется и поддерживается, а главное — в нем уже появилось то новое, что в «идеальный продукт» первого не вкрячишь никак — только заново писать всё.
финита.
//это было краткое содержание статьи методом «притчи»
Понимаете, не важно, какие у тебя программисты, главное — какие продавцы!
Кого волнуют баги продукта, если он успешно продается