Як ПРОСТІ ПРИНЦИПИ роблять тебе ПРОФІ в програмуванні: SOLID, DRY, KISS, YAGNI

Хочеш стати ТОП-програмістом і створювати круті продукти? Ці 4 принципи — SOLID, DRY, KISS, YAGNI — зроблять твій код ідеальним!
Я поясню їх на простих прикладах, щоб ти міг застосувати їх уже сьогодні.
Ти дізнаєшся, як уникнути помилок, прискорити розробку і вразити своїх колег.

Таймкоди:
0:00 Вступ
0:20 Що таке SOLID?
0:45 Single responsibility principle
1:15 Open/closed principle
2:23 Liskov substitution principle
4:17 Interface segregation principle
5:53 Dependency inversion principle
7:27 DRY
8:35 KISS
9:07 YAGNI

Що ти отримаєш з цього відео:

Як SOLID змінює твоє уявлення про архітектуру коду.
Чому DRY = менше роботи і більше результату.
KISS: працюй простіше, а не більше.
YAGNI: не пиши зайве — твій код скаже тобі "дякую".
Це відео для тих, хто хоче не просто писати код, а створювати рішення, які працюють!

Став лайк, підписуйся і пиши в коментарях, які принципи ти використовуєш. Твій шлях до ідеального коду починається тут!

[yurakirichenko]

Настільки прості і зрозумілі аналогії що можна і дітям в школі пояснювати. Дякую за корисний відосик.

[Armen_Sarkisian]

Дякую за це відео! Все просто та наглядно! Бажаю вам подальшого розвитку, миру та здоровʼя!

[yuriytereshchuk]

Чудове мовлення. Неочікувано якісно і без засмічення англізмами типу — кейс, стаді ітд, що так полюбляють вживати наші медійники. Дякую.

[magellan]

Блін круто, тепер мені не страшно, що треба ще вчити SOLID, DRY, KISS, YAGNI. Я думав це щось набагато складніше, а тут все за 10 хвилин пояснили.) Дякую, поставив лайк підписався і поставив дзвіночок. Будемо мати справу.🤝

[donutWiggum]

Просто пояснили принципи соліду, дякую

[TedFanat]

Солід це добре, але знати це одне, а вміти використати це зовсім інше) Використати там де це дійсно треба - це ще інше) Загалом ніщо не зробить з вас профі крім як тонни написаного гімнокоду, який ви поступово будете писати краще і краще) І солід це не догма, підходьте до всього прагматично і з контекстом задачі, а не намагайтесь впихнути якнайбільше принципів і патернів в свій код, бо від цього зазвичай одні проблеми. З деякими задачами і частинами коду варто взагалі від ООП повністю відійти і написати все в функціональному стилі, але тут вже питання чи підтримує ваша мова програмування цю парадигму

[FOLDIK_UA]

solid знав, і постійно використовував, пояснення сподобалось, тому це звісно лайк. На рахунок інших вперше чкю, тому йду дивитись далі😊

[thebucefal]

Дякую за відео. Було б класно ще це поповнити принципами GRASP

[AlexSeligerX]

все ок, тільки не поспішай!

підписався

[AndriiMarusiak]

дякую за відео. Питання по принципу підстановки Лісков, ти брав приклад з АІ моделі? бо скільки раз не питав їх, зажди про пташок та пінгвінів пишуть приклад

[MalbertFenstein]

З DIP дуже багато упущень.
Мета принципу не пихати усюди абстракції, а чітно розділити та правильно направити ЗАЛЕЖНОСТІ.
Як ви думаєте чому принцип містить слово Inversion в назві?

[alpha_x]

Здається все ж зрозуміло, до моменту коли не починаєш писати реальний проєкт (чисто мій досвід).

[MsJaneJack]

для Java наче всі принципи легкі і зрозумілі. зараз перейшла на python і трохи загубилась в тому, що є гарним кодом

[oleksiisevastianovych]

Single Responsibility розказано не вірно, клас має мати лише єдину причину для зміни а не виконувати тільки одну функцію

[oleksandrsova]

Профі тебе зробить хіба вміння переконати команду слідувати цим принципам. Те, що ти виключно сам почнеш це робити - великого ефекту не дасть.

[HostageOfTheSituation]

Було б непогано мати цю інформацію в текстовому вигляді.

[ihorkovich]

Фронтенду на реакт солід не треба, а на ютубі писати коментарі більше ніж 7 слів треба, так?

[lentar]

Тлумачення SRP невірне. PaymentProcessor не повинен мати посилання на EmailService, а точніше не має залежати від змін EmailService. Якщо щось зміниться у класі EmailService, тоді логіка PaymentProcessor буде автоматично змінена. Щоб не порушувати принцип, варто створити клас вищого рівня, який буде поступово викликати методи з PaymentProcessor та EmailProcessor, а залежність від EmailProcessor у PaymentProcessor треба прибрати. Детальніше описав Роберт Мартін у книзі Чиста Архітектура.

[sergozar]

як на мене професіонал це не той хто знає 100500 принципів і будує uml діаграми для кожного подиху, а той хто адекватно робить свою роботу не засмічуючи код лишньою фігнею. Я вважаю, що оцей весь "чистий" код переоцінений

[johngalt]

Чергове відео з буль буль буль, пробіглися по прикладам які ви самі не писали і все.
Поставив вподобайку лише через українську мову.
Це дуже складе питання щоб його отак поверхово пояснювати.
І ще великою помилкою є коли ви на екрані миттєво з'являється купа коду і за пару секунд глядач має це все переварити поки ви тараторите щось.
Потрібно пояснювати пишучи код і в процесі написання розмірковуючи навіщо ми це робимо і чому саме так треба. А 90% відосиків вони ні про що, або набити кількість переглядів.