SOLID vs. Уникнення передчасної абстракції

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

• Хочу уникнути передчасного абстрагування. З мого досвіду, малювання абстракційних ліній без конкретних випадків використання (таких, які існують зараз або в осяжному майбутньому) призводить до того, що вони малюються в неправильних місцях. Коли я намагаюся змінити такий код, лінії абстрагування заважають, а не допомагають. Тому я схильний помилятися на тому, що не малюю жодних абстракційних ліній, поки не буду добре уявляти, де вони були б корисні.

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

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

EDIT: Що стосується окремих принципів SOLID, я мав наголосити, що Заміна Ліскова - це ІМХО - формалізація здорового глузду, і його слід застосовувати всюди, оскільки абстракції не мають сенсу, якщо це не так. Крім того, кожен клас повинен нести єдину відповідальність на певному рівні абстракції, хоча це може бути дуже високий рівень з деталями реалізації, всі вони набиті на один величезний клас 2000 ліній. В основному, ваші абстракції повинні мати сенс, де ви вирішите зробити конспект. Принципи, які я сумніваюсь у випадках, коли модульність не є однозначно корисною, є відкрита-закрита, сегрегація інтерфейсу і особливо інверсія залежності, оскільки мова йде про модульність, а не просто абстрагування має сенс.

Нижче наведено прості принципи, які ви можете застосувати, щоб допомогти вам зрозуміти, як збалансувати дизайн системи:

• Принцип єдиної відповідальності: SSOLID. Ви можете мати дуже великий об’єкт за кількістю методів або кількістю даних і все одно дотримуватися цього принципу. Візьмемо для прикладу об’єкт Ruby String. Цей об’єкт має більше методів, ніж можна потиснути палицю, але він все ще несе лише одну відповідальність: утримуйте рядок тексту для програми. Як тільки ваш об’єкт починає брати на себе нову відповідальність, починайте замислюватися над цим. Проблема з технічним обслуговуванням задає себе питанням: "де я очікую знайти цей код, якщо у мене виникли проблеми з ним пізніше?"
• Простота рахується: Альберт Ейнштейн сказав: "Зробіть все максимально просто, але не простіше". Вам справді потрібен цей новий метод? Чи можете ви виконати те, що вам потрібно, з існуючим функціоналом? Якщо ви дійсно думаєте, що має бути новий метод, чи можете ви змінити існуючий метод, щоб задовольнити все необхідне? По суті рефактор, коли ви створюєте нові речі.

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

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

Як і у всіх інших творчих дисциплінах, немає абсолютів - просто компроміси. Чим більше ви це робите, тим "простіше" стає вирішувати, коли цього достатньо для вашої поточної проблеми або вимог.

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

I want to avoid premature abstraction.In my experience drawing abstraction lines without concrete use cases... 

Це частково правильно і частково неправильно.

Неправильно
Це не є причиною заважати застосувати принципи ОО / СОЛІД. Це лише заважає застосовувати їх занадто рано.

Який є...

Право
Не змінюйте код рефактора, поки він не буде відновлений; коли це вимоги завершені. Або коли "випадки використання" все є, як ви кажете.

I find simple, tightly coupled procedural or God object code is sometimes easier to understand than very well-factored...

Під час роботи в самоті або в силосному середовищі
Проблема з невиконанням ООС не відразу очевидна. Після написання першої версії програми:

Code is fresh in your head
Code is familiar
Code is easy to mentally compartmentalize
You wrote it

3/4 цих добрих речей швидко вмирають за короткий час.

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

У команді
Проблеми з невиконанням ОО негайно помітні. Хороший код OO є принаймні дещо самодокументованим та читабельним. Особливо в поєднанні з хорошим зеленим кодом. Крім того, відсутність структури ускладнює розділення завдань та інтеграцію набагато складніше.

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

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

Я схильний до цього більше підходити з точки зору You Ain't Gonna Need It. Ця публікація буде зосереджена зокрема на одному пункті: спадщині.

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

Хорошим прикладом цього є рамка MVC. Починаючи з нуля, ви створюєте одну велику сторінку з кодом позаду. Але тоді ви хочете додати ще одну сторінку. Однак один код, який знаходиться позаду, вже реалізує багато логіки, необхідної новій сторінці. Отже, ви абстрагуєте Controllerклас / інтерфейс, який буде реалізовувати логіку, характерну для цієї сторінки, залишаючи загальні речі у вихідному "боговому" коді позаду.

Якщо ви знаєте як розробник, коли НЕ застосовувати принципи через майбутнє коду, то добре для вас.

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

Що ще важливіше, врахуйте, що більшість розробників займаються денною роботою і не хвилюються так само, як ви. Якщо ви спочатку виклали довгі методи роботи, то які інші розробники, які входять до коду, думають, коли вони прийдуть його підтримувати чи розширювати? ... Так, ви здогадалися, BIGGER функції, LONGER запущені класи та БІЛЬШЕ Бог об'єкти, і вони не мають принципів на увазі, щоб мати можливість зловити зростаючий код і правильно закріпити його. Ви "читабельний" код тепер стає гнильним безладом.

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

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

Не забуваймо також, що великі функції та об'єкти Бога можуть бути надзвичайно важкими для перевірки. Якщо ви хочете залишатися спритними та відчувати себе "безпечно" при повторному факторингу та зміні коду, вам потрібні тести. Тести важко записати, коли функції чи об’єкти роблять багато речей.

Проблема з об'єктом бога полягає в тому, що зазвичай можна вигідно розбити його на частини. За визначенням, це робить більше ніж одне. Вся мета його розбиття на менші класи полягає в тому, щоб ви могли мати клас, який добре спрацьовує одну справу (і ви також не повинні розтягувати визначення "одна річ"). Це означає, що для будь-якого класу, коли ви дізнаєтесь одну річ, яку він повинен робити, ви зможете прочитати його досить легко і сказати, чи робить це одна справа правильно.

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

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

Крім того, слід пам’ятати про ТОЛИЙ, але скоріше як провід, ніж правило.

Що, якщо що, не так з об'єктами Бога та щільно зв'язаним кодом, якщо вам явно не потрібна більше модульність, не маєте значного дублювання і код читається?

Якщо додаток досить малий, все можна ремонтувати. У великих програмах об'єкти Бога швидко стають проблемою. Врешті-решт реалізація нової функції вимагає зміни 17 об'єктів Бога. Люди не дуже добре дотримуються 17-крокових процедур. Об'єкти Бога постійно змінюються декількома розробниками, і ці зміни доводиться повторно об'єднувати. Ви не хочете туди їхати.

Я поділяю Ваші занепокоєння щодо надмірної та невідповідної абстракції, але я не обов'язково так переймаюся передчасною абстракцією.

Це, мабуть, звучить як суперечність, але використання абстракції навряд чи спричинить проблему до тих пір, поки ви не занадто рано звертаєтесь до неї - тобто до тих пір, поки ви будете готові та зможете переробити її за потреби.

Це означає, що в коді є деяка ступінь прототипування, експериментування та зворотного відстеження.

Однак, не існує простого детермінованого правила, яке слід вирішити, щоб вирішити всі проблеми. Досвід - це багато, але ви повинні набути цього досвіду, помиляючись. І завжди є більше помилок, щоб зробити попередні помилки вас не підготували.

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

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

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

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

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

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

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

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