Rekonsiliasi saran pemrograman yang kontradiktif: dapatkan sesuatu berfungsi dan beralih vs benar-benar memikirkannya sebelum coding

Saya seorang programmer menengah dengan beberapa tahun pengalaman profesional yang setengah jalan melalui gelar master. Dalam belajar memprogram saya sering mendengar dua nasihat yang tampaknya saling bertentangan.

Nasihat pertama adalah membuat sesuatu bekerja dengan cepat, lihat cara kerjanya (baik melalui prototyping atau pengujian informal), perbaiki versi, lihat cara kerjanya lagi, perbaiki lagi ... dan kemudian ulangi siklus sampai selesai . Ini kadang-kadang disebut "pengembangan spiral" atau diucapkan sebagai "rilis awal, rilis sering."

Saran kedua adalah: benar-benar memikirkan sebuah proyek sebelum pernah menulis kode apa pun.

Saya sudah sukses dengan kedua metode dan saya akan mengatakan bahwa saya setuju dengan masing-masing filosofi.

Tapi sekarang saya mulai menangani proyek yang jauh lebih kompleks yang saya tidak tahu cara menyelesaikannya (seperti aplikasi terdistribusi dan pemrograman grafis berbasis kinerja).

Bagaimana cara saya mengerjakan proyek ini?

Apakah saya baru memulai pengkodean SESUATU dan belajar (platform / metode / bahasa / arsitektur) ketika saya pergi - atau apakah saya menunda dari pengkodean dan melakukan banyak penelitian / membaca sebelum saya bahkan membuka IDE?

Bagaimana saya merekonsiliasi saran saran pemrograman yang kontradiktif ini?

Saya tidak yakin bahwa memikirkan masalah lebih dulu vs pendekatan berulang bertentangan satu sama lain. Sama seperti banyak hal lainnya, saya pikir Anda harus berusaha untuk mencapai keseimbangan di antara keduanya. Bagaimana Anda menemukan keseimbangan? Itu adalah sesuatu yang Anda pelajari dengan pengalaman dan sering kali pelajaran terbaik (yaitu hal-hal yang memberi Anda pengalaman) adalah ketika Anda tidak melakukannya dengan benar (atau bahkan pelajaran yang lebih baik: langsung saja salah). Seperti yang sudah Anda tunjukkan, ada pepatah "rilis cepat, sering rilis". Ada lagi yang serupa, "gagal awal, gagal cepat, sering gagal"

Berpikir ke depan itu hebat dan Anda harus benar-benar melakukannya. Tetapi dengan pengalaman, pelajari kapan harus berhenti berpikir dan hanya membangun sesuatu bahkan jika Anda tidak memiliki semua data. Dengan membangunnya, Anda akan dapat memperoleh lebih banyak wawasan tentang domain masalah dan berpotensi menghasilkan solusi yang jauh lebih baik. Jadi saya sarankan untuk tidak mengecualikan satu dari yang lain tetapi membuat "kepala berpikir" bagian dari iterasi Anda dan seiring waktu saya pikir Anda akan menemukan jawaban yang tepat untuk pertanyaan ini sendiri.

Hanya sedikit contoh. Suatu hari saya berjuang dengan keputusan desain perangkat lunak. Kalau dipikir-pikir itu relatif sepele tapi saya punya dua alternatif dan sepertinya keduanya akan bekerja. Saya terus berputar kembali ke pro / kontra dari masing-masing dan kemudian berputar kembali dan mempertimbangkan kembali keputusan saya. Menengok ke belakang, agak memalukan berapa banyak waktu yang saya habiskan untuk berpikir. Lalu aku berkata pada diriku sendiri, f # @ k itu! Dan alih-alih menggunakan salah satu dari desain, saya hanya melanjutkan dan meretas beberapa kode bersama, sama sekali mengabaikan semua hal baik yang Anda pelajari tentang desain yang baik. Saya mendapatkan fitur ini bekerja dalam waktu sekitar 45 menit. Kemudian saya kembali, melihat kode saya dan refactored menjadi sesuatu yang solid dan sesuatu yang saya tidak akan merasa malu memeriksa kontrol sumber. Bagian yang lucu adalah bahwa setelah peretasan berhasil, untuk menghasilkan "

Hal lain yang saya rekomendasikan khusus untuk masalah yang Anda hadapi sekarang (yaitu tugas besar dan kompleks yang menjulang ke depan). Alih-alih melakukan hal-hal secara serial, lakukan secara paralel. Pecah hari Anda menjadi potongan-potongan di mana Anda melakukan penelitian dan kemudian berhenti, pindah persneling dan kode untuk sementara waktu, setidaknya pada bagian-bagian proyek yang tidak lengkap tidak diketahui. Dengan cara ini tetap dekat dengan kode akan memberi Anda perspektif yang lebih baik dan Anda tidak akan kehabisan tenaga dengan berusaha menyerap terlalu banyak informasi terlalu cepat. Bagi saya setidaknya, setelah beberapa jam penelitian, ada baiknya membiarkan otak mencerna barang, berganti tugas dan melakukan sesuatu yang lain untuk sementara waktu. Kemudian kembalilah ke penelitian lebih lanjut.

Ada keputusan tertentu yang perlu dibuat sebelumnya.

Apakah Anda membuat aplikasi web? Maka Anda perlu tahu seperti apa arsitektur secara keseluruhan. Arsitektur seperti MVC sudah menentukan seperti apa fungsi fungsional besar Anda (seperti perutean, pengontrol, model, lapisan layanan, protokol komunikasi, dan sebagainya); menciptakan semua itu dari nol akan menjadi jangka panjang, tidak perlu, dan mungkin lebih rendah dari yang sudah ditemukan.

Apakah Anda menulis segala jenis aplikasi yang melibatkan koleksi benda atau data? Maka Anda perlu tahu tentang jenis struktur data apa yang paling sesuai untuk skenario khusus Anda, dan apa karakteristik kinerjanya. Apakah Anda memerlukan waktu pencarian cepat? Bagaimana dengan set data yang dipesan? Akankah koleksi dalam memori dilakukan, atau apakah Anda memerlukan sesuatu yang lebih kuat dari industri seperti database? Anda tidak bisa hanya mulai coding tanpa memikirkan keputusan ini, karena jika Anda membuat pilihan yang salah, Anda harus memulai dari awal.

Yang mengatakan, begitu keputusan teknologi dibuat, Anda memiliki kebebasan dalam kerangka yang telah Anda buat. Tujuannya kemudian adalah untuk tetap fleksibel, berulang-ulang dan (berani saya katakan) cukup gesit sehingga ketika pelanggan berubah pikiran tentang apa yang mereka inginkan, Anda dapat mengakomodasi mereka dengan jumlah rewel yang minimum.

Bagaimana kamu melakukannya? Pengalaman, kebanyakan. Seperti yang pernah dikatakan seseorang, pengalaman adalah apa yang Anda dapatkan setelah Anda membutuhkannya. Tetapi jika Anda mengikuti keputusan desain yang berhasil dari orang lain (seperti yang terkandung dalam platform, perpustakaan dan alat perdagangan lainnya), Anda dapat belajar dari mereka dan mengurangi risiko Anda.

Saya tidak melihat keduanya sebagai saling eksklusif.

Seperti segala jenis manajemen proyek, Anda membutuhkan visi jangka panjang dan tujuan jangka pendek.

Tanpa yang pertama Anda akan berakhir membuang-buang waktu misalnya pada fitur yang bahkan mungkin tidak pernah digunakan dan tanpa yang terakhir Anda akan menghabiskan sepanjang hari mempertimbangkan bagaimana membuat aplikasi yang sempurna tanpa menyelesaikan proyek Anda.

Seberapa sering Anda melepaskan / etc. tergantung pada metodologi spesifik yang Anda gunakan.

Apa yang harus Anda teliti tergantung pada apa yang Anda ketahui versus apa yang tidak Anda sukai.

"Iterasi" dan "memikirkannya" tidak bertentangan, melainkan saling melengkapi.

Bahkan pada ekstrem mereka, mereka mencerminkan dua jalan untuk sampai ke tempat yang sama.

• Ekstrim dari Iteration adalah seribu monyet memukul-mukul seribu keyboard. Dengan waktu yang cukup mungkin Anda akan mendapatkan sesuatu yang memenuhi persyaratan.
• Ekstrem dari "think it through" adalah pendekatan Waterfall. Jika Anda beruntung persyaratan belum berubah secara dramatis sejak awal proyek pada saat Anda mengirimkan kode. Atau Anda akan berakhir dengan kelumpuhan analisis dan tidak menghasilkan apa-apa.

Anda harus memiliki pemahaman tentang domain dan masalahnya sebelum Anda mulai coding. Ini adalah bagian "memikirkannya". Idealnya, Anda akan melihat jalur tingkat tinggi dari awal hingga akhir tentang cara mengatasi masalah.

Tetapi Anda mungkin hanya melihat sebagian besar dari jalan itu, dan tentu saja tidak setiap berhenti di sepanjang jalan. Di situlah iterasi berperan. Anda dapat mulai mengulangi melalui versi aplikasi dan mencari umpan balik untuk:

• Identifikasi hambatan yang muncul di tingkat detail yang lebih rendah
• Lihat umpan balik dari para pemangku kepentingan untuk memperjelas daerah-daerah keruh di jalur tingkat tinggi.

The akar latin dari memutuskan sarana untuk "memotong". Iterasi memungkinkan Anda untuk memutuskan apa yang berhasil dalam praktik, bukan hanya teori dan iterasi memungkinkan Anda untuk memotong opsi lain yang tidak layak.

Jadi, Anda harus memikirkan masalahnya untuk memahami apa yang akan Anda lakukan. Tetapi kemudian Anda perlu mengulangi versi aplikasi untuk benar-benar mengubah ide menjadi kode aktual.

Aturan dasar saya: jika Anda tidak sepenuhnya memahami bagian masalah apa pun, Anda perlu mundur dan memikirkannya secara menyeluruh (saya menyertakan prototyping dan kode yang dibuang untuk memahami API, dll. Sebagai bagian dari "memikirkannya") . Jika pada dasarnya kumpulan masalah yang telah Anda pecahkan sebelumnya dan Anda hanya perlu mencari cara terbaik untuk menyatukan semuanya dalam contoh khusus ini, maka lakukan iterate.

Jujur saja, itu bukan aturan yang keras dan cepat. Saya benar-benar berpikir Anda perlu melakukan campuran keduanya untuk setiap proyek yang diberikan. Berapa banyak dari masing-masing yang Anda lakukan mungkin akan sangat tergantung pada seberapa dekat proyek itu dengan yang sudah Anda selesaikan di masa lalu.