Мне кажется, что выкрикивание из зала вопросов в процессе доклада должно пресекаться на корню модераторами. Такое выкрикивание сбивает докладчика с мысли, прерывает сам доклад, а еще не факт, что ответ на вопрос не будет дальше дан в ходе доклада и дальнейших тезисов. К тому же, аудитория вынуждена выслушивать вопрос от того, кто внезапно порешал, что его вопрос гораздо важнее, чем у остальных. Это, как минимум, невежливо и по отношению к докладчику, и по отношению к аудитории. А сам доклад хороший. Доводить до абсурда следование рекомендациям я бы не стал, но привнес бы многое в свой проект в той или иной степени.
Пересмотрел кучу твоих видео, я просто в шоке) ты говоришь совершенно гениальные вещи! Радикальные идеи, но мне кажется очень верные. Это все круто и должно стать мэйнстримом).
48:38 Разве здесь нет конфликта интересов? Девелопер будет пытать писать код с наибольшим кол-вом багов, а затем исправлять его, чтобы повысить себе зарплату.
И плюс, разве нет в текущем порядке разработки, что один незаменимый Герой фигачит и фигачит фичи. А потом оказывается, что в погоне за ЗП/KPI/etc - он накопил такой ТехДолг и столько багов, что вся остальная команда офигевает. Но Герой он же Герой, Молодец! Не говоря уже о новом сотруднике, для которого из-за таких геройств порог вхождения вырастает в разы.
@@daedaliusX Я в такой работаю, у нас проекту года нет, но благодаря одному такому быстроделу у нас есть куча "легаси" куда ни я, ни коллеги лишний раз залезать не хотят. Сам товарищ куда-то ушёл.
Очень понимаю заказчиков, которые не хотят платить больше за 200 ошибок в этом месяце, если в прошлом месяце ошибок было 100. Политика "скорость превыше качества", возможно, подойдет при разработке ПО, где пользователь готов мириться с большим количеством ошибок (хотя лояльность пользователей от увеличения багов будет скорее всего снижаться), но вряд ли она будет применима для разработки ПО, критичного к сбоям (финансы, медицина, авиация и т.д.). Попытка переложить ответственность с разработчика на pipeline разработки плоха тем, что pipeline не имеет интеллекта, в отличие от разработчика: проблемы в принципиально новом коде сможет рассчитать и предсказать человек, но не сможет определить автоматическая "система приема кода в master-ветку", разве что вы наделите ее искусственным интеллектом.
Мне тут на мой многомесячный комментарий ответили, а я пожалуй отвечу на ваш. Мне кажется вы не внимательно посмотрели, там не предлагалось заменить человека, а предлагалось ускорить его работу за счёт автоматизации и некоторой культуры, девопс одним словом. На своем месте остается код ревьюер и тестировщик т.е. люди, просто теперь типичные и самые частые ошибки, может ловить анализатор и люди могут не тратить на это свое время, а тратить его на более серьезные вещи чем какой-нибудь NPE. Но это уже ни особенно то новое, хотя многие почему-то ещё сопротивляются, а вот про доплату за нахождение багов и итеративное усиление пайплайна это прям отличная идея как по мне, про пайплайн вообще достойна быть вписана в какой-нибудь манифест=)
я думал, что пайплайн делается легче, потому что он и так тяжело туда идет, и из-за этого тот самый стресс. а тут предложение сделать его еще труднее, с чего бы это программист начнет этому радоваться - не понятно. автоматизация должна наращиваться и исправляться на новых проектах, релизах крайне постепенно, ибо будет ситуация, что всё пляшет под ногами программиста, и при этом сроки поджимают, не все будут ждать, а отсюда выплывет фактор профессионализма. время - деньги, и этого еще не отменяли.
Название кликбейтное конечно. Очевидно, что скорость не решает. Если кто-то делает быстро - скорее всего там все плохо и не с точки зрения багов. Баги - это хорошо, соглашусь. Процесс - один из ключевых моментов, тоже согласен. Как быстро кто-то на кнопки жмет скорости не прибавляет, только говонокода. Парить разаба продом - это вообще прикол. Аналитик напилил что нужно по задаче, разраб сделал, написал юнит-тесты, отдал автотестеру, после пройденых автотестов разрабу уже пофигу что там дальше. Что там на проде - пофиг. Нашли баг - тоже пофиг, пока не создали задачу на фикс. И никакого страха.
@@shchadenko "декоратор - лучший паттерн, если декоратор не помог, нужно сделать ещё один"=) На самом деле я понимаю обиду Егора на современное "ООП", и считаю, что смех смехом, а задуматься, есть над чем. Хотя вот недавно набрёл на его статью, что jaxb это плохо, надо парсинг инкапсулировать в самом объекте. Не прям чушь конечно, но категоричность опять же только насмешила, если так делать в интерпрайзе будет очень много боли. В целом неоднозначный спикер, вот у меня и не однозначное мнение о нем.
@@TopToro Были бы его рассуждения со ссылками на куски реального кода (какого-нибудь опенсорса хотя бы), где он видит минусы и плюс + если бы показывал, как "сталкивает решения лбами" и на практике показывает эффективность - цены бы ему не было. А так он просто ООП-фашист. С сугубо индивидуальным пониманием темы.
![10 главных причин провала сложных архитектур [ Innopolis University ]](/img/n.gif)
Мне кажется, что выкрикивание из зала вопросов в процессе доклада должно пресекаться на корню модераторами. Такое выкрикивание сбивает докладчика с мысли, прерывает сам доклад, а еще не факт, что ответ на вопрос не будет дальше дан в ходе доклада и дальнейших тезисов.
К тому же, аудитория вынуждена выслушивать вопрос от того, кто внезапно порешал, что его вопрос гораздо важнее, чем у остальных. Это, как минимум, невежливо и по отношению к докладчику, и по отношению к аудитории.
А сам доклад хороший. Доводить до абсурда следование рекомендациям я бы не стал, но привнес бы многое в свой проект в той или иной степени.
Это Барух выкрикивал, он вроде бы там и был модератором)
Тайтл звучит как пост мета ирония
Думаю, в те времена Егора мало кто понял. Потому и булили. Сейчас пересматриваю и во многом согласен.
Пересмотрел кучу твоих видео, я просто в шоке) ты говоришь совершенно гениальные вещи! Радикальные идеи, но мне кажется очень верные. Это все круто и должно стать мэйнстримом).
Либо он останется в истории как городской сумасшедший, либо он просто опередил свое время.
@@lvn5609 И то, и другое :)
И тут такой Warcraft 3 Reforged - бац!
О норм доклад от Егора) а думал, что снова будет стендап на тему ООП)
Начало на 4:46
я очень ждал услышать что-то новое, но когда ты все это используешь уже 4 года и слушаешь про это как что-то новое в 2019, это очень странно
Спасибо. Было интересно
Не знаю где вы тут стендап нашли. Хороший доклад. Глубокие мысли, прошедшие из практики.
2:22
48:38 Разве здесь нет конфликта интересов? Девелопер будет пытать писать код с наибольшим кол-вом багов, а затем исправлять его, чтобы повысить себе зарплату.
Если кволити гейты настроены так как говорит докладчик, то не получится
Другие разработчики это не позволят (по идее). Один ревьювер твой коллега и второй ревьювер архитектор.
И плюс, разве нет в текущем порядке разработки, что один незаменимый Герой фигачит и фигачит фичи. А потом оказывается, что в погоне за ЗП/KPI/etc - он накопил такой ТехДолг и столько багов, что вся остальная команда офигевает. Но Герой он же Герой, Молодец! Не говоря уже о новом сотруднике, для которого из-за таких геройств порог вхождения вырастает в разы.
@@roman-romadin Жиза. Знаю ситуации когда разработчик очень продуктивно решал задачи. Но то КАК он это делал ставило крест на всем сопровождении.
@@daedaliusX Я в такой работаю, у нас проекту года нет, но благодаря одному такому быстроделу у нас есть куча "легаси" куда ни я, ни коллеги лишний раз залезать не хотят. Сам товарищ куда-то ушёл.
В моей стране все хорошо, нет багов!
А ты кто такой? Чьих будешь?
Fear Driven Development))
Очень понимаю заказчиков, которые не хотят платить больше за 200 ошибок в этом месяце, если в прошлом месяце ошибок было 100. Политика "скорость превыше качества", возможно, подойдет при разработке ПО, где пользователь готов мириться с большим количеством ошибок (хотя лояльность пользователей от увеличения багов будет скорее всего снижаться), но вряд ли она будет применима для разработки ПО, критичного к сбоям (финансы, медицина, авиация и т.д.).
Попытка переложить ответственность с разработчика на pipeline разработки плоха тем, что pipeline не имеет интеллекта, в отличие от разработчика: проблемы в принципиально новом коде сможет рассчитать и предсказать человек, но не сможет определить автоматическая "система приема кода в master-ветку", разве что вы наделите ее искусственным интеллектом.
Мне тут на мой многомесячный комментарий ответили, а я пожалуй отвечу на ваш. Мне кажется вы не внимательно посмотрели, там не предлагалось заменить человека, а предлагалось ускорить его работу за счёт автоматизации и некоторой культуры, девопс одним словом. На своем месте остается код ревьюер и тестировщик т.е. люди, просто теперь типичные и самые частые ошибки, может ловить анализатор и люди могут не тратить на это свое время, а тратить его на более серьезные вещи чем какой-нибудь NPE. Но это уже ни особенно то новое, хотя многие почему-то ещё сопротивляются, а вот про доплату за нахождение багов и итеративное усиление пайплайна это прям отличная идея как по мне, про пайплайн вообще достойна быть вписана в какой-нибудь манифест=)
вы не поняли ни слова из доклада.
*0:02** программа не запустится кста)*
ДА ТЫ ЧТО
я думал, что пайплайн делается легче, потому что он и так тяжело туда идет, и из-за этого тот самый стресс. а тут предложение сделать его еще труднее, с чего бы это программист начнет этому радоваться - не понятно. автоматизация должна наращиваться и исправляться на новых проектах, релизах крайне постепенно, ибо будет ситуация, что всё пляшет под ногами программиста, и при этом сроки поджимают, не все будут ждать, а отсюда выплывет фактор профессионализма. время - деньги, и этого еще не отменяли.
Название кликбейтное конечно. Очевидно, что скорость не решает. Если кто-то делает быстро - скорее всего там все плохо и не с точки зрения багов. Баги - это хорошо, соглашусь. Процесс - один из ключевых моментов, тоже согласен. Как быстро кто-то на кнопки жмет скорости не прибавляет, только говонокода. Парить разаба продом - это вообще прикол.
Аналитик напилил что нужно по задаче, разраб сделал, написал юнит-тесты, отдал автотестеру, после пройденых автотестов разрабу уже пофигу что там дальше. Что там на проде - пофиг. Нашли баг - тоже пофиг, пока не создали задачу на фикс. И никакого страха.
Да вроде мысль доклада немного не такая. Т.е. речь не о скорости написания кода программистом.
У Егора прям стендапы, а не технические доклады. Забавно смотреть.
Про ооп реально смешно) А вот этот дтклад норм. Только вот имидж уже у него испорчен и все, что бы он не говорил, уже трудно воспринемать серьёзно
@@TopToro что именно у него смешного про ООП?
@@shchadenko "декоратор - лучший паттерн, если декоратор не помог, нужно сделать ещё один"=) На самом деле я понимаю обиду Егора на современное "ООП", и считаю, что смех смехом, а задуматься, есть над чем.
Хотя вот недавно набрёл на его статью, что jaxb это плохо, надо парсинг инкапсулировать в самом объекте. Не прям чушь конечно, но категоричность опять же только насмешила, если так делать в интерпрайзе будет очень много боли. В целом неоднозначный спикер, вот у меня и не однозначное мнение о нем.
@@TopToro зато интересно. По крайней мере не оставляет безразличных слушателей.
@@TopToro Были бы его рассуждения со ссылками на куски реального кода (какого-нибудь опенсорса хотя бы), где он видит минусы и плюс + если бы показывал, как "сталкивает решения лбами" и на практике показывает эффективность - цены бы ему не было. А так он просто ООП-фашист. С сугубо индивидуальным пониманием темы.
идеалист )
Хороший программист пишет код который не порождает баги в будущем. Это прозрачный и понятный код.
Потом появляется второй хороший программист и пишет свой прозрачный и понятный код. И потом эти два кода встречаются и начинают плодить баги.
На столько хороших программистов, я, за свои жалкие 15 лет разработки, пока не встречал.