Kapten Obvious to the Rescue!
Saya akan menjadi Kapten Obvious di sini dan mengatakan bahwa ada jalan tengah yang dapat ditemukan.
Anda memang ingin membangun untuk masa depan dan menghindari mengunci diri Anda ke dalam pilihan teknologi atau desain yang buruk. Tetapi Anda tidak ingin menghabiskan 3 bulan merancang sesuatu yang seharusnya sederhana, atau menambahkan titik ekstensi untuk aplikasi cepat dan kotor yang akan memiliki masa pakai 2 tahun dan tidak mungkin memiliki proyek tindak lanjut.
Sulit untuk menemukan perbedaannya, karena Anda tidak selalu dapat memprediksi kesuksesan produk Anda dan jika Anda perlu memperpanjangnya nanti.
Bangun untuk Sekarang jika ...
- proyek ini akan dibatalkan
- proyek ini memiliki masa hidup yang singkat
- proyek tidak boleh memiliki ekstensi
- proyek tidak memiliki nilai dampak risiko (sebagian besar dalam hal gambar)
Secara umum, proyek in-house atau sesuatu yang dibangun untuk pelanggan harus dikembangkan untuk saat ini. Pastikan untuk memiliki persyaratan langsung, dan hubungkan dengan mereka sesuai kebutuhan untuk mengetahui apa yang dibutuhkan dan apa yang tidak. Tidak ingin menghabiskan terlalu banyak waktu untuk hal-hal yang "menyenangkan untuk dimiliki." Tapi jangan kode seperti babi juga.
Tinggalkan Masalah Umum untuk nanti, jika mungkin perlu dan sepadan dengan usaha:
Bangun untuk Masa Depan jika ...
- proyek akan menjadi publik
- proyek adalah komponen yang akan digunakan kembali
- proyek ini adalah batu loncatan untuk proyek lain
- proyek akan memiliki proyek tindak lanjut atau rilis layanan dengan perangkat tambahan
Jika Anda membangun sesuatu untuk umum, atau itu akan digunakan kembali dalam proyek lain, maka Anda memiliki probabilitas yang jauh lebih tinggi bahwa desain yang buruk akan kembali menghantui Anda, jadi Anda harus lebih memperhatikan hal itu. Tapi itu tidak selalu dijamin.
Pedoman
Saya akan mengatakan mematuhi prinsip-prinsip berikut ini sebaik mungkin, dan Anda harus menempatkan diri Anda dalam posisi merancang produk yang efisien dan mudah beradaptasi:
- tahu bahwa YAGNI ,
- KISS ,
- setiap kali Anda ingin menggaruk gatal dan memikirkan tambahan, tulislah. Lihatlah kembali persyaratan proyek Anda dan tanyakan pada diri Anda apakah penambahan itu prioritas atau tidak. Tanyakan apakah mereka menambah nilai bisnis utama atau tidak.
Saya tahu bahwa saya pribadi cenderung terlalu banyak berpikir dan overengineer. Sangat membantu untuk menuliskan ide dan sangat sering berpikir ulang jika saya membutuhkan fitur tambahan. Seringkali, jawabannya adalah tidak, atau, "nanti akan keren." Gagasan terakhir itu berbahaya, karena mereka tetap berada di belakang kepalaku, dan aku harus memaksakan diriku untuk tidak merencanakannya.
Cara terbaik untuk kode tanpa rekayasa ulang dan tanpa memblokir diri sendiri untuk nanti adalah fokus pada desain minimal yang baik. Memecahkan berbagai hal baik sebagai komponen yang nanti dapat memperpanjang, tetapi tanpa berpikir sudah tentang bagaimana mereka dapat diperpanjang kemudian. Anda tidak dapat memprediksi masa depan.
Buat saja hal-hal sederhana.
Dilemmata
Overengineering
Apakah ini tren yang biasanya diikuti oleh pemrogram saat melakukan proyek seperti ini?
Sial ya. Ini adalah dilema yang diketahui, dan itu hanya menunjukkan bahwa Anda peduli dengan produk tersebut. Jika tidak, itu lebih mengkhawatirkan. Ada ketidaksepakatan tentang apakah kurang selalu benar-benar lebih dan jika lebih buruk selalu benar-benar lebih baik . Anda mungkin tipe pria MIT atau New Jersey . Tidak ada jawaban yang mudah di sini.
Prototyping / Quick-n-Dirty / Less is More
Apakah ini merupakan tren yang khas hanya untuk memberikan contoh yang bisa diterapkan sesegera mungkin?
Ini adalah praktik yang lazim, tetapi bukan bagaimana sebagian besar proyek didekati. Meski demikian, prototyping adalah tren yang bagus menurut saya, tetapi satu dengan downside berarti. Dapat tergoda untuk mempromosikan prototipe cepat dan kotor ke produk aktual, atau menggunakannya sebagai dasar untuk produk aktual di bawah tekanan manajemen atau kendala waktu. Saat itulah prototipe dapat kembali menghantui Anda.
Ada keuntungan yang jelas untuk membuat prototipe , tetapi juga banyak potensi untuk penyalahgunaan dan penyalahgunaan (banyak kebalikan dari keuntungan yang sebelumnya tercantum sebagai hasil).
Kapan Menggunakan Prototyping?
Ada petunjuk tentang jenis proyek terbaik untuk menggunakan prototyping :
[...] prototyping paling bermanfaat dalam sistem yang akan memiliki banyak interaksi dengan pengguna.
[...] prototyping sangat efektif dalam analisis dan desain sistem on-line, terutama untuk pemrosesan transaksi, di mana penggunaan dialog layar jauh lebih banyak bukti. Semakin besar interaksi antara komputer dan pengguna, semakin besar manfaatnya [...]
"Salah satu penggunaan prototyping cepat yang paling produktif hingga saat ini adalah sebagai alat untuk rekayasa kebutuhan pengguna yang berulang dan desain antarmuka manusia-komputer."
Di samping itu:
Sistem dengan sedikit interaksi pengguna, seperti pemrosesan batch atau sistem yang sebagian besar melakukan perhitungan, hanya mendapat sedikit manfaat dari pembuatan prototipe. Terkadang, pengkodean yang diperlukan untuk menjalankan fungsi sistem mungkin terlalu intensif dan potensi keuntungan yang dapat diberikan prototipe terlalu kecil.
Dan jika Anda memiliki monster hijau, pastikan untuk menyimpan prototipe sesuai anggaran ...