Saya programmer dengan pengalaman 1 tahun, baru-baru ini saya menyadari saya jarang memulai proyek dengan benar (sebagian besar proyek sampingan saya), biasanya siklus proyek berjalan seperti

1. Mulai dengan beberapa use case
2. Mulai coding
3. Sadarilah beberapa hal yang tidak saya tangani dengan baik, dan tidak cocok dengan basis kode saat ini.
4. Tulis ulang sebagian besar kode

dan ini mungkin beberapa kali

Jadi pertanyaan saya adalah

1. Apakah praktik seperti itu biasa, atau itu menyiratkan bahwa saya tidak kompeten?
2. Bagaimana saya dapat meningkatkan diri saya pada aspek ini?

Siklus yang Anda gambarkan adalah normal. Cara untuk memperbaiki keadaan bukanlah dengan menghindari siklus ini, tetapi merampingkannya. Langkah pertama adalah menerima bahwa:

1. Hampir mustahil untuk mengetahui segalanya pada hari pertama suatu proyek.
2. 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:

1. Mulai dengan beberapa use case
2. Mulai coding
3. Sadarilah beberapa hal yang tidak saya tangani dengan baik, dan tidak cocok dengan basis kode saat ini.
4. 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

Ini normal.

Anda dapat mengambil salah satu dari dua pendekatan:

1. Selamat Datang Change

Jika Anda berasumsi bahwa Anda akan salah, Anda harus membangun basis kode yang terbuka untuk diubah. Sebagian besar ini melibatkan mengambil kode di akhir buku tentang refactoring, dan membangun kode Anda seperti itu dari awal (dekomposisi, cakupan tes yang baik, ...).

2. Hindari Perubahan

Dalam hal ini Anda harus melakukan BDUF (desain besar di depan). Anda harus melakukan banyak prototipe kertas, mendiskusikan ide-ide dengan pengguna potensial atau diri Anda sendiri dengan mengelak, mencoba berbagai hal dalam prototipe atau maket, menuliskan spesifikasi yang lengkap, dan hanya sekali Anda merasa telah menemukan solusi maka akhirnya Anda dapat mulai coding. Melakukan semua itu tidak benar-benar menyingkirkan perubahan tak terduga, itu hanya mengurangi sedikit, tahun pertama atau lebih. Jadi, Anda masih harus membangun kode Anda agar mudah diubah.

Jadi, pada dasarnya, perubahan itu diberikan. Anggaplah itu akan terjadi. Buat kode Anda sesuai. Dalam praktiknya Anda dapat menemukan jalan tengah antara pendekatan desain-depan dan baru-coding yang menghindari perubahan serampangan tanpa terjebak dalam kelumpuhan analisis. Hanya butuh sedikit pengalaman.

Pengembangan perangkat lunak telah digambarkan sebagai serangkaian masalah "jahat" yang inheren .

Horst Rittel dan Melvin Webber mendefinisikan masalah "jahat" sebagai masalah yang hanya dapat didefinisikan secara jelas dengan memecahkannya, atau dengan memecahkan sebagiannya *. Paradoks ini menyiratkan, pada dasarnya, bahwa Anda harus "menyelesaikan" masalah sekali untuk mendefinisikannya dengan jelas dan kemudian menyelesaikannya lagi untuk menciptakan solusi yang berfungsi. Proses ini telah menjadi ibu dan pai apel dalam pengembangan perangkat lunak selama beberapa dekade

Ini dengan sempurna menggambarkan masalah yang Anda hadapi. Pada dasarnya, apa yang kita lakukan itu sulit . Jika ada bagian yang dapat digambarkan sebagai "rutin", lama kelamaan kami mengisolasi dan mengotomatiskannya. Jadi yang tersisa hanyalah yang baru atau yang sulit.

Ada cara lain untuk mengatasi masalah seperti ini; beberapa orang menghabiskan banyak waktu mempertimbangkan masalah sebelumnya dan tidak menulis kode sampai mereka merasa nyaman dengan desain. Yang lain mencari bimbingan dari orang-orang yang sudah menangani masalah seperti ini, baik melalui pemrograman berpasangan atau hanya situs-situs seperti ini.

Tetapi tentu saja pendekatan Anda tidak menyarankan ketidakmampuan. Satu-satunya masalah adalah jika, ketika Anda kembali, Anda tidak merenungkan mengapa Anda memilih untuk melakukan hal-hal seperti ini sejak awal, dan apakah Anda mungkin dapat melihat cara yang "lebih baik" tanpa menulis kembali.

Dalam banyak kasus, ada, dan Anda dapat memasukkannya ke dalam proses desain Anda untuk waktu berikutnya. Dalam beberapa kasus, tidak ada (atau biayanya akan setinggi atau lebih tinggi dari biaya pendekatan Anda yang lain), dan Anda bisa membiarkan kekhawatiran Anda pergi.

1. Ya, ini biasa, kecuali mungkin untuk bagian "tulis ulang sebagian besar kode". Anda tidak akan pernah mendapatkan semua persyaratan sejak awal, jadi penting untuk menghadapi perubahan dengan baik. Itulah konsep tentang "pemeliharaan kode". Tentu saja juga membantu menghabiskan lebih banyak waktu untuk mendapatkan persyaratan dan desain yang benar.
2. Pertama, pikirkan perubahan apa yang diperlukan dalam proyek-proyek sebelumnya dan bagaimana Anda dapat meramalkannya atau mempersiapkan diri dengan lebih baik. Di awal proyek, pikirkan lebih lanjut tentang detail kasus penggunaan. Lakukan beberapa desain abstrak (apa saja komponen utama dari kode dan bagaimana mereka berkomunikasi, apa API mereka) sebelum Anda mulai menerapkan. Yang paling penting, cobalah untuk menjaga kode sesederhana dan semudah mungkin untuk berubah, baca konsep-konsep seperti SOLID, KERING, KISS dan YAGNI.

Apakah praktik seperti itu biasa, atau itu menyiratkan bahwa saya tidak kompeten?

Itu tidak saling eksklusif. Polanya bisa umum, dan Anda mungkin masih tidak kompeten. Kompetensi Anda dapat ditentukan dengan mengukur kinerja Anda terhadap sasaran Anda. Apakah Anda memenuhi tujuan Anda?

Apakah pola ini biasa? Sayangnya ya. Banyak orang terjun ke dalam proyek tanpa ide yang jelas tentang masalah apa yang mereka selesaikan, bagaimana mereka akan merekayasa solusi yang tepat, dan metrik apa yang akan membentuk kesuksesan.

Bagaimana saya dapat meningkatkan diri saya pada aspek ini?

Jika Anda memutuskan untuk pergi ke suatu tempat dan baru saja mulai berjalan, dan kemudian menemukan satu hari di mana yang benar-benar perlu Anda lakukan adalah mengangkut seekor gajah dari Cape Town ke New York City, semua waktu yang Anda habiskan berjalan kaki sia-sia. Cari tahu apa yang Anda lakukan sebelum mulai melakukannya.

Setelah Anda mulai melakukannya, pertimbangkan: seperti apa kode yang tidak harus ditulis ulang ? Kode itu:

• Apakah satu hal yang bermanfaat.
• Apakah itu benar.
• Apakah itu dengan kinerja yang memadai.

Jadi: semakin banyak kode yang Anda tulis di mana kode itu melakukan satu hal bermanfaat dengan baik, benar, dengan kinerja yang baik, semakin sedikit kode yang harus Anda tulis ulang.

Saya pikir aman untuk mengatakan Anda tidak jauh dari cara kerja yang lebih baik, dan Anda bukan satu-satunya di kapal ini.

Apa yang saya pikir Anda lewatkan adalah bahwa, meskipun Anda menentukan apa yang Anda inginkan, Anda tidak berhenti untuk melakukan proses yang sama untuk bagaimana Anda akan melakukannya.

Langkah berhenti dan berpikir tentang cara mengatasi masalah ini secara keseluruhan disebut desain, ini adalah langkah yang membuat Anda meluangkan waktu dalam mengembangkan struktur atau arsitektur sistem sehingga semua yang Anda lakukan dari mereka berkontribusi pada solusi akhir, seperti memasangkan potongan-potongan ke dalam teka-teki gambar begitu Anda berhasil mengerjakan ujungnya.

Banyak orang tidak melakukan langkah ini, namun ketika saya mulai coding itu wajib. Saya pikir perbedaannya ada pada alat pengembangan - sedangkan saya mulai dengan editor teks, Anda sekarang memiliki semua jenis fitur yang memungkinkan Anda untuk melompat dan mengetik.

Jadi, luangkan sedikit waktu untuk mencari tahu area yang luas, komponen dan interoperabilitas di antara mereka, dan tentukan objek yang akan terdiri dari solusi Anda sebelum mulai kode. Itu tidak harus dalam detail besar, dan memahami bahwa Anda tidak akan melakukannya dengan benar di awal, jadi itu akan berkembang seiring waktu, tetapi apa yang dilakukan adalah membantu menghentikan Anda membuang-buang usaha untuk meninjau kembali hal-hal yang seharusnya tidak diperlukan. tidak perlu banyak berubah.

Anda sudah memiliki beberapa jawaban yang hebat tetapi pertanyaan Anda mengingatkan beberapa hal yang saya pikir akan saya coba sentuh.

1. Seperti yang Anda perhatikan saat menjalankan perubahan di jalan saya sarankan berpikir tentang bagaimana hal-hal berdampak proyek Anda dan bagaimana Anda bisa meminimalkan dampak dengan pilihan desain / coding sementara pada saat yang sama menghasilkan peta mental di mana orang sering membuat perubahan terlambat. Dengan pengalaman Anda dapat mengantisipasi dan memberi kode pada beberapa fleksibilitas untuk hal-hal yang Anda tahu akan menjadi penting - meskipun ada ketidaksepakatan tentang konsep ini di industri karena beberapa akan melawan upaya investasi Anda di area yang tidak secara khusus diminta, per se .

2. Di satu sisi pengujian, melemparkan prototipe untuk pemangku kepentingan proyek Anda bisa menjadi cara yang bagus untuk memperbaiki persyaratan. Namun, selama pengembangan Anda dapat mencari cara untuk "melihat" apa yang terjadi dalam kode Anda tanpa menyebabkan banyak kekacauan atau kerumitan. Tentu saja ada alat yang tersedia untuk membantu tetapi Anda juga dapat melakukan banyak hal tanpa itu jika Anda mau. Either way, keluar dari kode untuk melihat apa yang terjadi dengan mata kritis dapat memberikan berbagai jenis wawasan.

3. Cari kegiatan umum. Anda akan menemukan diri Anda menangani masalah yang sama berulang-ulang. Setelah beberapa saat, Anda akan menemukan kekurangan atau kompromi dari berbagai pilihan dan membidik metodologi yang membantu Anda menghindarinya. Tentu saja, jika Anda bekerja dalam suatu kerangka kerja, beberapa masalah ini mungkin sudah termasuk dalam alat yang sudah Anda gunakan.

4. Jika Anda bekerja dalam suatu kerangka kerja menghabiskan waktu, jika Anda dapat meluangkannya, untuk mempertimbangkan bagaimana melakukan sesuatu dari awal. Misalnya, Anda dapat dengan mudah mengumpulkan pesan permintaan, membuka soket dan mengeluarkan permintaan GET atau POST secara manual. Jika suka, Anda dapat secara manual mem-parsing pesan XML. Apa pun yang Anda lakukan, pertanyaan yang Anda hasilkan dan jawaban yang Anda temukan akan meningkatkan keterampilan Anda. Tentu saja, Anda harus memilih jenis masalah mendasar yang penting atau menarik. Saya akan mempertimbangkan pengembangan pribadi ini dan tidak berharap untuk menghabiskan banyak waktu di sini.

5. Peluru perak, metodologi dan masalah faktor buzz tinggi ada di mana-mana. Pada dasarnya, realitas yang mendasari bekerja dengan informasi tidak berubah begitu cepat. Catat apakah kerangka kerja, perangkat, atau metodologi yang ada merupakan bantuan atau hambatan dalam berbagai situasi. Di perusahaan besar, saya telah melihat banyak metodologi yang dicoba meskipun perusahaan tidak dapat melaksanakannya secara efektif. Sama seperti kerangka kerja, metodologi bukanlah cara yang gagal untuk berfungsi pada tingkat tinggi bahkan jika mereka didasarkan pada praktik beberapa tim yang sangat fungsional.

Sulit untuk memunculkan pengalaman dan membuatnya dapat diakses. Saya kira cara singkat untuk mengungkapkan semua ini adalah dengan membuka mata, memikirkan apa yang Anda lihat, dan tidak pernah berhenti belajar.

Saya ingin menambahkan beberapa petunjuk

1) Saya pribadi merasa luar biasa berguna untuk memulai dengan memvisualisasikan hal-hal. Gambar kotak, panah, garis ... Jangan pedulikan bahasa pemodelan apa pun yang Anda gunakan. Di tempat pertama Anda melakukannya UNTUK DIRI SENDIRI. Ini akan membantu aliran pemikiran Anda.

2) Temukan mitra sparring - ambil kopi dan flipchart / diagram dll dari atas dan pergi ke kota. IMHO bahkan lebih baik jika Anda tidak memiliki keterampilan teknologi yang cocok. Anda memantulkan ide untuk menerapkan usecase. Anda menemukan jalan buntu atau dua - Anda menemukan solusinya. Dengan pikiran yang gesit, sering kali lebih sedikit waktu yang dihabiskan dalam tahap ini daripada jika Anda menulis kode, itu tidak bekerja dan Anda harus membunuh potongan pekerjaan Anda atau mengulanginya

3) Temukan bos yang dapat memahami bahwa Anda kemungkinan tidak pernah melakukan peningkatan perangkat lunak tertulis. Jika Anda selalu memasukkan fitur / persyaratan baru yang dibuang di meja Anda dan tidak pernah peduli dengan perangkat lunak Anda, itu akan menyerang Anda dengan bug, perawatan yang tidak ramah, dan banyak rambut menarik beberapa tahun ke depan. Dapatkan alokasi waktu / anggaran perawatan perangkat lunak ini! Saya angka bulat yang baik adalah sekitar 20% dari waktu yang dibutuhkan untuk mengembangkan perangkat lunak yang dibutuhkan per tahun untuk menjaga bentuknya selama masa hidupnya.

4) Proses pembelajaran inkremental ini tidak pernah berhenti (dan tidak seharusnya)! Anda akan melihat kembali dalam 10 tahun dan tersenyum.

Semoga ini bisa membantu sedikit dan semoga berhasil!