Коли віддати перевагу узагальненому рішенню перед вирішенням конкретних випадків

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

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

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

Спочатку ви передаєте сіль. Потім перекладаємо перець. Потім перекладаємо тертий сир пармезан. На даний момент у вас є достатній досвід, щоб розпочати розробку загальної системи передачі приправ.

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

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

Досвід.

Єдиний спосіб дізнатися - спробувати один шлях раніше, побачивши, як це вас покусало в дупу (або ви витратили купу часу). Повторюйте, поки менше не покусаєте в попу.

Навіть тоді ви насправді не знаєте ; ви просто краще здогадаєтесь.

Щоб спиратися на відповіді dasblinkenlight та Paddy3118 , якщо у вас немає декількох випадків для реалізації, тоді вам не потрібно узагальнювати! Причина, що мультфільм XKCD є смішною, полягає в тому, що він висуває передчасне узагальнення . Після того, як його попросять передати сіль, небачений персонаж одразу перескакує до "розробки системи для передачі довільних приправ", коли все, прошене першим персонажем, було сіллю. Це хороший жарт для розробників, оскільки я думаю, що ми всі бачили випадки передчасного узагальнення.

Принцип, протилежний передчасному узагальненню, - YAGNI (You Ain't Gonna Need It). В Інтернеті є багато матеріалів про це, але в основному YAGNI вказує на низку ризиків узагальнення без вигоди декількох реальних випадків використання, включаючи можливість того, що випадки багаторазового використання можуть фактично не з’являтися. Або, більш тонко, відсутність реальних випадків використання вимагає зробити припущення про необхідність у майбутньому. Ці припущення можуть бути, а часто і є, невірними.

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

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

Зробити це один раз, зробити два рази, зробити це три рази, узагальнити.

Раз, два, багато!

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