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

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

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

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

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

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

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

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

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

Начало на 4:46

Fear Driven Development))

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

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

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

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

2:22

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

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

идеалист )

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

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

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

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

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