Bagaimana cara mengatasi pemrograman secara kebetulan? [Tutup]

Dalam buku The Pragmatic Programmer , para penulis menyebutkan pemrograman dengan konsep kebetulan . Ini menjelaskan apa itu, mengapa itu disebabkan, apa bahaya yang mungkin Anda temui dan itu dibandingkan dengan ladang ranjau darat dalam perang.

Apakah Anda pernah menonton film perang hitam putih tua? Prajurit yang lelah maju dengan hati-hati keluar dari sikat. Ada pembukaan di depan: apakah ada ranjau darat, atau apakah aman untuk dilintasi? Tidak ada indikasi bahwa itu ladang ranjau — tidak ada tanda, kawat berduri, atau kawah. Tentara itu menusuk tanah di depannya dengan bayonet dan kemenangannya, mengharapkan ledakan. Tidak ada. Jadi dia berjalan dengan susah payah melalui lapangan untuk sementara waktu, mendorong dan menusuk saat dia pergi. Akhirnya, yakin bahwa lapangan itu aman, ia berdiri tegak dan maju dengan bangga, hanya untuk dihancurkan berkeping-keping.

Penyelidikan awal prajurit untuk tambang tidak mengungkapkan apa-apa, tapi ini hanya keberuntungan. Dia dibimbing ke kesimpulan yang salah — dengan hasil yang menghancurkan.

Sebagai pengembang, kami juga bekerja di ladang ranjau. Ada ratusan jebakan yang hanya menunggu untuk menangkap kita setiap hari. Mengingat kisah prajurit itu, kita harus berhati-hati dalam menarik kesimpulan yang salah. Kita harus menghindari pemrograman secara kebetulan — mengandalkan keberuntungan dan kesuksesan tak disengaja — demi pemrograman yang sengaja ...

Tetapi saya tidak benar-benar puas dengan cara mereka menggambarkan masalah "bagaimana cara mengatasinya". Ya, Anda harus berpikir dulu sebelum menulis kode, tetapi bagaimana mempraktikkannya? Satu-satunya hal yang dapat saya pikirkan adalah dengan menambahkan fitur ke proyek open source yang ada, di mana Anda harus memiliki pengetahuan tentang "apa yang saya lakukan sekarang" dan "Bagaimana cara kerja kode lain", dan itu tidak berlaku ketika Anda sedang menulis proyek Anda sendiri.

EDIT:

ringkasan dari posting Anda:

• Jangan menebak langkah Anda selanjutnya, buktikan itu benar
• Unit test dan refactor sebanyak mungkin, bila perlu
• Tambahkan fitur – compile – test sesering mungkin
• Jika Anda tidak dapat menjelaskan kode ke noob, Anda mungkin memprogram secara kebetulan.

BTW, sulit menerima jawaban, sangat sulit. Semua jawaban sangat bagus :)

Anda tidak harus berpikir ke depan, cukup jelas apa yang sudah dilakukan, dan jelaskan apa yang sedang Anda lakukan saat ini.

Subrutin harus mengatakan apa yang mereka lakukan, melakukan apa yang mereka katakan, dan tidak memiliki ketergantungan tersembunyi. Kemudian seseorang yang memanggil mereka dapat dengan mudah memberi alasan tentang apa yang akan mereka lakukan.

Hindari negara global. (Variabel, lajang, dll.) Semakin banyak keadaan yang harus Anda miliki di kepala Anda untuk memahami hal-hal apa yang dilakukan, semakin sulit untuk memahami apa yang seharusnya terjadi dan menemukan kasus tepi.

Tulis tes unit. Tes unit sangat bagus untuk menangkap perilaku kode aktual yang baru saja Anda tulis, daripada perilaku ideal yang Anda harapkan.

Persingkat siklus edit / kompilasi / pengujian Anda. Ketika Anda menambahkan sejumlah besar kode dan menguji dengan buruk, maka kemungkinan besar ia akan berperilaku berbeda dari yang Anda pikirkan. Kemudian Anda "memperbaikinya" dengan beberapa perubahan acak, dan Anda mendapatkan jawaban yang tepat untuk saat ini, tetapi tidak tahu bagaimana itu sebenarnya terjadi. Anda sekarang pemrograman secara kebetulan. Tetapi ketika Anda menambahkan 5 baris dan kemudian menguji, kemungkinan Anda mendapatkan jawaban yang benar karena itu berfungsi seperti Anda berpikir itu bekerja jauh lebih baik. Saya dapat mengatakan dari pengalaman bahwa 5 potongan masing-masing 10 baris, yang diuji secara individual, adalah binatang yang sangat berbeda dari 50 baris kode yang diuji sekaligus.

Refactor tanpa ampun. Banyak kali saya melihat refactor yang akan membuat kode saya sedikit lebih sederhana tetapi mengambil banyak pekerjaan yang tidak ingin saya lakukan. Setelah saya mulai dengan sengaja menangani refactor-refactor itu sebagai prioritas, saya mendapati bahwa itu biasanya terbayar sendiri dalam waktu sebulan. Tetapi perhatikan kuncinya, refactor yang saya fokuskan adalah yang membuat kehidupan sehari-hari menjadi lebih sederhana, dan bukan yang memenuhi estetika sewenang-wenang yang lebih baik atau lebih umum. Para refactor yang telah saya pelajari menjadi lebih berhati-hati.

Tidak satu pun dari hal-hal ini memerlukan perencanaan terlebih dahulu. Tetapi mereka semua membuatnya lebih mudah untuk memahami kode yang ada, dan karena itu membuatnya mudah untuk mengimplementasikan potongan kecil berikutnya dengan cara yang disengaja.

Cukup banyak intinya untuk tidak menebak . Kebanyakan programmer baru melakukannya, tetapi saya pernah melihat veteran melakukannya juga, karena mereka pikir itu menghemat waktu penelitian. Sesuatu tidak berfungsi, jadi Anda menambahkan a +1atau a -1, mengubah a trueke falseatau sebaliknya, menyusun ulang beberapa pernyataan, menambah atau mengubah penundaan, mengubah prioritas utas, dan transformasi kecil lainnya, pada dasarnya menguji permutasi acak hingga berfungsi.

Itu sebagian besar berlaku untuk mengubah kode yang ada, tetapi juga merupakan faktor dalam kode baru, karena tidak ada yang benar-benar mulai dari awal. Anda selalu membangun di atas perpustakaan standar, sistem operasi, atau setidaknya arsitektur prosesor.

Dengan kata lain, Anda belum selesai sampai Anda tahu mengapa perbaikan Anda berhasil. Jalan yang Anda ambil untuk sampai ke sana tidak terlalu penting. Bahkan permutasi acak kadang-kadang dapat membantu untuk mempersempit bug yang sulit didiagnosis, selama Anda meluangkan waktu sesudahnya untuk bertanya pada diri sendiri, "Oke, mengubah true to false memperbaikinya, tetapi mengapa?"

Komentar paling menakutkan yang pernah saya temui dalam sebuah program adalah

Jangan sentuh ini. Berhasil. Kami tidak tahu bagaimana atau mengapa, tetapi itu berhasil. ¹

dan itu menakutkan hanya karena mengakui bahwa potongan kode adalah hasil pemrograman secara kebetulan .

Untuk menghindari pemrograman secara kebetulan, Anda harus dapat menjelaskan (kepada rekan kerja, diri Anda sendiri atau bebek karet ) persis apa yang dilakukan kode dan mengapa itu bekerja. Peluru untuk pemrograman secara sengaja sebagian besar membantu bergerak menuju tujuan untuk dapat menjelaskan kode.

¹ Untuk konteks, komentar ini muncul dalam kode yang menangani sakelar konteks dalam OS primitif. Kode sudah diproduksi selama beberapa tahun ketika saya menemukannya.

Untuk programmer baru, bagian terpenting dari mengatasi ini adalah untuk benar-benar memahami apa yang mereka lakukan.

Di banyak daerah, ketika Anda tidak tahu bagaimana melakukan sesuatu, Anda hanya pergi dengan coba-coba. Coba sesuatu; jika berhasil, bagus, jika tidak, coba sesuatu yang lain.

Dalam pemrograman, terutama ketika menggunakan bahasa yang memiliki konsep perilaku tidak terdefinisi (seperti C atau C ++), pendekatan ini tidak bekerja, karena kesuksesan bukan lagi keputusan boolean. Anda dapat memiliki hal-hal yang "jenis" bekerja, yang kadang-kadang berfungsi, yang bekerja untuk beberapa input tetapi tidak untuk yang lain.

Saya kadang-kadang mengajari programmer baru, dan kecenderungan untuk mencoba mengetik hal-hal acak untuk melihat apakah itu biasa. Mereka akan mengetik garis, dan kemudian menoleh ke saya dan bertanya, "Apakah akan bekerja seperti ini?" sementara itu jelas bahwa mereka sama sekali tidak tahu apakah itu mungkin.

Yang perlu diperhatikan adalah bahwa sebagai programmer baru Anda benar-benar harus dapat menjelaskan apa yang kode Anda lakukan. Anda harus belajar membaca kode, bukan hanya menulisnya.

(Tentu saja itu berlaku untuk programmer berpengalaman juga, tapi pengalaman saya di sini sebagian besar dengan pemula yang lengkap.)

Terlalu mudah untuk membuat kode, menguji dan memperbaiki "di jalur balap". Anda memiliki beberapa fungsionalitas yang diberikan X & Y, menghasilkan Z. Tetapi bagaimana jika X rusak dan Y tidak tersedia? Bagaimana jika Anda tidak dapat menampilkan Z? Selalu ingat apa yang salah dan buat catatan untuk siklus tes.

Jadikan rutinitas Anda singkat dan deskriptif - kode terbaik hanya membutuhkan sedikit (jika ada) komentar.

Metode yang berarti, nama kelas dan variabel pergi jauh untuk membantu keterbacaan.

Jika Anda menemukan bau kode maka BERHENTI. Bau itu tidak mungkin hilang dan sedikit usaha sekarang bisa menyelamatkan Anda dari kesedihan yang sangat besar di kemudian hari.

Sertakan pengujian dalam proses pengembangan Anda. Saya akan menganjurkan penggunaan BDD daripada TDD karena memaksa Anda untuk menggambarkan apa yang ingin Anda capai daripada bergantung secara buta pada serangkaian tes yang dapat memberi Anda rasa aman yang salah.

Tahan keinginan untuk menambahkan fitur-fitur keren lainnya (kecuali itu adalah proyek kesayangan Anda sendiri). Kode tambahan apa pun perlu dirancang, ditulis, diuji, dan dipelihara. Jika tidak diperlukan oleh klien / bisnis - Anda berisiko ini menjadi sumber daya yang sangat besar.