Принцип хорошего кода YAGNI ("You aren't gonna need it")

[@__homelander__]

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

[@promiskuitet]

Не знают о границах своих должностных обязанностей, потому что в 90%+ отечественных айти компаний нет элементарных job description для каждой роли и умения их правильно коммуницировать и управлять. Подозреваю, что не только в айти.

[@alexhali6003]

Прикольная фича: "Заказчику понравится..." и наезд камеры....Прям нагнал саспенса. Еще бы музыку из Психо наложить, и прям как начало хоррора)

[@OlavLadnav]

12:05 Известно же, что любую незнакомую кнопку в интерфейсе следует нажимать четное количество раз :)

[@adeusexmachina]

а что если это не toggle кнопка, а какой нибудь инкремент, ускоритель или чистильщик)

[@shitposting_box]

@@adeusexmachina одной рукй нажимать, второй креститься, третьей и четвертой держать пальцы на alt+f4

[@Leo_Leonidze]

Очень хороший контент для разработчиков, которые уже работают, таких мало. Спасибо 🤙🏻

[@Lammax2012]

Как всегда, классно и по делу! Спасибо!

[@АлександрИванов-ы2ч9з]

Благодарю Вас, отличные ролики! Хорошо вправляют мозг, на то место где он должен находится :-)

[@kurbankurbanov1547]

Однозначный лайк за объяснение и особенно за последний пример)

[@DeddyShot]

Сергей, спасибо за отличный выпуск! Привет Вам из Санкт-Петербурга, тестировщики Вас смотрят!)

[@antontevs]

С ремонтом и картиной, прям в точку!

[@mr.targimskiy3215]

Крутой мужик 💪🏻

[@vitalyromas6752]

Дякую, корисне відео, дуже на часі ). Особливо сподобалось чітке пояснення "розробник надає варіанти технічних рішень і інфо про наслідки, але саме замовник обирає технічне рішення." Світло, фон - класні, як і звук.

[@androidkasha]

Автор живет в идеальном мире где заказчик предоставляет полное ТЗ к проекту?

[@alekseiismirnov4705]

Золотые слова... Оно бы и вообще для жизни это использовать.

[@cheefoxcheefox2372]

- Почему мы не переходим на новые технологии? Они же более гибкие, экономят время разработчиков и орехи заказчика! - Потому что я не намерена экономить ни чужое время, ни чужие орехи! (ц)

[@dimageorgiev5798]

хороший формат спасибо вам

[@romantsyupryk3009]

Дуже дякую ваз за це відео.

[@NecroRomnt]

Подача дискуссионная. YAGNI для разработчиков прежде всего (мы же разработчики, ведь так?), но в ролике говорится про кражу денег, про менеджмент. Я поработал и украл деньги. Такую работу можно классифицировать как некачественную, но ни как не как кражу. Мне кажется стоит рассматривать этот вопрос с точки зрения разработки. Был хороший пример про лишнюю библиотеку логирования.

[@NecroRomnt]

@@firstnofate вот это вы зря.

[@agentr227]

было бы интересно посмотреть видео о том, как устанавливать цену за свои услуги.

[@MusinMihail]

Просить сколько хочется, и уменьшать, если не заплатили. Или увеличивать в следующий раз, если заплатили.

[@agentr227]

@@MusinMihail схема проверена?

[@aidynomirtay2139]

Agent Rediska по крайней мере схема выглядит очень заманчиво

[@homo-ergaster]

Есть 2 варианта: 1. All Inclusive. Когда к вам приходит заказчик с расплывчатым ТЗ или вообще без ТЗ и говорит, хочу, например, приложение чтобы запускать ракеты. И вы ему говорите очень завышенную цену просто включая в нее весь предполагаемый гимор и практически все что только можно туда включить. По такому принципу, например, работает студия Лебедева. 2. Вы требуете от заказчика предельно четкое и детальное ТЗ, примерно оцениваете трудозатраты на каждую фичу, умножаете на 20% (чтобы исключить возможные моменты, которые вы не учли), а затем умножаете на вашу ставку.

[@agentr227]

@@homo-ergaster спасибо большое за ответ, очень прояснил ситуацию😋

[@evisotskiydev]

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

[@vt236]

Надо смотреть конкретный случай, например заказчик чаще всего не попросит установку Dynatrace или ELK, но без этого разработка будет страдать в будущем

[@Brick87Game87]

Спасибо за видео)

[@Сергей-н7ъ1д]

Класс! Очень познавательно!

[@noklakek7363]

Круто, Модно, Современо.

[@aethernova]

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

[@maxlich9139]

тогда это принцип поцелуя)

[@vargvarg7922]

спасибо, классно подаешь инфу

[@vovayatsenko1524]

Здравствуйте. Можете рассказать в чем разница между Inversion of Control, Dependency Inversion Principle and Dependency Injection ?

[@writetoyourdestiny]

Про Dependency Inversion Principle уже есть видео на канале, поищи видео про SOLID т.к. это принцип входит в эту аббревиатуру.

[@vovayatsenko1524]

@@writetoyourdestiny я знаю, но наглядно рассмотреть и определить разницу межну ними очень было бы интересно)

[@12316231231231239]

Inversion of Control (Инверсия контроля) - так называется прием, когда инициализация объекта (вспомогательная функциональность) выносится за пределы тела класса, в этом случае контроль инициализации смещается (инвертируется) от разрабатываемого класса в сторону клиентского кода (где этот класс планируется использовать). Dependency Inversion Principle (Принцип инверсии зависимостей) - так называется прием из good practice SOLID, он говорит нам о том, что элементы разрабатываемой системы (поскольку речь идет об ООП, то под элементами следует понимать проектируемые классы) должны зависеть от абстракций (interfaces, abstract classes), а не от деталей (конкретных реализаций этих интерфейсов). Dependency Injection (Инъекция зависимостей) - так называют механизм внедрения зависимостей в проектируемый элемент (класс) системы - это и есть конкретная реализация приема IoC, когда инициализация объекта отделяется от его использования. Таким образом, эта работа (по инициализации) смещается на Dependency Container (DC), но это уже потроха DI. Советую Роберта Мартина, у него достаточно понятно и доступно все это описано.

[@ВладиславГиров-я9я]

респект за футболку.Vielen Dank aus Deutschland!)

[@svyatoslavs945]

Я этот принцип себе понимаю иначе: приходит заказчик или продакт оунер и говорит: а давайте зафигачи вот такую свистоперделку! И задача аналитика или архитектора объяснить, что эта хрень не нужна для выполнения бизнес-задачи, а время-силы-деньги отнимет ) Немного подумал и понял, что эти подходы скорее дополняют друг-друга, чем противоречат )

[@bashconsole]

Очень забавно... представил как группа спецов две недели бьется над портированием и на третью решает заглянуть в исходники и посмотреть почему не работает. Фантастический фильм просто.

[@IPWchild]

Ну хорошо, а рефакторинг? Когда заказчик постоянно хочет срочно реализовывать новые функции, в коде снежным комом накапливается то, что по-хорошему надо переписать нормально, но это происходит... Никогда. Может, имеет смысл закладывать рефакторинг старого кода в новые задачи, даже если заказчик этого не просил? Или про это есть другой принцип?

[@lyloo6577]

А Сергей об этом уже где-то рассказывал. Вроде мысль была такая: делай рефакторинг когда нужно, а заказчику говори что делаешь фичу

[@AlexS-gn9tq]

народная мудрость гласит: никогда нет денег и времени чтобы сделать сразу нормально, зато всегда есть сколько угодно ресурсов на то чтобы переписать заново, когда оно станет необслуживаемым. :(

[@RomanGoncharenya]

В целом согласен, но есть нюансы. Тут зависит насколько качественно и относительно быстро (с точки зрения ваших трудозатрат) сделана доп. фича. Если это качественная и приятная мелочь, то это плюс к впечатлению о вашем продукте. Это, как комплимент от шеф-повара. И кто знает - может, когда у заказчика будет в дальнейшем выбор идти делать к вам или к другому разработчику, то чаша весов качнется в вашу сторону. С другой стороны, бывают ситуации (на самом деле сплошь и рядом), что на этапе прототипирования (и составления ТЗ) не видно какой-то косяк с UI или логикой использования. И, если сделать "тупо по ТЗ", то получится не то пальто - будет неудобно или более подвержено ошибкам ввода со стороны пользователя и т.п. Можно, конечно, "включить дурака" и прикрыться "ну так в ТЗ так написано", но лучше сразу сделать правильно (даже, если это будет и бесплатным допом) - вы, в конце концов, эксперт или кто? Как минимум, нужно сигнализировать об этом клиенту (а это тоже, между прочим, трата времени). А исходя из логики YAGNI нужно просто "забить" и делать "как сказали".

[@RomanGoncharenya]

Да, и еще, кстати. С точки зрения заказчика тестирование - это и есть "ненужная фича", которая для него и является YAGNI. Мало найдется заказчиков, готовых за это дополнительно платить. Это же не значит, что теперь не делать тестирование.

[@torrvic1156]

А после этого вы будете делать заказчику минет по его первому соизволению 😂

[@arsenytsypushkin9725]

Данное мнение эксперта из области относится по большей части только к разработке для внешнего заказчика. Для собственного продукта компании все может быть немного не так. Не так уж и много документации в тех проектах, которые еще в начальной стадии разработки. Описания задач могут быть крайне размыты. Документации много где нет, и проект может быть только в прототипе или раннее MVP и вы хотите посмотреть, как пользователь оценит функциональность вашего продукта. Увидел мнение в комментарии выше и поддержу в своем - YAGNI, по моему мнению, это про усложнение функциональности, когда это не надо. Если разработчик видит реальный профит, который поможет своей компании стать лучше - always welcome.

[@Арлекинок]

О, помню у тебя лекция на 1:40 на канале лежит на эту тему (точнее ты ее затрагивал)

[@vladgonchar]

Все верно! Спасибо за озвучку!

[@milordplus]

Круто!

[@numrik-si]

А де ви бачили щоб замовник знав яка йому потрібна реалізація? Йому вихідна картинка повинна подобатись.

[@МурадАхмедов-ч1с]

Скажите пожалуйста, нарушается ли принцип YAGNI, если например в классах добавлены свойства, которые сейчас не используются, но будут использоваться, когда будет добавляться функционал, где то через неделю например? И второе нарушается ли принцип, если в функциях используется закоментированный кусок кода, типа пригодится через неделю, когда добавиться функционал?

[@gaitavr1992]

Сталкивался с людьми, которые маскируют подобные выходки под "гибкость" системы, мол легко можно будет расширять. Хотя никто вначале пути не знает, в какую сторону будет двигаться проект)

[@adeusexmachina]

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

[@kprohorow]

Прикольно що це все схоже на принцип з трансактного психоаналізу. Не давай порад та не роби людині послуг яких вона не просила)

[@DmitriyFromRiDDerrr]

Инициатива наказуема в программировании не оплачиваемая, а гавнокод всегда актуальный ))

[@Alex11Fox]

наказуемо не только в программировании но и везде

[@SlavaCh]

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

[@zencrazycat]

@@funky_hedgehog Бывают заказчики, которые складывают часть своих обязанностей на разработчиков и просят, чтоб они предлагали свои идеи и фичи, и участвовали в планировании продукта. Но, это очень спорный момент, насколько это правильно.

[@lampyrishive]

Лучше тогда писать код с учётом того что если эту фичу надо будет делать, то чтобы потом не пришлось весь код рефакторить, или костылить . И если надо будет - то делать за отдельную плату :) И без обмана и если что - проще интегрировать.

[@ДмитрийКвитка-х6р]

почему на странице курса QA не описаны требования к абитуриенту?

[@АлександрНевельский-л2з]

Ну тут есть ещё одна сторона: вряд ли заказчик заказывал написанные тесты :) Но их всё равно стоит делать.

[@АнатолийПоленичко]

Спасибо. есть огрехи реклама в перед окончанием мешает поставить лайк так потому что ее сразу закрывают вместе с видео.и есть орф. ошибка на сайте в по рекламме QA Automation "Кто знаком с ручным тестированте";)."

[@wunderrus]

Не выпендриваться и делать то, что сказали. Вот и весь принцип)

[@mr_brawlstars9601]

Есть вопросик к вам. Один человечек порекомендовал мне заниматься программированием и сказал про ваш канал и приложение на телефоне Sololearn. Но возможно он не учёл что мне всего 14 лет и я ничего не понимаю в программировании от слова совсем. Так вот, можете подсказать с чего начать и кто мне объяснит все основы программирования прежде чем переходить на изучение языков. (В школе мы затрагивали эту тему, но мне кажется Программа ABC это совсем другое)

[@DiMaS-to2hz]

Вводишь в гугле "(название нужного тебе языка программирования) для начинающих" и смотришь миллиарды миллионы гайдов. Конкретно на этом канале есть плэйлисты "Java для начинающих" и "Лекции по основам джавы"

[@11lvr11]

Я выучила SQL в Sololearn и на Ютубе. Сейчас учу C++, полет нормальный. На второй день изучения C++ уже постоянно практикуюсь, пишу простенькие программы из того, что выучила. ( Простая арифметика, например, или попросить пользователя ввести число) Я сейчас не шучу и не выпендриваюсь, поверьте, это возможно. У меня экономическое образование и опыт программирования в школе на информатике. Как бы банально это не звучало, но "чтобы научиться программировать ,нужно начать программировать", при этом, конечно, учить теорию перед этим. А если вы ещё совсем ничего не знаете, почитайте, как работает компьютер и интернет, почитайте историю программирования и первых языков.( Так делала я) Не стоит бояться, а то так можно никогда не начать. Удачи!

[@yaolegoleynik]

Спасибо

[@Имя-ц7к]

Мои коллеги используют принцип YAGNIDA

[@classborkau5551]

Сергей, а где серебряная кнопка ютубовская?

[@maxlich9139]

0:14 Подумал, что он говорит, что нам не понадобится знать расшифровку этого принципа))) (а то и сам принцип))) )

[@nelkor3427]

6:17 пять, десять, пятнадцать минут пятого

[@MrChamber1]

Грустная история про строчку кода и 3 недели поиска...

[@alexandrkruglyak]

"Вам это не понадобится короче" - можно выключать xD

[@fairplay6113]

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

[@AlexS-gn9tq]

Так а чем по большому счету отличается в этом случае продуктовая компания? Разве что тем, что свою идею можно вынести на обсуждение. За самовольное добавление не запрашиваемого бизнесом функционала, который не прошел этапы бизнес анализа, формулировки требований и тд. точно так же никто спасибо не говорит

[@ruslanzaporojets7021]

Пример с логгером не до конца расскрыт. Как знать что простой и удобный сейчас инструмент, завтра будет причиной проблем. Возможно он повышал продуктивность.

[@msvru]

Знал-бы где упаду - соломки подстелил-бы. Знал-бы что в будущем взбредёт в голову заказчику, реализовал-бы в коде заготовку для этого.

[@voronow3]

Принцип минимализма?

[@crutchmaster9637]

Так это же наше "не нужно". Всё не нужно, если явно не указанно обратное.

[@Alex11Fox]

Рекламная пауза, на "Поле Чудес"!!!

[@ДмитрийВершинин-й9з]

Интеллигентнейший человек: "Мы прот№;хались две недели из-за ср№ной строчки". Как это, Б(лин), знакомо. Так выпьем же за пи%дец в цехе!

[@nanvlad]

You ain't gonna need it - так проще прочитать)

[@denyszorin8675]

Средней зп в 3 тыс долларов... что-то я не так делаю видимо 😀 Или там тима чисто из сеньойоров ?)

[@viktormaloshuk2564]

это зп мидла, синьоры-помидоры больше получают свежую статистику по зп на доу.юа можно посмотреть

[@denyszorin8675]

Viktor Maloshuk я больше смотрю на реалии рынка в моем городе а не статистику на сайте :) я живу в Познани (Польша), то регуляр (около 4 лет опыта) может получать 1.5 - 2 баксов... конечно есть ребята которые берут 3-4 на этом же уровне, но это скорей исключения :)

[@viktormaloshuk2564]

@@denyszorin8675 мы же говорим о чистой сумме после налогов? 2к получают после 1,5-2 лет, а дальше на +500 каждые полгода :) понятно чего плачут те кто уехал

[@denyszorin8675]

Viktor Maloshuk ну вот только если в корпо попадёшь то такие зп. А так весь мелкий бизнес платит не так много. При зп у людей тут в 600-1000 долларов на обычной работе, то 2 тыс не так уж и плохо кажется для своих то годов 😂

[@AlexS-gn9tq]

@@viktormaloshuk2564 где же все эти мифические конторы, где каждые пол года +500? С кем ни говорил на эту тему, все описывают один и тот же сценарий: для повышения ЗП приходится менять место работы.

[@alexpetrov2531]

гуд инглиш лангуге, мир гефэльт

[@AK-ji3qv]

эээ... я извиняюсь, а в ресторане был не обман?)))

[@borshch334]

А че реально програмеры перед написанием кода не обмазговуют все? Типо ищат парадоксы и тп. И при написании кода проверяют функции на работоспособность и не коментируют ихнюю задачу?

[@proKaps]

придумали в общем всяких аббревиатур, чтобы джунов на собеседованиях мучить

[@winter-lb7id]

Работаю программистом год. Смотрю уже третье видео, в котором говориться что мол не делайте то, что не просят. Вам что, СТП не пишут о том, что конкретно нужно реализовать? На пальцах объясняют? Как вообще можно в здравом уме начать реализовывать то, о чем тебя не просили?

[@bloodborn9632]

В конечном итоге за бесплатные фичи раплачивается тот кто потом сопровождает эту туеву кучу когда которая написана просто так но за которую потом спрашивают :))

[@davyknight1891]

Это что за вода за 300 гривен?

[@ИванНикитин-ч7б]

You ain't gonna need it. Ю эйнт гона нид ит.

[@andrewzaitsev6668]

2 недели на то чтобы узнать несовместимость версий библиотек... ну либо java плохо ошибки выводит, либо вы что то не то смотрели... конечно же печальная история...

[@МихаилВикторович-р2я]

5-7-8-10-15 минут пятого

[@ОсокинВадим-и4я]

Всегда думал, что YAGNI это про то чтобы объяснить заказчику что его задачу можно решить уже имеющимися средствами, вместо создания нового функционала. Но наверное это не про заказную разработку)))

[@acrrono]

ну ладно, второй

[@no101vmv]

копец у вас там зарплаты

[@daniyarkokabayev8453]

YAGNI - это неиспользуемые сниппеты, в том числе закомментированные, и ненужный оверхед. А на видео поток мыслей вперемешку с прохладными историями

[@СергейКондратенко-о9ц]

на видео как раз объяснение на примерах, почему сниппеты и оверхед - это плохо

[@anti1am3r]

@@СергейКондратенко-о9ц примеры откровенно говоря тухлые. Особенно про логирование

[@МихаилВикторович-р2я]

Украли деньги либо у заказчика, либо у работодалеля, либо у себя (если вне рабочее время)

[@olezhonnv3215]

Это где такая вода, за 300 гривен? Что-то за пределами здравого смысла. Может 30 гривен? Ну потому что 300 - это золотая вода должна быть.

[@olezhonnv3215]

Ресторан для олигархов?

[@SergeyNemchinskiy]

Ну, неудачно заехали в ресторан. Самое главное, что назывался он простенько, мы рассчитывали, что это вообще кафе

[@АртурМ-ч4х]

Первый...ну вы поняли )

[@АлександрМамзиков-х1у]

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

[@sergeyleluk9501]

Сергей, поправьте, пожалуйста очки. Немного жутко смотреть на человека, когда глаза на разных уровнях по вертикали.

[@sardaucar]

Ну вот, футболка уже не с Украиной...

[@CensorsGoToHellWatchKittens247]

5:00 - Извините, но не могу с вами согласиться. Что за "перенести на другой проект", "уменьшили его прибыль". Нет уж, воровство это вороство. В случае с заказчиком - да, это воровство. В соответствии со здравым смыслом. А в случае с работодателем это воровство исключительно в терминах эксплуатации людей друг другом. И вообще, не работодатель ли обворовывает своих работников, (1) определяя их зарплату, выгодную для него, и (2) используя их способности для реализации своих бизнес-задач? ;) А в остальном (кроме 13:48) полностью согласен, хороший принцип. В контексте выполнения чужих заказов, разумеется. Про ядерный реактор прикольный пример))

[@CensorsGoToHellWatchKittens247]

Прикол в том, что в идеальном мире не должно быть вообще никаких "работодателей" и каждый должен работать на себя (ну или на друзей, когда это нужно) ) Если работник соглашается работать за зарплату, выгодную для него, то это значит лишь то, что он знает себе цену. И это норма. А вот считать ли это воровством... Допустим, в качестве абсурдного примера, $1000000 за Hello World? Может, это и воровство, вот только в рамках экономики это будет, внезапно, нормой, т.к. кто какую цену за свои труды хочет, тот такую и устанавливает. Другой вопрос, что в рыночной экономике это вполне может и не сработать - просто купят (у) кого-нибудь другого. И вот, вроде бы, такая нормальная вещь, как знание цены себе, превращается в такую плохую вещь, как воровство (абсурдный пример выше был просто абсурдным примером - можно использовать более адекватные примеры, но суть не изменится). Почему? А ответ простой: из-за экономики. Ну, я сразу написал: "А в случае с работодателем это воровство исключительно в терминах эксплуатации людей друг другом." К чему последний абзац я, если честно, не понял. Эта тема, когда заказчику передаются исключительные права - вообще отдельная песня)

[@worker9249]

//потратитить время на ненужную функцию(//