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

แชร์
ฝัง
  • เผยแพร่เมื่อ 19 ม.ค. 2025

ความคิดเห็น • 141

  • @__homelander__
    @__homelander__ 2 ปีที่แล้ว +24

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

    • @promiskuitet
      @promiskuitet 11 หลายเดือนก่อน +1

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

  • @alexhali6003
    @alexhali6003 4 ปีที่แล้ว +59

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

  • @Leo_Leonidze
    @Leo_Leonidze 4 ปีที่แล้ว +7

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

  • @OlavLadnav
    @OlavLadnav 4 ปีที่แล้ว +46

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

    • @adeusexmachina
      @adeusexmachina 4 ปีที่แล้ว +4

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

    • @shitposting_box
      @shitposting_box 4 ปีที่แล้ว +18

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

  • @АлександрИванов-ы2ч9з
    @АлександрИванов-ы2ч9з 4 ปีที่แล้ว +15

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

  • @Lammax2012
    @Lammax2012 4 ปีที่แล้ว +21

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

  • @DeddyShot
    @DeddyShot 4 ปีที่แล้ว +5

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

  • @vitalyromas6752
    @vitalyromas6752 4 ปีที่แล้ว +4

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

  • @kurbankurbanov1547
    @kurbankurbanov1547 4 ปีที่แล้ว +4

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

  • @antontevs
    @antontevs 4 ปีที่แล้ว +3

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

  • @cheefoxcheefox2372
    @cheefoxcheefox2372 2 ปีที่แล้ว +3

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

  • @NecroRomnt
    @NecroRomnt 4 ปีที่แล้ว +10

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

    • @NecroRomnt
      @NecroRomnt 4 ปีที่แล้ว

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

  • @androidkasha
    @androidkasha 3 ปีที่แล้ว +5

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

  • @agentr227
    @agentr227 4 ปีที่แล้ว +20

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

    • @MusinMihail
      @MusinMihail 4 ปีที่แล้ว +1

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

    • @agentr227
      @agentr227 4 ปีที่แล้ว

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

    • @aidynomirtay2139
      @aidynomirtay2139 4 ปีที่แล้ว

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

    • @homo-ergaster
      @homo-ergaster 4 ปีที่แล้ว +5

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

    • @agentr227
      @agentr227 4 ปีที่แล้ว

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

  • @alekseiismirnov4705
    @alekseiismirnov4705 3 ปีที่แล้ว +1

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

  • @mr.targimskiy3215
    @mr.targimskiy3215 4 ปีที่แล้ว +7

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

  • @evisotskiydev
    @evisotskiydev 3 ปีที่แล้ว +8

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

    • @vt236
      @vt236 2 ปีที่แล้ว

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

  • @vovayatsenko1524
    @vovayatsenko1524 4 ปีที่แล้ว +18

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

    • @writetoyourdestiny
      @writetoyourdestiny 4 ปีที่แล้ว +1

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

    • @vovayatsenko1524
      @vovayatsenko1524 4 ปีที่แล้ว +4

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

    • @12316231231231239
      @12316231231231239 4 ปีที่แล้ว +8

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

  • @aethernova
    @aethernova 4 ปีที่แล้ว +6

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

    • @maxlich9139
      @maxlich9139 4 ปีที่แล้ว

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

  • @romantsyupryk3009
    @romantsyupryk3009 4 ปีที่แล้ว +2

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

  • @ВладиславГиров-я9я
    @ВладиславГиров-я9я 4 ปีที่แล้ว +1

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

  • @numrik-si
    @numrik-si ปีที่แล้ว +1

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

  • @arsenytsypushkin9725
    @arsenytsypushkin9725 4 ปีที่แล้ว +3

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

  • @IPWchild
    @IPWchild 4 ปีที่แล้ว +8

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

    • @lyloo6577
      @lyloo6577 4 ปีที่แล้ว +1

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

    • @AlexS-gn9tq
      @AlexS-gn9tq 4 ปีที่แล้ว +3

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

  • @dimageorgiev5798
    @dimageorgiev5798 4 ปีที่แล้ว +2

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

  • @noklakek7363
    @noklakek7363 4 ปีที่แล้ว +2

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

  • @RomanGoncharenya
    @RomanGoncharenya 4 ปีที่แล้ว +4

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

    • @RomanGoncharenya
      @RomanGoncharenya 4 ปีที่แล้ว

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

    • @torrvic1156
      @torrvic1156 5 หลายเดือนก่อน

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

  • @svyatoslavs945
    @svyatoslavs945 4 ปีที่แล้ว +3

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

  • @МурадАхмедов-ч1с
    @МурадАхмедов-ч1с ปีที่แล้ว

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

  • @lampyrishive
    @lampyrishive 2 ปีที่แล้ว +1

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

  • @vladgonchar
    @vladgonchar 4 ปีที่แล้ว +2

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

  • @Brick87Game87
    @Brick87Game87 4 ปีที่แล้ว +2

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

  • @bashconsole
    @bashconsole 3 ปีที่แล้ว +1

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

  • @АнатолийПоленичко
    @АнатолийПоленичко 4 ปีที่แล้ว

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

  • @Сергей-н7ъ1д
    @Сергей-н7ъ1д 3 ปีที่แล้ว +1

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

  • @ДмитрийКвитка-х6р
    @ДмитрийКвитка-х6р 4 ปีที่แล้ว +1

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

  • @Арлекинок
    @Арлекинок 4 ปีที่แล้ว +3

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

  • @vargvarg7922
    @vargvarg7922 4 ปีที่แล้ว +1

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

  • @mr_brawlstars9601
    @mr_brawlstars9601 4 ปีที่แล้ว +2

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

    • @DiMaS-to2hz
      @DiMaS-to2hz 4 ปีที่แล้ว +1

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

    • @11lvr11
      @11lvr11 4 ปีที่แล้ว +3

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

  • @gaitavr1992
    @gaitavr1992 4 ปีที่แล้ว +1

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

    • @adeusexmachina
      @adeusexmachina 4 ปีที่แล้ว

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

  • @classborkau5551
    @classborkau5551 4 ปีที่แล้ว +1

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

  • @Имя-ц7к
    @Имя-ц7к ปีที่แล้ว +1

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

  • @АлександрНевельский-л2з
    @АлександрНевельский-л2з 2 ปีที่แล้ว +1

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

  • @fairplay6113
    @fairplay6113 4 ปีที่แล้ว +17

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

    • @AlexS-gn9tq
      @AlexS-gn9tq 4 ปีที่แล้ว +2

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

  • @ruslanzaporojets7021
    @ruslanzaporojets7021 4 ปีที่แล้ว +1

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

  • @kprohorow
    @kprohorow 2 ปีที่แล้ว +2

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

  • @milordplus
    @milordplus 2 ปีที่แล้ว

    Круто!

  • @DmitriyFromRiDDerrr
    @DmitriyFromRiDDerrr 4 ปีที่แล้ว +16

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

    • @Alex11Fox
      @Alex11Fox 4 ปีที่แล้ว

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

    • @SlavaCh
      @SlavaCh 4 ปีที่แล้ว +3

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

    • @zencrazycat
      @zencrazycat 4 ปีที่แล้ว +1

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

  • @wunderrus
    @wunderrus 3 ปีที่แล้ว +1

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

  • @maxlich9139
    @maxlich9139 4 ปีที่แล้ว +1

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

  • @cybersystem5137
    @cybersystem5137 หลายเดือนก่อน

    А какими могут быть нежелательные последствия СЛЕДОВАНИЯ ему? ))) И почему рассмотрели только с точки зрения фич, а не написания кода?

  • @crutchmaster9637
    @crutchmaster9637 4 ปีที่แล้ว +2

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

  • @voronow3
    @voronow3 4 ปีที่แล้ว

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

  • @MrChamber1
    @MrChamber1 4 ปีที่แล้ว +2

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

  • @yaolegoleynik
    @yaolegoleynik 4 ปีที่แล้ว

    Спасибо

  • @msvru
    @msvru 4 ปีที่แล้ว

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

  • @alexandrkruglyak
    @alexandrkruglyak 3 หลายเดือนก่อน

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

  • @borshch334
    @borshch334 2 ปีที่แล้ว

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

  • @denyszorin8675
    @denyszorin8675 4 ปีที่แล้ว +2

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

    • @viktormaloshuk2564
      @viktormaloshuk2564 4 ปีที่แล้ว

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

    • @denyszorin8675
      @denyszorin8675 4 ปีที่แล้ว

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

    • @viktormaloshuk2564
      @viktormaloshuk2564 4 ปีที่แล้ว +1

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

    • @denyszorin8675
      @denyszorin8675 4 ปีที่แล้ว +1

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

    • @AlexS-gn9tq
      @AlexS-gn9tq 4 ปีที่แล้ว

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

  • @nelkor3427
    @nelkor3427 4 ปีที่แล้ว +2

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

  • @bloodborn9632
    @bloodborn9632 2 ปีที่แล้ว

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

  • @winter-lb7id
    @winter-lb7id 9 หลายเดือนก่อน

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

  • @AK-ji3qv
    @AK-ji3qv 3 หลายเดือนก่อน

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

  • @davyknight1891
    @davyknight1891 4 ปีที่แล้ว

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

  • @andrewzaitsev6668
    @andrewzaitsev6668 3 ปีที่แล้ว

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

  • @ДмитрийВершинин-й9з
    @ДмитрийВершинин-й9з 2 ปีที่แล้ว

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

  • @Alex11Fox
    @Alex11Fox 4 ปีที่แล้ว

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

  • @proKaps
    @proKaps 10 หลายเดือนก่อน

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

  • @nanvlad
    @nanvlad 4 ปีที่แล้ว +1

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

  • @МихаилВикторович-р2я
    @МихаилВикторович-р2я ปีที่แล้ว

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

  • @olezhonnv3215
    @olezhonnv3215 4 ปีที่แล้ว

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

    • @olezhonnv3215
      @olezhonnv3215 4 ปีที่แล้ว

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

    • @SergeyNemchinskiy
      @SergeyNemchinskiy  4 ปีที่แล้ว

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

  • @ОсокинВадим-и4я
    @ОсокинВадим-и4я 4 ปีที่แล้ว +1

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

  • @alexpetrov2531
    @alexpetrov2531 4 ปีที่แล้ว

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

  • @no101vmv
    @no101vmv 4 ปีที่แล้ว

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

  • @daniyarkokabayev8453
    @daniyarkokabayev8453 4 ปีที่แล้ว +5

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

    • @СергейКондратенко-о9ц
      @СергейКондратенко-о9ц 4 ปีที่แล้ว +1

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

    • @anti1am3r
      @anti1am3r 4 ปีที่แล้ว +1

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

  • @ИванНикитин-ч7б
    @ИванНикитин-ч7б 4 ปีที่แล้ว

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

  • @АлександрМамзиков-х1у
    @АлександрМамзиков-х1у 4 ปีที่แล้ว +1

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

  • @МихаилВикторович-р2я
    @МихаилВикторович-р2я ปีที่แล้ว

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

  • @acrrono
    @acrrono 4 ปีที่แล้ว

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

  • @АртурМ-ч4х
    @АртурМ-ч4х 4 ปีที่แล้ว

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

  • @sergeyleluk9501
    @sergeyleluk9501 4 ปีที่แล้ว

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

  • @sardaucar
    @sardaucar 4 ปีที่แล้ว

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

  • @CensorsGoToHellWatchKittens247
    @CensorsGoToHellWatchKittens247 4 ปีที่แล้ว +2

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

    • @CensorsGoToHellWatchKittens247
      @CensorsGoToHellWatchKittens247 4 ปีที่แล้ว

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

  • @worker9249
    @worker9249 4 ปีที่แล้ว

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