Kutipan Torvalds tentang programmer yang baik [ditutup]


238

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?

18
Saya pikir pertanyaan ini mungkin memiliki beberapa jawaban yang sama-sama valid. Tapi itu pertanyaan yang bagus. Saya suka kutipan itu. Ini mengungkapkan mengapa saya tidak mengerti programmer yang khawatir tentang beralih bahasa. Jarang bahasa yang penting dalam suatu program, itu struktur data dan bagaimana mereka berhubungan.
Ryan Kinal

5
Mungkin jika Anda meluangkan waktu membuat struktur data "elegan" maka kode tidak harus berbelit-belit untuk menangani struktur data ini? Saya mungkin terlalu bodoh untuk benar-benar tahu arti dari kutipan Torvalds. :}
programmer

3
@RyanKinal Tapi tentu saja bahasa itu penting , karena membuatnya lebih mudah untuk berurusan dengan dan berpikir tentang struktur data tertentu. Pikirkan tentang semua bahasa yang berspesialisasi dalam Parsing LISt, misalnya, atau bahasa yang memiliki dukungan asli untuk struktur data yang harus diretas ke dalam bahasa lain, (set dan array jarang muncul dalam pikiran).
kojiro

83
Ngomong-ngomong, Torvalds tidak sendirian dalam hal ini: "Tunjukkan padaku bagan alurmu dan sembunyikan meja-mu, dan aku akan terus menjadi bingung. Tunjukkan padaku mejamu, dan aku biasanya tidak akan memerlukan bagan alurmu; itu akan menjadi jelas. " - Fred Brooks, The Mythical Man-Month. "Tunjukkan kodenya padamu dan sembunyikan struktur datamu, dan aku akan terus menjadi bingung. Tunjukkan padaku struktur datamu, dan aku biasanya tidak membutuhkan kodemu; itu akan jelas." dan "Struktur data pintar dan kode bodoh bekerja jauh lebih baik daripada sebaliknya." - Eric S. Raymond, Katedral dan The Bazaar.
Jörg W Mittag

4
Ini menjelaskan mengapa kernel Linux berantakan :)
l1x

Jawaban:


326

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.


25
kode terbaik tidak dapat menebus struktur data yang buruk gravy adalah benar
Conrad Frix

5
Dia berbicara dari sudut pandang programmer membuat perubahan ke git sendiri. Sudut pandang pengguna akhir sepenuhnya ortogonal untuk diskusi ini, selain pembuatan kode yang mudah dipelihara untuk bug yang lebih sedikit dan penambahan fitur yang lebih cepat.
Karl Bielefeldt

2
@ James: Dia mengatakan bahwa perangkat lunaknya lebih baik (karenanya lebih mudah digunakan, dan digunakan oleh lebih banyak orang) karena struktur datanya lebih baik. Tentu saja Anda tidak perlu tahu tentang struktur data perangkat lunak yang Anda gunakan, tetapi Anda peduli dengan mereka, secara tidak langsung, bahkan jika Anda tidak menyadarinya, karena struktur data yang mendorong hal-hal yang memang Anda sadari. peduli tentang.
ruakh

1
+1. Jawaban ini menempatkan konteks pada pernyataan yang dapat ditafsirkan sebagai sesuatu yang sangat berbeda. Siapa pun yang telah membaca monstrositas 5.000 baris file tahu persis apa yang saya maksud.
riwalk

20
"Khawatir tentang struktur data terlebih dahulu, dan kode Anda secara alami akan lebih bersih.": Negarawan Romawi Cato ( en.wikipedia.org/wiki/Cato_the_Elder ) dulu mengatakan "Rem tene, verba sequentur" = "Buat argumennya jelas dalam pikiran Anda, kata-kata akan mengikuti secara alami ". Hal yang sama dengan pemrograman: memahami struktur data dan desain terlebih dahulu, kode aktual akan mengikuti dengan sendirinya.
Giorgio

60

Algoritma + Struktur Data = Program

Kode hanyalah cara untuk mengekspresikan algoritma dan struktur data.



Ini berlaku untuk pemrograman prosedural; di OOP sedikit berbeda.
m3th0dman

3
Pada dasarnya tidak ada perbedaan. Anda memiliki data dan melakukan serangkaian operasi di dalamnya. Variabel dan metode anggota. Hal yang persis sama. Seluruh esensi komputasi sejak 50-an telah dibangun di atas aturan yang sangat sederhana bahwa program terdiri dari algoritma memodifikasi struktur data, dan itu terus berlaku 60 tahun kemudian. Anda juga dapat mempertimbangkan program sebagai fungsi . Mereka mengambil input yang mereka operasikan untuk menghasilkan output . Persis seperti fungsi matematika.
zxcdw

31

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.


Saya ingat ini juga!
Jesvin Jose

1
OTOH, lihat pertanyaan StackOverflow tentang int**. Itu seharusnya meyakinkan Anda bahwa data sebenarnya TIDAK jelas; hanya menjadi demikian dengan melampirkan makna pada data. Dan makna itu ada dalam kode.
MSalters

29

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).


17
Heh, saya bertanya-tanya apakah generasi programmer berikutnya akan bertanya: "Orang-orang bodoh pernah berkata Code is easy, it's the logic behind the code that is complex, apa maksudnya?"
yannis

36
@YannisRizos Itu akan sangat membingungkan ketika orang tidak yakin apakah itu dikatakan oleh orang - orang yang bodoh, atau satu orang dengan nama Morons.
KChaloux

14

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".


Setiap programmer menggunakan program yang menghasilkan kode. Mereka sering disebut "kompiler", kadang-kadang dalam kombinasi dengan "penghubung". Mereka mengambil (relatif) input yang dapat dibaca manusia dan dapat ditulis oleh manusia, yang biasanya (tetapi tidak selalu) disediakan dalam beberapa jenis format teks, dan mengubahnya menjadi data yang dapat dipahami oleh komputer sebagai instruksi dan dijalankan.
CVn

13

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.


12

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 .


+1: Saya setuju dengan Anda. Aspek lain adalah bahwa sering programmer lebih khawatir tentang fitur bahasa keren apa yang akan mereka gunakan, daripada berfokus pada struktur data dan algoritma mereka dan bagaimana menuliskannya dengan cara yang sederhana dan jelas.
Giorgio

Saya juga setuju. Faktanya adalah mudah untuk mengubah potongan-potongan kode yang terisolasi, tetapi lebih sulit untuk mengubah struktur data atau antarmuka antara potongan-potongan kode (karena jenis-jenis perubahan ini dapat mempengaruhi banyak hal daripada hanya satu hal).
Brendan

5

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.


2

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.


2
Tetapi berfokus pada hutan atau pohon dengan mengesampingkan yang lain bisa merugikan, jadi saya tidak berpikir analogi ini cocok.
kojiro

1
@kojiro: Dalam ekspresi tidak dapat melihat hutan untuk pohon , diasumsikan bahwa seseorang yang dapat melihat hutan juga akan melihat pohon (lihat en.wiktionary.org/wiki/see_the_forest_for_the_trees ). Karena itu saya pikir ini analogi yang baik di sini.
Treb

2

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.


2

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.

1

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


1

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


0

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.


0

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)


-2

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.


-4

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.

Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.