Hampir setiap programmer mahir mengatakan bahwa sangat berguna untuk membaca kode profesional lain. Biasanya mereka menyarankan open source.
Apakah Anda membacanya atau tidak? Jika ya, seberapa sering dan bagaimana prosedur membaca kode? Juga, agak sulit bagi pemula untuk berurusan dengan SVN - banyak file. Apa solusinya?
Jawaban:
Apakah Anda membacanya atau tidak?
Iya nih.
Jika ya, seberapa sering
Harian. Selalu. Saya bekerja dengan banyak proyek sumber terbuka (kebanyakan yang berhubungan dengan Python) dan harus membaca sumbernya karena ini adalah dokumentasi yang paling akurat.
dan bagaimana prosedur membaca kode?
Um Buka dan Baca.
Juga, agak sulit bagi pemula untuk berurusan dengan SVN - banyak file. Apa solusinya?
Buka dan Baca. Kemudian baca lebih lanjut.
Ini tidak mudah. Tidak ada yang membuatnya mudah. Tidak ada Jalan Kerajaan untuk memahami. Itu butuh kerja.
Ada beberapa lapisan pada teka-teki yang Anda miliki. Pertama, mulailah dari tingkat atas, pandangan mata burung untuk berbicara. Setelah Anda memeriksa proyek, akan ada banyak file dalam struktur direktori. Itu sama apakah Anda melihat sumber terbuka atau sumber tertutup (kode sumber adalah kode sumber setelah semua). Jadi mulailah dengan ini:
Dibutuhkan latihan, tetapi pasti bisa dilakukan. Semakin banyak Anda tahu tentang perpustakaan dan kerangka kerja aplikasi yang digunakan, semakin Anda tahu bagaimana kode perlu diatur dan di mana mencari jawaban untuk pertanyaan spesifik. Beberapa kode sedikit lebih sulit diikuti, terutama jika tidak langsung. Itu sebabnya Anda membutuhkan pensil dan kertas. Akhirnya bola lampu meledak di kepala Anda dan Anda mendapatkannya. Saat itulah membaca sisa kode lebih masuk akal.
Bukan membaca seperti Anda membaca novel, tetapi lebih seperti bagaimana Anda membaca buku referensi. Cara yang baik adalah dengan mengambil bug yang baru saja diperbaiki dari pesan check-in, melakukan perubahan apa yang berubah, dan membaca bagian yang relevan sampai Anda memahami masalah dan solusinya. Kerentanan keamanan yang dipublikasikan dengan baik adalah bug yang menyenangkan karena ada banyak diskusi tentang mereka di forum. Kemudian pilih salah satu bug "low hanging fruit" dari pelacak bug dan baca sampai Anda mengerti bagaimana cara memperbaikinya sendiri. Sebagian besar profesional pembacaan kode dilakukan secara insidental dalam rangka memperbaiki bug atau menambahkan fitur.
Biasanya sampel kode terbaik hampir tidak terlihat. Anda akan langsung memahaminya tanpa membacanya lebih dari sekali. Mereka membuatnya tampak seperti itu sangat mudah untuk ditulis, meskipun kode yang bagus biasanya melewati banyak konsep. Ini menghasilkan perasaan paradoks bahwa tentu saja kode yang diberikan adalah cara yang jelas untuk melakukannya, meskipun itu bukan cara pertama yang Anda pikirkan.
Bila Anda menemukan kode seperti itu, mencoba untuk memahami wawasan yang masuk ke menulisnya, dan prinsip-prinsip desain yang terlibat, jadi ketika Anda menemukan diri Anda dalam situasi yang sama di masa depan mudah-mudahan Anda dapat menerapkan prinsip-prinsip yang sama.
Salah satu trik yang saya gunakan cukup sering ketika membaca beberapa fungsi rumit, segmen kode adalah mulai refactoring menjadi sesuatu yang lebih mudah dibaca tanpa mengubah logika.
Bagaimana harus berurusan dengan "banyak file"? Tidak ada bedanya dengan ketika Anda menulis kode Anda sendiri, kecuali Anda tidak memiliki pengetahuan sebelumnya tentang organisasinya kecuali didokumentasikan.
Jika Anda, sebagai programmer yang diklaim, tidak dapat mengetahui struktur proyek dari "banyak file" apakah itu proyek yang sangat tidak terorganisir, atau Anda seorang programmer yang tidak kompeten (atau, dalam kasus ekstrim, keduanya).
Mulailah membaca, cobalah untuk menemukan beberapa titik masuk atau kelas / metode pivot yang penting, dan bangun pemahaman tentang bagaimana semuanya datang bersama dari sana. Tidak akan instan, akan memakan waktu, tetapi dapat dilakukan bahkan jika tidak ada dokumentasi sama sekali.
Hal terbaik yang dapat Anda harapkan ketika membaca kode proyek lain, baik itu API atau perangkat lunak adalah bahwa variabel, fungsi dan nama makro tidak disingkat ambigu atau dinamai sehingga Anda dapat mengetahui maksud mereka.
Tapi selain itu, dibutuhkan jumlah yang layak penyebaran pengetahuan di seluruh bahasa, teknik pemrograman dan juga tentang tujuan kode itu sendiri untuk dapat menyelam ke dalam kode yang kompleks.
Saat ini saya mencoba untuk melihat bagaimana Lua melakukan beberapa sihirnya, tapi saya sampai pada titik di atas di mana banyak pengidentifikasi diberi nama secara samar dan agak disingkat ke titik di mana saya tidak tahu garis mana yang sedang dicoba untuk melakukan hal yang saya tahu yang harus dilakukan di beberapa titik dalam kode fungsi ... Sering variabel huruf dan nama fungsi / makro agak disingkat melakukan kepalaku di.
Setelah melihat "Pertama, mulailah pada level tinggi, pandangan burung-mata" sebagai @Berin Loritsch menyarankan Anda dapat mencari unittests dan / atau tes integrasi jika ada.
unittests menarik untuk melihat bagaimana (api-) detail bekerja.
Integrationtest biasanya memberikan gambaran yang baik atas proses bisnis.