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

Рет қаралды 49,517

5 жыл бұрын

Ближайшая конференция - Joker 2024, 9 октября (Online), 15-16 октября (Санкт-Петербург + трансляция).
Подробности и билеты: jrg.su/Ypf1HW
- -
. . . . Егор известен своими провокационными заявлениями со сцены, постами в социальных сетях, печатными изданиями и статьями в своем блоге. В этот раз он затронет тему качества ПО и того, почему, как ни странно, качество кода даже близко не является задачей разработчика, а является необходимым условием рабочего окружения. Это спорное заявление он будет отстаивать все 50 минут доклада.
Егор твердо уверен, что программисты должны думать не о качестве, а только о скорости. Они должны стремиться как можно быстрее закрывать задачи, чтобы проект не стоял на месте.

Пікірлер: 45

@MaximGorbatyk 4 жыл бұрын

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

@TheGeorgich88 4 жыл бұрын

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

@anton.lobanov_co 3 жыл бұрын

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

@lvn5609 3 жыл бұрын

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

@alexanderspeshilov839 3 жыл бұрын

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

@stanislavzemlyakov5442 Жыл бұрын

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

@user-qx3jt8fw1v Жыл бұрын

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

@kosto238 3 жыл бұрын

Надо не скорость против качества, а исключить догматику. Егор периодически дает хорошие идеи, но решать где они эффективны и уместны стоит в конкретных проектах. Где-то да гдето нет

@kirillsh8383 3 жыл бұрын

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

@liamsmith7052 3 жыл бұрын

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

@RomanVasilevich 4 жыл бұрын

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

@kryanod 2 жыл бұрын

Начало на 4:46

@VinnySanPuhimoto731 3 жыл бұрын

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

@etojan 3 жыл бұрын

ДА ТЫ ЧТО

@mrin0 3 ай бұрын

2:22

@igorpi25 Жыл бұрын

Fear Driven Development))

@user-sz7kt8nf1m 3 жыл бұрын

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

@Morrado 5 ай бұрын

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

@alexperemey6046 4 ай бұрын

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

@MaximZemlyanoy 3 жыл бұрын

идеалист )

@Ryurix 3 жыл бұрын

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

@1Virkom 3 жыл бұрын

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

@zemafon 3 жыл бұрын

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

@linkernick5379 4 жыл бұрын

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

@TopToro 5 жыл бұрын

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

@romanandriyanov204 4 жыл бұрын

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

@asperanskiy 4 жыл бұрын

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

@alexnov2930 2 жыл бұрын

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

@uasco-da-gama 5 жыл бұрын

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

@TopToro 5 жыл бұрын

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

@roman-romadin 4 жыл бұрын

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

@roman-romadin 4 жыл бұрын

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

@daedaliusX 4 жыл бұрын

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

@karelalex 3 жыл бұрын

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

@mityabor 4 жыл бұрын

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

@TopToro 4 жыл бұрын

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

@shchadenko 4 жыл бұрын

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

@TopToro 4 жыл бұрын

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

@lvn5609 3 жыл бұрын

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

@user-gh8sg8nr4w 3 жыл бұрын

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

@annamikhaylova4851 4 жыл бұрын

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

@TopToro 4 жыл бұрын

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

@user-dd1di2fv6i 2 жыл бұрын

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