Як грати разом "Вам це не потрібно" та "Зараз краще, ніж ніколи"?

Я часто відчуваю, що обіймаю "зараз краще, ніж ніколи", коли просуваю СУХОСТЬ дизайну. Як правило, я вважаю, що мені потрібно виховувати розуміння Єдиного авторитетного місця для частини знання в контексті системи інших знань. Таким чином, я схильний проектувати систему "зараз".

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

Як ці два візерунки формуються вгору?

Які практики ви використовуєте для того, щоб вони грали добре?

Як ви навчаєте їх разом, не створюючи плутанини?

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

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

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

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

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

В будь-якому випадку, ви не можете нічого втратити з YAGNI.

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

Приклад

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

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

Практичний спосіб робити те, як він це зробив. Він розпочав роботу з PHP та MySQL, і переробив та переписав у міру необхідності на основі ділової цінності , масштабування мільйонів користувачів мало величезну ділову цінність, але не на день 0. У день 0 просто запуск чогось було величезною цінністю для бізнесу.

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

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

Шлях Дзен Пітона говорить:

Зараз краще, ніж ніколи. Хоча ніколи не буває краще, ніж зараз.

Ідея полягає в тому, що це не тому, що ви можете зараз визначити щось, що вам належить. Вам це потрібно зараз?

• Так: зробіть це зараз!
• Ні: не робіть цього! Чекайте потреби! ЯГНІ!

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

Отже, YAGNI, поки ви цього не зробите, тоді РОБИТИ ЗАРАЗ. Не чекай!

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

Але для того, що це варто, я не згоден з другою пропозицією, що "Зараз краще, ніж ніколи". Якщо вимога важлива, тоді доведеться її виконати. Тож "ніколи" - це не можливість. Якщо це не важливо, то "зараз" не краще - "ніколи" не краще.

Всього два мої центи.

Як ці два візерунки формуються вгору?

Вони ортогональні і не мають нічого спільного.

Які практики ви використовуєте для того, щоб вони грали добре?

Гм. Вони обидва? Що ще може бути?

Як ви навчаєте їх разом, не створюючи плутанини?

YAGNI описує функції, які бачать користувачі. Вам не потрібно фантазії.

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

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

Місцеві рішення, які ви приймаєте, повинні бути прозорими для решти системи.
Наприклад, якщо у вас є компонент CookieSource, який вимагає CookieFactoryперетворення знань, які CookieRecipesвони знають Cookies, виходячи з деяких ваших вхідних параметрів, то CookieSourceце не потрібно і, таким чином, не повинно залежати від того, як CookieFactoryреалізовано і як CookieRecipesвони представлені.
Якщо CookieFactoryнасправді це Bakery, це може взяти будь-яке, Recipeвідповідно, Pastryне має значення. І якщо вам не потрібна ця функціональність, немає необхідності в її реалізації. І в світі немає причин, чому ви не можете їх потім додати, за винятком випадків, коли немає чіткого бар'єру для абстракції між CookieSourceпослугами, якими він користується.

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

Найпростіше рішення, яке я знайшов - очікувати змін під час написання коду вперед. Коли я передаю якусь функцію bool функції, я, як правило, змінюю її якнайшвидше на прапор / переписки, щоб це було a) більш читабельним і b) легким для розширення. Так само, якщо я помітив, що я передаю купу параметрів там, де це пахне, мені знадобиться ще один, я зазвичай створюю спеціальну структуру. Сподіваємось, що YAGNI це, але якщо ви зробите в якийсь момент, це не зламає всіх користувачів одразу жахливо, і "груба робота" вже зроблена. Досить часто ви можете просто додати коментар, як / * майбутні доповнення, увійдіть сюди * /, або так, зрозуміло, що це ще не реалізовано, але ось де його додати. Це, як правило, допомагає найбільше, оскільки я пізніше виявив, що рефакторинг інтерфейсів є найбільш трудомістким.

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

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

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

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