Bagaimana Anda melacak proyek-proyek besar?

Ketika berhadapan dengan sebuah proyek yang memiliki banyak file berbeda, saya sepertinya selalu lupa bagaimana bagian-bagian berinteraksi satu sama lain. Saya tidak pernah benar-benar memiliki banyak masalah dalam memahami komponen-komponen yang lebih kecil secara terpisah, tetapi seiring dengan meningkatnya kompleksitas proyek, saya mendapati diri saya tidak mampu secara mental membangun pemahaman tentang apa yang sedang terjadi. Saya perhatikan ini terutama dengan proyek-proyek OOP, karena jumlah metode dan file sumber meningkat.

Latar belakang saya: Saya seorang programmer web otodidak. Saya telah menangani sebagian besar python untuk skrip cepat dan kotor, tetapi saya juga telah melakukan beberapa proyek Django dasar . Saya suka kerangka kerja web seperti labu , karena dalam kesederhanaan tata letak file tunggal, saya dapat dengan mudah melacak (kebanyakan) dari apa yang terjadi.

Saya sekarang menemukan diri saya dalam situasi di mana saya perlu berinteraksi dengan proyek PHP Zend Framework besar yang dikembangkan orang lain, dan saya kewalahan dengan mencoba memahami kode yang menyebar ke banyak file.

Teknik dan proses apa yang menurut Anda berguna untuk memahami basis kode besar yang telah dikembangkan oleh orang lain? Apakah ada diagram tertentu yang Anda temukan membantu Anda memahami gambar yang lebih besar?

Trik untuk memahami basis kode yang besar adalah dengan tidak mencoba memahami semua itu. Setelah ukuran tertentu, Anda tidak bisa memegang model mental di kepala Anda dari semuanya. Anda mulai dengan titik jangkar yang masuk akal untuk tugas apa pun yang perlu Anda kerjakan terlebih dahulu, kemudian cabang dari sana, belajar hanya bagian-bagian yang Anda butuhkan dan percaya bahwa sisanya berfungsi seperti yang diiklankan. Ini seperti memahami rekursi. Jika Anda mencoba memegang seluruh tumpukan di kepala Anda, otak Anda meledak.

Grep, debuggers, dan intellisense adalah teman Anda di sini. Jika Anda tidak tahu bagaimana suatu fungsi akhirnya dipanggil, atur breakpoint di atasnya dan jalani jejak stack.

Hal lain yang perlu diperhatikan adalah basis kode besar tidak muncul entah dari mana. Semakin besar, semakin banyak programmer yang memiliki pengalaman di dalamnya, jadi tanyakan kepada mereka di mana untuk memulai, tetapi lebih spesifik. Ajukan pertanyaan seperti, "Saya perlu menambahkan penyedia pembayaran baru. Di mana dalam kode itu saya harus mencari?" Fokus hanya pada tugas itu daripada mencoba memahami seluruh basis kode, dan sepotong demi sepotong keakraban Anda akan tumbuh.

Tidak ada jalan pintas. Anda hanya harus menderita karenanya.

Untuk menjawab pertanyaan Anda tentang cara mendapatkan diagram, doxygen adalah yang Anda inginkan. AFAIK berfungsi dengan PHP.

Secara umum, saya melalui tahapan yang kira-kira mengikuti ketika menemukan basis kode baru:

1. Memahami apa yang dilakukannya dari sudut pandang pengguna. Mampu benar-benar menggunakan aplikasi sendiri seperti pengguna yang kuat. Memahami bagaimana pengguna akhir yang sebenarnya bekerja dengannya. Ini bisa mengharuskan Anda duduk bersama mereka sampai Anda memperoleh pemahaman yang kuat tentang apa yang mereka lakukan.

2. Berkomunikasi dengan pengembang asli, jika memungkinkan. Pada awalnya, Anda akan memiliki pertanyaan arsitektur yang dirangsang oleh pengalaman pengguna akhir. Kemudian, Anda akan memiliki pertanyaan implementasi tentang kasus tepi dan detail. Mampu mendapatkan jawaban dari pengembang akan membantu jauh lebih banyak daripada komentar atau dokumentasi (yang paling tidak lengkap dan sering menyesatkan atau sama sekali tidak ada).

3. Pelajari tentang kerangka apa pun yang Anda gunakan. Paling tidak, Anda harus dapat membuat "hello world" atau aplikasi sederhana lainnya dengan kerangka kerja itu sebelum masuk ke aplikasi produksi.

4. Dapatkan seluruh proses penyebaran (paling baik dilakukan saat pengembang asli memegang tangan Anda). Jika Anda tidak dapat mengambil basis kode saat ini dan membangunnya dan menyebarkannya melalui lingkungan uji / validasi / prod, Anda bersulang. Bahkan perubahan terkecil akan membutuhkan melompat melalui semua rintangan penyebaran, jadi mengapa tidak segera turunkan bagian ini? Dengan melakukan hal itu, Anda akan diperkenalkan ke semua server, basis data, layanan, dan skrip yang digunakan oleh aplikasi - Anda akan tahu "di mana ia tinggal".

5. Dapatkan pegangan pada tes fungsional (jika ada). Bagaimana Anda tahu jika benda itu berjalan dengan baik? Apa yang harus dilakukan oleh orang-orang operasi untuk perawatan dan pemberian makan aplikasi?

6. Memahami log aplikasi. Meskipun saya belum pernah bekerja dengan PHP, saya akan menebak dan mengatakan bahwa aplikasi PHP yang serius akan memiliki beberapa jenis logging. Jika Anda memahami log, Anda akan memiliki titik awal yang baik ketika saatnya tiba untuk masalah debugging.

---- Perhatikan bahwa sampai di sini, saya bahkan belum menyebutkan dengan cermat melihat basis kode. Ada BANYAK yang dapat Anda pelajari tentang proyek besar tanpa melihat kodenya. Pada titik tertentu, tentu saja, Anda harus merasa nyaman dengan kode tersebut. Inilah yang membantu saya:

7. Untuk diagram, doxygen adalah alat yang sangat baik yang akan menghasilkan grafik panggilan dan hubungan lainnya untuk Anda. Kebetulan memiliki kemampuan PHP! Jika Anda belum mencoba doxygen, Anda harus mencobanya. Meskipun saya tidak dapat menjamin seberapa jelasnya kode di dalam kerangka kerja, tetapi ini bisa membantu. Pengembang asli sering terkejut dengan apa yang mereka lihat ketika disajikan dengan dokumen yang dihasilkan oleh oksigen dari kode mereka. Kabar baiknya adalah sangat membantu untuk mengeringkan ingatan mereka dan membantu Anda lebih baik.

8. Jika Anda memiliki serangkaian unit test, mencermati mereka harus memberikan jendela ke dalam cara kerja aplikasi. Ini juga akan menjadi tempat pertama untuk mencari bug yang mungkin Anda perkenalkan saat melakukan perubahan.

9. Bookmark IDE sangat berharga untuk menandai hot spot di basis kode. Mampu beralih melalui mereka dengan cepat akan meningkatkan pemahaman.

10. Membaca laporan bug terbaru dan resolusi mereka juga berharga untuk memahami hot-spot dan akan membantu Anda mempercepat bagian-bagian basis kode yang paling relevan.

Seperti yang diminta, inilah komentar saya sebagai jawaban.

Ketika bekerja dengan kode orang lain, saya cenderung membuat atau jika mungkin menghasilkan diagram kelas UML untuk memberi saya gambaran umum tentang struktur statis. Diagram visual membantu saya terutama ketika saya harus kembali nanti dan sudah lupa konteks kelas. Kadang-kadang aku melakukannya untuk perilaku dinamis juga untuk line out interaksi antara collaborateurs, tapi saya tidak melakukan itu yang sering.

Jika basis kode berisi tes (integrasi atau unit), kadang-kadang layak untuk diperiksa juga.

Saya sebenarnya akan mulai melakukan ini selama minggu ini di mana klien baru perlu perangkat tambahan untuk produk yang ditinggalkan oleh pengembang lain. Berikut langkah-langkah yang harus diikuti:

a) Identifikasi kerangka kerja pemrograman yang digunakan, yang membantu dalam mengetahui bagaimana aplikasi mengalir.

b) Identifikasi layanan umum - pencatatan, penanganan pengecualian, MVC, koneksi basis data, audit, tampilan (pembuatan halaman) karena ini adalah bagian yang paling banyak kami gunakan.

c) Jalankan melalui arus pengguna umum (dalam aplikasi) kemudian cobalah untuk menyelaraskannya dengan bagaimana kode diletakkan

d) Cobalah untuk membuat beberapa perubahan dan lihat bagaimana hasilnya. Ini adalah langkah terbesar karena sampai Anda mulai membuat perubahan kode masih berupa kotak hitam ....

Saya akan memberi tahu Anda gagasan lain apa yang saya dapatkan selama dua minggu ke depan

Pikir saya adalah bahwa Anda harus membaca dokumentasi. Saya tahu peretas senang memberi tahu Anda "kode adalah dokumentasi" dan menggunakannya sebagai alasan untuk tidak menulis dokumentasi apa pun, tetapi mereka salah. Lihatlah kernel Linux, sebuah proyek perangkat lunak besar jutaan baris kode: Saya tidak berpikir ada orang yang bisa benar-benar segar tanpa harus membaca buku dan mengambilnya. Jika kode yang Anda kerjakan tidak didokumentasikan (atau berkomentar dengan baik jika proyek yang lebih kecil) maka mungkin itu bukan kode yang baik.

Jika Anda bekerja dengan sesuatu yang sangat besar dengan nol dokumentasi (saya pernah ke sana juga, itu kasar!), Yang saya temukan yang membantu adalah mencoba mengisolasi bagian yang sedang Anda kerjakan. Di bagian kode itu, cari tahu bagaimana data / peristiwa / pesan / interaksi masuk dan keluar dari unit itu. Dengan kata lain, merekayasa balik antarmuka. Tuliskan. Lain kali Anda bekerja pada unit lain (bonus jika berbicara dengan yang Anda bekerja dulu), lakukan hal yang sama. Simpan semua dokumentasi Anda. Setelah beberapa bulan, Anda akan memiliki gambaran yang bagus tentang bagaimana benda itu mengalir.

Cari tahu antarmuka satu unit kecil yang sedang Anda kerjakan, dan catat untuk referensi nanti. Seiring waktu Anda akan menjahit sebagian besar cara kerjanya. Temukan apa yang program Anda lakukan dan lacak bagaimana pesan itu mengalir. Misalnya, jika sistem Anda mengambil beberapa pesan jaringan input dan mengirimkan pesan keluaran, lacak bagaimana pesan itu mengalir melalui sistem, tanpa khawatir tentang semua detailnya - lihat saja kemana perginya.

Apa yang saya lakukan adalah membuat model UML tunggal dari semua file yang telah dibalik dari java ke UML. Pendekatan ini berarti bahwa model tersebut tidak lagi hanya pandangan abstrak dari proyek tetapi proyek itu sendiri sepenuhnya dipetakan ke MOF dan karena itu UML.

Apa yang saya dapatkan adalah model tunggal besar yang disusun oleh beberapa sub model yang masing-masing disusun oleh paket yang disusun oleh pengklasifikasi, dll. Bekerja di tingkat multi proyek juga memungkinkan saya untuk melacak setiap pengklasifikasi dan pemanggilan metode pada tingkat multi proyek. Maksud saya, metode yang sama dapat memanggil satu classifier dalam proyek A dan classifier lain dalam proyek B. Satu-satunya cara untuk melihat struktur penuh proyek adalah membalikkan keduanya sekaligus. Saya tidak punya waktu untuk membuat diagram komponen dan informasinya tidak terlalu akurat. Saya lebih suka meminta komputer untuk membalikkan proyek lengkap untuk saya. Saya melakukan pembalikan pada setiap iterasi dengan tim dan semua diagram saya segera diperbarui. Rekayasa terbalik bersifat inkremental dan menggunakan pemetaan Java to UML Id. Maksud saya, setiap elemen java dipetakan ke elemen MOF tunggal dan unik yang tetap sama selama semua kehidupan proyek bahkan jika refactored. Melakukan hal itu tidak memberikan batasan lagi untuk pemodelan UML dan memungkinkan pemodelan proyek yang sangat besar dan kompleks. Untuk informasi Anda, saya bekerja dengan proyek yang memiliki lebih dari 5 000 000 baris kode OOP. Semua proyek saya dibalik dengan benar dan navigasi grafis dimungkinkan

Saya hanya menggunakan diagram kelas karena dari model UML saya, saya dapat membuat sebanyak mungkin tampilan yang diperlukan yang selalu terkini. Saya juga bisa membuat model proyek yang sangat kompleks.