Kutipan Torvalds tentang programmer yang baik [ditutup]

Secara tidak sengaja saya menemukan kutipan berikut oleh Linus Torvalds:

"Pemrogram yang buruk khawatir tentang kode. Pemrogram yang baik khawatir tentang struktur data dan hubungan mereka."

Saya sudah memikirkannya selama beberapa hari terakhir dan saya masih bingung (yang mungkin bukan pertanda baik), maka saya ingin membahas hal berikut:

• Penafsiran apa dari ini yang mungkin / masuk akal?
• Apa yang bisa diterapkan / dipelajari darinya?

Mungkin membantu untuk mempertimbangkan apa yang Torvalds katakan tepat sebelum itu:

git sebenarnya memiliki desain sederhana, dengan struktur data yang stabil dan terdokumentasi dengan baik. Sebenarnya, saya adalah pendukung besar merancang kode Anda di sekitar data, daripada sebaliknya, dan saya pikir itu salah satu alasan git cukup berhasil [...] Saya akan, pada kenyataannya, mengklaim bahwa perbedaannya antara programmer yang buruk dan yang baik adalah apakah ia menganggap kode atau struktur datanya lebih penting.

Apa yang dia katakan adalah bahwa struktur data yang baik membuat kode sangat mudah untuk dirancang dan dipelihara, sedangkan kode terbaik tidak dapat menggantikan struktur data yang buruk.

Jika Anda bertanya-tanya tentang contoh git, banyak sistem kontrol versi mengubah format data mereka secara relatif untuk mendukung fitur-fitur baru. Ketika Anda memutakhirkan untuk mendapatkan fitur baru, Anda seringkali harus menjalankan semacam alat untuk mengonversi basis data juga.

Misalnya, ketika DVCS pertama kali menjadi populer, banyak orang tidak tahu bagaimana dengan model yang didistribusikan membuat penggabungan jauh lebih bersih daripada kontrol versi terpusat. Jawabannya adalah apa-apa, kecuali struktur data terdistribusi harus menjadi jauh lebih baik untuk memiliki harapan bekerja sama sekali. Saya percaya algoritma gabungan terpusat telah menyusul, tetapi butuh waktu yang cukup lama karena struktur data lama mereka membatasi jenis algoritma yang dapat mereka gunakan, dan struktur data baru memecahkan banyak kode yang ada.

Sebaliknya, meskipun ada ledakan fitur di git, struktur datanya hampir tidak berubah sama sekali. Khawatir tentang struktur data terlebih dahulu, dan kode Anda secara alami akan lebih bersih.

Algoritma + Struktur Data = Program

Kode hanyalah cara untuk mengekspresikan algoritma dan struktur data.

Kutipan ini sangat akrab dengan salah satu aturan dalam "The Art of Unix Programming" yang merupakan keahlian Torvalds sebagai pencipta Linux. Buku ini ada online di sini

Dari buku ini adalah kutipan berikut yang menguraikan tentang apa yang Torvalds katakan.

Rule of Representation: Lipat pengetahuan menjadi data sehingga logika program bisa bodoh dan kuat.

Bahkan logika prosedural yang paling sederhana sulit bagi manusia untuk memverifikasi, tetapi struktur data yang cukup kompleks cukup mudah untuk dibuat model dan alasannya. Untuk melihat ini, bandingkan daya ekspresif dan penjelas dari diagram (katakanlah) pohon pointer lima puluh simpul dengan diagram alur program lima puluh baris. Atau, bandingkan penginisialisasi array yang mengekspresikan tabel konversi dengan pernyataan switch yang setara. Perbedaan transparansi dan kejelasannya sangat dramatis. Lihat Peraturan Rob Pike 5.

Data lebih mudah ditelusuri daripada logika program. Oleh karena itu di mana Anda melihat pilihan antara kompleksitas dalam struktur data dan kompleksitas dalam kode, pilih yang pertama. Lebih lanjut: dalam mengembangkan desain, Anda harus secara aktif mencari cara untuk mengubah kompleksitas dari kode ke data.

Komunitas Unix tidak memunculkan wawasan ini, tetapi banyak kode Unix yang menunjukkan pengaruhnya. Fasilitas bahasa C dalam memanipulasi pointer, khususnya, telah mendorong penggunaan struktur referensi yang dimodifikasi secara dinamis di semua tingkat pengkodean dari kernel ke atas. Pengejaran pointer sederhana dalam struktur seperti itu sering melakukan tugas yang implementasi dalam bahasa lain malah harus mewujudkan dalam prosedur yang lebih rumit.

Kode itu mudah, itu logika di balik kode yang kompleks.

Jika Anda khawatir tentang kode itu berarti Anda belum mendapatkan dasar-dasar itu dan kemungkinan hilang pada kompleks (yaitu struktur data dan hubungan mereka).

Untuk sedikit memperluas jawaban Moron , idenya adalah bahwa memahami rincian kode (sintaksis, dan sedikit banyak, struktur / tata letak) cukup mudah sehingga kita membangun alat yang dapat melakukannya. Compiler dapat memahami semua yang perlu diketahui tentang kode untuk mengubahnya menjadi program / pustaka yang berfungsi. Tetapi kompiler tidak dapat benar-benar menyelesaikan masalah yang dilakukan oleh programmer.

Anda dapat mengambil argumen satu langkah lebih jauh dan mengatakan "tetapi kami memiliki program yang menghasilkan kode", tetapi kode yang dihasilkannya didasarkan pada semacam input yang hampir selalu dibuat dengan tangan.

Jadi, apa pun rute yang Anda ambil untuk mendapatkan kode: baik itu melalui semacam konfigurasi atau input lain yang kemudian menghasilkan kode melalui alat atau jika Anda menulisnya dari awal, bukan kode yang penting. Ini adalah pemikiran kritis dari semua bagian yang diperlukan untuk mendapatkan kode yang penting. Di dunia Linus yang sebagian besar struktur data dan hubungan, meskipun di domain lain mungkin bagian lain. Tetapi dalam konteks ini, Linus hanya mengatakan "Saya tidak peduli jika Anda dapat menulis kode, saya peduli bahwa Anda dapat memahami hal-hal yang akan menyelesaikan masalah yang saya hadapi".

Linus berarti ini:

Tunjukkan pada saya diagram alur [kode] Anda, dan sembunyikan tabel [skema] Anda, dan saya akan terus menjadi bingung; perlihatkan kepada saya tabel [skema] Anda dan saya biasanya tidak perlu diagram alur [kode] Anda: mereka akan jelas.

- Fred Brooks, "The Mythical Man Month", bab 9.

Saya pikir dia mengatakan bahwa desain tingkat tinggi secara keseluruhan (struktur data dan hubungan mereka) jauh lebih penting daripada rincian implementasi (kode). Saya pikir dia menghargai programmer yang bisa mendesain sistem daripada mereka yang hanya bisa fokus pada detail sistem.

Keduanya penting, tetapi saya akan setuju bahwa umumnya jauh lebih baik untuk mendapatkan gambaran besar dan memiliki masalah dengan detail daripada sebaliknya. Ini terkait erat dengan apa yang saya coba ungkapkan tentang memecah fungsi besar menjadi yang kecil .

Yah, saya tidak bisa sepenuhnya setuju, karena Anda harus khawatir tentang semua itu. Dan dalam hal ini, salah satu hal yang saya sukai dari pemrograman adalah beralih melalui berbagai tingkat abstraksi dan ukuran yang melompat cepat dari memikirkan nanodetik ke memikirkan bulan, dan kembali lagi.

Namun, hal-hal yang lebih tinggi lebih penting.

Jika saya memiliki beberapa masalah yang menyebabkan perilaku salah, mungkin tidak terlalu sulit untuk diperbaiki. Jika itu menyebabkan kinerjanya rendah, itu mungkin tidak masalah.

Jika saya memiliki cacat dalam pilihan struktur data dalam sub-sistem, yang menyebabkan perilaku yang salah, ini adalah masalah yang jauh lebih besar dan lebih sulit untuk diperbaiki. Jika itu menyebabkan kinerja di bawah, itu bisa sangat serius atau jika tertahankan, masih jauh kurang baik daripada pendekatan saingan.

Jika saya memiliki cacat dalam hubungan antara struktur data paling penting dalam suatu aplikasi, yang menyebabkan perilaku yang salah, saya telah mendesain ulang secara besar-besaran di depan saya. Jika itu menyebabkan kinerjanya rendah, mungkin sangat buruk sehingga hampir akan lebih baik jika itu berperilaku salah.

Dan itulah yang membuat sulit menemukan masalah tingkat rendah (memperbaiki bug tingkat rendah biasanya mudah, itu menemukan mereka yang bisa sulit).

Hal-hal tingkat rendah itu penting, dan kepentingannya yang tersisa sering kali dikecilkan secara serius, tetapi pucat dibandingkan hal-hal besar.

Seseorang yang tahu kode melihat "pohon." Tetapi seseorang yang mengerti struktur data melihat "hutan". Oleh karena itu programmer yang baik akan lebih fokus pada struktur data daripada pada kode.

Mengetahui bagaimana data akan mengalir adalah penting. Mengetahui aliran mengharuskan Anda mendesain struktur data yang baik.

Jika Anda kembali dua puluh tahun, ini adalah salah satu nilai jual besar untuk pendekatan berorientasi objek menggunakan SmallTalk, C ++, atau Java. Pitch besar - setidaknya dengan C ++ karena itulah yang saya pelajari pertama - adalah mendesain kelas dan metode, dan kemudian segala sesuatu yang lain akan jatuh ke tempatnya.

Linus tidak diragukan lagi berbicara dalam istilah yang lebih luas, tetapi struktur data yang dirancang buruk sering membutuhkan pengerjaan ulang kode tambahan, yang juga dapat menyebabkan masalah lain.

Apa yang bisa diterapkan / dipelajari darinya?

Kalau boleh, pengalaman saya dalam beberapa minggu terakhir. Diskusi sebelumnya mengklarifikasi jawaban untuk pertanyaan saya: "apa yang saya pelajari?"

Saya menulis ulang beberapa kode dan merefleksikan hasil yang terus saya lihat & mengatakan "struktur, struktur ..." adalah mengapa ada perbedaan dramatis. Sekarang saya melihat bahwa struktur data yang membuat perbedaan. Dan maksud saya semua .

• Setelah menguji pengiriman asli saya, analis bisnis mengatakan kepada saya itu tidak berfungsi. Kami mengatakan "tambah 30 hari" tetapi yang kami maksud adalah "tambahkan sebulan" ( hari di tanggal yang dihasilkan tidak berubah). Tambahkan tahun, bulan, hari; bukan 540 hari selama 18 bulan misalnya.

• Cara mengatasinya: dalam struktur data ganti integer tunggal dengan kelas yang berisi banyak integer, perubahan konstruksinya terbatas pada satu metode. Ubah pernyataan aritmatika tanggal aktual - semuanya 2.

Imbalannya

• Implementasi baru memiliki lebih banyak fungsi tetapi kode algoritma lebih pendek dan jelas lebih sederhana.

Dalam Memperbaiki kode perilaku / hasil:

• Saya mengubah struktur data, bukan algoritma.
• TIDAK ada logika kontrol yang disentuh di mana pun dalam kode.
• Tidak ada API yang diubah.
• Struktur pabrik kelas data tidak berubah sama sekali.

Saya suka membayangkan tim pustakawan yang sangat pandai di perpustakaan yang dibuat dengan jutaan buku acak dan brilian, itu akan sangat bodoh.

Tidak bisa setuju dengan Linus. Berfokus pada data sangat membantu menyaring solusi yang sederhana dan fleksibel untuk masalah yang diberikan. Git sendiri adalah contoh pembuktian - memberikan banyak fitur yang didukung di tahun-tahun pengembangan, struktur data inti sebagian besar tetap tidak berubah. Itu ajaib! --2c

Saya telah melihat ini banyak daerah.

Pikirkan tentang analisis bisnis ... Katakanlah Anda sedang menganalisis cara terbaik untuk mendukung Pemasaran di perusahaan produk konsumen seperti Colgate. Jika Anda mulai dengan windows mewah, atau teknologi terbaru, Anda tidak akan membantu bisnis hampir sebanyak jika Anda memikirkan kebutuhan data bisnis terlebih dahulu, dan kemudian khawatir tentang presentasi nanti. Model data hidup lebih lama dari perangkat lunak presentasi.

Pertimbangkan untuk membuat halaman web. Jauh lebih baik untuk memikirkan tentang apa yang ingin Anda tunjukkan (HTML) terlebih dahulu, dan khawatir tentang gaya (CSS) dan skrip (pilih alat Anda) setelahnya.

Ini bukan untuk mengatakan coding juga tidak penting. Anda membutuhkan keterampilan pemrograman untuk mendapatkan apa yang Anda butuhkan pada akhirnya. Data adalah fondasi. Model data yang buruk mencerminkan model bisnis yang terlalu rumit atau tidak terpikirkan.

Saya menemukan diri saya menulis fungsi baru dan memperbarui yang sudah ada lebih sering daripada harus menambahkan kolom atau tabel baru ke skema database saya. Ini mungkin benar untuk semua sistem yang dirancang dengan baik. Jika Anda perlu mengubah skema Anda setiap kali Anda perlu mengubah kode Anda, ini pertanda jelas bahwa Anda adalah pengembang yang sangat buruk.

kualitas indikator kode = [perubahan kode] / [perubahan skema basis data]

"Tunjukkan padaku diagram alurmu dan sembunyikan mejamu, dan aku akan terus menjadi bingung. Tunjukkan padaku mejamu, dan aku biasanya tidak akan membutuhkan diagram alurmu; itu akan jelas." (Fred Brooks)

Sepertinya ide ini memiliki berbagai interpretasi dalam berbagai jenis pemrograman. Ini berlaku untuk pengembangan sistem dan juga berlaku untuk pengembangan perusahaan. Sebagai contoh, orang dapat berargumen bahwa pergeseran tajam fokus ke domain dalam desain berbasis domain jauh seperti fokus pada struktur data dan hubungan.

Inilah interpretasi saya tentang itu: Anda menggunakan kode untuk membuat struktur data, jadi fokusnya harus pada yang terakhir. Ini seperti membangun jembatan - Anda harus merencanakan untuk merancang struktur yang solid daripada yang terlihat menarik. Kebetulan struktur data dan jembatan yang ditulis dengan baik terlihat baik sebagai hasil dari desain efisien mereka.