Тверді принципи проти YAGNI

Коли принципи SOLID стають YAGNI?

Як програмісти, ми постійно робимо компроміси між складністю, ремонтом, часом розробки тощо. Серед інших, два з найрозумніших рекомендацій щодо вибору - це, на мій погляд, принципи SOLID та YAGNI. Якщо вам це не потрібно; не будуйте його, а зберігайте його в чистоті.

Наприклад, наприклад, коли я дивлюсь серії dimecast на SOLID , я бачу, що вона починається як досить проста програма, і закінчується як досить складна (кінець, так, складність також в очах глядача), але це все ще робить мені цікаво: коли принципи SOLID перетворюються на те, що вам не потрібно? Усі тверді принципи - це способи роботи, які дозволяють використовувати зміни на більш пізньому етапі. Але що робити, якщо вирішити проблему досить просто, і це викидне додаток, то що? Або принципи SOLID чимось завжди застосовуються?

Як просять у коментарях:

• Тверді принципи
• ЯГНІ

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

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

Зазвичай я використовую такий підхід: якщо я пишу простий додаток для певного завдання, я іноді відмовляюся від принципів великого імені на користь кількох рядків коду, які працюють. Якщо я виявлю, що я повертаюся до цього додатку, щоб вносити подальші зміни, я знайду час, щоб зробити його ТВОРЧОЮ (хоча б дещо, оскільки 100% застосування принципів рідко можливо).

У великих програмах я починаю з малого, і коли програма розвивається, я застосовую принципи SOLID, де це можливо. Таким чином я не намагаюся спроектувати всю справу вперед до останнього перерахунку. Це, на мій погляд, приємне місце, де співіснують YAGNI та SOLID.

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

Натомість краще зрозуміти принципи та проблеми, які SOLID намагається вирішити; а також принципи та проблеми, з якими намагається вирішити YAGNI. Ви побачите, що одна стосується архітектури вашої програми, а друга стосується процесу розробки в цілому. Хоча в деяких випадках можливе перекриття, вони є різними проблемами.

YAGNI (Ви не потребуєте цього [вигадливий американський абревіатура]) стурбований тим, що економить час розробника, додаючи сталеві залізобетонні фундаменти до мосту, який призначений тільки для простягання 3-футової широкої затоки, коли простіший дерев'яний міст буде робити просто штрафу. Якщо ми пролягаємо на милі широкою річкою і потребуємо підтримки кількох тракторних причепів, звичайно, нам знадобляться додаткові фундаментальні роботи. По суті, YAGNI пропонує вам переглянути більшу картину та дизайн для поточних потреб. Це вирішення проблеми зробити щось занадто складне, оскільки ми передбачимо низку потенційних потреб, які замовник ще не визначив.

SOLID переймається тим, як ми переконаємося, що шматки мосту належним чином поєднуються та можуть бути збережені з часом. Ви можете застосовувати принципи SOLID як для дерев'яного мосту, так і для сталевого залізобетонного моста.

Коротше кажучи, ці дві концепції не обов'язково суперечать один одному. Коли ти стикаєшся з ситуацією, коли ти вважаєш, що вони є, настав час поглянути на велику картину. Залежно від вашого висновку, ви можете вирішити покінчити з частиною принципів SOLID або ви можете вирішити, що вам це дійсно потрібно.

Принципи SOLID не потрібні, коли це програма, що викидає; інакше вони завжди потрібні.

SOLID та YAGNI не розходяться: Хороший дизайн класу полегшує додаток в обслуговуванні. YAGNI просто зазначає, що ви не повинні додавати можливість для вашої програми бути такою настроюваною жахливістю, яка може робити все під сонцем, - якщо цього насправді не потрібно.

Це різниця між автомобільним класом, який має чітко визначені межі (SOLID), і класом автомобіля, який має можливість самолікування (YAGNI), перш ніж клієнт про це вимагає.

Нічого не стосується завжди! Не дозволяйте архітекторам архітектури лякати вас! Важливо - спробувати зрозуміти, з якими проблемами намагаються вирішити ці принципи, щоб ви могли прийняти зважене рішення щодо їх застосування.

Нещодавно я намагався зрозуміти, коли я повинен використовувати Принцип єдиної відповідальності ( ось що я придумав.)

Сподіваюся, це допомагає!

Є цитата, приписана Ейнштейну (ймовірно, варіація реальної ):

"Все повинно бути максимально простим, але не простішим".

І це більш-менш підхід, який я використовую при зіткненні з компромісом SOLID проти YAGNI: застосовувати їх альтернативно, тому що ніколи не знаєш, чи є програма «викинутим» кодом чи ні. Отже, просто додайте шар бруду, який працює, а потім відшліфуйте його до більш чистих інтерфейсів ... і повторюйте, поки не перейдете на потрібний рівень ентропії. Сподіваємось.

Існує багато способів розробити програму для заданої проблеми; SOLID - це спроба виявити властивості хорошого дизайну. Правильне використання SOLID повинно спричинити за собою програму, яку простіше міркувати та змінювати.

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

Програма, розроблена добре, не обов'язково орієнтована лише на необхідні їй функції. Програма, орієнтована лише на необхідні функції, не обов'язково має бути добре розроблена. Немає компромісу, лише дві ортогональні осі у просторі прийняття рішень. Ідеальна програма є одночасно модульною і має лише істотні функції.

Я думаю, що ви повинні запустити YAGNI, і коли є потреба, SOLIDify.

Що я маю на увазі - це SOLID, тож коли ви додаєте новий клас, вам не доведеться переробляти, просто перемкніть реалізацію (наприклад), ну, на мою думку, просто напишіть свій код і коли побачите, що ви змінюєте речі - змініть його на SOLID (тобто побоюючись рефакторингу, який SOLID повинен врятувати від вас - це не так вже й погано, коли ви тільки починаєте).

Ви не витрачаєте час, тому що вам доведеться виконати роботу в будь-якому випадку (на початку), і там, де це потрібно, вам приємно і охайно.

Я думаю, ви можете назвати це лінивою оцінкою SOLID.