Apakah normal untuk memikirkan masalah desain selama berhari-hari tanpa kode yang ditulis? [Tutup]

Kadang-kadang saya menatap kosong ke ruang angkasa atau membuat sketsa ide dan menulis beberapa kode palsu di atas kertas. Lalu saya menggaruknya dan mulai lagi, kemudian ketika saya pikir saya punya solusi yang tepat untuk masalah saya mulai menulis kode.

Apakah normal berpikir selama berhari-hari tanpa menulis kode apa pun? Apakah ini pertanda bahwa saya mendekati masalah sepenuhnya salah? Itu membuat saya gugup untuk tidak mendapatkan kode nyata yang ditulis dalam IDE saya.

Bergantung pada masalah yang Anda coba selesaikan, fase desain bisa memakan waktu berminggu - minggu dan berbulan-bulan (jika tidak bertahun-tahun), bukan hanya berhari-hari.

Dibutuhkan pengalaman untuk tidak mulai menghancurkan kode dengan segera. Memikirkan arsitektur dan desain tingkat tinggi harus memakan waktu berhari-hari jika tidak lebih lama - pasti sesuatu yang harus terjadi sebelum Anda mulai menulis kode Anda.

Ini biasanya disebut sebagai "Analisis Kelumpuhan"

Itu biasa tapi salah. Pada titik tertentu Anda perlu menguji berbagai ide untuk melihat apa yang paling cocok untuk Anda, kemudian secara bertahap memperbaikinya.

Dianjurkan membaca programmer Pragmatis Khusus Bab 2 bagian tentang "Tracer Bullets"

Ini sangat umum. Namun jika Anda mengambil pendekatan "Tes pertama" atau TDD, itu kurang umum dan mungkin membantu Anda merumuskan ide-ide Anda lebih baik.

Kebiasaan biasanya merupakan hasil dari pendekatan coba-coba untuk berbagai hal dan melanjutkan apa yang memberi kita hasil yang diinginkan dan menghindari yang tidak. Melakukan apa yang kita sukai dan menghindari apa yang tidak kita sukai juga ikut berperan. Itu bekerja sampai batas tertentu karena pada akhirnya, kita akan melakukan sesuatu yang tidak kita sukai untuk mendapatkan bayaran.

Itu tergantung apa yang mengarahkan Anda ke ini dan alasan Anda. Berikut ini beberapa di antaranya:

• Terlalu sering, Anda harus mengubah kode karena perubahan desain
• Anda tidak mengubah desain yang buruk karena solusi yang lebih rendah sudah dikodekan
• Anda lebih suka menggambar dan mendesain daripada menulis penundaan kode
• harus khawatir tentang sintaks dan detail pengkodean, mengalihkan perhatian Anda dari memikirkan desain yang lebih baik.

Mudah-mudahan, Anda telah menemukan bahwa jika Anda mendesain lebih lama, kode Anda lebih baik. Jika Anda dapat melihat ke belakang dan melihat bahwa tidak masalah berapa lama Anda menghabiskan waktu untuk desain, Anda mungkin ingin mengubahnya. Pertimbangan lain adalah seberapa sering Anda menemukan masalah setelah Anda menulis kode dibandingkan dengan bekerja dengan desain Anda. Jika Anda tidak menemukan masalah sampai setelah Anda menulis beberapa kode, Anda harus mempertimbangkan keseimbangan dan mulai mengkode sesuatu lebih cepat daripada nanti. Mungkin pendekatan ini dapat diterapkan pada penggunaan teknologi yang lebih baru atau fitur yang sangat kompleks.

Saya tidak tahu apakah saya memiliki disiplin untuk tetap dengan satu pendekatan atau yang lain bahkan ketika saya menemukan satu bekerja lebih baik daripada yang lain. Terkadang saya merasa perlu untuk pergi ke papan tulis; yang lainnya keyboard.

Ini sangat umum dan saya merasa ini cara yang lebih baik untuk menangani dan memahami banyak hal. Saat mengerjakan sebuah proyek, saya sering macet dan butuh satu atau dua hari untuk memahami bagaimana saya bisa mendekatinya dengan lebih baik. Bahkan setelah masalah selesai, saya menunggu satu hari berlalu. Ini membuat saya lebih segar dan siap.

Ini adalah fenomena alam dan bagus bagi pengembang untuk mencegat waktu dan pikirannya.

Ketika saya mengambil kursus dalam manajemen proyek, salah satu hal yang instruktur terkait dengan kami tentang perencanaan, yang melekat di kepala saya, adalah bahwa aturan praktis yang mereka ajarkan di militer adalah untuk mencari 1/3 dari waktu untuk perencanaan . Jadi, jika Anda memiliki operasi yang mengharuskan Anda untuk menyelesaikan 3 bulan dari sekarang, mencari menghabiskan satu bulan untuk perencanaan sebelum Anda memulai eksekusi.

Dalam pandangan saya, ada tiga pendekatan, masing-masing cocok untuk situasi pengkodean tertentu

1. Saya telah melihat masalah yang sama sebelumnya, jadi saya punya ide yang bagus tentang pola yang harus diterapkan, dan sudah jelas bagaimana solusi harus berperilaku dan merespons.

   => Gunakan BDD / TDD mulai dari solusi yang diinginkan dan bekerja ke kode. (Ok, kadang-kadang saya curang dan menulis sedikit kode dan kemudian tes - semacam 2. bersarang -. 1. pendekatan).

2. Saya punya ide bagus tentang pola untuk diterapkan, tetapi saya tidak yakin seperti apa solusinya.

   => Prototipe untuk melihat hal-hal menarik apa yang muncul. Pindah ke 1. saat saya mencari tahu hal-hal menarik yang diinginkan.

3. Saya tidak yakin pola apa yang diterapkan.

   => Pikirkan masalah itu dan bagaimana berbagai cara mendekati masalah memengaruhi kode. Pindah ke 2) atau 1) tergantung pada hasil latihan itu.

Dengan kata lain, jawabannya adalah favorit insinyur: Itu tergantung.

Lebih baik menghabiskan satu bulan berpikir dan merancang daripada menyiapkan prototipe cepat berdasarkan desain di bawah standar yang kemudian harus Anda kalahkan. Terutama jika Anda berada di tim; ketika orang lain mulai bergantung pada kode Anda, akan lebih sulit untuk menerapkan desain yang lebih baik dengan API yang berbeda.

Saya setuju dengan jawaban lain bahwa, pada prinsipnya, meluangkan waktu untuk memikirkan masalah / solusi adalah ide yang bagus. Namun, jika Anda merasa terjebak, saya punya beberapa rekomendasi untuk cara membuat proses perencanaan sedikit lebih koheren:

• Buat artefak desain. Jadi bagaimana jika Anda tidak menulis kode? Mungkin Anda hanya menulis jurnal pemikiran Anda. Atau sketsa solusi umum. Atau bahkan hanya ringkasan yang sangat bagus dari masalah yang Anda saring dari waktu ke waktu. Saat Anda mempertimbangkan ide dan menerima / menolaknya, simpan log alasan Anda pada subjek. Dengan cara ini, pada akhirnya Anda masih bisa menunjuk barang kiriman dunia nyata sebagai bukti kerja keras Anda.

• Bicaralah dengan orang-orang! Tidak ada yang seperti memiliki manusia yang hidup dan bernafas dengan siapa untuk mendiskusikan ide. Jika Anda merasa sedang buntu, bicarakan dengan seseorang. Raih seseorang - siapa pun! - dan jelaskan masalahnya kepada mereka. Buat sketsa pemikiran Anda tentang cara mengatasi masalah. Bahkan jika yang mereka lakukan adalah menghirup, menghembuskan napas, dan mengedipkan mata selama sepuluh menit saat Anda mengoceh, kemungkinan Anda akan menemukan wawasan baru hanya dalam proses menjelaskan masalah .

Seperti yang dikatakan Satchel Paige, "Kadang-kadang saya duduk dan berpikir, dan kadang-kadang saya hanya duduk."

Saya kira apa yang ia maksudkan adalah bahwa kadang-kadang ada baiknya untuk menjernihkan pikiran Anda karena hal itu dapat membuat Anda memikirkan masalah Anda dengan cara yang berbeda. Jadi, jika Anda tidak menabrak kode Anda mungkin akan menemukan solusi atau ide yang mungkin menghindari Anda sebaliknya. Jadi, ya, itu normal dan praktik yang baik untuk tidak langsung masuk ke pengkodean.

Ada dua cara saya melakukan proses ini sendiri. Saya membuat folder di mana saya memiliki file teks dan gambar apa pun yang terkait dengan proyek. Saya menuliskan ide-ide saya di sana dan mencoba dan menyelamatkan seluruh proses pemikiran sebaik mungkin. Saya juga akan membuat proyek scratchpad di mana saya dapat dengan cepat menguji ide-ide sederhana dari algoritma ke tata letak CSS.

Program = Algoritma + Struktur Data

IMHO, proses desain (pemecahan masalah) sepenuhnya memerintah. Detail implementasi (masalah teknis) mengikuti dan menyelesaikan secara alami.

Ini kasus pemikiran saya.

1. Mulai dari awal Pertama-tama dibutuhkan gagasan kasar tentang apa yang Anda inginkan. Coba dapatkan daftar beberapa persyaratan, atau buatlah. Perlu sedikit waktu untuk memikirkan hal-hal di sini. Setelah Anda memiliki setidaknya sebuah karya yang Anda yakin Anda inginkan, mengetahui sebagian besar antarmuka dari karya tersebut, kemudian mulai mengkodekan.

2. Memperbaiki masalah dengan kode yang ada Pertama-tama, telusuri masalahnya. Ini mungkin memerlukan waktu untuk tidak menulis kode asli (Beberapa kode debug mungkin ditulis, tetapi ini biasanya tidak disimpan). Setelah Anda menemukan masalah, tergantung pada kerumitannya, mulailah menulis kode untuk mencoba dan memperbaikinya. Tidak banyak yang harus dipikirkan begitu bug diketahui. Jika masalah berhasil menjadi cacat desain utama, lihat bagian selanjutnya.

3. Perubahan desain / fitur utama Ini kemungkinan besar yang akan paling membutuhkan pemikiran. Pemikiran untuk menjaga struktur, kompatibilitas ke belakang, dll. Harus dimasukkan. Memikirkan perubahan terbaik bisa menghemat waktu yang signifikan, tetapi biasanya bagi saya tidak lebih dari beberapa hari.

4. Menambahkan fitur sederhana Jika tidak ada perubahan desain yang signifikan diperlukan, maka cukup kode dalam fitur Anda, menggunakan beberapa percobaan / kesalahan. Ini seharusnya tidak memerlukan banyak waktu secara umum.

Saya tidak akan setuju dengan konsensus yang satu ini. Saya lebih suka mulai membuat prototipe sesuatu segera setelah saya bahkan memiliki ide tertulis-pada-serbet samar tentang bagaimana saya ingin sistem saya bekerja. Hampir tidak mungkin bagi saya untuk memikirkan semua detail kecil yang dapat menyebabkan masalah kecuali saya menentukan hal-hal dengan cara yang sangat tepat. Jika saya hanya mendiskusikan desain dengan orang-orang, terlalu mudah untuk menggerakkan beberapa masalah yang lebih kompleks. Setelah saya menentukan hal-hal seperti ini, mungkin juga secara langsung dalam kode sumber daripada beberapa cara ekspresi lain yang sama persis dan formal tetapi tidak dapat dikompilasi dan dieksekusi.

Itu tergantung pada apa yang Anda maksud untuk "normal" . Berbicara tentang diri saya, saya pikir kode adalah alat pembelajaran yang hebat. Jadi, ketika menghadapi masalah yang kompleks, saya membuat sketsa di atas kertas tetapi saya juga melakukan beberapa pengkodean berbasis tes. Kode memberi tahu saya bahwa papan tulis tidak dapat mengatakan dan sebaliknya, dan mungkin hasilnya adalah wawasan atau kebutuhan untuk beberapa pertanyaan lagi kepada pakar domain.

Jadi saran sebenarnya adalah: "Gunakan setiap alat pembelajaran yang diperlukan untuk lebih dekat dengan definisi masalah" , tetapi juga "ingat bahwa ini adalah alat belajar, jadi jangan jatuh cinta dengan mereka" baik kode dan sketsa dimaksudkan untuk dibuang .

Di era pemrograman RAD dan lincah ini, Anda harus mulai mengembangkan segera setelah Anda dapat mengidentifikasi bagian utama dari sistem, detail akan muncul. Karena Perangkat Lunak semakin besar, fokus secara prematur pada setiap detail tunggal tidak akan membawa Anda ke mana pun.