Разбираем говнокод. Типичные ошибки ведущих программистов
Вставка
- Опубліковано 17 чер 2024
- Популярные ошибки ведущих разработчиков программного обеспечения, которые совершаются каждый день и ведут к увеличению стоимости поддержки и расширения приложений любого размера.
В этом видео рассмотрим реальный пример созданного ПО, который смело претендует на почётный ярлык «Говнокод».
Каким образом, в кратчайшие сроки, непродуманное решение привело к частым отказам работоспособности системы. Высокой стоимости внесения каких-либо изменений и повышенному сцеплению (coupling and cohesion) независимых модулей.
Но главное, вы увидите успешно внедренное решение и как оно помогло решить все вышеперечисленные архитектурные и дизайнерские проблемы.
Программа:
00:00 Введение
02:13 Описание бизнес-задачи
04:52 Совет
05:38 Говнокод и ошибки
12:44 Решение #1
15:08 Решение #2
17:06 Решение #3
18:20 Итоги
21:37 Выводы
Наш сайт:
jetbulb.com/
interview.jetbulb.com/
Мы в социальных сетях:
t.me/jetbulb
Отличный формат(рубрика) который обязательно должен жить и стать фишкой этого канала. Однозначно Лайк! И на правах лайкнувшего, если можно, небольшое замечание, чуть поменьше воды и больше сути, чтобы видео были короче...
Спасибо за твой отзыв))
Замечания приняты во внимание.
Контент, который мы заслужили. Подобных видео на ютубе не встречал. Хотелось бы побольше таких видео, разборов частых ошибок разработчиков и их решений. Спасибо
Макс твой контент-это квинтэссенция полезных конкретных советов и практических вещей. Я просто восхищаюсь тобой!! Ты делаешь реально полезный контент!!
Обожаю Ваш канал. Желаю дальнейших успехов из Тель Авива)
Спасибо)
Наш респект!
Я бы ещё подумал над:
- кастомизацией Exception. А не кидать общий Exception.
- Уйти от Object в пользу Generic. Избежать приведения типов и ClassCastException.
- использовать паттерн Стратегия. Таким образом сделать код расширяемым и отвечающим принципам SOLID.
или декоратор
Все верно.))
Правда не сильно вижу, куда тут стратегию подставлять при данных установках.
Стратегия говорит о получении доступа к подтипу абстрактной операции из контекста домена, при условии, что для этого домена таких подтипов может быть много.
То есть, есть менеджер и много видов операций обобщённых типом абстрактным и в зависимости от этого выполнить что-то.
Например: нарисовать карту на сервисе Google или на PDF документе.
В тоже время, не скажу что твоя мысль неправильная, вопрос только где она найдет применение в развивающейся задаче.)))
Респект!
Кайфовый формат, очень понравилось
Крутое видео и крутая марка на фоне)))
Марка чего?
@@gingerCatStore Почтовая марка
Спасибо Вам за все...
Вижу несколько ошибок.
- Огромное колличество аргуметов можно было бы объединить в отдельный объект и передавать его, а не это вот всё)
-Map параметризированная Objectом тоже не нравится, но починить не представляю
-Эксепшн везде глаза режет
-Может быть я скажу сейчас полную фигную, но get, getById, add, update тоже можно было бы улучшить. Сделав, например, интерфейс общий, который бы давал эти методы для каждой конкретной сущности и возвращал эту Map
Это моё чисто нубское мнение даже не джуниора
Update. А, ну сингл Sngl rspnsblt это само собой, я не думал, что это нужно писать вообще
Отличные замечания.
Можно создать обобщенный (generic) интерфейс и там уже указывать типы данных, для конкретных расширений и\или реализаций. Это позволит уйти от Object и Map там где не надо.
З.Ы. Вот многие говорят что SOLID и так понятно, он используется неявно. Однако, в тоже время многие попросту не следуют его элементарным наставлениям.
Этот разработчик нехило меня мотивирует. Думаешь: простой паренек, а столько знает.
Хехе, что-то мне эта задача с водителями и прокладкой маршрутов напоминает))
Interface segregation в действии)
Maksim thanks for the quality content. Watching all the interviews, I got a huge amount of knowledge and a job offer.
Thank you :)
This is the best feedback I have ever expected because when you know that what you do makes value for others, then this is the achievement.
1) 4 интерфейса имеют по 4 одинаковых метода: можно заменить это одним интерфейсом с разумным названием
2) РоутерСервис: согласно клин код бест практис: у функции должно быть в идеале 0 аргументов :) максимум 3. Поэтому создаём объекты Трак, Документ, Драйвер и передаём их как аргументы + используем ваш любимый билдер паттерн)
Отличные замечания и все в точку))
норм тема) лайк от СЕООНЛИ
Нарушение SRP приводит к God object, если кратко)
И ISP, который гласит, что лучше иметь много интерфейсов чем один общий
Обычно такие видео записывают нудные менторы, которых смотришь и хочется спать :).
Спасибо этому лектору за живенькую подачу материала, смотрится весело и с интересом! 😀
Спасибо большое ☺️
Будем и дальше стараться.
Хотелось бы посмотреть на практическую реализацию данного проекта. Имеется нехватка опыта построения архитектуры приложения.
Проект является частной собственностью, показывать я его не имею права.
Переписывать тоже дело непростое, небыстрое.
Я бы рекомендовал посмотреть оперсорсы, такие как Spring Framework.
Там много хороших и плохих примеров.
что-то поменялось, то ли прическа то ли лого... ))
Было бы круто поработать с таким лидом. Спасибо за контент.
поверь, работать с ним тебе не понравиться. Слишком много самолюбования
На словах "минутка призыва" неконтролируемо напрягся.
Зачем собирать интерфейсы сабдоменов в домены? Контроллеры доменов соответственно будут громоздкими
Это сервисы бизнес-логики и с контроллерами соприкасаться не будут. А даже если будут, то не являются частью Публичного API.
Потому можно быть спокойным, на сложности контролёров и их типов это не отразиться.
Использовать более подходящий инструмент, где 2 менеджера уже бы через 20 минут работали.
Вроде как джеки чан классы называются божественными классами (god class)
В том числе. Но разве компания не имеет право на слови псевдонимы?
Надо красок в жизнь добавлять)))
Какого фига провод торчит перед монитором. Весь ролик на него пялился))))
😀
Аааа зачем ты это написал!!! Мои глаза!!!
@@kishkish1632 🤣
Кабель короткий не вообще не гнется, самом глаз отрезает.
Пока такой workaround.
Сори.
@@Jetbulb попробуй поискать г образный разъем. Тогда кабель сразу на 90градусов уйдет под ноутбук и не будет маячить.
@@kotcheshir
Как вариант. Но я сейчас думаю про докстанцию, потому эти проблемы могут уйти сами по себе.
Тогда будет возможность использовать гибкий кабель и проблема уйдет.
kdeха на фоне детектед😀. или это мак😅
Задача уровня архитектора
Сеньеров сюда даже пускать нельзя
Но так как все экономят, то имеем то что имеем
Ситуация стандартная, рабочая и не самая плохая
Золотые слова.
Респект
Начинаем с минутки призыва?) Я вижу у вас рекламная интеграция с городским военкоматом...))) 😆
Немного "вывернутый наизнанку" пример из DDD.
Соглашусь.
Однако, тут больше речь шла не про DDD-архитектуру, но о принципах ООП дизайна и как с ними работать.
@@Jetbulb , объяснения и пример хорошие. Просто предысторию нужно было описать не как говнокод, а, к примеру, "сначала требования были просты и вся логика умещалась в один интерфейс. В ходе реализации аппетиты бизнеса росли и наш интерфейс стал разбухать пока не превратился в то, что мы имеем."
@@user-up2lc4kb5o Понял вас.
Не совсем так, как описываете)
Как раз так и было, что изначально требования заказчика были искажены разработчиком ответственным за эту часть.
В ходе реализации проекта-примера, требования не менялись до самого релиза.
Об этом то и речь в этом видео, что интерфейс изначально был оценен и разработан неправильно.
Надеюсь, пролил немного света :)
@@Jetbulb , спасибо за разъяснение, теперь стало понятнее))
@@user-up2lc4kb5o Да и вам спасибо)))
Все это натолкнуло на мысли, что в видео неправильно расставлены акценты и определенные вещи надо указывать более четко и явно.
вижу сзади картинку про русский корабль, вы с Украины?)
Да))
г. Одесса ⚓🚤
@@Jetbulb Привет с Черкас💪🏻
@@user-vv7tj4pf7b Респект
Heeeeeeeeeeeeeeeyyyyyy!
бро,ленивый пошел айти
10 минут говорит про букву I из Solid, строя из себя умника. FP просто
The interface segregation principle: "Clients should not be forced to depend upon interfaces that they do not use.
Что-то с эскалацией укробешенства у автора даже лицо меняется.