Siklus yang Anda gambarkan adalah normal. Cara untuk memperbaiki keadaan bukanlah dengan menghindari siklus ini, tetapi merampingkannya. Langkah pertama adalah menerima bahwa:
- Hampir mustahil untuk mengetahui segalanya pada hari pertama suatu proyek.
- Bahkan jika Anda entah bagaimana tahu segalanya, pada saat Anda menyelesaikan proyek maka sesuatu (persyaratan klien, pasar tempat mereka berada, teknologi tempat Anda bekerja, keinginan pelanggan mereka) akan berubah dan dibuat di Setidaknya sebagian dari apa yang Anda tahu tidak benar atau salah.
Karena itu, tidak mungkin untuk merencanakan semuanya di muka, dan bahkan jika Anda bisa, mengikuti rencana itu akan membuat Anda membangun sesuatu yang tidak sempurna atau usang. Mengetahui hal ini, kami mengintegrasikan perubahan ke dalam perencanaan kami. Mari kita lihat langkah-langkah Anda:
- Mulai dengan beberapa use case
- Mulai coding
- Sadarilah beberapa hal yang tidak saya tangani dengan baik, dan tidak cocok dengan basis kode saat ini.
- Tulis ulang sebagian besar kode
Itu sebenarnya titik awal yang bagus. Inilah cara saya mendekatinya:
1. Mulai dengan beberapa use case
Baik. Dengan mengatakan "kasus penggunaan", Anda berfokus pada apa perangkat lunak ini untuk . Dengan mengatakan "beberapa", Anda tidak berusaha menemukan segalanya; Anda berpegang teguh pada jumlah pekerjaan yang bisa diatur. Yang saya tambahkan di sini adalah memprioritaskan mereka. Dengan klien atau pengguna akhir Anda, cari jawaban untuk pertanyaan ini:
Apa yang paling kecil, perangkat lunak paling sederhana yang bisa saya berikan kepada Anda yang akan memperbaiki situasi Anda?
Ini adalah produk minimum yang layak - apa pun yang lebih kecil dari ini tidak membantu pengguna Anda, tetapi risiko apa pun yang lebih besar terlalu banyak perencanaan terlalu dini. Dapatkan informasi yang cukup untuk membangun ini, lalu lanjutkan. Berhati-hatilah bahwa Anda tidak akan tahu segalanya pada saat ini.
2. Mulai coding.
Bagus. Anda mulai bekerja sesegera mungkin. Sampai Anda menulis kode, klien Anda telah menerima manfaat nol. Semakin banyak waktu yang Anda habiskan untuk merencanakan, semakin lama klien menghabiskan waktu menunggu tanpa pengembalian.
Di sini, saya akan menambahkan pengingat untuk menulis kode yang baik . Ingat dan ikuti Prinsip SOLID , tulis tes unit yang layak di sekitar segala hal yang rapuh atau kompleks, buat catatan tentang apa pun yang Anda mungkin lupa atau yang mungkin menyebabkan masalah nanti. Anda ingin menyusun kode Anda sehingga perubahan tidak akan menimbulkan masalah. Untuk melakukan hal ini, setiap kali Anda membuat keputusan untuk membangun sesuatu ini cara bukan yang cara, Anda menyusun kode Anda sehingga sedikit kode mungkin dipengaruhi oleh keputusan itu. Secara umum, cara yang baik untuk melakukan ini adalah dengan memisahkan kode Anda:
- menggunakan komponen yang sederhana dan terpisah (tergantung pada bahasa dan situasi Anda, komponen ini bisa berupa fungsi, kelas, perakitan, modul, layanan, dll. Anda mungkin juga memiliki komponen besar yang dibangun dari komponen yang lebih kecil, seperti kelas dengan banyak fungsi, atau perakitan dengan banyak kelas.)
- setiap komponen melakukan satu pekerjaan, atau pekerjaan yang berkaitan dengan satu hal
- perubahan cara satu komponen melakukan pekerjaan internalnya seharusnya tidak menyebabkan komponen lain harus berubah
- komponen harus diberikan hal-hal yang mereka gunakan atau tergantung pada, daripada mengambil atau membuat mereka
- komponen harus memberikan informasi ke komponen lain dan meminta mereka untuk melakukan pekerjaan, daripada mengambil informasi dan melakukan pekerjaan itu sendiri
- komponen tidak boleh mengakses, menggunakan, atau bergantung pada cara kerja komponen lainnya - hanya menggunakan fungsi yang dapat diakses publik
Dengan melakukan ini, Anda mengisolasi efek perubahan sehingga dalam kebanyakan kasus, Anda dapat memperbaiki masalah di satu tempat, dan sisa kode Anda tidak menyadarinya.
3. Menghadapi masalah atau kekurangan dalam desain.
Ini akan terjadi. Itu tidak bisa dihindari. Terima ini. Ketika Anda menekan salah satu dari masalah ini, putuskan jenis masalah apa itu.
Beberapa masalah adalah masalah dalam kode atau desain Anda yang membuatnya sulit untuk melakukan apa yang seharusnya dilakukan perangkat lunak. Untuk masalah ini, Anda harus kembali dan mengubah desain Anda untuk memperbaiki masalah.
Beberapa masalah disebabkan oleh tidak memiliki informasi yang cukup, atau dengan memiliki sesuatu yang tidak Anda pikirkan sebelumnya. Untuk masalah ini, Anda harus kembali ke pengguna atau klien Anda, dan tanyakan kepada mereka bagaimana mereka ingin mengatasi masalah tersebut. Ketika Anda memiliki jawabannya, Anda kemudian pergi dan memperbarui desain Anda untuk menanganinya.
Dalam kedua kasus, Anda harus memperhatikan bagian mana dari kode Anda yang harus diubah, dan saat Anda menulis lebih banyak kode, Anda harus memikirkan bagian mana yang mungkin harus berubah di masa depan. Ini membuatnya lebih mudah untuk mencari tahu bagian mana yang mungkin terlalu saling terkait, dan bagian mana yang perlu lebih terisolasi.
4. Tulis ulang bagian dari kode
Setelah Anda mengidentifikasi bagaimana Anda perlu mengubah kode, Anda dapat pergi dan melakukan perubahan. Jika Anda telah menyusun kode dengan baik, maka ini biasanya melibatkan hanya mengubah satu komponen, tetapi dalam beberapa kasus mungkin melibatkan penambahan beberapa komponen juga. Jika Anda merasa harus mengubah banyak hal di banyak tempat, maka pikirkan mengapa itu terjadi. Bisakah Anda menambahkan komponen yang menyimpan semua kode ini di dalam dirinya sendiri, dan kemudian memiliki semua tempat ini hanya menggunakan komponen itu? Jika Anda bisa, lakukan itu, dan lain kali Anda harus mengubah fitur ini Anda akan dapat melakukannya di satu tempat.
5. Tes
Penyebab umum masalah dalam perangkat lunak adalah tidak mengetahui persyaratan dengan cukup baik. Ini seringkali bukan kesalahan pengembang - seringkali, pengguna juga tidak yakin apa yang mereka butuhkan. Cara termudah untuk menyelesaikan ini adalah membalikkan pertanyaan. Alih-alih bertanya "apa yang Anda butuhkan untuk dilakukan perangkat lunak?", Setiap kali Anda melewati langkah-langkah ini, berikan kepada pengguna apa yang telah Anda buat sejauh ini dan tanyakan kepada mereka "Saya membuat ini - apakah ia melakukan apa yang Anda butuhkan?". Jika mereka mengatakan ya, maka Anda telah membangun sesuatu yang memecahkan masalah mereka, dan Anda dapat berhenti bekerja! Jika mereka mengatakan tidak, maka mereka akan dapat memberi tahu Anda dengan istilah yang lebih spesifik apa yang salah dengan perangkat lunak Anda, dan Anda bisa meningkatkan hal spesifik itu dan kembali untuk umpan balik yang lebih banyak.
6. Belajar
Saat Anda menjalani siklus ini, perhatikan masalah yang Anda temukan dan perubahan yang Anda buat. Apakah ada polanya? Bisakah kamu meningkatkan?
Beberapa contoh:
- Jika Anda terus mendapati Anda mengabaikan sudut pandang pengguna tertentu, dapatkah Anda membuat pengguna itu lebih terlibat dalam fase desain?
- Jika Anda tetap harus mengubah hal-hal agar kompatibel dengan teknologi, dapatkah Anda membuat sesuatu untuk antarmuka antara kode Anda dan teknologi itu sehingga Anda hanya perlu mengubah antarmuka?
- Jika pengguna terus berubah pikiran tentang kata-kata, warna, gambar atau hal-hal lain di UI, dapatkah Anda membuat komponen yang menyediakan aplikasi lainnya sehingga semuanya berada di satu tempat?
- Jika Anda menemukan bahwa banyak perubahan Anda berada di komponen yang sama, apakah Anda yakin komponen itu hanya berpegang pada satu pekerjaan? Bisakah Anda membaginya menjadi beberapa bagian yang lebih kecil? Bisakah Anda mengubah komponen ini tanpa harus menyentuh yang lain?
Menjadi gesit
Apa yang Anda tuju adalah gaya bekerja yang dikenal sebagai Agile. Agile bukanlah metodologi, ini adalah kumpulan metodologi yang menggabungkan banyak hal (Scrum, XP, Kanban, untuk beberapa nama), tetapi kesamaan yang dimiliki semuanya adalah gagasan bahwa segala sesuatu berubah, dan sebagai pengembang perangkat lunak kami harus merencanakan untuk beradaptasi dengan perubahan daripada menghindari atau mengabaikannya. Beberapa prinsip intinya - khususnya, yang relevan dengan situasi Anda - adalah sebagai berikut:
- Jangan merencanakan lebih jauh ke depan daripada yang dapat Anda prediksi dengan percaya diri
- Buat kelonggaran untuk hal-hal yang berubah saat Anda pergi
- Daripada membangun sesuatu yang besar dalam sekali jalan, membangun sesuatu yang kecil dan kemudian memperbaikinya secara bertahap
- Tetap melibatkan pengguna akhir dalam proses, dan dapatkan umpan balik yang cepat dan teratur
- Periksa pekerjaan dan kemajuan Anda sendiri, dan belajarlah dari kesalahan Anda