Чи надихаються шаблони дизайну?

Я мав дискусію з одним із наших старших розробників, який займався цим бізнесом 20 років. Він досить відомий в Онтаріо за блогом, який він пише.

Дивна річ - це те, що він мені сказав: він сказав, що є фрагмент коду, з яким можна працювати, тому що він написаний з підручника, і не враховує реального світу. Додавання нового поля до шару інтерфейсу користувача / бази даних / даних займає 2-3 години, тоді як для його коду - 30 хвилин.

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

Тоді також існує ідея, що більшість веб-розробників Канади вважають за краще, щоб їх модель даних успадковувалась із класів Data Layer, а не тримала її ізольовано. Я запитав його: "Хіба це не галузевий стандарт, щоб модель була відокремлена від рівня даних?" Він казав іноді, але більшість людей тут воліють не робити цього, бо це занадто багато роботи.

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

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

Що ви робите з цих тверджень?

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

Шаблони дизайну та кращі практики - це не одне і те ж. Деякі люди думають, що вони є, і заганяють людей, які знають, що роблять гайки. Навіть якщо вони не знають правильного імені для того, що роблять.

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

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

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

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

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

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

Stackoverflow.SE та Programmers.SE переважно спонукають людей дотримуватися найкращих практик, таких як SOLID, а не галузеві стандарти . Хочаш вірити чи ні, галузевим стандартом фактично є "велика кулька грязі" - серйозно.

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

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

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

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

Щоб додати супу ще одну метафору, дизайнерські зразки - це помічник помічника Microsoft Office. "Ви, здається, робите те ж саме з цілою купою речей. Чи можу я допомогти вам у цьому, пропонуючи вам Ітератор або Відвідувач?"

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

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

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

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

Додавання нового поля до шару інтерфейсу користувача / бази даних / даних займає 2-3 години, де, як і в його коді, потрібно 30 хвилин.

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

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

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

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

Ваш колега, здається, страждає від синдрому НІГ ("Тут не винаходили").

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

Уникання дизайнерських моделей насправді дивує. У мої останні 30 років кодування та управління кодерами дизайнерські зразки допомагали складати слова про речі, які були зроблені інстинктивно, допомагаючи швидше зрозуміти наміри, переваги, незручності, ризик, можливості та пов'язані з ними схеми. Шаблони дизайну виявились справжніми прискорювачами для оволодіння складністю!

• Можливо, ваш колега насправді набагато розумніший, ніж більшість із нас, і він може дозволити собі накладні витрати на винахідлення без помітного зниження продуктивності?

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

Багаторівневі підходи виявилися кращими за інші архітектури в більшості корпоративних додатків. Провідні пакети світового класу структуровані навколо цієї ідеї та перевершують кустарні архітектури на порядки. Мартін Фаулер представляє такий підхід у своїй чудовій книзі "Шаблони архітектури підприємства". Ой! Вибачте ще раз: мова йде про перевірені зразки; немає жодного шансу на думку НІГ вашого колеги ;-)

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

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

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

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

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

У цьому світлі, якщо ви справді не зобов'язані писати 100% одноразовий код, де жодні концепції чи реалізації не використовуються від одного випадку використання до іншого, ви майже напевно використовуєте хоча б деякі шаблони дизайну. Вони можуть не мати яскравих, поширених назв, таких як "Сховище" або "Блок роботи" або навіть "MVC", але це не робить їх "не дизайнерським зразком".

Зазвичай мені подобається думати про це, наприклад, "навігації" за допомогою GPS. Вивчаючи «кращі практики» та «схеми дизайну» - ви навчитесь користуватися маршрутом навігації GPS. Але коли ви знаєте місцевість, ви часто дізнаєтесь, що рух по бічній дорозі призведе вас до минулих проблемних ділянок, швидше та / або краще потрапить туди. Це майже те саме, що стосується цих речей - досвід дає змогу деконструювати панель інструментів і робити скорочення.

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

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

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

Додавання нового поля до шару інтерфейсу користувача / бази даних / даних займає 2-3 години, де, як і в його коді, потрібно 30 хвилин.

Якщо ви хочете "оптимізувати" дизайн, вам потрібно сказати, що ви намагаєтеся оптимізувати.

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

Наприклад, ідея шаблону "MVC" оптимізує такі речі, як:

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

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

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

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

Шаблони дизайну - це інструменти. Як і інструменти, є два способи їх використання: правильний та неправильний спосіб. Наприклад, якщо я дам вам викрутку і цвях і попрошу з’єднати два шматки дерева разом, ви повинні попросити мене молотком. Молотки використовують для цвяхів, тоді як викрутки використовуються для саморізів.

Занадто часто модель дизайну рекламується як Єдиний вірний шлях, що часто відповідає дійсності лише тоді, коли виникають конкретні проблеми. Молодші розробники часто подобаються дітям, коли знаходять щось нове, з чим грати; вони хочуть застосувати цю модель дизайну до всього . І в цьому немає нічого суттєвого поганого, якщо вони з часом дізнаються, що Шаблон А застосовується до проблеми B, а Шаблон C застосовується до проблеми D. Так само, як ви не використовуєте викрутку для прибивання цвяхів, ви не використовуєте конкретний шаблон лише тому, що він існує; ви використовуєте шаблон, тому що це найкращий (відомий) інструмент для роботи.

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

Звичайно, молодшим розробникам часто здається, що вони придумують нові способи робити старі речі, а іноді ці способи є кращими. Однак занадто часто це стає наслідком ефекту Даннінга-Крюгера; розробник знає достатньо, щоб скласти функціональну програму, але не розуміє власних обмежень. Єдиний спосіб подолати це, мабуть, через досвід, як позитивний, так і негативний. Вони ігнорують шаблони, тому що вважають себе вищими, але не знають, що насправді 10 000 розробників вже використовували певний дизайн, а потім відкинули його, бо насправді це було погано.

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

Кожен, хто стверджує, що шаблони - це Шлях, або стверджує, що зразки є «Беню існування», помиляється. Шаблони - це інструменти, призначені для застосування у конкретних ситуаціях та мають різний ступінь успіху залежно від обставин. Це правда, яка не залежить від того, вибрали ви MVC чи ні, використовуєте ви об'єкти передачі даних чи ні, і т. Д. Що важливо, це впровадження коду у досить короткий проміжок часу, який працює досить добре для користувачів, і розумно не має логічних помилок.

Зазвичай шаблони дозволять узгоджувати форму дизайну, і будуть краще, ніж ігнорувати всі шаблони на користь написання 100% оригінальних ідей, але ви не можете уникнути всіх шаблонів. Наприклад, якщо y = x + 5, чи дійсно ви збираєтесь написати y = x + (5 * 3 + 15/3) / 4, просто щоб уникнути шаблону написання x + 5? Ні, не ти. Ви збираєтесь написати y = x + 5 і переходите до наступної проблеми.

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

Ви не можете "уникати шаблонів дизайну", за винятком того, я думаю, уникаючи проектувати будь-які дві частини вашої системи однаково (що я не рекомендую, і я сумніваюся, що це робить ваш старший розробник). Напевно, це означає «уникати сліпого використання дизайну лише тому, що він дотримується шаблону дизайну». Думати про те, чим ти займаєшся, безумовно, є «найкращою практикою», і для викладання повинен існувати один університет ; на жаль, це, здається, не відбувається.

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

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

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