Apakah menulis perangkat lunak lebih mudah daripada membaca dan memahaminya dari awal? [Tutup]

12

Saya dan seorang teman saya membahas kemarin tentang perbedaan antara menulis perangkat lunak C ++ besar dan memahaminya sebagai karyawan baru.

Apakah mungkin karena suatu perangkat lunak dilakukan satu baris pada satu waktu dan proses ini menyerupai bagaimana kita (manusia) mempelajari sesuatu dan membangun sesuatu di atas yang lain, menulis perangkat lunak besar sebenarnya lebih mudah daripada membacanya dan memahami apa fungsinya (melangkah melalui kode membantu tetapi Anda perlu mengingat beberapa kelas / file sumber bersama-sama Anda bahkan tidak tahu apa yang telah mereka tulis, kode multithreaded menambah poin malus)?

Ini kedengarannya aneh pada awalnya, tetapi setelah kami berpikir sedikit rasanya masuk akal

— Makane Elhay
sumber

1

Penjelasan singkat tentang penutupan: Meskipun ini adalah pertanyaan yang sangat bagus, itu juga salah satu yang tidak bisa dijawab, hanya dibahas (secara luas). Ada terlalu banyak faktor untuk dipertimbangkan, kualitas kode dan gaya, keterampilan belajar pembaca dan keakraban dengan proyek dan bahasa, ukuran proyek dan sebagainya. Jika Anda tertarik untuk membahas lebih lanjut tentang penutupan, sudah ada pertanyaan tentang itu di situs Meta kami.

— yannis

Buku "Pola Magang" berbicara tentang Perjalanan dari Novice ke Master Craftsman. Ini menjawab banyak pertanyaan pemula, pemagang, pemrogram tingkat pekerja harian dalam pertumbuhan karier mereka. Butuh beberapa waktu untuk menggunakan banyak pola tetapi itu adalah bagian dari perjalanan. Salah satu polanya adalah menulis 'Mainan Rusak' atau 'Prototipe' yang membantu seseorang untuk mencari tahu dan membandingkan dengan sistem produksi. Ada banyak pola yang lebih bermanfaat.

— GuruM

41

Berdasarkan pengalaman saya, saya akan memberi peringkat kegiatan berikut ini dari yang paling mudah ke yang paling sulit.

Membaca kode yang bagus
Menulis kode yang buruk
Menulis kode yang bagus
Membaca kode yang buruk

Peringkat di atas mengarah ke 2 kesimpulan

Meskipun lebih mudah untuk menulis kode daripada membaca kode yang buruk, lebih mudah untuk membaca kode yang baik daripada menulis kode Anda sendiri
Menulis kode yang buruk lebih mudah daripada menulis kode yang baik, tetapi menulis kode yang buruk membuat Anda siap untuk membaca kode yang buruk, yang merupakan hal tersulit dari semuanya. Terutama karena kode buruk dibaca lebih dari yang tertulis.

Tentu saja, kode yang baik dan kode yang buruk adalah generalisasi yang luas. Saya merekomendasikan Kode Lengkap dan Kode Bersih untuk detail lebih lanjut tentang kode yang baik.

— Aaron Kurtzhals
sumber

Banyak hal lain dapat menyebabkan "kode buruk" - kurangnya konsistensi internal, visi yang menyatukan, atau perencanaan. Kurangnya perencanaan atau modularisasi kode yang tepat. Saya telah melihat kode bagus yang tidak ada gunanya karena tidak menggunakan fitur bahasa built-in yang akan bekerja dengan baik.

— Ben DeMott

Juga, cara menulis kode yang baik: cdn.thenextweb.com/files/2011/01/65987_700b.jpg

— CurtisHx

2

Dalam skala saya, membaca kode yang buruk tetap lebih mudah daripada menulis kode yang baik. Paling buruk, Anda dapat meluncurkan debugger pada kode buruk yang Anda coba baca, atau mengeditnya dengan alat refactoring.

— mouviciel

2

Menulis kode yang buruk hanya mudah sampai pada titik di mana ia harus berintegrasi dan bekerja, atau berubah sehubungan dengan perubahan persyaratan. Jika Anda "memprogram diri sendiri ke sudut" maka itu tidak lagi mudah.

— Kaz

@mouviciel Membaca kode buruk yang ditulis oleh programmer yang sangat pintar yang seharusnya tidak menulis kode buruk bisa jadi sulit. Membaca kode buruk yang ditulis oleh programmer naif itu mudah. Pakai "topi naif" Anda dan menjadi jelas apa yang gagal dicapai oleh kode tersebut. :)

— Kaz

13

Pertanyaan ini menarik bagi Konsensus Salah. http://en.wikipedia.org/wiki/False-consensus_effect

Orang yang berbeda belajar dan menyerap informasi secara berbeda. Ini mirip dengan pelajar auditori, pelajar visual dan pelajar kinestetik. Bagi sebagian orang, membaca kode lebih mudah, bagi yang lain, membuat kode lebih mudah. Bagi saya, ini yang terakhir. Bagi orang lain di tim saya, ini adalah yang pertama. Saya tidak percaya menemukan semacam konsensus atau mayoritas berguna. Lebih baik untuk memahami bagaimana otak Anda menyerap dan mempelajari informasi dan menggunakan pengetahuan itu untuk membuat diri Anda lebih baik dan belajar untuk menerima orang lain yang berbeda.

— mawcsco
sumber

1

Tentunya mengajukan pertanyaan dan pendapat menyaring jauh lebih baik daripada hanya percaya hipotesis ini (atau yang lainnya) secara otomatis benar. Mengenali bagaimana berbagai orang mendekati masalah yang sama sering kali dapat memiliki efek positif pada kinerja tim serta meningkatkan interaksi sosial.

— Robbie Dee

7

Anda benar sekali. Bertanya adalah awalnya. Dan, memahami bahwa ada Konsensus Palsu bermanfaat untuk pengertian. Itu sebabnya saya "menjawab" pertanyaan itu alih-alih mengabaikannya.

— mawcsco

7

perbedaan antara menulis perangkat lunak C ++ besar dan memahaminya sebagai karyawan baru

Ini tidak sama dengan perbedaan antara perangkat lunak membaca dan menulis. Ketika Anda baru mengenal suatu proyek (dan terutama ketika Anda baru mengenal sebuah perusahaan), Anda harus belajar lebih banyak dari sekadar apa yang dilakukan oleh kode. Memahami mengapa kode melakukan apa yang sering dilakukan memerlukan pemahaman tentang bagaimana bisnis bekerja dan bagaimana proyek terkait dengan seluruh organisasi. Singkatnya, membaca kode tanpa manfaat pengetahuan latar belakang adalah tugas yang lebih lambat dan lebih sulit daripada membaca kode ketika Anda sepenuhnya memahami konteks di mana kode bekerja.

Ada adalah perbedaan antara menulis merek kode baru pada proyek greenfield dan membaca dan memodifikasi kode yang ada, tapi saya tidak akan mengatakan yang satu ini tentu lebih mudah daripada yang lain, hanya berbeda. Ketika Anda membuat sesuatu yang baru, Anda tidak perlu khawatir tentang bagaimana membuat kode Anda bekerja dengan apa yang sudah ada, tetapi Anda harus khawatir tentang membuat proyek Anda cukup luas dan mudah beradaptasi sehingga akan tetap berguna di masa depan . Ketika Anda mengerjakan proyek yang sudah ada, Anda sering dapat menggunakan apa yang sudah ada sebagai panduan, tetapi Anda harus terlebih dahulu memahami apa yang ada di sana.

Sebagai "rekrut baru" biasanya lebih baik bekerja pada proyek yang sudah ada secara khusus karena ini membantu Anda untuk mempelajari semua hal yang tidak Anda ketahui: bagaimana bisnis bekerja, bagaimana berbagai proyek bekerja sama, mengkode standar dan praktik, dan bahkan (terutama) apa yang bisa diperbaiki.

— Caleb
sumber

Memahami 'konteks' luasnya / kedalaman sistem dan API yang mendasarinya dengan pengalaman. Apa komponen logis dari sistem? Bagaimana komponen-komponen ini berinteraksi satu sama lain? Mekanisme apa yang mereka gunakan dari blok bangunan yang mendasarinya? Bagaimana blok bangunan yang mendasari berperilaku di jalur yang berbeda? Apa kendala / tujuan sistem? Mengapa jalan-jalan tertentu dipilih daripada kandidat lain? Jika Anda perlu menambahkan komponen baru apa yang bisa Anda gunakan kembali dan apa yang perlu Anda tambahkan lagi? Bisakah Anda melihat dari 'di dalam sistem'? Buku Super untuk melihat Cara Berpikir dan Belajar Pragmatis.

— GuruM

Membangun 'Prototipe' atau 'Mainan Rusak' (dengan kekurangan yang diketahui dan hanya untuk mengeksplorasi alternatif) akan membantu "memaksa" diri untuk memikirkan pertanyaan-pertanyaan di atas. Menambahkan komponen dan menambahkan fitur yang diikuti oleh Refactoring akan membantu orang mendapatkan "rasa" untuk masalah yang ada dan solusi yang mungkin (melalui pencarian forum mungkin).

— GuruM

4

Ini pertanyaan yang menarik, tetapi saya cenderung cenderung lebih mudah membaca dan memahami daripada membuatnya.

Jika Anda seorang veteran, programmer berpengalaman, maka Anda cenderung membaca kode dan pergi "Ya, pilihan yang baik, periksa, oh, saya mungkin telah melakukan X daripada Y", dll. Anda dapat memodifikasi atau tweak, tetapi itu akan menghemat waktu lebih banyak daripada menulis dari awal (Kecuali ada alasan untuk melakukannya).

Jika Anda seorang programmer yang lebih baru, maka "Anda tidak tahu apa yang tidak Anda ketahui", maka Anda harus menemukan / mempelajari semua hal kecil, dan sangat mungkin Anda akan memiliki beberapa inefisiensi dalam kode. Anda mungkin akan mengembangkan pemahaman bahasa yang lebih besar.

Tetapi dalam kedua kasus itu, akan lebih mudah untuk membaca kode dan pergi dari sana daripada menulisnya sepenuhnya dari awal.

— JohnP
sumber

2

Kebanyakan programmer merasa lebih mudah untuk memahami kode yang mereka tulis sendiri dibandingkan dengan kode yang ditulis orang lain. Ini karena pembelajaran garis-demi-garis yang Anda sebutkan, juga hanya masalah gaya dan bakat individu. Itulah sebabnya begitu banyak reinvention roda terjadi.

Namun, itulah pemandangan pepohonan. Pandangan hutan adalah bahwa lebih mudah untuk membaca kode daripada menulisnya dari awal. Misalnya, apakah lebih mudah untuk menulis pengolah kata baru dari awal, atau mempelajari basis kode yang ada dengan cukup baik untuk melakukan perbaikan?

Ketika Anda mulai membaca kode, Anda dapat memikirkan bazillion cara untuk membuat kode lebih mudah bagi Anda untuk dibaca. Anda menghabiskan pertama saat hanya menelusuri kode, mencoba mencari tahu letak tanah, kadang-kadang dalam arsitektur benar-benar laknat tentang bagaimana Anda ingin melakukannya. Tetapi bahkan dalam basis kode yang sangat besar, Anda mungkin akan menghabiskan 40-80 jam memutar roda Anda, dibandingkan dengan ratusan ribu jam kerja yang telah diinvestasikan untuk membuat aplikasi itu.

— Karl Bielefeldt
sumber

Bisakah Anda menulis kode dan tidak memahaminya? Salin mungkin.

— JeffO

@ Jeffe Sepanjang waktu - lol ...

— Robbie Dee

1

Orang yang menulis perangkat lunak hampir selalu memiliki pemahaman terbaik tentang program hanya karena mengetahui logika dan proses berpikirnya saat menulisnya.

Saya tidak berpikir bahwa menulis kode sama sekali dapat dibandingkan dengan membaca kode dalam hal kemudahan pemahaman. Di satu sisi, hanya menulis perangkat lunak memberikan pemahaman yang lebih besar tentang perangkat lunak tertentu karena pengetahuan tentang konteks yang terkait dengan masing-masing bagian kode, pustaka yang digunakan, dll. Namun, membaca kode yang ditulis orang lain mungkin sulit dipahami dalam hal perangkat lunak yang sebenarnya, tetapi dalam hal memahami bahasa itu dapat memberikan wawasan tentang cara-cara baru dalam melakukan sesuatu atau menggunakan perpustakaan yang mungkin tidak Anda pertimbangkan untuk digunakan, yang dapat membuat hidup Anda lebih mudah menulis kode.

Dalam hal membangun pengetahuan, saya pikir membaca kode dan menulis kode sangat terhubung dan dalam banyak hal membangun satu sama lain. Kode penulisan pengalaman memberikan kemudahan memahami kode orang lain, dan kode membaca memungkinkan Anda memiliki waktu yang lebih mudah untuk menulis kode (melalui konsep logika baru, penggunaan perpustakaan, dll).

— StMotorSpark
sumber

1

Ini adalah sesuatu yang secara pribadi saya rasa sudah terbukti dengan sendirinya, tetapi saya tidak pernah sepenuhnya yakin bahwa hal itu berlaku untuk masyarakat pemrograman secara keseluruhan. Sebagai contoh, saya mengenal beberapa pembuat kode yang sangat berbakat yang alih-alih membaca dokumentasi, dengan senang hati dapat mengambil kode orang lain dan memahaminya seolah-olah itu adalah kode mereka sendiri.

Ini mengarah pada pertanyaan: apakah ini penting?

Jika Anda membaca kode, kemungkinan Anda membuat perubahan daripada menulis ulang. Bahkan jika Anda menulis ulang, Anda kemungkinan akan menulis ini dalam bahasa / versi baru sehingga Anda mungkin tidak perlu membuat kode dengan cara yang sama. Maksud saya adalah bahwa tidak selalu perlu untuk memahami semua kode sepanjang waktu.

Semua ini benar, metodologi pengembangan yang lebih baru misalnya BDD mengakui bahwa penting bagi logika bisnis untuk lebih jelas dari kode daripada kode hanya menjadi sarana untuk menggerakkan mesin. Ini tentu saja bukan hal yang baru - konsep ini telah ada sejak karya mani Donald Knuth: Programate Literate .

— Robbie Dee
sumber

1

Saya masuk ke jawaban StMotorSpark, hanya menambahkan:
Tergantung pada banyak faktor, itu tidak bisa menjadi pertanyaan ya atau tidak, misalnya:

Apakah kode yang ada didokumentasikan dengan baik dan ditulis dengan baik atau apakah terlihat seperti spageti tanpa rasa atau komentar?
Apakah ini aplikasi kecil dengan situasi yang sangat langka yang menghabiskan waktu tanpa akhir untuk mencari tahu bagaimana solusinya, atau aplikasi yang lebih besar namun sederhana?
dll.

— JoseTeixeira
sumber

1

Poin yang sangat bagus; Namun, saya berpendapat bahwa itu lebih tergantung pada orang tersebut. Misalnya bahkan jika ada beberapa kode yang hampir tidak memiliki dokumentasi, itu masih dapat memberikan wawasan dalam bentuk "Aneh, saya bertanya-tanya apa itu". Jika seseorang benar-benar ingin belajar, mereka akan menemukan sesuatu yang bermanfaat terlepas dari ukuran program atau dokumentasi. Dengan mengingat hal itu, dokumentasi dan kode yang baik yang tidak melebihi ukurannya membantu secara substansial.

— StMotorSpark

1

Sepenuhnya setuju, itu juga sangat tergantung pada orang tersebut. Hanya perhatikan bahwa karena persyaratan pekerjaan burung hantu, sebagian dari kita melakukan banyak pengembangan dari awal sementara yang lain melakukan banyak pemeliharaan. Ini pasti akan menyempurnakan dua keahlian yang berbeda, tidak peduli apakah mereka memulai keduanya dengan cara berpikir yang terorganisasi dengan baik, tingkat logika dan pemahaman bahasa yang sama, ...

— JoseTeixeira