Дизайн для майбутніх змін або вирішення проблеми [закрито]

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

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

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

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

Щоб звести його до одного великого правила: менше - більше.

Ви знайомі з Agile? Один з великих принципів Agile - YAGNI . Я вважаю, що це найкращий спосіб підійти до речей.

"Вам це не потрібно" ... це принцип екстремального програмування (XP), який заявляє, що програміст не повинен додавати функціональність, поки не буде визнано необхідним. Рон Джеффріс пише: "Завжди реалізовуйте речі, коли вони вам справді потрібні, ніколи, коли ви просто передбачите, що вони вам потрібні".

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

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

Це, мабуть, одна з найскладніших частин розробки програмного забезпечення, оскільки вам потрібно пройти лінію між "YAGNI" та "PYIAC" (Paint Yourself Into A Corner).

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

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

Я витрачаю деякий час наперед, думаючи про загальний напрямок дизайну - не надто багато, але достатньо, щоб в основному накреслити огляд високого рівня. Потім я дотримуюся гнучкої методології, заснованої на історії, використовуючи TDD для розробки рішень для окремих сюжетів. Коли я впроваджую через TDD, я пам’ятаю свій огляд високого рівня та (а) спрямовую свої конкретні реалізації на виконання огляду високого рівня або (b) рефактор (і вдосконалення) свого розуміння / спрямування на високому рівні на основі що я дізнаюся під час тестування / впровадження.

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

Хороший дизайн відповідає майбутнім змінам і, безумовно, варто йти на це. Розглянемо операційну систему UNIX та її "все є філософією файлів". Це дизайнерське рішення було прийнято не для задоволення певної негайної потреби, а з метою майбутніх вимог. Можна здригнутися, подумавши, як виглядатиме операційна система на основі "спритного" дизайну.

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

Я думаю, я чув, як інші люди щось говорили про таке:

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

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

Це залежить від проекту, і, коротше кажучи, досвід навчить вас, що таке "+1".

Філософію YAGNI , що вам не знадобиться, можна узагальнити (із статті):

На думку тих, хто виступає за підхід YAGNI, спокуса написати код, який наразі не є необхідним, але може бути в майбутньому, має такі недоліки:

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

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

В основному, враховуючи перелік конкретних вимог, спроектуйте це, однак це не означає, що не слід:

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

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

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

Що це говорить? "Коли все, що у вас є, є молоток, все починає виглядати як цвях".

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