Perpaduan yang tepat antara perencanaan dan pemrograman pada proyek baru

Saya akan memulai proyek baru (permainan, tapi itu tidak penting). Ide dasarnya ada di kepala saya tetapi tidak semua detailnya.

Saya tidak ingin memulai pemrograman tanpa perencanaan, tetapi saya benar-benar berjuang melawan keinginan saya untuk melakukannya. Saya ingin perencanaan sebelumnya untuk mencegah refactoring seluruh aplikasi hanya karena fitur baru yang bisa saya pikirkan memerlukannya. Di sisi lain, saya tidak ingin merencanakan beberapa bulan (waktu luang) dan memulainya karena saya khawatir saya akan kehilangan motivasi saat ini.

Apa yang saya cari adalah cara menggabungkan keduanya tanpa satu mendominasi yang lain. Haruskah saya mewujudkan proyek dengan cara scrum? Haruskah saya membuat cerita pengguna dan kemudian menyadarinya? Haruskah saya mengaktifkan fitur? (Saya memiliki beberapa pengalaman dalam scrum dan cara klasik "spesifikasi untuk kode".)

Pembaruan : Bagaimana memulai dengan "klik boneka" dan mengimplementasikan fungsionalitas nanti?

Anda berada di jalur yang benar. Tidak perlu menghabiskan waktu berbulan-bulan untuk merencanakan, tetapi Anda pasti harus memiliki semacam rencana.

Perencanaan akan membantu Anda mengatur pemikiran Anda, mengidentifikasi teknologi yang mungkin Anda butuhkan, memperjelas titik-titik masalah, dan memberi Anda peta jalan untuk bekerja sehingga Anda dapat memecahnya menjadi tujuan yang terukur.

Selain itu, Anda dapat melakukan perencanaan beberapa hari hanya untuk mengetahui bahwa ini adalah buang-buang waktu Anda. Mungkin ketika merencanakan, Anda menyadari bahwa Anda jauh dari liga atau bahwa apa yang Anda coba lakukan tidak dapat dipasarkan. Lebih baik untuk mengetahui hal itu sekarang sehingga Anda dapat menginvestasikan kembali waktu Anda ke ide-ide lain yang Anda miliki, daripada pergi menyusuri jalan ini hanya untuk menjadi tersesat di hutan, dikelilingi oleh tanaman merambat kode yang ketat dan jalur logika yang keliru yang memutar otak Anda menjadi simpul.

Rencanakan produk minimum yang layak , dan terapkan itu. Kemudian dengarkan pengguna Anda dan rencanakan peningkatan logis berikutnya, dan terapkan itu. Ulang.

Tidak peduli berapa banyak waktu yang Anda habiskan untuk merencanakan dan merancang program Anda, Anda selalu berakhir menulis ulang bagian itu. Ini seperti gravitasi, tidak pintar menyangkal keberadaannya.

Orang harus menyadari bahwa refactoring adalah bagian normal dari perkembangan dan itu hanya masalah memutuskan kapan Anda melakukannya. Tunggu lama dan Anda berakhir dengan spaghetti dalam jumlah besar, memohon untuk menulis ulang sepenuhnya. Tidak lucu.

Saran saya adalah merencanakan sedikit tetapi memulai coding secepatnya dan refactor, refactor, refactor untuk menjaga kode dalam bentuk. Prinsip KERING (jangan ulangi diri Anda sendiri) adalah indikator yang bagus untuk itu.

Ketika saya dalam posisi ini saya kadang-kadang memanfaatkan TDD (test driven development) dan mulai merencanakan beberapa tes untuk bagian paling kompleks dari sistem yang saya kembangkan. Atau saya dapat mengumpulkan beberapa kode pseudo tingkat tinggi, sekali lagi untuk area yang paling kompleks. Saya menemukan proses ini memberi saya rencana aksi yang longgar dan membantu saya mengidentifikasi area mana yang paling memakan waktu.

Bagi saya pendekatan ini bekerja karena ia hidup di antara pengkodean dan perencanaan. Setelah Anda memiliki ide pengujian dan / atau kode semu Anda dapat bekerja melalui setiap bagian logis dan mengimplementasikan kode. Saya sering menangani bagian tersulit dari solusi yang diusulkan terlebih dahulu, karena biasanya bagian tersulit adalah fitur inti dari aplikasi dan Anda selalu dapat menunda bel dan peluit.

Karena Anda berkomentar bahwa sebagian besar kode ada di kepala Anda dan Anda siap untuk menyelam dan memprogram, menggunakan pendekatan ini dapat membantu Anda fokus pada setiap bagian tanpa pikiran Anda menjadi kabur oleh sistem secara keseluruhan.

Untuk meringkas lebih ringkas, orang bisa mengatakan "menangani bagian tersulit pertama, membagi dan menaklukkan, dengan kode pseudo dan / atau rencana TDD"!

Coba saja buat kode modular. Apa pun yang Anda rencanakan kemungkinan akan dibuang selama iterasi berikutnya.

Saya sarankan paling tidak menuliskan ide-ide Anda. Tergantung pada ukuran proyek, banyak perencanaan formal mungkin tidak diperlukan. Namun jika itu sangat besar, Anda mungkin ingin menyelamatkan diri dari sakit kepala dan menghabiskan beberapa hari melakukan perencanaan yang lebih mendalam.