Al
Лида ещё страшного и сурового можно, чтобы он выбрал, а остальные смирились просто
Anonymous
выживший выбирает фреймворк
Anonymous
потом под него набираешь остальных
Pavel
Отмечу, что это ха, а не икс
Eugene
Просто выгнать всех нытиков, которые вечно хотят куда-то переехать
Дима
Берешь
Дима
ghcjs
Pavel
На самом деле из хотелок переехать на другой стек достаточно быстро вырастаешь
Дима
И все вопросы и подобные предложения отпадают
Al
"Слушай, я тут подумал, почему мы на ванилле пишем, есть же Х"
Есть охуенный способ с такими работать: "Слушай, интересная мысль, давай её обсудим, только вот эти пару фич запили ещё", далее следует давать размеренные порции новых завтраков и фич листы
Al
Потом он не выдержит и сам всё перепишет в своё личное время, и тут можно уже принять, или сказать, что пруф оф концепт показал, что вышла хуйня
Дима
Менеджер от бога
Pavel
у меня вон некоторые проекты еще на ember.js живут кстати
Pavel
а некоторые на node.js 0.11
Pavel
апдейтить правда жопа геморой
Pavel
но, в целом, согласен - надо ехать, а не шашечки
Al
апдейтить правда жопа геморой
Это правильно, это хорошо, ни в коем случае не надо давать время на апгрейд и технический долг, ведь бизнесу не до этого, паровозик должен идти, и в топку постоянно надо подкидывать фичи и срочные багфиксы, если по дороге начинают отваливаться колёса - лучше и дешевле заменить их на говно и палки, чем останавливать паровозик и заниматься реинжинирингом
Pavel
Ирония неуместна, патаму что я это понимаю
Pavel
Pavel
Просто есть проекты, в которых это ок. Они либо потом имеют бюджет на апдейт мощный, либо это становится неактуально.
Nikita
а я то думаю что все срут в код, а то оказывается санкционированно
Дима
Just as planned
Дима
💩
Nikita
зато теперь есть свободное время, вместо улучшения проекта по вечерам, ура товарищи
Eugene
ну есть же отличная цитата: "Я раньше поражался тому, как уродливы изнутри «взлетевшие» проекты. Сейчас я знаю: красивые проекты не взлетают, потому что они не успевают взлететь. Пока инженеры в белых халатах прикручивают красивый двигатель к идеальному крылу, бригада взлохмаченных придурков во главе с безумным авантюристом пролетает над ними на конструкции из микроавтобуса, забора и двух промышленных фенов, навстречу второму туру инвестиций. Авантюрист любезно раздаёт восторженным пассажирам талоны и бумажные пакетики."
Anonymous
нужен agile
https://www.youtube.com/watch?v=UZq4sZz56qM
Anonymous
Это правильно, это хорошо, ни в коем случае не надо давать время на апгрейд и технический долг, ведь бизнесу не до этого, паровозик должен идти, и в топку постоянно надо подкидывать фичи и срочные багфиксы, если по дороге начинают отваливаться колёса - лучше и дешевле заменить их на говно и палки, чем останавливать паровозик и заниматься реинжинирингом
Некоторым проектам проще поддерживать жизнь в их бренных телах, чем уговорить перейти с какахи на что-то вменяемое, ведь "все работает". Хотя работает всё на магии. На таких проектах просто руки опускаются и хочется лишь поскорей разгрести очередную пачку багов, чтобв спокойно на норм проекте поработать.
И этот ксок ведь даже не взлетевший проект, а скорее наоборот, потонувший.
Alex
Какой фронтенд выбрать для нового проекта, чтобы год никто не выносил мозги "а давайте переедем на ххх" ? )
https://svelte.technology же!
Дима
"Дельфины спасают людей" потому что те, кого они отнесли в море уже не могут об этом рассказать.
Поэтому сложно представить, сколько конструкций из фекалий и говна не взлетело чисто из-за того, что их делали тяп ляп
Eugene
"Дельфины спасают людей" потому что те, кого они отнесли в море уже не могут об этом рассказать.
Поэтому сложно представить, сколько конструкций из фекалий и говна не взлетело чисто из-за того, что их делали тяп ляп
Подход "тяп-ляп" плох всегда, это факт. Я пытался сказать, что многие разработчики под предлогом разгребания говна, занимаются оверинжинергингом. Код в большом проетке никогда не бывает идеальным. Я пока не встретил ни одного проекта, который умер из-за говна в коде. Зато видил много проектов, которые умирали из-за медленных итераций, отсутсвия фокуса и плохих продаж.
Slava
Евгений, как хорошо что вы есть
Slava
У вашего работодателя
Eugene
Ахах, не думаю, что мой работодатель так думает)
Slava
И зря
Pavel
Подход "тяп-ляп" плох всегда, это факт. Я пытался сказать, что многие разработчики под предлогом разгребания говна, занимаются оверинжинергингом. Код в большом проетке никогда не бывает идеальным. Я пока не встретил ни одного проекта, который умер из-за говна в коде. Зато видил много проектов, которые умирали из-за медленных итераций, отсутсвия фокуса и плохих продаж.
одно дело это понимать, а другое дело делать. подход тяп-ляп иногда связан с внутренними процессами, в которые тот же тимлид не в силах вмешаться
Nikita
Мой опыт говорит о том что если преоект не взлетел то виноваты управленцы
Eugene
+1, иногда это технические управленцы в том числе.
Anonymous
на vc ru была статистика согласно которой стартапы не взлетают по техническим причинам только в 5% случаев. Остальные 95% процентов это плохой маркетинг, неудачная идея и т.д.
Pavel
ага
Pavel
это про публичные проекты в основном, потому что в закрытых чаще всего тот же РП может технический долг на условно говоря любое время растянуть
Viktor
идея
Artem
Эт
Artem
А вакансии тут размещают
Viktor
даже если она гавенореализуема
Artem
!?
Viktor
но идея стоящая
Viktor
она взлетит
Igor
Viktor
а так если все скука смертная, то даже мега спецы не помогут
HashTag
Подписка на #вакансия
Slava
Ребята, у проекта есть разные этапы. И техническая часть она не отвязана от проекта. Если у вас продукт, который решает какую-то острую боль клиента - то он может прожить какое-то время из говна и палок, главное не упустить момент быстренько навести там порядок (более-менее).
Slava
То есть на этапе "ранних последователей" можно закрывать на это глаза, потом как только накопится критическая масса - будет бобо :)
Viktor
ну оно и естественно
Viktor
запускаешь и чистишь
Slava
Чистишь уже в процессе... =)
KlonD90
Это правильно, это хорошо, ни в коем случае не надо давать время на апгрейд и технический долг, ведь бизнесу не до этого, паровозик должен идти, и в топку постоянно надо подкидывать фичи и срочные багфиксы, если по дороге начинают отваливаться колёса - лучше и дешевле заменить их на говно и палки, чем останавливать паровозик и заниматься реинжинирингом
Ну такое быстро накопится технический долг и стоимость изменений и гарантий возрастет адово. Лучше сразу сделать устойчиво с тестами чем потом нести репутационные риски.
Al
Вот как возрастёт адово, так только можно до бизнеса будет достучаться ) Ещё к тому времени 90% команды свалит нахуй
Gordey
Не занимайтесь преждевременной оптимизацией дети мои
Gordey
*сказал он и ушел рефакторить*
Таймураз
Лучше с самого начала просто писать нормальный код без алгоритмических ухищрений. Чтобы позже с ним было легче работать. А потом уже вдуматься в алгоритм работы и, если надо, оптимизировать
Таймураз
Это не занимает так много времени, как кажется, однако в будущем читабельный код спасет от лишнего рефакторинга и пучок нервов
KlonD90
Да ну время сделать хорошо обычно бывает 1 раз в самом начале фичи. Тут конечно зависит от того насколько вы понимаете бизнес требования. Типа что сегодня они просят сделай а вы понимаете что через год будет фича б и имеете какую-то архитектуру готовую масштабироваться к этому.
Vladislav
Ахах, не думаю, что мой работодатель так думает)
Угу, работодатель вообще редко о таком думает (:
Vladislav
У говнокода есть только один минус – если его не подравнивать иногда, то можно пройти точку невозврата, когда поддержка начнет занимать больше времени, чем разработка фич
Владимир
просто некоторые люди любят устроить НИИ в своей конторе
Roman
"детские болезни" разработчиков
Ohar
+
Ohar
Некоторые причём не видят в этом проблемы
Roman
уровень опыта и компетенции не позволяет
все через это проходят
Anonymous
Вот вы все про технический долг рассуждаете, а проблема большинства стартапов в UX и самом продукте и часто приходится на ходу менять интерфейсы и бизнес-логику, поэтому ни о каком продумывании правильной архитектуры вообще речи идти не может и пока вы ничего не продаете и нет ни какой маржинальности у проекта, нехер и думать об технической части, под которой большинство подразумевают успевать за всеми трендами кодерских нововедений. Но вот почему то я сам ни как не могу следовать этому правилу
Ohar
Всё так
Slava
Ну да, мы начинали проект с экпертизой в backbone, а сейчас тяжело переезжаем на React, потому что нет возможности сделать sustainable service на коде, который непонятно откуда выстреливает событиями. Вот она "техническая часть" :)
Владимир
Ну да, мы начинали проект с экпертизой в backbone, а сейчас тяжело переезжаем на React, потому что нет возможности сделать sustainable service на коде, который непонятно откуда выстреливает событиями. Вот она "техническая часть" :)
может просто стоило потратить время на то чтобы причесать и написать хорошую доку по событиям в бекбоне
Slava
С технологиями работают люди, люди как правило имеют амбиции, хотят фана, страдают перфикционизмом, а еще хотят не устаревать с точки зрения знаний.
Slava
Где тут бэкбон
Slava
И второй вопрос, риторический - поможет ли дока разгрести те проблемы, которые просто отсутствуют на другой технологии :) Но в чем-то вы правы. да