Я щойно прочитав посилання на статтю, яку ви опублікували, я мушу сказати, що Фаулер зробив деякі дуже хороші моменти, і багато чого, що він сказав, я виступав з нашою командою роками.
ІМО, якщо ви зробите будь-який пристойний дизайн, ви не повинні потрапляти в те, що вважалося б тупиковою ситуацією. Я завжди розглядав програмне забезпечення як складовий елемент . Я все ще вірю в деякий передовий дизайн, але головна мета - не розробити весь продукт, а забезпечити загальну архітектуру / напрямок, щоб ваша команда могла уявити загальну картину, над якою ми всі працюємо. Якщо у вас є кусочки кубиків і трикутників, корисно промальовувати, як би склали замок, перш ніж просто почати плескати шматки разом.
Оскільки я родом з OO land, для мене кожен блок є класом, а площа поверхні цього блоку - це публічний інтерфейс (те, що видно зовнішніми або похідними класами). Якщо ви будете дотримуватися хороших принципів SOLID, ви переконаєтесь, що кожен блок є надзвичайно простим і має інтуїтивно зрозумілий інтерфейс. Повертаючись до моєї аналогії, ви хочете переконатися, що код створює лише прості форми. Кожного разу, коли ви створюєте занадто складні класи (багато функцій, багато змінних), ви створюєте фігури, які важко повторно використовувати, коли вимоги змінюються.
Я погоджуюся з Фаулером у тому, що найбільший ризик / виклик для еволюційного дизайну полягає в тому, що ви залишаєте дизайнерські рішення на час кодування, і ви очікуєте, що кожен окремий розробник прийме ці рішення. Тут система може вийти з ладу, якщо у вас немає належних механізмів зворотного зв’язку. Кожного разу, коли вимагається нова функція, надзвичайно спокусливо просто знайти функцію, яку потрібно розширити, помістити в неї якийсь умовний характер і просто додати цілу купу коду прямо у цю функцію. Іноді це може бути все, що потрібно, але це також (IMO) єдина найпоширеніша практика, яка призводить до тупикових компонентів. Це не має нічого спільного з еволюційним дизайном. Це те, що називається "без дизайну".
Поки ви знайдете час, щоб відступити назад і сказати, почекайте хвилину, цей клас вже має 15 змінних членів, дозвольте мені витягнути 6 з них і помістити їх у власний автономний клас, ваше програмне забезпечення буде складатися з дуже легкого - вагові, гнучкі та багаторазові будівельні блоки. Впевнені, що якщо прем'єр-міністри зійдуть і змінять половину вимог до вас, можливо, доведеться вийняти кілька своїх блоків, покласти їх назад на полицю і скласти нові (так само, як при будівництві замку, ви можете використовувати не всі ваші циліндри). Але на той момент це лише частина ведення бізнесу. Вимоги змінилися, і зберігаючи свій код гнучким та модульним, ви зможете змінити свій продукт, щоб він відповідав вашому новому напрямку бізнесу.
Я вважаю, що цей еволюційний підхід до проектування працює з кожним рівнем майстерності інженера. Особисто я займався програмним забезпеченням дуже давно, і до того, як наша команда перейшла на спритну методологію, я відповідала за доставку декількох основних компонентів з мого комп'ютера розробників майже безпосередньо до замовника з майже будь-якою якістю. У той же час ці компоненти завжди залишалися гнучкими та ретельними.
Я лише намагаюся сказати, що вважаю себе відносно пристойним у розробці програмного забезпечення. У той же час, якщо ви попросили мене написати документ на 100 сторінок, дати його кодеру і очікувати, що він спрацює, я, ймовірно, не міг створити себе з паперового пакета. Починаючи роботу, я іноді малював би декілька UML-подібних (дуже спрощених, не повних мов) діаграм, але, коли я починаю кодувати, я б переробляв за необхідності, і мій кінцевий код ніколи не буде схожий на те, що я спочатку намалював. Навіть якщо я витрачаю місяць-два на роздуми над кожною дрібницею, я не можу уявити, як хтось інший зможе взяти мої діаграми та придумати суцільний програмний продукт, не змінюючи дизайн, який вони кодують.
На іншому кінці спектру, в даний час у моїй команді (зараз спритна, і я це повністю підтримую) у нас є пару хлопців, які приєдналися до нас із вбудованої землі, де вони робили лише C протягом останніх 15 років. Я, очевидно, допоміг з початковим плануванням та складанням занять, але я також переконався, що слідкуйте за регулярними оглядами коду та сеансами мозкового штурму, де ми обговорюємо застосування програм SOLID та принципи проектування. Вони створили код спагетті, який трохи змусив мене, але, лише злегка відштовхнувшись від мене, вони почали переробляти те, що вже було вироблено. сказати це, але після переміщення цього коду це виглядає набагато зрозуміліше і зрозуміліше. Тупик відвернутий. Точка I ' Я намагаюся зробити те, що навіть той, хто є абсолютно новим для OO, може створити дещо пристойний код, якщо він має наставника з більшим досвідом, щоб нагадати йому, що "еволюційний дизайн" - це не те саме, що "no design". І навіть деякі його "складніші" класи не такі страшні, тому що кожен клас не має такої великої відповідальності (тобто не так багато коду), так що найгірше стає гірше, якщо цей клас "тупикові", ми патронник і записувати клас заміни, який має той самий публічний інтерфейс (поки що я ніколи не бачив необхідності в цій надзвичайній ситуації ні в чому, про що ми писали, і я робив огляд коду двічі на тиждень).
На завершення я також твердо вірю в конструкторські документи (принаймні, для бізнес-умов моєї нинішньої команди), але головна мета для наших дизайнерських документів - організаційна пам'ять , тому фактичні документи пишуться після створення коду та реконструйований Перед кодуванням у нас, як правило, є швидка (іноді не така швидка) фаза проектування, де ми накреслюємо заняття на серветках / mspaint / visio, і я завжди нагадую людям, що ця фаза створює шлях, а не крок, і коли вони починають кодування, все, що не має сенсу, слід змінювати. Навіть із цими нагадуванням, новіші хлопці прагнуть повернути підходящий код до оригінального дизайну, незалежно від того, наскільки це проти них неприродно. Зазвичай це стосується оглядів коду.
Данг, я багато писав. Вибач за те.