Правильний поєднання планування та програмування нового проекту

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

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

Що я шукаю - це спосіб поєднання обох, без того, щоб один домінував над іншим. Чи варто реалізовувати проект на шляху скупості? Чи слід створювати розповіді користувачів, а потім реалізовувати їх? Чи повинен я працювати за допомогою функції? (У мене є досвід роботи з scrum та класичним способом "специфікація для коду".)

Оновлення : як щодо того, щоб почати з манекена "натискання" та реалізувати функціонал пізніше?

Ви на правильному шляху. Не потрібно витрачати місяці на планування, але ви обов'язково повинні мати якийсь план.

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

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

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

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

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

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

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

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

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

Якщо коротко підсумувати, можна сказати, "спочатку вирішуйте найважчу частину, діліться і перемагайте, за допомогою псевдокоду та / або планів TDD"!

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

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