it-swarm-id.com

Bagaimana Anda menyelam ke basis kode besar?

Alat dan teknik apa yang Anda gunakan untuk menjelajahi dan mempelajari basis kode yang tidak dikenal?

Saya memikirkan alat-alat seperti grep, ctags, unit-tes, tes fungsional, generator diagram-kelas, grafik panggilan, metrik kode seperti sloccount, dan seterusnya. Saya akan tertarik dengan pengalaman Anda, pembantu yang Anda gunakan atau tulis sendiri dan ukuran basis kode yang digunakan untuk bekerja.

Saya menyadari bahwa berkenalan dengan basis kode adalah proses yang terjadi dari waktu ke waktu, dan keakraban dapat berarti apa saja dari "Saya dapat meringkas kode" hingga "Saya dapat memperbaiki dan mengecilkannya hingga 30% dari ukuran". Tetapi bagaimana cara memulai?

145
miku

yang selalu saya lakukan adalah sebagai berikut:

Buka banyak salinan editor saya (Visual Studio/Eclipse/Apapun) dan kemudian debug dan lakukan jeda baris langkah melalui kode. Cari tahu alur kode, susun jejak untuk melihat di mana titik-titik kunci berada dan pergi dari sana.

Saya bisa melihat metode demi metode - tapi itu bagus jika saya bisa mengklik sesuatu dan kemudian melihat di mana dalam kode itu dieksekusi dan ikuti. Mari saya merasakan bagaimana pengembang ingin semuanya bekerja.

55
ist_lion

Bagaimana kamu memakan se ekor gajah?

Satu gigitan sekaligus :)

Serius, saya mencoba berbicara dengan penulis kode terlebih dahulu.

64
user2567

Apakah saya harus meretas sampai saya menyelesaikan pekerjaan

Sebagian besar, ya (maaf).

Pendekatan yang mungkin Anda pertimbangkan:

  1. Coba cari tahu apa yang seharusnya dilakukan kode, dalam istilah bisnis.
  2. Baca semua dokumentasi yang ada, tidak peduli seberapa buruk itu.
  3. Bicaralah dengan siapa pun yang mungkin tahu sesuat tentang kode.
  4. Langkah melalui kode di debugger.
  5. Perkenalkan perubahan kecil dan lihat apa yang rusak.
  6. Buat perubahan kecil pada kode untuk membuatnya lebih jelas.

Beberapa hal yang saya lakukan untuk mengklarifikasi kode adalah:

  1. Jalankan prettifier kode untuk memformat kode dengan baik.
  2. Tambahkan komentar untuk menjelaskan apa yang menurut saya mungkin dilakukan
  3. Ubah nama variabel untuk membuatnya lebih jelas (menggunakan alat refactoring)
  4. Menggunakan alat yang menyoroti semua penggunaan simbol tertentu
  5. Mengurangi kekacauan dalam kode - kode komentar, komentar tidak berarti, inisialisasi variabel tidak berguna dan sebagainya.
  6. Ubah kode untuk menggunakan konvensi kode saat ini (sekali lagi menggunakan alat refactoring)
  7. Mulai mengekstrak fungsionalitas ke dalam rutinitas yang bermakna
  8. Mulailah menambahkan tes jika memungkinkan (tidak sering mungkin)
  9. Singkirkan angka ajaib
  10. Mengurangi duplikasi jika memungkinkan

... dan peningkatan sederhana apa pun yang dapat Anda lakukan.

Secara bertahap, makna di balik itu semua harus menjadi lebih jelas.

Adapun tempat untuk memulai? Mulailah dengan apa yang Anda ketahui. Saya menyarankan input dan output. Anda sering bisa mendapatkan pegangan tentang apa yang seharusnya dan untuk apa mereka digunakan. Ikuti data melalui aplikasi dan lihat kemana ia pergi dan bagaimana itu diubah.

Salah satu masalah yang saya miliki dengan semua ini adalah motivasi - itu bisa menjadi kerja keras yang nyata. Ini membantu saya untuk memikirkan seluruh bisnis sebagai sebuah teka-teki, dan untuk merayakan kemajuan yang saya buat, tidak peduli seberapa kecil.

39
Kramii

Situasi Anda sebenarnya umum. Siapa pun yang harus masuk ke pekerjaan baru di mana ada kode yang ada untuk bekerja akan berurusan dengan beberapa elemen itu. Jika sistem ini adalah sistem warisan yang benar-benar jahat, maka sangat mirip dengan apa yang telah Anda jelaskan. Tentu saja, tidak pernah ada dokumentasi saat ini.

Pertama, banyak yang merekomendasikan Bekerja Efektif dengan Legacy Code oleh Michael Feathers. Ini memang buku yang bagus, dengan bab-bab berguna seperti "Saya tidak bisa membuat kelas ini menjadi test harness" atau "Aplikasi saya tidak memiliki struktur" meskipun terkadang Feathers hanya dapat menawarkan lebih banyak simpati daripada solusi. Secara khusus, buku dan contoh-contohnya sebagian besar ditujukan untuk mengeriting bahasa. Jika Anda bekerja dengan prosedur SQL keriput mungkin tidak cukup berguna. Saya pikir bab ini, "Saya tidak mengerti kode ini cukup baik untuk mengubahnya," berbicara tentang masalah Anda. Feathers menyebutkan di sini hal-hal yang jelas seperti mencatat dan menandai daftar, tetapi juga menunjukkan bahwa Anda dapat menghapus kode yang tidak digunakan jika Anda memiliki kontrol sumber. Banyak orang meninggalkan bagian kode yang dikomentari, tetapi itu sering kali tidak membantu.

Selanjutnya, saya pikir pendekatan yang Anda sarankan tentu saja merupakan langkah yang baik. Anda harus memahami terlebih dahulu pada level tinggi apa tujuan kode tersebut.

Pasti bekerja dengan seorang mentor atau seseorang di tim jika Anda harus mendapatkan pertanyaan dijawab.

Juga, ambil kesempatan untuk mendukung kode jika cacat terungkap (meskipun terkadang Anda tidak perlu menjadi sukarelawan untuk ini ... cacat tersebut akan menemukan Anda!). Pengguna dapat menjelaskan untuk apa mereka menggunakan perangkat lunak dan bagaimana cacat memengaruhi mereka. Itu bisa menjadi sedikit pengetahuan yang sangat berguna ketika mencoba memahami arti dari perangkat lunak. Selain itu, masuk ke kode dengan target serangan yang disengaja terkadang dapat membantu memfokuskan Anda saat menghadapi "the beast."

32
Bernard Dy

Saya suka melakukan hal berikut ketika saya memiliki file sumber yang sangat besar:

  • Salin seluruh kekacauan ke papan klip
  • Rekatkan ke Word/textmate apa pun
  • Kurangi ukuran font seminimal mungkin.
  • Gulir ke bawah melihat pola dalam kode

Anda akan kagum melihat betapa anehnya kode ini terlihat ketika Anda kembali ke editor normal Anda.

13
sal

Ini membutuhkan waktu

Jangan merasa terlalu tergesa-gesa saat mencoba memahami basis kode warisan, terutama jika itu menggunakan teknologi/bahasa/kerangka kerja yang tidak Anda kenal. Itu hanya kurva belajar yang tidak dapat dihindari yang membutuhkan waktu.

Salah satu pendekatan adalah bolak-balik antara kode dan tutorial tentang teknologi terkait. Anda membaca/menonton tutorial, lalu melihat kode untuk melihat bagaimana pendahulu Anda melakukannya, mencatat persamaan dan perbedaan, membuat catatan, dan mengajukan pertanyaan kepada pengembang yang ada.

"Mengapa kamu melakukan bagian ini dengan cara ini"

"Saya perhatikan sebagian besar orang daring melakukannya dengan cara ini, dan Anda semua melakukannya dengan cara lain. Mengapa demikian?"

"Apa yang membuat kalian semua memilih teknologi X daripada teknologi Y?"

Jawaban atas pertanyaan-pertanyaan ini akan membantu Anda memahami sejarah proyek dan alasan di balik keputusan desain dan implementasi.

Akhirnya, Anda akan merasa cukup akrab dengannya sehingga Anda dapat mulai menambahkan/memperbaiki sesuatu. Jika semuanya tampak membingungkan atau sepertinya ada terlalu banyak "keajaiban" yang terjadi, Anda belum menghabiskan cukup waktu untuk mencarinya, mencernanya, dan membuat diagramnya. Membuat diagram (diagram urutan, diagram alur proses, dll.) Adalah cara yang bagus bagi Anda untuk memahami proses yang kompleks, ditambah lagi mereka akan membantu "orang berikutnya".

12
CFL_Jeff

cscope dapat melakukan apa pun yang bisa dilakukan ctag untuk C, plus, ia juga dapat membuat daftar tempat semua fungsi saat ini dipanggil. Plus itu sangat cepat. Timbangan mudah ke jutaan LOC. Terintegrasi dengan rapi ke emacs dan vim.

Penghitung Kode C dan C++ - cccc dapat menghasilkan metrik kode dalam format html. Saya telah menggunakan wc juga untuk mendapatkan LOC.

doxygen dapat menghasilkan sintaks yang disorot dan kode referensi silang dalam html. Berguna dalam menjelajah basis kode besar.

9
aufather

Cara saya merekomendasikan dengan Drupal dan itu tidak benar-benar Drupal spesifik: mulai dengan pelacak masalah. Pasti akan ada laporan bug lama, tidak tertutup, pasti. Bisakah Anda melakukannya?) mereproduksi mereka? Jika ya, perbarui tiket mengkonfirmasinya. Jika tidak, tutuplah. Anda akan menemukan cara ini satu ton cara untuk menggunakan perangkat lunak dan Anda dapat mulai mengintip ke dalam basis kode di mana ia crash. Atau Anda dapat mulai melangkah melalui kode dan melihat bagaimana itu tiba di tempat ia crash. Dengan cara ini Anda tidak hanya akan mulai memahami basis kode tetapi juga mengumpulkan satu ton karma dan pertanyaan Anda akan disambut hangat oleh masyarakat.

8
chx

Satu hal penting yang harus dilakukan adalah menggunakan tooling untuk menghasilkan grafik dependensi untuk mengeksplorasi top-down arsitektur kode. Pertama visualisasikan grafik antara .NET rakitan atau guci, ini akan memberi Anda ide tentang bagaimana fitur dan lapisan diatur, kemudian Gali ke dalam dependensi namespaces (di dalam satu atau beberapa kerabat. Rakitan atau guci NET) untuk memiliki gagasan kode berbutir halus. struktur dan akhirnya Anda bisa melihat dependensi kelas untuk memahami bagaimana sekumpulan kelas berkolaborasi untuk mengimplementasikan fitur. Ada beberapa alat untuk menghasilkan grafik dependensi, seperti NDepend for .NET misalnya, yang menghasilkan grafik di bawah ini.

enter image description here

Saya pernah memiliki insinyur perangkat lunak yang cukup fantastis memberi tahu saya bahwa bentuk analisis dan pemeliharaan kode yang paling mahal adalah berjalan melalui kode, baris demi baris; tentu saja, kita adalah programmer, dan itu cukup banyak dengan pekerjaan itu. Media bahagia, saya pikir, adalah untuk (dalam urutan ini): 1. Dapatkan notebook untuk membuat catatan tentang bagaimana Anda memahami kode untuk bekerja, dan menambahkannya seiring berjalannya waktu 2. Lihat dokumentasi tentang kode 3. Bicaralah dengan penulis atau orang lain yang telah mendukung basis kode. Minta mereka untuk "brain dump" 4. Jika Anda sampai pada titik di mana Anda memahami beberapa hubungan kelas tingkat detail, lakukan beberapa langkah-debugging kode untuk melakukan beberapa sintesis antara bagaimana Anda berpikir kode bekerja dan bagaimana kode sebenarnya bekerja.

5
Tim Claason

Pertama-tama pahami apa yang seharusnya dilakukan - tanpanya itu mungkin omong kosong. Bicaralah kepada pengguna, baca manual, apa pun.

Kemudian tekan jalankan dan mulai berjalan kode untuk apa yang tampaknya menjadi fungsi utama.

5
Jon Hopkins

Memecah dan menaklukkan. Saya melihat setiap fungsi dan kode yang terkait, melangkah melaluinya dan melanjutkan ke yang berikutnya, perlahan-lahan membangun gambaran keseluruhan.

Jika proyek ini memiliki unit test, saya juga suka melaluinya, mereka selalu sangat terbuka dan memberi pencerahan.

3
aredkid
  1. Jalankan semua tes, jika ada, dan lihat kode mana yang dicakup dan mana yang tidak.
  2. Jika kode yang perlu Anda ubah tidak tercakup, cobalah menulis tes untuk menutupnya.
  3. Ubah kodenya. Jangan hancurkan tes.

Lihat Michael Feathers 'Bekerja Efektif dengan Legacy Code

3
kevin cline

Inilah daftar pendek saya:

  1. Jika memungkinkan, mintalah seseorang memberikan tampilan kode tingkat tinggi. Pola apa yang dipertimbangkan, konvensi macam apa yang dapat saya harapkan untuk dilihat, dll. Ini mungkin memiliki beberapa putaran untuk itu karena pada awalnya saya akan mendapatkan satu cerita bahwa ketika saya menjadi lebih akrab dengan kode, saya mungkin memiliki pertanyaan baru untuk bertanya ketika saya bekerja melalui bawang dari proyek yang sudah ada sebelumnya.

  2. Jalankan kode dan lihat seperti apa sistem itu. Memang itu mungkin memiliki lebih dari beberapa bug, tetapi ini dapat berguna untuk mendapatkan ide tentang apa yang dilakukannya. Ini bukan tentang mengubah kode, tetapi hanya melihat bagaimana ini berjalan. Bagaimana berbagai bagian cocok menjadi sistem secara keseluruhan?

  3. Cari tes dan indikator lain dari dokumentasi dasar yang dapat membantu dalam membangun model mental internal kode. Di sinilah saya mungkin menyarankan setidaknya beberapa hari kecuali ada sangat sedikit dokumentasi dan tes tentu saja.

  4. Seberapa baik saya tahu bahasa dan kerangka kerja yang digunakan dalam proyek ini? Pentingnya di sini adalah perbedaan antara melihat beberapa hal dan pergi, "Ya, melihat itu belasan kali sebelumnya dan mengetahuinya dengan cukup baik," dan "Apa yang sedang diupayakan di sini? Siapa yang mengira ini adalah ide yang bagus?" jenis pertanyaan yang walaupun saya tidak akan mengatakannya dengan keras, saya akan memikirkan mereka terutama jika saya melihat kode warisan yang mungkin sangat rapuh dan orang-orang yang menulisnya tidak tersedia atau tidak ingat mengapa hal-hal dilakukan sebagaimana adanya. Untuk area baru, mungkin bermanfaat untuk menghabiskan waktu ekstra untuk mengetahui apa struktur dan pola apa yang dapat saya temukan dalam kode ini.

Last but not least: Ketahui harapan mereka yang menjalankan proyek dalam hal apa yang seharusnya Anda lakukan di setiap titik waktu, mengingat beberapa ide berikut dari apa yang mungkin diharapkan:

  • Apakah Anda memasukkan fitur baru?
  • Apakah Anda memperbaiki bug?
  • Apakah Anda kode refactoring? Apakah standar baru bagi Anda atau mereka sangat akrab?
  • Apakah Anda seharusnya membiasakan diri dengan basis kode?
3
JB King

Saya akan mengatakan untuk memulai dengan dokumentasi, dll., Tetapi dalam pengalaman saya, kedalaman dokumentasi dan pengetahuan lokal sering berbanding terbalik dengan usia, ukuran dan kompleksitas sistem.

Yang sedang berkata, saya biasanya mencoba mengidentifikasi beberapa utas fungsional. Secara fungsional, saya maksudkan hal-hal seperti masuk, menarik daftar pelanggan, dll. Jika polanya konsisten sama sekali, satu utas akan memberi Anda bagian sistem yang bagus, belum tentu lengkap. Cara terbaik untuk menentukan apakah polanya konsisten adalah dengan menganalisis beberapa utas.

Saya pikir ini tidak perlu dikatakan tetapi, menurut saya, lebih baik untuk memahami sistem dari perspektif fungsional daripada dari perspektif teknis. Saya biasanya tidak terlalu khawatir tentang alat-alat yang digunakan (ORM, log logging, dll.) Dan lebih fokus pada pola (MVP, dll.) Yang sedang digunakan. Dalam pengalaman saya, alat umumnya lebih cair daripada pola.

2
Casey

Cetak kode sumber dan mulailah membacanya. Jika ukurannya sangat besar, cetak saja bagian-bagian tertentu untuk lebih memahami dan membuat sebanyak mungkin catatan/komentar yang Anda butuhkan.

Lacak melalui program mulai dari awal pelaksanaannya. Jika Anda ditugaskan ke bagian tertentu dari basis kode, lacak eksekusi di dalam bagian itu dan cari tahu struktur data apa yang digunakan.

Jika Anda menggunakan bahasa berorientasi objek, cobalah membuat diagram kelas umum. Ini akan memberi Anda gambaran tingkat tinggi yang baik.

Sayangnya, pada akhirnya, Anda harus membaca kode sebanyak mungkin. Jika Anda beruntung, pemrogram sebelumnya telah menulis sebanyak mungkin dokumentasi untuk membantu Anda memahami apa yang sedang terjadi.

2
Rudolf Olah

Saya selalu mencoba dan mulai dengan titik masuk ke dalam program, karena semua program memiliki satu (misalnya metode utama, kelas utama, init, dll). Ini kemudian akan mengarahkan saya ke apa yang memulai dan kadang-kadang bagaimana hal-hal terkait.

Setelah itu saya menelusuri. Basis data dan DAO dikonfigurasikan di suatu tempat, jadi saya bisa merasakan bagaimana hal-hal disimpan. Mungkin semacam kelas instance global juga dimulai, dan di sana saya bisa mencari tahu apa yang sedang disimpan. Dan dengan alat refraktori yang bagus, saya bisa mengetahui siapa yang memanggil apa.

Saya kemudian mencoba dan menemukan di mana antarmuka dikonfigurasi dan ditangani, karena ini adalah titik masuk berikutnya dari informasi. Alat pembiasan, pencarian, dan debugging membantu dalam pencarian saya. Saya kemudian bisa mencari tahu di mana penanganan informasi dimulai dan berakhir, bekerja dengan cara saya melalui semua file kelas.

Saya kemudian mencoba dan menulis aliran di atas kertas, hanya untuk membungkus kepala saya di sekitar hal-hal. Tombol kirim lolos ke verifikasi umum yang kemudian diteruskan ke DAO atau database dan kemudian disimpan dalam database. Ini adalah penyederhanaan besar pada sebagian besar aplikasi, tetapi ini adalah ide umum. Pena dan kertas sangat membantu di sini, karena Anda dapat mencatat semuanya dengan cepat dan tidak perlu khawatir tentang pemformatan dalam program yang seharusnya membantu Anda.

2
TheLQ

Beberapa hal yang saya lakukan ...

1) Gunakan alat analisis sumber seperti Monitor Sumber untuk menentukan berbagai ukuran modul, metrik kompleksitas dll. Untuk memahami proyek dan membantu mengidentifikasi area yang tidak sepele.

2) Bor melalui kode atas ke bawah di Eclipse (baik untuk memiliki editor yang dapat menelusuri referensi, dll.) Sampai saya mengetahui apa yang terjadi dan di mana di basis kode.

3) Kadang-kadang, saya menggambar diagram dalam Visio untuk mendapatkan gambar arsitektur yang lebih baik. Ini dapat bermanfaat bagi orang lain di proyek ini juga.

2
JeffV

Hal pertama yang perlu Anda lakukan ketika mempelajari basis kode baru adalah belajar tentang apa yang seharusnya dilakukan, bagaimana penggunaannya, dan bagaimana menggunakannya. Kemudian mulai melihat dokumentasi arsitektur untuk mempelajari bagaimana kode ditata, juga lihat bagaimana database pada saat ini. Pada saat yang sama Anda belajar arsitektur waktu yang baik untuk meninjau setiap aliran proses atau menggunakan dokumen kasus. kemudian mulai menyelam dan membaca kode setelah Anda memahami gambaran besarnya, tetapi hanya kode yang terkait dengan pekerjaan apa pun yang Anda lakukan pada kode ini, jangan hanya mencoba membaca semua kode. Lebih penting untuk mengetahui di mana kode itu harus melakukan X daripada bagaimana tepatnya X dilakukan, kode itu selalu ada untuk memberi tahu Anda bagaimana jika Anda dapat menemukannya.

Saya menemukan bahwa hanya mencoba untuk melompat dan membaca kode tanpa tujuan di luar belajar kode umumnya tidak produktif, mencoba melakukan perubahan kecil sendiri atau meninjau kode perubahan orang lain adalah penggunaan waktu Anda yang jauh lebih produktif.

2
Ryathal

Jika basis kode besar, maka fokuskan perhatian Anda ke bagian yang sedang dikerjakan. Kalau tidak, Anda akan merasa kewalahan dan mungkin kepala Anda akan meledak. Saya pikir beberapa ikhtisar tingkat tinggi sangat membantu (jika tersedia), tetapi kemungkinan Anda akan menghabiskan banyak waktu di debugger untuk mengikuti alur program. Merupakan ide bagus untuk mendapatkan gambaran umum aplikasi dan melihatnya digunakan, sehingga Anda dapat memahami bagaimana/apa/mengapa kode tersebut digunakan.

Saya biasanya menjalankan semacam alat kompleksitas kode pada kode untuk memberi tahu saya di mana area masalahnya. Area yang mendapat skor tinggi mungkin sangat sulit untuk diperbarui. Misalnya, saya mengalami fungsi yang mencetak 450 pada skala siklomatik. Benar saja, ratusan IF. Sangat sulit untuk mempertahankan atau mengubahnya. Jadi bersiaplah untuk yang terburuk.

Juga, jangan takut untuk bertanya kepada pengembang yang ada, terutama jika mereka bekerja pada sistem. Simpan pikiran internal Anda untuk diri sendiri dan fokus untuk menyelesaikan masalah. Hindari komentar yang dapat membuat pengembang lain menjadi kesal. Bagaimanapun, itu mungkin bayi mereka dan tidak ada yang suka diberi tahu bahwa bayi mereka jelek.

Ambil langkah kecil, bahkan perubahan kode terkecil pun bisa berdampak besar.

Saya merasa sangat membantu untuk menghasilkan aliran kode program jadi jika saya membuat perubahan, saya dapat melakukan pencarian ketergantungan untuk melihat metode/fungsi apa yang memanggil apa. Misalkan saya mengubah metode C.

Jika hanya 1 metode/fungsi yang memanggil C, maka itu adalah perubahan yang cukup aman. Jika 100-an metode/fungsi memanggil C, maka itu akan berdampak lebih besar.

Semoga basis kode Anda dirancang dengan baik, ditulis, dan dipelihara. Jika demikian, perlu waktu untuk memahaminya tetapi akhirnya gelombang akan berbalik.

Jika itu adalah bola lumpur yang besar, Anda mungkin tidak akan pernah mengerti (atau ingin memahami) cara kerjanya.

2
Jon Raynor

Saya melakukan begitu banyak ...

Inilah pendekatan saya saat ini untuk situasi ketika ada "sesuatu yang berfungsi", dan Anda harus membuatnya "bekerja dengan cara lain".

  1. Dapatkan tujuan, sistem itu harus menyelesaikannya (jika tidak tertulis) - tulislah. Tanyakan manajer, karyawan lain, bahkan mantan jika mereka tersedia. Tanyakan kepada pelanggan atau cari dokumentasi apa pun.
  2. Dapatkan spesifikasi. Jika tidak ada - tulislah. Tidak ada gunanya meminta seseorang untuk itu, seolah-olah itu tidak ada, maka Anda berada dalam situasi ketika orang lain tidak peduli. Jadi hanya cara menulis sendiri (nantinya akan lebih mudah merujuknya).
  3. Dapatkan desain. Tidak ada - tulis Cobalah untuk merujuk pada dokumen dan kode sumber apa pun sebanyak mungkin.
  4. Tulis desain terperinci untuk bagian yang perlu Anda ubah.
  5. Tentukan bagaimana Anda mengujinya. Jadi Anda bisa yakin bahwa kode lama dan baru bekerja dengan cara yang sama.
  6. membuat sistem dapat dibangun dalam satu langkah. Dan uji dengan kode lama. Masukkan ke SVC jika belum.
  7. Terapkan perubahan. Tidak lebih awal.
  8. verifikasi setelah sebulan atau lebih, bahwa tidak ada yang rusak.

Satu lagi opsi opsional yang mungkin memerlukan di antara setiap langkah: f off manager (pemilik proyek) yang memberi tahu Anda bahwa "perubahan ini harus sudah dilakukan kemarin". Setelah beberapa proyek, ia bahkan dapat mulai membantu mendapatkan spesifikasi dan dokumen terlebih dahulu.

Tapi biasanya (terutama untuk skrip) tidak mungkin dalam lingkup bisnis (biaya akan terlalu tinggi, sementara nilainya akan rendah). Salah satu opsi adalah tidak melakukan perubahan apa pun, sampai masa kritis tercapai, dan sistem mati dari produksi (mis. Sistem baru akan datang) atau manajemen memutuskan bahwa semua ini layak dilakukan.

PS: Saya ingat satu kode yang digunakan untuk 5 klien dengan pengaturan yang berbeda. Dan setiap perubahan (fitur baru) diharuskan untuk memikirkan "bagian apa yang digunakan", dan "konfigurasi apa yang dimiliki klien" sehingga tidak mengubah apa pun, dan bukan pada kode copypaste. Menempatkan pengaturan mereka ke cv proyek, dan menulis spesifikasi, mengurangi waktu berpikir ini hampir menjadi 0.

2

Tidak akan ada dokumentasi atau dokumentasi minim, atau akan ketinggalan zaman. Temukan semua dokumentasi yang ada. Jika ada di repositori tim, jangan membuat salinan. Jika tidak, letakkan di sana dan minta izin manajer Anda untuk mengaturnya, mungkin dengan pengawasan.

Dapatkan semuanya dalam repositori untuk tim dan tambahkan Glosarium. Semua pangkalan memiliki jargon; mendokumentasikannya dalam glosarium. Buat bagian untuk alat, produk, khusus pelanggan, dll.

Buat/Perbarui dokumen pembuatan lingkungan perangkat lunak. Semua alat, kebiasaan, pilihan pemasangan, dll. Buka di sini.

Kemudian unggah dokumen Memulai Dengan "ProductName" atau sejenisnya. Biarkan itu hanya aliran pikiran dan pengaturan diri seiring waktu. Kemudian, lihat dokumen yang ketinggalan jaman dan kembalikan ke tanggal. Pengembang lain akan menghargai itu, Anda akan berkontribusi dengan cara yang unik saat mempelajari kode. Terutama mendokumentasikan semua hal seperti itu yang membuat Anda salah atau disebut salah atau kontra-intuitif.

Setelah kurva condong Anda berakhir, jangan khawatir tentang memperbarui dokumentasi. Biarkan pria baru berikutnya melakukan itu. Ketika dia tiba, arahkan dia ke pekerjaan Anda. Ketika dia terus-menerus mengganggumu untuk jawaban, jangan jawab dia. Sebaliknya, tambahkan pertanyaan ke dokumentasi Anda dan kemudian berikan urlnya. Alat pancing.

Salah satu efek sampingnya adalah Anda akan membuat alat yang Anda sendiri dapat rujuk berbulan-bulan dari sekarang ketika Anda lupa.

Dan meskipun ini bukan dokumentasi, masalah terkait adalah prosedur aneh dan intensif yang dilakukan oleh rekan setim Anda. Otomatiskan dengan batch, skrip sql dan sejenisnya, dan bagikan juga. Bagaimanapun, pengetahuan prosedural bisa dibilang sebesar pengetahuan deklaratif dalam hal menjadi produktif di lingkungan baru. Apa pun itu, jangan lakukan itu; alih-alih, buat skrip, dan jalankan skrip. Pancing menyerang lagi.

1
toddmo

Ini sering terjadi. Sampai saya mulai bekerja pada platform open source saya tidak berpikir saya pernah memulai pekerjaan yang tidak dimulai dengan pengakuan bahwa kode memiliki beberapa 'kebiasaan'.

Anda bisa mendapatkan jalan panjang dengan langkah debugger dan banyak kegigihan. Sayangnya sering kali butuh waktu dan pengalaman untuk mempelajari bola besar tertentu dari lumpur dan bahkan setelah bertahun-tahun masih ada beberapa subsistem yang muncul yang tidak diketahui oleh siapa pun.

1
Jeremy French

Saya pikir salah satu hal terpenting adalah mengambil fitur sederhana, memilih yang paling sederhana yang dapat Anda pikirkan, dan mengimplementasikannya. Jika ada daftar keinginan yang dikelola gunakan itu atau berbicara dengan seseorang yang akrab dengan basis kode dan minta mereka untuk menyarankan fitur. Biasanya saya berharap ini menjadi perubahan dengan 5 ~ 20 LOC. Poin penting bukanlah bahwa Anda menambahkan fitur yang sangat mewah tetapi Anda sedang bekerja (atau lebih tepatnya bergulat :)) dengan basis kode dan melalui seluruh alur kerja. Anda harus melakukannya

  1. Baca kode untuk memahami komponen yang Anda modifikasi
  2. Ubah kode dan pahami bagaimana hal itu berdampak pada sistem di sekitarnya.
  3. Uji perubahan dan dengan demikian mengidentifikasi bagaimana komponen berinteraksi satu sama lain
  4. Tulis test case dan semoga memecahkan satu atau dua test case sehingga Anda bisa memperbaikinya dan memahami invarian dari sistem.
  5. Bangun benda itu atau lihat CI membangunnya lalu kirimkan

Daftarnya berjalan tetapi intinya adalah bahwa proyek mini seperti ini akan membawa Anda melalui semua item pada daftar periksa Anda untuk berkenalan dengan suatu sistem dan juga menghasilkan perubahan produktif yang dilakukan.

1
Osada Lakmal

Satu hal kecil yang ingin saya tambahkan:

Salah satu alat yang saya mulai gunakan baru-baru ini untuk masalah seperti ini yang telah banyak membantu adalah pemetaan pikiran. Alih-alih mencoba menjejalkan semua detail tentang bagaimana sesuatu diterapkan di kepala saya, saya akan membangun mindmap yang menggambarkan bagaimana sistem yang saya lalui bekerja. Ini benar-benar membantu saya lebih memahami apa yang sedang terjadi dan apa yang masih perlu saya pikirkan. Ini juga membantu saya melacak apa yang perlu saya ubah pada skala yang sangat tepat.

Saya sarankan menggunakan pesawat gratis di antara kebanyakan pilihan pemetaan pikiran.

1
c.hughes

Saya menulis posting yang cukup panjang tentang topik ini. Berikut ini kutipannya

Saya memikirkan masalah ini cukup lama. Saya memutuskan untuk menulis solusi pribadi saya sebagai proses umum. Langkah-langkah yang saya dokumentasikan adalah sebagai berikut:

  1. Buat Lembar Kosakata
  2. Pelajari Aplikasi
  3. Jelajahi Dokumentasi yang Tersedia
  4. Buat Asumsi
  5. Temukan Perpustakaan Pihak Ketiga
  6. Analisis Kode

Proses ini ditulis dalam konteks aplikasi desktop besar, tetapi teknik umum masih berlaku untuk aplikasi web, dan modul yang lebih kecil.

diambil dari: Proses Untuk Mempelajari Kode Bar

1
Lars

Ada beberapa tips kecil yang bisa saya bagikan.

Untuk produk yang sudah ada, saya mulai mengujinya secara intensif. Jika memilih/ditugaskan tugas, saya akan lebih fokus pada fitur tertentu.

  • Langkah selanjutnya adalah menemukan kode di mana saya dapat membobolnya dan mulai menjelajahi Di jalan saya akan menemukan modul tergantung, perpustakaan, kerangka kerja dll.

  • Langkah selanjutnya adalah membuat diagram kelas sederhana dengan tanggung jawabnya (Seperti kartu CRC)

  • Mulai lakukan perubahan kecil atau lakukan bug kecil untuk diperbaiki dan dilakukan. Jadi kita bisa mempelajari alur kerja proyek; bukan hanya kode. Seringkali produk besar akan memiliki semacam pembukuan demi otorisasi dan audit (mis. Proyek perawatan kesehatan)

  • Berbicaralah dengan orang-orang yang sudah mengerjakan proyek. Ekspresikan ide, pikiran, dan sebagai gantinya, dapatkan pengalaman dan pandangan mereka tentang bekerja dengan proyek ini untuk waktu yang lama. Ini cukup penting karena itu juga membantu Anda bergaul dengan tim dengan baik.

1
sarat

Saya mendorong Anda untuk menulis unit test sebelum Anda mengubah apa pun di bola lumpur. Dan hanya cukup ubah kode pada saat tes lulus. Saat Anda refactor, tambahkan tes unit sebelumnya sehingga Anda tahu bahwa fungsi bisnis belum rusak oleh refactoring.

Apakah pair memprogram opsi? Memiliki orang lain untuk memantulkan ide adalah ide bagus untuk menghadapi jumlah yang tidak menyenangkan itu.

1
David Weiser

Berikut adalah prosedur yang kami gunakan untuk menghilangkan duplikat.

  • pilih awalan komentar standar untuk duplikat (kami menggunakan [dupe] tepat setelah penanda komentar;
  • tulis spesifikasi dengan tim Anda tentang nama yang akan digunakan untuk prosedur duplikat;
  • putaran pertama: semua orang mengambil beberapa file, dan menambahkan [dupe][procedure_arbitrary_name] sebelum prosedur digandakan;
  • putaran kedua: semua orang mengambil prosedur, atau bagian dari prosedur, dan memberikan nilai yang menunjukkan urutan disukai dari implementasi tujuan yang berbeda yang berbeda (string kemudian akan menjadi: [dupe][procedure_arbitrary_name][n]);
  • ronde ketiga: yang bertanggung jawab untuk setiap prosedur menulis ulang di kelas yang relevan;
  • ronde keempat: grep senang!
1
cbrandolino

Sudah lama sejak saya harus menyelam ke basis kode besar sendiri. Tetapi dalam beberapa tahun terakhir saya mencoba berkali-kali untuk memasukkan pengembang baru ke dalam tim di mana kami memiliki basis kode yang ada, agak besar.

Dan metode yang kami gunakan berhasil, dan saya akan katakan adalah cara paling efektif tanpa pertanyaan IMHO, adalah pemrograman pasangan.

Dalam 12 bulan terakhir, kami memiliki 4 anggota baru di tim, dan setiap saat, anggota baru akan berpasangan dengan anggota lain yang sangat mengenal basis kode. Pada awalnya, anggota tim yang lebih tua akan memiliki keyboard. Setelah sekitar 30 menit kami akan meneruskan keyboard ke anggota baru, yang akan bekerja di bawah bimbingan anggota tim yang lebih tua.

Proses ini telah terbukti cukup berhasil.

1
Pete

Cara saya mempelajari proyek kode besar adalah sebagai berikut:

  1. buat proyek, dan gunakan.
  2. gunakan IDE untuk membuka proyek. Misalnya: Eclipse atau Codelite. Kemudian gunakan IDE untuk mengindeks semua kode sumber proyek).
  3. Gunakan IDE untuk menghasilkan diagram kelas jika bahasa proyek mendukung fungsi ini.
  4. Temukan metode utama. Metode utama adalah entri program. Metode utama juga merupakan entri yang baik untuk menjelajahi proyek.
  5. Temukan inti-struktur data dan fungsi-fungsi program. Lihatlah implementasinya.
  6. Ubah beberapa kode proyek. Buat dan gunakan itu. Perhatikan apakah berhasil! Anda akan didorong dengan memodifikasi program.
  7. Setelah Anda memahami aliran utama program dan implementasi sistem inti, Anda dapat menjelajahi modul-modul lain dari program.

    Sekarang Anda telah memahami proyek kode besar! Selamat menikmati!

0
Edward Shen