Я використовую спритну методологію (SCRUM) вже близько трьох років, і я бачу певні її переваги, особливо в короткостроковому зворотньому зв’язку на багатьох рівнях (від клієнтів, які мають ранній доступ до реалізованих функцій, від тестерів, які можуть перевірити функції як як тільки вони будуть впроваджені, від інших розробників, які можуть надати дуже швидкий зворотній зв'язок щодо нового коду через огляд тощо).
З іншого боку, у мене є дві відкриті проблеми, першу з яких я спробую пояснити в цьому питанні.
Проблема: Складність отримати хороший дизайн
Я намагаюсь робити рефакторинг, як тільки код стає безладним, я пишу тести одиниць, наскільки це можливо (що допомагає запобігти помилкам взагалі і, зокрема, рефакторингу). З іншого боку, розробка якоїсь складної функції з невеликими кроками, щоденна фіксація та постійне переосмислення коду, коли він стає неструктурованим, не дозволяє мені створити дійсно гарний дизайн.
Єдиний добре розроблений модуль, який я міг виготовити останнім часом, я отримав, використовуючи інший підхід: я проаналізував проблему протягом декількох днів (у мене фактично була проблема, що пройшла через розум за пару місяців, перш ніж я почав серйозно працювати над цим ), замальовував досить детальний проект усіх занять та їхніх стосунків ще пару днів, а потім замкнувся в своєму кабінеті і записав увесь код, працюючи без перерви близько трьох тижнів. Результат - найкраща річ, яку я створив за певний час, із дуже мало помилок, які досить легко було знайти та виправити, та з дуже чітким дизайном, який не потребував відповідних змін з тих пір.
Тож дотепер я вважав, що набагато ефективніше заздалегідь отримати загальну картину того, що я хочу зробити, ніж починати писати код невеликими кроками з надією, що велика картина магічно з'явиться в процесі. Маючи максимум зусиль, підхід до розвитку малого приросту завжди призводив мене до гіршого дизайну.
Питання : Хто-небудь мав подібний досвід? Я застосовую SCRUM неправильно або на що слід звернути увагу, якщо я хочу розвиватися невеликими кроками і все-таки закінчуватись добре розробленою програмою? Або я повинен запланувати історію користувача дизайну, перш ніж розпочати фактичне кодування? Чи вважається це гарною практикою, принаймні для особливостей, які складніші за середні?
Редагувати - ПРИМІТКА
Я усвідомлюю той факт, що хороший дизайн не є чимось абсолютним і не має значення сам по собі, але це залежить від контексту, і що слід орієнтуватися на дизайн, достатньо хороший для вирішення проблеми.
Наприклад, я не переймаюся хорошим дизайном, якщо мені доведеться реалізувати простий компонент, який (1) повинен бути готовий якнайшвидше, (2) буде використовуватися лише один раз, (3) використовується іншими частинами системи (YAGNI).
Я дбаю про хороший дизайн, коли компонент (1) буде використовуватися кілька разів і в декількох різних випусках продукту, (2) потрібно підтримувати і розширювати з часом, (3) має багато інших компонентів залежно від нього .
The only well-designed module I could produce recently I obtained by taking a different approach- Ви відповіли на власне запитання. Вам все одно потрібна якась передня конструкція; не можна сподіватися, що хороший дизайн просто органічно виросте від рефакторингу. Це не працює так.