Кстати пример с полями для ИНН и скайпа - это как раз на самом деле яркий пример КИСС. Вот было поле для ИНН и программист не делал его валидацию или проверки, потому что ему это не задавали. И вот конечный пользователь уже нашёл этому полю применение не по назначению. Как только бизнес-требования расширились (или опомнились что не делали валидацию и нанесли в систему мусора) - добавили проверку поля. И это благо, что все эти поля с ценными уникальными данными не стёрлись системой, которая сочла их ошибкой. А если бы программист проявил инициативу заранее сам и предусмотрел применение поля не по назначению - он бы отошел от КИСС, но при этом не позволил бы применять поле не по назначению. Часто продакт-менеджер не обладает всей широтой представления о поведении пользователей. И валидация полей - это одно из немногих, чего часто нет в бизнес требованиях, но должно быть с точки зрения опыта программиста. Как минимум валидация показывает самому оператору, что он неввёл одну цифру или опечатался и продублировал одну цифру. Поэтому принципу КИСС нужно следовать умно и валидацию делать не через задницу, а так чтобы пользователь мог ввести любой текст, а на выходе получить уведомление об ошибке если она есть, форматируя как нужно внутри системы и не озадачивая этим пользователя. Главное нужное количество цифр. А если в бизнес требованиях вообще нет проверок и функциональностей, которые с точки зрения программиста должны быть как базис диалога пользователя и системы - он должен уточнить это отдельно и зафиксировать: "да, тут валидацию не делаем, а вот тут делаем". И чем больше программист сам обладает опытом нахождения подобных уязвимостей или слабостей интерфейсов, тем больше он добавит проверок, которые не заложил менеджер. Опять же сейчас всё обсуждается с продакт менеджером и оунером, если делается по аджайлу.
@@yagami23100 если бы его организация потеряла все данные из валидированных полей - это было бы своеобразным злом, и именно в таком контексте должен был быть озвучен тот случай. Типа вот программист делал по КИСС и не предусмотрел заранее, а пользователи потом потеряли данные. Но автор сделал другой вывод: что программист и дальше не должен был валидировать поле ради удобства тех, кто применил его не по назначению. Это уже двойной стандарт и непоследовательность. Концепция Кисс не должна быть выше обновляющихся бизнес-требований для конечного исполнителя, как предлагает автор, типа ну раз сделали изначально без валидации (согласно Кисс) то и пусть навеки-вечные так и остаётся для сохранения лояльности клиентов. Или что, программист должен был пойти наперекор новым бизнес требованиям? Спорить с решениями оунера и продакта? Встать на сторону клиентов, которые там хранят свои скайпы, телефоны, счета банков, адреса и прочую муть, засоряющую базу данных?))
@@chikenmacnugget В одном из последних видео про уход из программирования он рассказал, что давно перешел на руководящую должность в своем бизнесе про обучение и не пишет код. Это значит уже начал утрачивать некоторые важные нюансы мышления программиста уровня мидла-сеньора, которым особенно в стартапах как раз и платят выше, чтобы они закрывали своим опытом дыры в ТЗ, а не следовали КИСС, мол, дак не просили же, вот я и не сделал. Осознанное применение КИСС не делая валидаций если их нет в ТЗ - это признак хитрожопости - ведь потом за разгребвание мусора из системы тоже придется платить деньги. Но это простительно стажеру джуниору, который только обретает полноценное мышление и опыт и ему дополнительные задачи брать в тягость. А по хорошему при наборе в команду мидлов и сеньоров нужно делать тест на мышление. И между хитрожопым КИСС-истом и опытным Абстракционистом выбирать второго, главное все его инициативы заверять перед реализацией, добавляя в ТЗ и смету задним числом. Это реально ценные кадры.
Серёг, отличная подача, приятно слушать, спасибо за твой контент А теперь я понадеюсь что у тебя великолепное чувство юмора: Я половину видео думал что ты "подглядываешь в монитор" который "висит слева сверху" :) Потом конечно всё понял
Еще хотелось бы добавить поговорку "Усложнять просто, упрощать сложно", многие программисты не следуют принципу KISS потому что им лень думать, как сделать проще и понятнее. Пишут код в стиле "что вижу то пою"
Принципы KISS и YAGNI в отношении задач работают только тогда, когда задачи написаны корректно и исчерпывающе. А не так, когда тебе говорят - "ну мы тут описали все основное, а ты дальше сам должен понимать что требуется клиенту". Потомо делаешь все по инструкции без отступлений, и получаешь такой диалог: - "А почему вот этого нет?" - "Потому что этого нет в требованиях." - "Так это же и так понятно!"
По имеющимся сообщениям, акроним был придуман Кларенсом Джонсоном, ведущим инженером Lockheed Skunk Works (создатели Lockheed U-2, SR-71 Blackbird и многих других). В то время как уже несколько десятилетий популярно использование расшифровки «Keep it simple, stupid», Джонсон расшифровал KISS как «Keep it simple stupid» (без запятой) и эта трактовка до сих пор используется многими авторами (в английском языке, в отличие от русского, запятая используется для обособления (выделения) обращения достаточно редко). В ней не было никакого скрытого смысла, что инженер был глуп; как раз наоборот. Этот принцип лучше всего иллюстрируется историей, когда Джонсон вручил команде инженеров-авиаконструкторов набор инструментов, поставив им условие: механик среднего уровня должен суметь отремонтировать реактивный самолёт, который они проектировали, в полевых условиях только с этими инструментами. Таким образом, «stupid» относится к отношению между тем, что всё ломается, и сложностью необходимого для этого ремонта.
Насчёт проверки формата тел.номера. Забьём на неё и огребём в будущем проблемы, когда захотим что-то в автоматическом режиме с ним делать. Например, искать дубли, завести тел.книжку, звонки через встроенный sip, сбор статистики и т.п. Поэтому нифига подобного - входные данные, которые должны иметь какой-либо формат(типа номер телефона или email), должны и проверятся относительно его и приводится к нему(убираем тире или наоборот расставляем однообразно в тел.номере и т.п.). Если надо иметь несколько номеров, то пожалуйста - разрешаем писать несколько через запятую. Но формат надо проверять. Опыт автоматизации подобных вещей показывает, что в будущем с подобными полями(которые не проверялись сразу) могут быть проблемы.
Не всегда согласен с теоретическим мнением и выводами ведущего. Но что несомненно ценно - его богатый практический опыт! Слушаю его "байки про былое" и нахожу их очень полезными, особенно для молодых программистов. Например, да - пользователи могут использовать программу таким "странным" образом, какой и не приходил в голову разработчику программы.
Много параметров в конфигурация нужна что бы потом адаптировать под нагрузку и скорость. Размер порции выполненой за раз, скорость обновления отрисовки. Параметры для системных админов. И иногда приходится для них написать интерфейс чтобы туда не вносили не допустимые значения(устранять конфликтующие значения).
В разработке проектов многое зависит от заказчика, его требований и области применения продукта. Например, если работаешь с постоянным заказчиком длительное время и знаешь его "особенности". Например, когда в изначальном ТЗ от заказчика не присутствуют определенные фичи, а 2 дня после релиза заказчик просит - "Ой, а нам тут нужно ещё это, это и это", ты добавляешь, делаешь релиз, через 2 дня просьба повторяется. Со временем, уже зная специфику своих клиентов мы начали добавлять в проекты тонну фич, которые могут понадобиться заказчику, в результате он доволен как слон. Но это единичный случай, повторюсь, всё зависит от менталитета заказчика.
Хм, насчёт валидация. Мы писали биллинг для телефонной станции. Однажды выяснилось что несколько абонентов при поиске по фамилии не попадают в результат. Как оказалось, вместо букв Ч были цифры 4, вместо О цифра 0. Мы офигели, Сразу исправили, накинули валидатор. Оказалось что операторы абонентского отдела были старые телеграфистки, а в телеграфе есть замена букв цифрами для экономии символов.
Дядя Сережа, перед тем как рассказать про "разницу использования наследования и делегирования", расскажите про делегирование, что, как, почему. Коротко и понятно, как вы умеете - спасибо)))
В KISS тоже надо знать меру и писать аккуратно и дальновидно. Вот пример с портом из видео, да можно захардкодить порт и это будет работать, а можно сделать свойство (гетер, сетер) "PORT". которое будет так же возвращать всего лишь захардкоженный порт, дополнительных трудозатрат нет, но при этом, потом, если тебе надо будет получать этот сраный порт каким-то способом с подвыподвертом, тебе не придется искать по всему приложению где же ты использовал этот порт.
В системах написанных студентами или динозаврами я встречал перегруженность конструкциями, которые были не задействованы или не доделаны вовсе. Причиной тому было что бросались на задачу как быки на ширму, сам был таким. Далее встречал только контрактный принцип. Даже когда с foris billing делали "расчёты побратски" все ненужное скрыли за фасадом.
Lombok - это не только автогенерация. Это и @SneakThrows, и исключение сгенереных методов из репорта code coverage. Кроме того, сгенеренный руками код (пусть даже и в IDE) надо поддерживать. К примеру, не забывать добавлять новые поля в toString(). Lombok позволяет этого избегать.
Про валидацию полей очень несогласен. Юзер не должен вносить в поля то, что не предусмотрено. Но он должен это не делать с первого дня жизни системы, конечно если он 5 лет писал Скайп в ИНН, а тут резко ему зарезали опцию, то это нельзя, но если б тебе изначально говорилось "иди в жопу, пиши цифры", то хрен бы ты туда скайпов напихал, а скорее написал бы разрабу "Бэн, ай нид хелп, добавь поле ИНН мне нада" и всё. Плохо не то, что он валидацию добавил, а то, что не сделал это изначально.
Можно перекрикивать как метод доказательства своей правоты. Но опыт подсказывает, что в большинстве случаев валидировать надо только те поля, значения которых впоследствии будут использоваться/читаться другими программами автоматически и на этих значениях будет строиться другая бизнес логика.
Совершенно согласен. Ну и ещё одна проблема - незнание авторами упомянутого софта потребностей своих клиентов, и, как следствие, вывод нерелевантной информации без возможности кастомизации
Неудачный пример с полем для идентификатора ИНН. На самом деле они были правы, что типизировали его. Вот представьте, что кто-то вписал в поле ИНН со скайпа ник, который может быть понятный ему одному, и кто-то отправил таки в налоговую отчет с ИНН в виде имени скайпа или же какой-то другой программист решил облегчить работу бухгалтера и написал классную программу, упрощающую отправку отчетов в налоговую. Как Вы думаете какая будет реакция у налоговой? А какая будет реакция у бухгалтера, когда вернулась ошибка из налоговой на следующий день, а время сдачи отчета было вчера? Главная их ошибка была, это то что нужно было изначально типизировать это поле. Ваша же ошибка была в том, что если в этом поле использовался ИНН, то нужно было использовать его по назначению, а не говорить, что ах какие не хорошие разработчики, решили провалидировать это поле.
зачастую, один и тот же софт продается разным заказчикам, и потом для заказчиков делают доработки - вот и появляется куча различных настроек, которые нужны только кому -то одному. Монолит, лучшая архитектура в мире, гениальные аналитики-архитекторы - наше всё
С одной стороны безумно плюсовал, но потом подумал... Работаю рук.группы эксплуатации/техпода. И в работе сталкивался с таким числом жути... Но если к ней родимой приложить эти принципы, то с небольшой натяжкой - подходят) Но эта "натяжка" как раз и создаёт максимум гемора. Часто разрабы нахардкодят так, что потом добавить небольшие элементы удобства обслуживания этого добра - это будет аж изменение архитектуры. И потом каждую команду разрабов и продуктологов приходится убеждать вложиться и переделать - чем раньше, тем лучше... Особенно при интеграционных взаимодействиях, чтобы можно было прикрутить и мониторинг, и логи нормальные и элементы контроля админки... А все потому что задачи ставили от бизнес потребностей с принципом кисс Упуская поддержку в принципе ( Да, или косяк архитекторов, или бизнес уговаривает удешевить... Ведь это дорого. Хотя потом оказывается ещё дороже, когда приходится или переделывать, или нанимать и обучать в огромном количестве сходящих с ума операторов. В общем и целом - принцип при наличии мозга реально работает. Но, имхо, для многих смотрящих и некоторых говнокодеров целевой мыслью может показаться, что проще - это главное. По крайней мере, такой червячок остался после двух просмотров. Был бы рад вашим комментариям или вообще дико плюсовал отдельному видео по учёту нюансов, важных для дальнейшей поддержки продукта, если он не мелкий или не планируется таким в конечной точке. А вообще - спасибо за все, что вы делаете!
Здравствуйте, Сергей. Говорят, что хороший стиль написания кода - это писать его от интерфейсов. И такой вопрос в каких случаях лучше применять интерфейсы к классам? Не нужно же писать интерфейсы и тыкать их в программе для всех классов.
блин, во смотрю сейчас свой курсач 2009 года, консольные крестики нолики на С++ на 2500 строк и свою личную CMS на 800 строк на PHP 2019 года. Смеяться и плакать хочется.
Очень сомнительно, что разработчики по своей инициативе добавили ту валидацию ИНН. Скорее всего это было по заявкам пользоватетей. Есть такой отчет 1ДФ. Кому и на сколько ты продал или оказал услуг. Вот если там в поле ИНН ошибешься, то в лучшем случае лишний раз побегаешь по кабинетам налоговой, а в худшем попадешь на штраф. Раз программа была давно, то никаких Ме ДОК-ов тогда не было и отчеты надо было на дискетках таскать и в распечатке.
не в противоречие принципу KISS, но не могу не заметить: что касается полей валидации - их таки нужно валидировать очень аккуратно и точно (и вобще все, что приходит от пользователя), потому что в один прекрасный день в поле вы получите что-то типа "do_bad_shit(); :)
KISS конфликтует с возможным требованием расширяемости и переиспользования в будущем. Обычная диалектика. И между этими сторонами нужно соблюдать баланс. Если конечно продукт не в стиле "сделал и долой с плеч"
что не так с хибернейтом для валидации бинов? У хибера же есть проект Hibernate Validator, который специально для этого сделан? Геттеры и Сеттеры это мусор в коде, лучше заменить аннотацией. Да и ломбок работает только во время компиляции - его зависимостей не будет после её окончания.
16:17 Сделать второй телефон дополнительный. А так, заполнение данных, мне кажется, должно иметь минимально необходимые данные и кучу всяких приписок и дополнений на усмотрение пользователя
А не получается ли, что KISS противоречит SOLID? в частности в вопросах наследования и использования интерфесов, которые заранее предпологают их использования для созданий новых классов в будущем?
При правильном подходе к разработке интерфейс является принадлежностью того, КТО вызывает, а не того, КОГО вызывают. В таком случае, если реализация интерфейса сильно не отклоняется от требований вызывающей стороны, то всё нормально. Опять же, всё зависит от конкретной ситуации. В одной использование целого фреймворка ради одной маленькой функции будет неприемлемо, в другой это может быть нормальным решением.
@@0imax "того, КТО вызывает" -- вы имеете ввиду интерфейс зависит от прав пользователя в программе? Тогда на каждое право свой interface и они дальше комбинруются, и динамически добавляются пользователю при логине?
@@nocomments9061 речь не о правах доступа. Вот Вы пишите программу, вызывая у объектов какие-то методы. Другой программист пишет сами эти классы. Набор методов (т.е. интерфейс) этих классов - это Ваша принадлежность, Вам должно быть удобно их вызывать. Таким образом можно легко заменить одни классы на другие, просто сделав ещё одну реализацию того же интерфейса. Если же интерфейс, т.е. набор методов, диктует разработчик вызываемых классов, то для замены одного класса на другой придётся весь вызывающий их код переписать под интерфейс нового класса.
Огромное спасибо вам Сергей за информативные видео! Мне три года изучения понадобились, чтобы наконец начать понимать, а о чём собственно эти принципы 😂Возможно я могу быть тупым 😅
это называется оверенжениринг. если делать максимально просто и тупо - получится полная херня неподдерживаемая. тут скорее дело такое что если ты хочешь запихнуть какую нибудь дополнительную функциональность и она прямо сейчас не нужна - нужно четко понимать понадобится она в ближайшем будущем или нет. если да, то лучше ее сделать. но это надо четко осознавать. очередной принцип который если бездумно применять везде - получится хрень. нужно везде балансировать)
Согласен с Вашим высказыванием, но я бы добавил. Если вещь понадобится в ближайшем будущем, код был должен быть организован таким образом, чтобы добавление этой "будущей" функциональности требовало минимальных усилий. Т.е не нужно сразу реализовывать все что может понадобиться. Код должен быть гибок к новым изменениям.
Так уж устроен мозг, что нейронные связи формируются лучше через сотню примеров и уточнений, чем одно утверждение. Иначе все бы учились по справочнику.
@@venom5583 Через сотню примеров и уточнений уже забываешь/замылевается первоначальный принцип, погребенный под кучей всей этой второстепенной информации. "Знание некоторых принципов легко возмещает незнание некоторых фактов" - К. Гельвеций Кстати, это изречение я опять же от Лиса услышал )
@@alexxx4434 Но как ты получишь знание без примеров и уточнений на что эти принципы распространяются, а на что нет, чтобы принцип не превращался в религию? Вот к примеру сказали тебе KISS YAGNI и ты будучи студентом понимаешь это как не писать геттеры, сеттеры, интерфейсы, хардкодить константы магическими числами для экономии строк) Так что знание принципов не возмещает незнания фактов если эти принципы противоречат друг другу и у тебя недостаточно опыта чтобы определить оптимальный компромисс между ними.
Стоп! Если строим систему с нуля мы же первым делом пишем интерфейсы, потом тесты, тестируем парадигму на устойчивость и только после этого приступаем к конкретной реализации. Как в данном контексте можно даже лишний параметр получить?
Мужик, щас не 2006 год, ты в курсе? Написать что-то без валилации - это буквально отстрелить самому себе яйца. Про валилацию прям супер вредный совет. Мало того, что клиент не обязан знать ничего про валилацию, так это ещё и самый типичный вектор атак - заинджектить во входные параметры некорректный данные и заставить сделать программу то, что она делать не должна. Validate your input - одна из самых базовых задач любого современного разработчика, который хоть что то слышал про безопасную разработку. Никакие принципы вроде DRY, KISS или даже SOLID не имеют приоритета над обычным коммон сенс. Лучше потерять трех клиентов, которые не догадались ввести по шаблону номер телефона, чем потерять всю базу данных, остановить сервис для всех остальных своих клиентов или разослать всем свои клиентам какой нибудь малварь в рассылочке. Какой то курс по говнокодингу.
Судя по другим источникам вы неверно истолковываете ту часть принципа, которая говорит о "не имеет смысла реализовывать дополнительные функции". Этот принцип подразумевает, что некоторый функционал лучше оставить на своём месте (если его наличие не усложняет понимание код), а не выносить в отдельную функцию. Вы же рассказываете о YAGNI (сами говорите о пересечении), это именно он, а не KISS.
Вот так, раньше, в прошлом веке, например, винда умещалась на нескольких дискетах, эксель 4.0 - на одной и мог запускаться прямо с неё!, а сейчас..., но функционал изменился не настолько радикально
@@0imax Эксель - это массовый продукт "для всех', а у каждого потребителя - свои потребности, вот каждый и использует необходимые ему возможности. Размеры растут за счёт импорта ненужных библиотек и всего того, что было сказано в этом ролике. Функционал, с того времени, - почти не изменился.
Наверно в силу того что я не программист не совсем согласен с выпуском. Может большая часть принципом предназначена для оутсорс разработки. Для продуктовой компании, которая собирается развиваться десятки лет надо заложить все что можно, если на это требуется разумное количество ресурсов
К сожалению простоту сложно продать. Заказчики требуют спринги, микросервисы, контейнеры и девопс. Чем сложнее архитектура, тем лучше привлекательней решение, и клиент видит за что он платит деньги.
Точно - сделайте то, что вас просит заказчик. А потом переделайте еще 20 раз, потому что он передумал, не знал, сомневался, хотел попробовать, ему сказали иначе, у него поменялась ситуация, кто-то вышел из отпуска и так далее и тому подобное. К сожалению, но нет. Практика показывает, что даже простую задачу лучше сразу делать сложно, универсально и с кучей настроек. Просто чтобы потом не переделывать.
А потом переделывайте, потому что ваша "обобщенность" оказалось не так, какую хотел заказчик, а вам его шиза даже в голову не приходила. В итоге все приходят к тому, что максимально универсальным делают только ядро проекта, которое везде и всюду на интерфейсах как точках расширения. А дальше уже нужный функционал докидывается на это ядро сверху итеративно. Всегда, когда проект начинается, нужно собрать максимум данных о том, какие абстракции являются устойчивыми, а какие - нет. Иначе это будет сизифов труд.
@@НикитаГлухов-п5ю Разумеется. Просто моя практика показывает, что с универсальностью лучше "перебдеть, чем недобдеть". Как только начнешь keep it simple - всё, ты попал. Будут просто километры неуниверсального и дублирующегося кода. Которые ты замучаешься рефакторить, да и никто тебе не даст на это времени - так что объем этой мусорки будут возрастать и возрастать. И в итоге ты убежишь на другой проект, бросив запоротый кому-то другому. "Шиза в голову не приходила" - ну какую-то адекватность заказчика всё равно приходится закладывать конечно - иначе просто ничего не напишешь, если ни одному его слову верить нельзя. То есть, допустим, если он говорит, что ему надо передать некие данные из пункта Б в пункт Ж - то видимо надо передать, да. Вот по составу и структуре этих данных я бы верить не стал. А в саму необходимость передачи - придется.
-Давайте напишем функциональность Х, её в ТЗ не было, но нюхом чую что запросят -Ты чо, следуй KISS, и не умничай * Клиент запрашивает функциональность Х * Программисты, поскольку следовали KISS, не могут добавить Х не переписав всё с нуля 0_0
архитектура должна была предполагать X, Y и Z. Вы же знаете, что захочет заказчик. И постоянную Планка ни в коем случае не пишите числом в каждой формуле, вдруг изменится))
Так это проблема заказчика. До старта же все обговаривается, функционал, время на работу и т.д. Доп функционал, доп деньги. А кодерам какая разница, работа есть и отлично)
@@Лучшеникакогознаниячемникакое есть только два варианта: работа по часам и работа по ТЗ. Если программист соглашается на условия " я пока не знаю что я хочу, но удовлетвори меня за 100 рублей" то он самдурак :)
То что ты думаешь , не то что вводит заказчик. . Чем меньше строк кода тем меньше багов.! круто. но ! чем больше красивых строк Python тем больше в x^степине больше багов?
Не могу согласиться с некоторыми советами. Пару слов по поводу примера об ИНН и телефонах в контексте современных веб сервисов. Первое: каждое узко направленное поле ввода всегда должно иметь соответствующую валидацию и констрейнты в бд. Любая последующая обработка таких данных становится невозможной если не были соблюдены правила ввода. Вы никогда не узнаете в какой день прийдут новые требования по этим данным. Второе: чтоб избежать каши в данных достаточно нанять UX дизайнера, который по юскейсам нарисует подходящий интерфейс с нужными возможностями. Юзер пишет емейл в поле фамилии не потому что он не понимает что делать, а потому, что UX кривой. Нет поля для емейла или коммента, например.
@@SergeyNemchinskiy це такий собі аргумент, я від усіх колег чую "вільно розмовляю" а насправді ото тільки ці фрази і знають, далі "мнє так удобнєй". Додайте рубрику Немчинський Українець , як раз попрактикуємось в тісному кругу розробників, література вже є з перекладами технічних і не тільки термінів:) якісь новини, особисто мені таке цікаво, ясна річ справа за автором.
lombok и генерация ацессоров IDE это совсем разные вещи. Во втором случае IDE генерит кучу бойлерплейта, с котором потом придется сталкиваться при рефакторинге, и просто при чтении кода.
@@SergeyNemchinskiy ну да - у нас в углу кто-то накакал, но не мешает же? Не смотрите туда, окошко откройте. Бойлерплейт в любом случае мешает. Конечно, в основном его приходится пролистывать в поисках полезной нагрузки, но это тоже занимает время. Особенно когда приходится переключаться между множеством классов. Это просто мусор в коде, он не нужен.
и это только ацессоры, а equals/hashCode? Сколько раз было такое, что при добавлении поля забывали его прописать. И да, оно там ещё и под слоем ацессоров где-то зарыто.
@@SteelS0ldier это нужный и важный "бойлерплейт". Как минимум в многопоточном окружении есть задача изготовить иммутабельный POJO, при этом требование рекурсивной иммутабельности для всех полей поджика слишком строгое и нужно реализовать копирующие геттеры. Ломбок и прочие костыли так не умеют (есть только анноташка @Value которая делает не совсем то, что нужно). Код должен быть абсолютно прозрачным, а современные IDE позволяют сворачивать/разворачивать тела методов в редакторе. Кучу раз бывало такое, что нужно было подебажить библиотеку X, а ее исходники не совпадают с class-файлами, потому что Lombok нагенерил доп. код и у отладчика несоответствие между сурсами и байткодом.
2:30 Только хотел сказать, что, по факту, любой современный фреймворк (из мира PHP точно) нарушает принцип KISS, потому что имеет в себе сильно больше, чем нужно для 90% задач, где этот фреймворк используется. С другой стороны, в велосипедах, даже простых, тоже ничего хорошего нет. В общем, нет идеальных решений, во всем есть недостатки.
Но 10% всё ещё где то используется, а значит этот функционал нужен. Автор видео говорил о том, что не нужно делать то, что не просили или то, что никто не будет использовать в ближайшем будущем. Но если хотя бы 1% пользователей например использует какой то функционал который большинство не использует - это уже много.
Так а зачем использовать фреймворк, от которого требуется только 10% функционала?) Проще уж подключить нужные либы и использовать их. P.S. Это ваш субъективный взгляд. Очень много работаю с Laravel, за всё время пригодился, пожалуй, весь его функционал, кроме Mix. На большей части проектов так же используется сильно больше чем 10%.
код удаленный из проекта но оставшийся в гите, там и останется навечно. при необходимости восстановления функционала будет написан заново если конечно не найдется ктото, кто помнит, что такое есть...
![Биология поведения человека: Лекция #4. Молекулярная генетика, I [Роберт Сапольски, 2010. Стэнфорд]](http://i.ytimg.com/vi/RvWv9Rh_34E/mqdefault.jpg)
Спасибо за ваш труд! Расскажите потом пожалуйста про делегирование и наследование и что где следует применять)
Расскажите, пожалуйста, когда наследование а когда делегирование:)
И что это вообще такое
@@aleksanderm1947 азазаза, тестировщик ...)
@@КонстантинЪЪЪ html coder
слушаю с интересом.
расскажите про делегирование и наследование, будет полезно.
спасибо.
да всё просто: делегируешь код джуну, он его наследует... :-D)))
@@apristen очень спасибо. 👍
Кстати пример с полями для ИНН и скайпа - это как раз на самом деле яркий пример КИСС. Вот было поле для ИНН и программист не делал его валидацию или проверки, потому что ему это не задавали. И вот конечный пользователь уже нашёл этому полю применение не по назначению. Как только бизнес-требования расширились (или опомнились что не делали валидацию и нанесли в систему мусора) - добавили проверку поля. И это благо, что все эти поля с ценными уникальными данными не стёрлись системой, которая сочла их ошибкой. А если бы программист проявил инициативу заранее сам и предусмотрел применение поля не по назначению - он бы отошел от КИСС, но при этом не позволил бы применять поле не по назначению. Часто продакт-менеджер не обладает всей широтой представления о поведении пользователей. И валидация полей - это одно из немногих, чего часто нет в бизнес требованиях, но должно быть с точки зрения опыта программиста. Как минимум валидация показывает самому оператору, что он неввёл одну цифру или опечатался и продублировал одну цифру. Поэтому принципу КИСС нужно следовать умно и валидацию делать не через задницу, а так чтобы пользователь мог ввести любой текст, а на выходе получить уведомление об ошибке если она есть, форматируя как нужно внутри системы и не озадачивая этим пользователя. Главное нужное количество цифр. А если в бизнес требованиях вообще нет проверок и функциональностей, которые с точки зрения программиста должны быть как базис диалога пользователя и системы - он должен уточнить это отдельно и зафиксировать: "да, тут валидацию не делаем, а вот тут делаем". И чем больше программист сам обладает опытом нахождения подобных уязвимостей или слабостей интерфейсов, тем больше он добавит проверок, которые не заложил менеджер. Опять же сейчас всё обсуждается с продакт менеджером и оунером, если делается по аджайлу.
Самое интересное запросить у программиста поле для ИНН, а вводить туда скайп и потом еще возмущаться...
@@yagami23100 если бы его организация потеряла все данные из валидированных полей - это было бы своеобразным злом, и именно в таком контексте должен был быть озвучен тот случай. Типа вот программист делал по КИСС и не предусмотрел заранее, а пользователи потом потеряли данные. Но автор сделал другой вывод: что программист и дальше не должен был валидировать поле ради удобства тех, кто применил его не по назначению. Это уже двойной стандарт и непоследовательность. Концепция Кисс не должна быть выше обновляющихся бизнес-требований для конечного исполнителя, как предлагает автор, типа ну раз сделали изначально без валидации (согласно Кисс) то и пусть навеки-вечные так и остаётся для сохранения лояльности клиентов. Или что, программист должен был пойти наперекор новым бизнес требованиям? Спорить с решениями оунера и продакта? Встать на сторону клиентов, которые там хранят свои скайпы, телефоны, счета банков, адреса и прочую муть, засоряющую базу данных?))
@@chikenmacnugget В одном из последних видео про уход из программирования он рассказал, что давно перешел на руководящую должность в своем бизнесе про обучение и не пишет код. Это значит уже начал утрачивать некоторые важные нюансы мышления программиста уровня мидла-сеньора, которым особенно в стартапах как раз и платят выше, чтобы они закрывали своим опытом дыры в ТЗ, а не следовали КИСС, мол, дак не просили же, вот я и не сделал. Осознанное применение КИСС не делая валидаций если их нет в ТЗ - это признак хитрожопости - ведь потом за разгребвание мусора из системы тоже придется платить деньги. Но это простительно стажеру джуниору, который только обретает полноценное мышление и опыт и ему дополнительные задачи брать в тягость. А по хорошему при наборе в команду мидлов и сеньоров нужно делать тест на мышление. И между хитрожопым КИСС-истом и опытным Абстракционистом выбирать второго, главное все его инициативы заверять перед реализацией, добавляя в ТЗ и смету задним числом. Это реально ценные кадры.
Нашел пару фраз что бы поспорить, но опыт говорит что это для спора в курилке, а не на всеобщем обозрении ))) Категорически плюсую видео!
Работодателя: - Как вы относитесь к Kiss?
Я: *поцелуй*
Работодатель: - Эээ вы не так меня поняли, но вы приняты...
Работодателя: - Как вы относитесь к Kiss?
Я: ай воз мейд фо ловинг ю бэйби!
Работодатель: - Эээ вы не так меня поняли, но вы приняты...
я-то думаю почему ни разу не слышал на собеседовании об этом принципе
Ахаха 😂Это корка)
Серёг, отличная подача, приятно слушать, спасибо за твой контент
А теперь я понадеюсь что у тебя великолепное чувство юмора:
Я половину видео думал что ты "подглядываешь в монитор" который "висит слева сверху" :)
Потом конечно всё понял
Еще хотелось бы добавить поговорку "Усложнять просто, упрощать сложно", многие программисты не следуют принципу KISS потому что им лень думать, как сделать проще и понятнее. Пишут код в стиле "что вижу то пою"
Под чаёк в обед самое то. Ждем байки про то, когда лучше юзать наследование, а когда делегирование!
Принципы KISS и YAGNI в отношении задач работают только тогда, когда задачи написаны корректно и исчерпывающе. А не так, когда тебе говорят - "ну мы тут описали все основное, а ты дальше сам должен понимать что требуется клиенту".
Потомо делаешь все по инструкции без отступлений, и получаешь такой диалог:
- "А почему вот этого нет?"
- "Потому что этого нет в требованиях."
- "Так это же и так понятно!"
Отличный преподаватель! Вчера даже сел после видео задачи решать.
Спасибо за интересный контент.
какая стильная футболочка у этого розового мишки, сидящего возле чашки :)
Это то что мне нужно было посмотреть очень давно, столько времени ушло в чёрную дыру🥲
Приятный по софт общению Сергей Немчинский !)
А главное по объяснению - ничего не потеряно.
как же шикарно наткнуться на этот канал! Спасибо!
Сергей, вы молодец, спасибо вам за контент
Сергей, благодарю!
Спасибо вам! Я только учусь, но вы так интересно рассказываете, что даже новичку интересно!
По имеющимся сообщениям, акроним был придуман Кларенсом Джонсоном, ведущим инженером Lockheed Skunk Works (создатели Lockheed U-2, SR-71 Blackbird и многих других).
В то время как уже несколько десятилетий популярно использование расшифровки «Keep it simple, stupid», Джонсон расшифровал KISS как «Keep it simple stupid» (без запятой) и эта трактовка до сих пор используется многими авторами (в английском языке, в отличие от русского, запятая используется для обособления (выделения) обращения достаточно редко). В ней не было никакого скрытого смысла, что инженер был глуп; как раз наоборот.
Этот принцип лучше всего иллюстрируется историей, когда Джонсон вручил команде инженеров-авиаконструкторов набор инструментов, поставив им условие: механик среднего уровня должен суметь отремонтировать реактивный самолёт, который они проектировали, в полевых условиях только с этими инструментами. Таким образом, «stupid» относится к отношению между тем, что всё ломается, и сложностью необходимого для этого ремонта.
Сергей, хотелось бы как можно больше примеров из Вашего опыта, как и в этом видео
стараюсь :)
Keep it simple, suka
Насчёт проверки формата тел.номера. Забьём на неё и огребём в будущем проблемы, когда захотим что-то в автоматическом режиме с ним делать. Например, искать дубли, завести тел.книжку, звонки через встроенный sip, сбор статистики и т.п. Поэтому нифига подобного - входные данные, которые должны иметь какой-либо формат(типа номер телефона или email), должны и проверятся относительно его и приводится к нему(убираем тире или наоборот расставляем однообразно в тел.номере и т.п.). Если надо иметь несколько номеров, то пожалуйста - разрешаем писать несколько через запятую. Но формат надо проверять. Опыт автоматизации подобных вещей показывает, что в будущем с подобными полями(которые не проверялись сразу) могут быть проблемы.
Спасибо, Сергей. Один из лучших каналов, хоть я и питонист))
Не всегда согласен с теоретическим мнением и выводами ведущего. Но что несомненно ценно - его богатый практический опыт! Слушаю его "байки про былое" и нахожу их очень полезными, особенно для молодых программистов. Например, да - пользователи могут использовать программу таким "странным" образом, какой и не приходил в голову разработчику программы.
Очень полезное видео, спасибо !
Много параметров в конфигурация нужна что бы потом адаптировать под нагрузку и скорость. Размер порции выполненой за раз, скорость обновления отрисовки. Параметры для системных админов. И иногда приходится для них написать интерфейс чтобы туда не вносили не допустимые значения(устранять конфликтующие значения).
Принцип KISS очень субъективен, для одного кодера одно просто и очевидно, для другого другое. Нет общих стандартов простоты )))
Данный принцип в первую очередь больше всего пересекается с моим любимым принципом "х.х. и в продакшн".
Всё POOP (practical object-oriented programming) такое.
@@БарометрАтмосферныйэто надо запомнить обязательно 😂Главный принцип! Спасибо! 😅Повеселили.
В разработке проектов многое зависит от заказчика, его требований и области применения продукта. Например, если работаешь с постоянным заказчиком длительное время и знаешь его "особенности". Например, когда в изначальном ТЗ от заказчика не присутствуют определенные фичи, а 2 дня после релиза заказчик просит - "Ой, а нам тут нужно ещё это, это и это", ты добавляешь, делаешь релиз, через 2 дня просьба повторяется. Со временем, уже зная специфику своих клиентов мы начали добавлять в проекты тонну фич, которые могут понадобиться заказчику, в результате он доволен как слон. Но это единичный случай, повторюсь, всё зависит от менталитета заказчика.
а давай про наследование и делегирование! - звучит прям как то чего не хватало)
Хм, насчёт валидация. Мы писали биллинг для телефонной станции. Однажды выяснилось что несколько абонентов при поиске по фамилии не попадают в результат.
Как оказалось, вместо букв Ч были цифры 4, вместо О цифра 0. Мы офигели,
Сразу исправили, накинули валидатор. Оказалось что операторы абонентского отдела были старые телеграфистки, а в телеграфе есть замена букв цифрами для экономии символов.
Спасибо за видео! Про наследование было бы прямо очень интересно =)
Дядя Сережа, перед тем как рассказать про "разницу использования наследования и делегирования", расскажите про делегирование, что, как, почему. Коротко и понятно, как вы умеете - спасибо)))
В KISS тоже надо знать меру и писать аккуратно и дальновидно. Вот пример с портом из видео, да можно захардкодить порт и это будет работать, а можно сделать свойство (гетер, сетер) "PORT". которое будет так же возвращать всего лишь захардкоженный порт, дополнительных трудозатрат нет, но при этом, потом, если тебе надо будет получать этот сраный порт каким-то способом с подвыподвертом, тебе не придется искать по всему приложению где же ты использовал этот порт.
согласен. Я под "захордкодить" имел в виду, конечно, вынести это значение в константу и ее везде использовать
@@SergeyNemchinskiy стоит уточнить, а то зрители будут потом рассказывать "Немчинский разрешил" :)
Запишите, пожалуйста, про монолит!
В системах написанных студентами или динозаврами я встречал перегруженность конструкциями, которые были не задействованы или не доделаны вовсе. Причиной тому было что бросались на задачу как быки на ширму, сам был таким. Далее встречал только контрактный принцип. Даже когда с foris billing делали "расчёты побратски" все ненужное скрыли за фасадом.
Видео Must have для большинства java-программистов кодящих на spring и spring boot.
Для всех программистов :)
Lombok - это не только автогенерация. Это и @SneakThrows, и исключение сгенереных методов из репорта code coverage. Кроме того, сгенеренный руками код (пусть даже и в IDE) надо поддерживать. К примеру, не забывать добавлять новые поля в toString(). Lombok позволяет этого избегать.
Про валидацию полей очень несогласен. Юзер не должен вносить в поля то, что не предусмотрено. Но он должен это не делать с первого дня жизни системы, конечно если он 5 лет писал Скайп в ИНН, а тут резко ему зарезали опцию, то это нельзя, но если б тебе изначально говорилось "иди в жопу, пиши цифры", то хрен бы ты туда скайпов напихал, а скорее написал бы разрабу "Бэн, ай нид хелп, добавь поле ИНН мне нада" и всё. Плохо не то, что он валидацию добавил, а то, что не сделал это изначально.
Можно перекрикивать как метод доказательства своей правоты. Но опыт подсказывает, что в большинстве случаев валидировать надо только те поля, значения которых впоследствии будут использоваться/читаться другими программами автоматически и на этих значениях будет строиться другая бизнес логика.
@@vladgonchar , привет xss дыркам
Совершенно согласен. Ну и ещё одна проблема - незнание авторами упомянутого софта потребностей своих клиентов, и, как следствие, вывод нерелевантной информации без возможности кастомизации
Сергей, спасибо за ваши видео, очень интересно и полезно. Выпустите видео про наследование и делегирование.
Неудачный пример с полем для идентификатора ИНН. На самом деле они были правы, что типизировали его. Вот представьте, что кто-то вписал в поле ИНН со скайпа ник, который может быть понятный ему одному, и кто-то отправил таки в налоговую отчет с ИНН в виде имени скайпа или же какой-то другой программист решил облегчить работу бухгалтера и написал классную программу, упрощающую отправку отчетов в налоговую. Как Вы думаете какая будет реакция у налоговой? А какая будет реакция у бухгалтера, когда вернулась ошибка из налоговой на следующий день, а время сдачи отчета было вчера? Главная их ошибка была, это то что нужно было изначально типизировать это поле. Ваша же ошибка была в том, что если в этом поле использовался ИНН, то нужно было использовать его по назначению, а не говорить, что ах какие не хорошие разработчики, решили провалидировать это поле.
Круто, что я живу по этому принципу
зачастую, один и тот же софт продается разным заказчикам, и потом для заказчиков делают доработки - вот и появляется куча различных настроек, которые нужны только кому -то одному. Монолит, лучшая архитектура в мире, гениальные аналитики-архитекторы - наше всё
Спасибо большое!
С одной стороны безумно плюсовал, но потом подумал...
Работаю рук.группы эксплуатации/техпода. И в работе сталкивался с таким числом жути...
Но если к ней родимой приложить эти принципы, то с небольшой натяжкой - подходят)
Но эта "натяжка" как раз и создаёт максимум гемора.
Часто разрабы нахардкодят так, что потом добавить небольшие элементы удобства обслуживания этого добра - это будет аж изменение архитектуры. И потом каждую команду разрабов и продуктологов приходится убеждать вложиться и переделать - чем раньше, тем лучше... Особенно при интеграционных взаимодействиях, чтобы можно было прикрутить и мониторинг, и логи нормальные и элементы контроля админки...
А все потому что задачи ставили от бизнес потребностей с принципом кисс Упуская поддержку в принципе (
Да, или косяк архитекторов, или бизнес уговаривает удешевить...
Ведь это дорого.
Хотя потом оказывается ещё дороже, когда приходится или переделывать, или нанимать и обучать в огромном количестве сходящих с ума операторов.
В общем и целом - принцип при наличии мозга реально работает. Но, имхо, для многих смотрящих и некоторых говнокодеров целевой мыслью может показаться, что проще - это главное. По крайней мере, такой червячок остался после двух просмотров.
Был бы рад вашим комментариям или вообще дико плюсовал отдельному видео по учёту нюансов, важных для дальнейшей поддержки продукта, если он не мелкий или не планируется таким в конечной точке.
А вообще - спасибо за все, что вы делаете!
Здравствуйте, Сергей. Говорят, что хороший стиль написания кода - это писать его от интерфейсов. И такой вопрос в каких случаях лучше применять интерфейсы к классам? Не нужно же писать интерфейсы и тыкать их в программе для всех классов.
вообще-то нудно. но писать именно от интерфейсов очень сложно
@Sergey Nemchinskiy Так что по итогу с видео про делегирование ?
- Как решить проблему с избыточным количеством уровней абстракции?
- Добавить новый уровень абстракции
Возможно они стали использовать поле ИНН для общения с другими сервисами принимающие строгий формат.
Спасибо вам большое за ето видео.
блин, во смотрю сейчас свой курсач 2009 года, консольные крестики нолики на С++ на 2500 строк и свою личную CMS на 800 строк на PHP 2019 года. Смеяться и плакать хочется.
Нужно понимать где заканчивается KISS, и начинается лень с пофигизмом😀
про делегирование и наследование было бы здорово
Гугл в помощь
Просим про делегирование и наследование
Очень сомнительно, что разработчики по своей инициативе добавили ту валидацию ИНН. Скорее всего это было по заявкам пользоватетей. Есть такой отчет 1ДФ. Кому и на сколько ты продал или оказал услуг. Вот если там в поле ИНН ошибешься, то в лучшем случае лишний раз побегаешь по кабинетам налоговой, а в худшем попадешь на штраф. Раз программа была давно, то никаких Ме ДОК-ов тогда не было и отчеты надо было на дискетках таскать и в распечатке.
не в противоречие принципу KISS, но не могу не заметить: что касается полей валидации - их таки нужно валидировать очень аккуратно и точно (и вобще все, что приходит от пользователя), потому что в один прекрасный день в поле вы получите что-то типа "do_bad_shit(); :)
ржу с голоса, который задействован для "а давайте" программистов
KISS конфликтует с возможным требованием расширяемости и переиспользования в будущем. Обычная диалектика. И между этими сторонами нужно соблюдать баланс. Если конечно продукт не в стиле "сделал и долой с плеч"
что не так с хибернейтом для валидации бинов? У хибера же есть проект Hibernate Validator, который специально для этого сделан? Геттеры и Сеттеры это мусор в коде, лучше заменить аннотацией. Да и ломбок работает только во время компиляции - его зависимостей не будет после её окончания.
Видосик про наследование +++
16:17
Сделать второй телефон дополнительный.
А так, заполнение данных, мне кажется, должно иметь минимально необходимые данные и кучу всяких приписок и дополнений на усмотрение пользователя
Сергей, у меня вопрос не по теме. Что вы можете сказать про RxJava и про технологии ректиного программирования?
Еще порой люди любят усложнят логику методов, классов и их взаимодействия
А не получается ли, что KISS противоречит SOLID? в частности в вопросах наследования и использования интерфесов, которые заранее предпологают их использования для созданий новых классов в будущем?
При правильном подходе к разработке интерфейс является принадлежностью того, КТО вызывает, а не того, КОГО вызывают.
В таком случае, если реализация интерфейса сильно не отклоняется от требований вызывающей стороны, то всё нормально.
Опять же, всё зависит от конкретной ситуации. В одной использование целого фреймворка ради одной маленькой функции будет неприемлемо, в другой это может быть нормальным решением.
@@0imax "того, КТО вызывает" -- вы имеете ввиду интерфейс зависит от прав пользователя в программе? Тогда на каждое право свой interface и они дальше комбинруются, и динамически добавляются пользователю при логине?
@@nocomments9061 Речь про программный интерфейс, не графический.
@@0imax я про программный тоже, понял вас так.
@@nocomments9061 речь не о правах доступа.
Вот Вы пишите программу, вызывая у объектов какие-то методы. Другой программист пишет сами эти классы. Набор методов (т.е. интерфейс) этих классов - это Ваша принадлежность, Вам должно быть удобно их вызывать.
Таким образом можно легко заменить одни классы на другие, просто сделав ещё одну реализацию того же интерфейса.
Если же интерфейс, т.е. набор методов, диктует разработчик вызываемых классов, то для замены одного класса на другой придётся весь вызывающий их код переписать под интерфейс нового класса.
Расскажите, куда делась вязаная лисичка?)
Ещё один голос за inheritance vs composition
Сейчас как раз джанго начал изучать самостоятельно. Скажите пожалуйста а сколько ж курс стоит? А то я по ссылке не нашел цену
Подробнее плиз о делегировании
Класс.
Огромное спасибо вам Сергей за информативные видео! Мне три года изучения понадобились, чтобы наконец начать понимать, а о чём собственно эти принципы 😂Возможно я могу быть тупым 😅
Даже с позиции теории надёжности, чем система проще тем она более надёжная и безотказная.
Сергей, а не будет ли видео про Xamarin?
он не специалист по .NET, а про мобиьную разработку и тем более Xamarin вообще не в курсе. Сергей Java dev из мира кровавого энтерпрайза.
это называется оверенжениринг. если делать максимально просто и тупо - получится полная херня неподдерживаемая. тут скорее дело такое что если ты хочешь запихнуть какую нибудь дополнительную функциональность и она прямо сейчас не нужна - нужно четко понимать понадобится она в ближайшем будущем или нет. если да, то лучше ее сделать. но это надо четко осознавать. очередной принцип который если бездумно применять везде - получится хрень. нужно везде балансировать)
Согласен с Вашим высказыванием, но я бы добавил. Если вещь понадобится в ближайшем будущем, код был должен быть организован таким образом, чтобы добавление этой "будущей" функциональности требовало минимальных усилий. Т.е не нужно сразу реализовывать все что может понадобиться. Код должен быть гибок к новым изменениям.
Я нахожу это ироничным, что видео про KISS само не следует принципу KISS. )
Не следует, потому что разжевывает?
фолыч первый и второй - топ!)
(я про автарку)
Так уж устроен мозг, что нейронные связи формируются лучше через сотню примеров и уточнений, чем одно утверждение. Иначе все бы учились по справочнику.
@@venom5583 Через сотню примеров и уточнений уже забываешь/замылевается первоначальный принцип, погребенный под кучей всей этой второстепенной информации.
"Знание некоторых принципов легко возмещает незнание некоторых фактов"
- К. Гельвеций
Кстати, это изречение я опять же от Лиса услышал )
@@alexxx4434 Но как ты получишь знание без примеров и уточнений на что эти принципы распространяются, а на что нет, чтобы принцип не превращался в религию? Вот к примеру сказали тебе KISS YAGNI и ты будучи студентом понимаешь это как не писать геттеры, сеттеры, интерфейсы, хардкодить константы магическими числами для экономии строк)
Так что знание принципов не возмещает незнания фактов если эти принципы противоречат друг другу и у тебя недостаточно опыта чтобы определить оптимальный компромисс между ними.
Вообще данный принцип, в указанной редакции, прерогатива архитектора и аналитиков. В коде обычно говорят о ненужной сложности функций.
Валидация в поле ИНН обязательна.
Стоп! Если строим систему с нуля мы же первым делом пишем интерфейсы, потом тесты, тестируем парадигму на устойчивость и только после этого приступаем к конкретной реализации. Как в данном контексте можно даже лишний параметр получить?
Мужик, щас не 2006 год, ты в курсе? Написать что-то без валилации - это буквально отстрелить самому себе яйца. Про валилацию прям супер вредный совет. Мало того, что клиент не обязан знать ничего про валилацию, так это ещё и самый типичный вектор атак - заинджектить во входные параметры некорректный данные и заставить сделать программу то, что она делать не должна. Validate your input - одна из самых базовых задач любого современного разработчика, который хоть что то слышал про безопасную разработку. Никакие принципы вроде DRY, KISS или даже SOLID не имеют приоритета над обычным коммон сенс. Лучше потерять трех клиентов, которые не догадались ввести по шаблону номер телефона, чем потерять всю базу данных, остановить сервис для всех остальных своих клиентов или разослать всем свои клиентам какой нибудь малварь в рассылочке. Какой то курс по говнокодингу.
Наследование? Делегирование?
Судя по другим источникам вы неверно истолковываете ту часть принципа, которая говорит о "не имеет смысла реализовывать дополнительные функции". Этот принцип подразумевает, что некоторый функционал лучше оставить на своём месте (если его наличие не усложняет понимание код), а не выносить в отдельную функцию. Вы же рассказываете о YAGNI (сами говорите о пересечении), это именно он, а не KISS.
Вот так, раньше, в прошлом веке, например, винда умещалась на нескольких дискетах, эксель 4.0 - на одной и мог запускаться прямо с неё!, а сейчас..., но функционал изменился не настолько радикально
Это наглядная демонстрация нарушения принципа KISS, т.к. тот же эксель большинство пользователей не используют и на 10% всех его возможностей))
@@0imax Эксель - это массовый продукт "для всех', а у каждого потребителя - свои потребности, вот каждый и использует необходимые ему возможности. Размеры растут за счёт импорта ненужных библиотек и всего того, что было сказано в этом ролике. Функционал, с того времени, - почти не изменился.
@@qr46654 Если что - это была шутка :)
@@0imax шутки шутками, но это не прикольно, когда нужно тратить деньги, получая, в основном, "улучшения" в виде визуальных эффектов
@@qr46654 Это да.
Скайп до попадания в руки m$ был вполне приличным...
Наверно в силу того что я не программист не совсем согласен с выпуском. Может большая часть принципом предназначена для оутсорс разработки. Для продуктовой компании, которая собирается развиваться десятки лет надо заложить все что можно, если на это требуется разумное количество ресурсов
К сожалению простоту сложно продать. Заказчики требуют спринги, микросервисы, контейнеры и девопс. Чем сложнее архитектура, тем лучше привлекательней решение, и клиент видит за что он платит деньги.
Делайте всё так , чтобы другим людям было удобно переделывать
Точно - сделайте то, что вас просит заказчик. А потом переделайте еще 20 раз, потому что он передумал, не знал, сомневался, хотел попробовать, ему сказали иначе, у него поменялась ситуация, кто-то вышел из отпуска и так далее и тому подобное.
К сожалению, но нет. Практика показывает, что даже простую задачу лучше сразу делать сложно, универсально и с кучей настроек. Просто чтобы потом не переделывать.
А потом переделывайте, потому что ваша "обобщенность" оказалось не так, какую хотел заказчик, а вам его шиза даже в голову не приходила. В итоге все приходят к тому, что максимально универсальным делают только ядро проекта, которое везде и всюду на интерфейсах как точках расширения. А дальше уже нужный функционал докидывается на это ядро сверху итеративно. Всегда, когда проект начинается, нужно собрать максимум данных о том, какие абстракции являются устойчивыми, а какие - нет. Иначе это будет сизифов труд.
@@НикитаГлухов-п5ю
Разумеется. Просто моя практика показывает, что с универсальностью лучше "перебдеть, чем недобдеть". Как только начнешь keep it simple - всё, ты попал. Будут просто километры неуниверсального и дублирующегося кода. Которые ты замучаешься рефакторить, да и никто тебе не даст на это времени - так что объем этой мусорки будут возрастать и возрастать. И в итоге ты убежишь на другой проект, бросив запоротый кому-то другому.
"Шиза в голову не приходила" - ну какую-то адекватность заказчика всё равно приходится закладывать конечно - иначе просто ничего не напишешь, если ни одному его слову верить нельзя. То есть, допустим, если он говорит, что ему надо передать некие данные из пункта Б в пункт Ж - то видимо надо передать, да. Вот по составу и структуре этих данных я бы верить не стал. А в саму необходимость передачи - придется.
Нужны ли знания дискриминантной математики в изучении языка Java ?
-Давайте напишем функциональность Х, её в ТЗ не было, но нюхом чую что запросят
-Ты чо, следуй KISS, и не умничай
* Клиент запрашивает функциональность Х
* Программисты, поскольку следовали KISS, не могут добавить Х не переписав всё с нуля 0_0
если будут следовать другим принципам, то смогут добавить что угодно не переписывая с нуля)
архитектура должна была предполагать X, Y и Z. Вы же знаете, что захочет заказчик. И постоянную Планка ни в коем случае не пишите числом в каждой формуле, вдруг изменится))
Так это проблема заказчика. До старта же все обговаривается, функционал, время на работу и т.д. Доп функционал, доп деньги. А кодерам какая разница, работа есть и отлично)
@@alexanderberman9629
Если вам платят по часам и готовы добавлять часы на эти переделки - то всё отлично, да. Кроме слова "если".
@@Лучшеникакогознаниячемникакое есть только два варианта: работа по часам и работа по ТЗ. Если программист соглашается на условия " я пока не знаю что я хочу, но удовлетвори меня за 100 рублей" то он самдурак :)
То что ты думаешь , не то что вводит заказчик. . Чем меньше строк кода тем меньше багов.! круто.
но ! чем больше красивых строк Python тем больше в x^степине больше багов?
где купить хороший микрофон?
Не могу согласиться с некоторыми советами. Пару слов по поводу примера об ИНН и телефонах в контексте современных веб сервисов.
Первое: каждое узко направленное поле ввода всегда должно иметь соответствующую валидацию и констрейнты в бд. Любая последующая обработка таких данных становится невозможной если не были соблюдены правила ввода. Вы никогда не узнаете в какой день прийдут новые требования по этим данным.
Второе: чтоб избежать каши в данных достаточно нанять UX дизайнера, который по юскейсам нарисует подходящий интерфейс с нужными возможностями. Юзер пишет емейл в поле фамилии не потому что он не понимает что делать, а потому, что UX кривой. Нет поля для емейла или коммента, например.
Лайк за тризуб, чекаю коли Сергій заговорить соловїною :)
Я вільно розмовляю українськой, але мене зручніше російською, тому от....
@@SergeyNemchinskiy це такий собі аргумент, я від усіх колег чую "вільно розмовляю" а насправді ото тільки ці фрази і знають, далі "мнє так удобнєй". Додайте рубрику Немчинський Українець , як раз попрактикуємось в тісному кругу розробників, література вже є з перекладами технічних і не тільки термінів:) якісь новини, особисто мені таке цікаво, ясна річ справа за автором.
lombok и генерация ацессоров IDE это совсем разные вещи. Во втором случае IDE генерит кучу бойлерплейта, с котором потом придется сталкиваться при рефакторинге, и просто при чтении кода.
серьезно? Вы читаете код гетеров и сетторов? Вы хотите об этом поговорить?
@@SergeyNemchinskiy ну да - у нас в углу кто-то накакал, но не мешает же? Не смотрите туда, окошко откройте. Бойлерплейт в любом случае мешает. Конечно, в основном его приходится пролистывать в поисках полезной нагрузки, но это тоже занимает время. Особенно когда приходится переключаться между множеством классов. Это просто мусор в коде, он не нужен.
и это только ацессоры, а equals/hashCode? Сколько раз было такое, что при добавлении поля забывали его прописать. И да, оно там ещё и под слоем ацессоров где-то зарыто.
У Сергея Джава головного мозга :) Понять и простить :)
@@SteelS0ldier это нужный и важный "бойлерплейт". Как минимум в многопоточном окружении есть задача изготовить иммутабельный POJO, при этом требование рекурсивной иммутабельности для всех полей поджика слишком строгое и нужно реализовать копирующие геттеры. Ломбок и прочие костыли так не умеют (есть только анноташка @Value которая делает не совсем то, что нужно). Код должен быть абсолютно прозрачным, а современные IDE позволяют сворачивать/разворачивать тела методов в редакторе. Кучу раз бывало такое, что нужно было подебажить библиотеку X, а ее исходники не совпадают с class-файлами, потому что Lombok нагенерил доп. код и у отладчика несоответствие между сурсами и байткодом.
2:30
Только хотел сказать, что, по факту, любой современный фреймворк (из мира PHP точно) нарушает принцип KISS, потому что имеет в себе сильно больше, чем нужно для 90% задач, где этот фреймворк используется. С другой стороны, в велосипедах, даже простых, тоже ничего хорошего нет. В общем, нет идеальных решений, во всем есть недостатки.
Но 10% всё ещё где то используется, а значит этот функционал нужен. Автор видео говорил о том, что не нужно делать то, что не просили или то, что никто не будет использовать в ближайшем будущем. Но если хотя бы 1% пользователей например использует какой то функционал который большинство не использует - это уже много.
Так а зачем использовать фреймворк, от которого требуется только 10% функционала?) Проще уж подключить нужные либы и использовать их. P.S. Это ваш субъективный взгляд. Очень много работаю с Laravel, за всё время пригодился, пожалуй, весь его функционал, кроме Mix. На большей части проектов так же используется сильно больше чем 10%.
понапридумали же... Считаю доп функционал нужен, это продукт. А вот при доработке - только ТЗ, ни шагу в сторону.
Здравствуйте, мои дорогие, меня зовут Сергей Сириусли... )))
Аналогия с рабочими - весёлая. Это же ровно как и в работе программиста бывает.
Про валидацию Сергей описывает типичное ООП-расπZdяйство, невозможное в приличном ФП.
А в неприличном?))
@@0imax , неприличное - лиспы и прочее бестиповое лямбда исчисление.
код удаленный из проекта но оставшийся в гите, там и останется навечно. при необходимости восстановления функционала будет написан заново
если конечно не найдется ктото, кто помнит, что такое есть...
физические константы хардкодить? и жить без sv_gravity?
Lombok решает! У него нет зависимостей в рантайме. Как раз эта библиотека позволяет в 10 раз упростить джавовский код до версии 15 preview.