Егор Бугаенко - Не думайте о качестве, думайте о скорости

[@MaximGorbatyk]

Мне кажется, что выкрикивание из зала вопросов в процессе доклада должно пресекаться на корню модераторами. Такое выкрикивание сбивает докладчика с мысли, прерывает сам доклад, а еще не факт, что ответ на вопрос не будет дальше дан в ходе доклада и дальнейших тезисов. К тому же, аудитория вынуждена выслушивать вопрос от того, кто внезапно порешал, что его вопрос гораздо важнее, чем у остальных. Это, как минимум, невежливо и по отношению к докладчику, и по отношению к аудитории. А сам доклад хороший. Доводить до абсурда следование рекомендациям я бы не стал, но привнес бы многое в свой проект в той или иной степени.

[@TheGeorgich88]

Это Барух выкрикивал, он вроде бы там и был модератором)

[@Weeb1367]

Тайтл звучит как пост мета ирония

[@anton.lobanov_co]

Пересмотрел кучу твоих видео, я просто в шоке) ты говоришь совершенно гениальные вещи! Радикальные идеи, но мне кажется очень верные. Это все круто и должно стать мэйнстримом).

[@lvn5609]

Либо он останется в истории как городской сумасшедший, либо он просто опередил свое время.

[@alexanderspeshilov839]

@@lvn5609 И то, и другое :)

[@stanislavzemlyakov5442]

Думаю, в те времена Егора мало кто понял. Потому и булили. Сейчас пересматриваю и во многом согласен.

[@TopToro]

О норм доклад от Егора) а думал, что снова будет стендап на тему ООП)

[@linkernick5379]

И тут такой Warcraft 3 Reforged - бац!

[@kryanod]

Начало на 4:46

[@romanandriyanov204]

я очень ждал услышать что-то новое, но когда ты все это используешь уже 4 года и слушаешь про это как что-то новое в 2019, это очень странно

[@ГлебВалерьевич-у6ы]

Спасибо. Было интересно

[@mrin0]

2:22

[@RomanVasilevich]

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

[@uasco-da-gama]

48:38 Разве здесь нет конфликта интересов? Девелопер будет пытать писать код с наибольшим кол-вом багов, а затем исправлять его, чтобы повысить себе зарплату.

[@TopToro]

Если кволити гейты настроены так как говорит докладчик, то не получится

[@roman-romadin]

Другие разработчики это не позволят (по идее). Один ревьювер твой коллега и второй ревьювер архитектор.

[@roman-romadin]

И плюс, разве нет в текущем порядке разработки, что один незаменимый Герой фигачит и фигачит фичи. А потом оказывается, что в погоне за ЗП/KPI/etc - он накопил такой ТехДолг и столько багов, что вся остальная команда офигевает. Но Герой он же Герой, Молодец! Не говоря уже о новом сотруднике, для которого из-за таких геройств порог вхождения вырастает в разы.

[@daedaliusX]

@@roman-romadin Жиза. Знаю ситуации когда разработчик очень продуктивно решал задачи. Но то КАК он это делал ставило крест на всем сопровождении.

[@karelalex]

@@daedaliusX Я в такой работаю, у нас проекту года нет, но благодаря одному такому быстроделу у нас есть куча "легаси" куда ни я, ни коллеги лишний раз залезать не хотят. Сам товарищ куда-то ушёл.

[@VinnySanPuhimoto731]

*0:02** программа не запустится кста)*

[@etojan]

ДА ТЫ ЧТО

[@asperanskiy]

В моей стране все хорошо, нет багов!

[@alexnov2930]

А ты кто такой? Чьих будешь?

[@igorpi25]

Fear Driven Development))

[@annamikhaylova4851]

Очень понимаю заказчиков, которые не хотят платить больше за 200 ошибок в этом месяце, если в прошлом месяце ошибок было 100. Политика "скорость превыше качества", возможно, подойдет при разработке ПО, где пользователь готов мириться с большим количеством ошибок (хотя лояльность пользователей от увеличения багов будет скорее всего снижаться), но вряд ли она будет применима для разработки ПО, критичного к сбоям (финансы, медицина, авиация и т.д.). Попытка переложить ответственность с разработчика на pipeline разработки плоха тем, что pipeline не имеет интеллекта, в отличие от разработчика: проблемы в принципиально новом коде сможет рассчитать и предсказать человек, но не сможет определить автоматическая "система приема кода в master-ветку", разве что вы наделите ее искусственным интеллектом.

[@TopToro]

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

[@АнтонДудкевич]

вы не поняли ни слова из доклада.

[@компаниядоставкиЕдадомой.ру]

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

[@Morrado]

Название кликбейтное конечно. Очевидно, что скорость не решает. Если кто-то делает быстро - скорее всего там все плохо и не с точки зрения багов. Баги - это хорошо, соглашусь. Процесс - один из ключевых моментов, тоже согласен. Как быстро кто-то на кнопки жмет скорости не прибавляет, только говонокода. Парить разаба продом - это вообще прикол. Аналитик напилил что нужно по задаче, разраб сделал, написал юнит-тесты, отдал автотестеру, после пройденых автотестов разрабу уже пофигу что там дальше. Что там на проде - пофиг. Нашли баг - тоже пофиг, пока не создали задачу на фикс. И никакого страха.

[@alexperemey6046]

Да вроде мысль доклада немного не такая. Т.е. речь не о скорости написания кода программистом.

[@mityabor]

У Егора прям стендапы, а не технические доклады. Забавно смотреть.

[@TopToro]

Про ооп реально смешно) А вот этот дтклад норм. Только вот имидж уже у него испорчен и все, что бы он не говорил, уже трудно воспринемать серьёзно

[@shchadenko]

@@TopToro что именно у него смешного про ООП?

[@TopToro]

@@shchadenko "декоратор - лучший паттерн, если декоратор не помог, нужно сделать ещё один"=) На самом деле я понимаю обиду Егора на современное "ООП", и считаю, что смех смехом, а задуматься, есть над чем. Хотя вот недавно набрёл на его статью, что jaxb это плохо, надо парсинг инкапсулировать в самом объекте. Не прям чушь конечно, но категоричность опять же только насмешила, если так делать в интерпрайзе будет очень много боли. В целом неоднозначный спикер, вот у меня и не однозначное мнение о нем.

[@lvn5609]

@@TopToro зато интересно. По крайней мере не оставляет безразличных слушателей.

[@НикитаГлухов-п5ю]

@@TopToro Были бы его рассуждения со ссылками на куски реального кода (какого-нибудь опенсорса хотя бы), где он видит минусы и плюс + если бы показывал, как "сталкивает решения лбами" и на практике показывает эффективность - цены бы ему не было. А так он просто ООП-фашист. С сугубо индивидуальным пониманием темы.

[@MaximZemlyanoy]

идеалист )

[@Ryurix]

Хороший программист пишет код который не порождает баги в будущем. Это прозрачный и понятный код.

[@1Virkom]

Потом появляется второй хороший программист и пишет свой прозрачный и понятный код. И потом эти два кода встречаются и начинают плодить баги.

[@zemafon]

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