Bagaimana cara membaca ribuan baris kode tanpa dokumentasi? [Tutup]

Sebelumnya saya sedang mencari kontrol TimeLine yang baik untuk proyek WPF. Saya menemukan jawaban di Sini yang mengarahkan saya ke proyek CodePlex ini .

Sekarang saya ingin mengubah kode untuk memenuhi kebutuhan budaya saya. Tetapi ada beberapa ketidakcocokan!

Pertanyaanku adalah:

Bagaimana Anda berinteraksi dengan ribuan baris kode?

EDIT:

Pintasan apa pun akan menjadi luar biasa!

Anda menambahkan komentar ke kode sumber ketika Anda sudah cukup memahaminya untuk dapat melakukannya. Refactor komentar ini dengan penuh semangat karena Anda semakin mengerti.

1. Langkah melalui kode
2. Ganti nama sesuai kebutuhan
3. Reaktor sesuai kebutuhan
4. Ulangi sampai Anda benar-benar mengerti

... dan kodenya akan berterima kasih untuk itu. ;-)

Ambil satu tindakan, debug (berulang-ulang) kode untuk menemukan bagaimana tindakan itu dilakukan. Tuliskan hal yang sama dalam bahasa sederhana untuk mendapatkan pemahaman yang lebih baik!

Sesuatu yang ditulis Joel Spolsky jauh ketika di blognya (tidak dapat menemukan artikel sekarang) benar-benar terjebak dengan saya mengenai hal ini:

Dia mengatakan bahwa kode bukan bahasa manusia alami, tetapi sebagai programmer, kita dengan mudah terbuai untuk berpikir bahwa itu adalah, dan bahwa kita harus dapat membacanya seperti itu. Akibatnya, banyak dari kita melihat kode baru dan berharap dapat "membacanya" dan memahaminya segera, seolah-olah itu adalah blok teks dalam bahasa Inggris.

Jadi saya pikir kuncinya adalah pada dasarnya hanya lambat, metodis, dan ilmiah. Dan seperti yang orang lain katakan - berkomentar (dan bahkan refactor) saat Anda pergi. Jangan jatuh ke dalam pola pikir "Saya hanya harus melihatnya dan segera mengerti".

Oh, dan ya, kadang-kadang saya masih jatuh ke dalam perangkap ini. "Lakukan apa yang aku katakan, bukan seperti yang aku lakukan", dan semua itu. :)

SE-Radio mewawancarai Dave Thomas tentang hal ini

Episode podcast ini memiliki banyak tips dan teknik untuk memasuki 'budaya' proyek dan memahami bagaimana penduduk asli hidup.

Saya harus melakukan ini baru-baru ini dengan proyek lebih dari 100.000 LOC. Ide pertama saya adalah bahwa lebih mudah untuk melihat pola dari grafik 100 atau bahkan 1000 node daripada dari 100.000 baris teks.

Jadi saya menghabiskan 45 menit dan menulis program Python pendek (<100LOC) untuk menguraikan apa yang saya butuhkan darinya, dan menggambar hubungan objek. Saya menghasilkan sumber Graphviz , yang merupakan bahasa yang sangat mudah untuk dihasilkan. (Tidak ada yang istimewa tentang Python di sini: Ruby atau C # atau Common Lisp atau apa pun yang bisa melakukannya dengan baik.)

Pada proyek lain, saya telah melihat orang menggunakan Graphviz untuk dependensi modul, grafik panggilan, riwayat versi, semua hal. Meta-tool visualisasi program terbaik.

(Mungkin itu karena saya mengambil kompiler , tapi saya merasa aneh bahwa ketika seorang programmer dihadapkan dengan masalah, jawabannya sepertinya selalu "menulis program!", Kecuali ketika masalahnya melibatkan kode sumber ke suatu program.: - )

Melangkahinya di debugger saat berjalan, itu satu-satunya cara untuk memahami basis kode baru yang besar.

Pahami bahwa benar-benar tidak ada jalan pintas untuk mencari sesuatu dengan penuh. (Dan jika Anda memiliki masalah dengan kalimat itu, pendidikan Anda telah diabaikan. Ini berasal dari "Stranger In a Strange Land", oleh Robert A. Heinlein.)

Bacalah, satu halaman setiap kali, satu rutin setiap kali. Tambahkan komentar. Buat gambar struktur data utama. Kenali algoritme. Dapatkan pengetahuan sebelumnya.

Tahan godaan untuk menghidupkan debugger. Area pandang debugger terlalu kecil: Anda melihat satu baris pada satu waktu, tetapi Anda benar-benar tidak melihat ke mana saja Anda pergi atau ke mana Anda pergi.

Apa pun yang Anda lakukan, tuliskan sebanyak mungkin yang Anda bisa, jadi tidak ada yang berakhir di posisi yang sama dengan Anda.

Anda perlu menggunakan petunjuk. dapatkan petunjuk tentang apa yang harus Anda cari dan gunakan fungsionalitas pencarian lingkungan atau IDE Anda secara luas yang dapat membawa Anda ke bagian kode yang diinginkan yang ingin Anda ubah.

membaca 14 ribu baris kode java tidak masuk akal. Fungsionalitas pencarian adalah penyelamat hidup Anda

Orang yang berbeda memiliki gaya belajar yang berbeda, demikian YMMV. Hal pertama yang saya lakukan dalam situasi ini adalah membaca seluruh basis kode setidaknya sekali. Itu memberi saya ide umum di mana semuanya berada. Lalu saya memilih bagian untuk memeriksa lebih detail. Struktur data akan menjadi tempat yang baik untuk memulai. Setelah saya memiliki ide umum tentang apa yang terjadi, saya melakukan hal yang sama dengan bagian lain dari kode yang berinteraksi dengan yang pertama. Setelah iterasi yang cukup, saya memiliki perasaan yang baik tentang bagaimana kode bekerja.

Cara terbaik, karena dengan semua pemrograman tidak hanya potongan besar kode uncommented, adalah memecahnya menjadi beberapa bagian. Ini adalah sesuatu yang harus Anda lakukan di kepala Anda serta secara visual dalam kode. Ini mungkin berarti menambahkan komentar tebal atau banyak jeda baris. Ini membantu sambil menggulirnya untuk melihat bagian-bagiannya. Cobalah untuk menemukan potongan kode logis.

Tentu saja, ketika Anda mengerti sedikit, komentari mereka untuk apa yang Anda tahu pada waktu itu, mungkin mencatat tentang sesuatu yang Anda tidak mengerti.

Saya juga merekomendasikan untuk tidak mencoba memahami seluruh bagian sejak awal. Alih-alih mencoba memahami bagian yang perlu Anda ketahui saat ini dan mengerjakan sisanya nanti.

Saya akan mulai dengan menggunakan Leo Editor dalam mode @shadow dengan menggunakan node kloning secara aktif . Ini memungkinkan seseorang untuk menambahkan catatan dan komentar untuk setiap bagian kode yang sedang dipelajari tanpa mengubah kode , dan anotasi akan selalu dalam konteks, di samping kode yang dibicarakannya. Berikut ini contoh alur kerja dokumen:

Misalnya, ketika saya memperbaiki bug di Leo, saya membuat simpul biasa untuk mewakili bug. Node bug ini adalah pandangan saya tentang semua data dalam kode sumber Leo yang berhubungan dengan bug. Ketika saya menemukan kode yang terkait dengan bug, saya mengkloning node mereka dan memindahkannya di bawah bug bug. Saya juga akan menambahkan node biasa sebagai anak-anak dari node bug. Node-node ini berisi laporan bug asli, deskripsi bagaimana saya memperbaiki bug, data pengujian, atau catatan lain yang mungkin ingin saya simpan.

Setelah saya membuat simpul bug, saya hanya berkonsentrasi pada simpul itu dan anak-anaknya. Saya dapat memeriksa node bug dan anak-anaknya tanpa harus melompat keluar garis besar. Semua yang saya butuhkan ada di satu tempat. Ketika saya benar-benar memperbaiki bug saya bisa melakukannya dengan mengubah klon. Sekali lagi, saya tidak harus melompati garis besar. Tidak masalah seberapa besar atau kompleks keseluruhan garis besarnya: Saya hanya berurusan dengan simpul bug dan anak-anaknya. Fokus yang sangat sempit ini membuatnya lebih mudah untuk memperbaiki bug.

Gambar diagram sumber: hubungan data, hubungan fungsional, hubungan objek. Tentukan agregasi, aliran data, dan aliran kode. Gambar jauh lebih baik daripada komentar untuk ini, dan dapat dipisahkan dari kode.

Sebelum Anda refactor apa pun menulis tes. Banyak tes. Tes yang sangat spesifik untuk blok kecil kode yang setidaknya dapat dipanggil, karena akan tergantung pada bagaimana kekacauan yang Anda warisi ditulis.

Keuntungan dari menulis tes untuk memulai adalah bahwa Anda harus memiliki semacam pemahaman kode sebelum Anda bisa mengujinya, sehingga setiap tes yang Anda tulis semoga akan sedikit pengetahuan yang diperoleh. Anda juga dapat sangat mengomentari tes dengan asumsi Anda di samping asersi.

Dengan melakukan tes terlebih dahulu, Anda tidak berisiko mengubah sesuatu dalam kode yang memiliki efek knock-on yang tidak dapat Anda ketahui. Anda juga akan memiliki jaring pengaman ketika Anda datang untuk memperbaiki kode.

Saya menggunakan alat seperti doxygen, untuk menghasilkan diagram kelas secara keseluruhan, daripada menambahkan pemahaman saya tentang apa yang dilakukan masing-masing kelas.

Lalu saya mengambil beberapa bug mudah dari antrian bug (sebelum manajer saya memberikan bug yang sulit kepada saya: P), kemudian jalankan melalui fungsi itu ke debugger dan mencoba untuk menghasilkan aliran data kasar atau model aliran kode.

Misalnya fungsi ekspor di beberapa perangkat lunak: jadi saya mencoba memahami bagaimana sumber data dibaca, dari mana dalam kode (antarmuka dasar) saya dapat mengevaluasi data yang dibaca dengan benar menggunakan kelas saya dan diagram alir kode, kelas mana yang bertanggung jawab untuk jenis ekspor, dll. Saya pikir setengah dari pemahaman dilakukan, setelah Anda memiliki diagram kelas dan diagram alir.

Dekati cacat sepele, misalnya NullPointerException. Hindari segala sesuatu tentang konkurensi pada awalnya, apa pun yang pada dasarnya akan melibatkan pemahaman banyak kode sekaligus.

Setelah Anda memperbaiki beberapa bug, Anda mungkin akan memiliki ide yang cukup bagus. Bagaimanapun juga, ini bekerja untuk saya.

Pada dasarnya tindakan untuk menulis kode bersih harus dimulai langsung dari desain. Jika kami membuat kode dalam bahasa OOP, buatlah UML, bagikan dengan rekan-rekan dan yakinlah bahwa desain tidak ambigu. Bagaimanapun kami pengembang harus yakin bahwa desain menyelesaikan masalah dan bukan ambiguo.

Ketika datang ke pengkodean kita harus memastikan desain dikonversi menjadi kode yaitu Entitas ke kelas atau struct, operasi untuk berfungsi dll.

Dan saya membaca kertas putih http://queue.acm.org/detail.cfm?id=2063168 yang membahas tentang gaya pengkodean atau bagaimana kita dapat menggunakan ruang, lekukan, variasi font karena kebanyakan IDE dapat kita gunakan untuk menulis BANYAK Kode CLEANER di mana kita manusia dapat memahami sebanyak mesin lakukan. Ini lebih menekankan pada penulisan kode bebas komentar sehingga kode kita akan muncul sebagai paragraf itu sendiri.