Це поганий знак того, що я часто переробляю під час розробки проекту?

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

• "Гей, мені потрібен клас _ _. Я раніше про це не думав".
• "Зачекайте, ця функція справді повинна бути в тому класі, а не в цьому. Я перенесу її."
• "Це насправді має бути два класи замість одного. Я розділю його".
• "Я повинен зробити так, щоб ці три самостійні класи успадкували від одного абстрактного класу."
• Etcetera, etcetera.

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

Це нормальна частина розвитку. Два основних принципи безперервного дизайну :

1. Ви не всезнаючий, не можете знати всю систему від початку до кінця до початку.
2. Дизайн не є статичним. Це є більш поширеним, коли проект уже тривалий час використовується, і проблеми, які він вирішує зараз, - це не ті проблеми, які він вирішував, коли він був написаний вперше.

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

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

Те, що ви робите, в народі називають "рефакторинг". Якщо ви коли-небудь перестанете це робити, то у вас виникнуть проблеми.

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

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

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

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

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

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

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

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

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

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

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