Pembuatan prototipe dan refactoring cepat

Kadang-kadang ketika saya memulai proyek kecil (seperti aplikasi android), saya tidak tahu pendekatan mana yang akan berhasil pada akhirnya, dan saya hanya mencoba satu pendekatan dan mencobanya. Tetapi jika saya tidak pernah menggunakan pendekatan ini sebelumnya (untuk semacam aplikasi saya belum pernah diprogram sebelumnya) itu seperti melangkah ke medan yang tidak diketahui. Saya tidak tahu perpustakaan mana yang harus digunakan (mungkin saya harus mencoba beberapa perpustakaan) dan ada begitu banyak yang tidak layak (seperti: cara mendapatkan data audio mentah di android)

Jadi proses pengembangan saya berjalan seperti ini:

• Tuliskan kode untuk melihat apakah pendekatan tersebut memiliki peluang. (Semakin tidak pasti pendekatannya, semakin jelek kodenya)
• Jika berhasil, banyak refactor sampai itu indah

Saya pikir itu bisa membuang-buang waktu jika saya merencanakan desain perangkat lunak saya secara rinci pada saat ini, itu akan seperti merencanakan perjalanan tanpa peta.

Apakah ini bagian dari pengembangan aglie? Bagaimana Anda menghadapi medan yang tidak dikenal dalam pengembangan perangkat lunak?

Itu tidak ada hubungannya dengan gesit, tetapi orang-orang menganggap itu melakukan karena itu yang mereka pikir Agile; pengembangan ayam tanpa kepala di komune hippy.

Apa yang Anda lakukan adalah menilai teknologi karena saat ini Anda tidak memiliki cukup pengalaman untuk membuat penilaian. Ini bagus dan tidak pernah berakhir karena perpustakaan baru, kerangka kerja, bahasa dan platform muncul hampir setiap hari.

Bagaimana Anda menangani hal-hal yang tidak diketahui sebenarnya adalah pertanyaan yang sangat bagus dan akhirnya untuk meneliti alternatifnya, menilai mereka dan kemudian memilihnya.

Keterampilan yang cenderung dikaitkan dengan Agile yang membantu di sini melibatkan pembuatan kode yang mudah dan aman untuk diperbaiki. TDD adalah contoh yang bagus. Ini mendorong Anda untuk mempertimbangkan perkembangan Anda dalam hal hasil. "Kode ini harus menghasilkan hasil ini" yang memfokuskan pikiran dan mengurangi jumlah kode yang tidak berkontribusi terhadap penyelesaian tujuan.

Jika Anda menulis kode mengikuti prinsip SOLID (Akronim), Anda akan berada di posisi yang baik nanti untuk mengganti perpustakaan jika Anda membuat pilihan yang salah, atau, seperti yang sering terjadi, Anda melebihi pilihan Anda.

Ada baiknya Anda mengajukan pertanyaan semacam ini. Ada terlalu banyak pengembang yang karena berbagai alasan tidak akan mengambil risiko muncul "bodoh" dengan meluangkan waktu untuk memilih teknologi yang benar. Membuat kesalahan di awal proyek tidak terlambat. Eksperimen adalah kunci bukan pemborosan, jadi saya pikir Anda akan melakukannya dengan cara yang benar.

Apakah ini bagian dari pengembangan aglie? Bagaimana Anda menghadapi medan yang tidak dikenal dalam pengembangan perangkat lunak?

Apa yang Anda uraikan bukanlah Agile. Pengembangan Agile lebih tentang mempromosikan perencanaan adaptif, pengembangan evolusi, dan penyampaian dengan pendekatan berulang waktu. Agile memang mendorong respons yang cepat dan fleksibel terhadap perubahan. Dengan demikian, re-factoring kode Anda sebagai pengembangan berlangsung memiliki potongan metodologi Agile di dalamnya.

Berurusan dengan proyek yang tidak diketahui dimulai dengan mengumpulkan persyaratan yang diketahui, dengan desain tingkat tinggi. Setelah Anda mendapatkan sebagian besar komponen, Anda dapat mencari solusi yang tepat. Yang mengatakan, membangun bukti-konsep kecil sebelum pengembangan penuh adalah pendekatan yang diikuti oleh tim kami.

Ada prinsip pengembangan perangkat lunak yang disebut SOLID . Dalam pengalaman saya, menerapkannya pada masalah / masalah selalu merupakan langkah maju dalam meningkatkan basis kode proyek Anda.

Tergantung pada proyek, jika Anda bekerja sendiri pada proyek kecil, mungkin masuk akal untuk melakukan riset dan investigasi teknologi Anda sebagai bagian dari pengembangan. Dan meskipun bukan bagian dari Agile, tentu saja metodologi Agile dapat digunakan untuk menambahkan beberapa kontrol untuk ini. Namun ini membuat prosesnya sangat sulit untuk diprediksi / atau kotak waktu. Mungkin baik-baik saja, bahkan lebih cepat, jika bekerja sendirian di proyek kecil yang sepenuhnya milik Anda, biarkan persyaratan Anda terungkap saat Anda mempelajarinya. Gunakan prinsip yang baik di sepanjang jalan, dan konsisten dan Anda tidak perlu terlalu banyak faktor.

Di tempat kerja kami menggunakan Kanban, Scrum, dan pendekatan air terjun yang lebih tradisional. Bergantung pada proyek, saya menemukan bahwa perkembangan kompleks dengan persyaratan di muka yang terdefinisi dengan baik tidak paling cocok untuk gesit, namun banyak yang akan tidak setuju.

Sebelum kita mulai bekerja bahkan pada proyek yang gesit (semua kecuali yang paling sederhana), kami membuat beberapa dokumentasi. Kami memiliki mock up (jika ui fokus), satu set persyaratan, dan spesifikasi fungsional.

Pengembangan akan diminta untuk membuat spesifikasi teknis dari spesifikasi fungsional, dan selama proses ini kami akan menentukan teknologi dan melakukan penelitian awal yang kami butuhkan. Proses ini tampaknya sangat penting bagi saya, karena memberikan kesempatan untuk melihat kesenjangan dalam persyaratan / spesifikasi fungsional - dan memberikan keputusan teknologi besar di muka kepada orang-orang dengan pengalaman dan pengetahuan sistem untuk membuat keputusan seperti itu.

Namun yang penting, adalah bahwa spesifikasi fungsional bisa menjadi daftar poin-poin, dan spesifikasi teknologi biasanya akan menjadi model, dengan beberapa poin-poin dan teknologi mengarahkan, mungkin hanya 3 atau 4 halaman dalam beberapa kasus.

Bahkan ketika menjalankan proyek gesit kami membuat dokumentasi:

• Semua dokumentasi memiliki biaya.
• Berkembang melawan persyaratan tingkat tinggi yang bergerak dan tidak jelas memiliki biaya.
• Keseimbangan yang tepat untuk hal di atas tergantung pada proyek Anda, budaya, dan orang-orang.
• Kami mendokumentasikan Tepat pada waktunya, dokumen keluar dari tanggal.
• Kami mendokumentasikan cukup / cukup.
• Kami tidak memelihara atau memperbarui dokumen-dokumen ini, kami tidak berupaya keras untuk mendapatkannya. Mereka kecil. Kami berharap akan membuangnya.
• Kami mengatasi hal-hal besar yang tidak diketahui seperti keputusan teknologi, persyaratan kabur, dan arsitektur di muka.
• Kami tahu apa yang kami kembangkan sebelum kami mulai.
• Kami memercayai pengembang untuk membuat keputusan berdasarkan dokumentasi dan mendiskusikan masalah apa pun.
• Kami menghargai komunikasi daripada dokumentasi, karena itu kami berharap semua yang terlibat sering berkomunikasi.
• Kami mendokumentasikan sistem (ikhtisar) setelah pengembangan, bukan selama, bukan sebelumnya.

Anda lihat ada air terjun kecil dalam proses tangkas kami.

Jika Anda bekerja sendiri, buat model dimuka (diagram!) Dan mainkan dan pilih teknologi, dan kemudian ketika Anda memiliki konsep persyaratan tingkat tinggi ini, maju terus dan kembangkan dengan cara berulang yang gesit, tetapi pertimbangkan prinsip-prinsip yang baik dan konsistensi saat Anda pergi dan Anda akan perlu faktor ulang lebih sedikit, lebih banyak faktor ulang saat Anda pergi.

Tetapi secara umum, jika ada biaya nyata yang terlibat (bukan hobi) tahu apa yang Anda kembangkan sebelum Anda menulis kode, tetapi jangan buang terlalu banyak waktu menulis dokumentasi yang akan menjadi berlebihan cepat karena Anda akan berubah pikiran, dan harus mengubah pikiran Anda selama pengembangan saat Anda menjadi lebih baik. Dan proyek Anda bisa berubah arah, tetapi mulai dari fondasi yang bagus dan terdefinisi dengan baik.

Ini kira-kira bagaimana saya memulai proyek baru dan berhasil dengan baik, dengan asumsi kita berbicara tentang proyek kecil. Misalnya, saya tidak akan menempuh rute ini jika saya sedang menulis ORM atau sesuatu sebesar itu. Kadang-kadang saya akan melakukan penelitian yang lebih formal ketika saya benar-benar di atas kepala saya. Tetapi sebagian besar saya hanya mulai menulis kode dan melihat apa yang terjadi. Anda harus siap membuang banyak kode saat melakukan ini.