Dalam basis kode warisan, bagaimana saya dengan cepat mengetahui apa yang sedang digunakan dan apa yang tidak?

Saya telah diminta untuk mengevaluasi apa yang tampaknya menjadi basis kode warisan substansial, sebagai pendahulu untuk mengambil kontrak mempertahankan basis kode itu.

Ini bukan pertama kalinya saya berada dalam situasi ini. Dalam contoh ini, kodenya adalah untuk situs game multipemain multi-profil yang cukup tinggi dan cukup tinggi, mendukung setidaknya beberapa ribu pemain online sekaligus. Seperti banyak situs seperti itu, yang satu ini adalah campuran dari teknologi front-end dan back-end.

Struktur situs seperti yang terlihat dari dalam ke luar, berantakan. Ada beberapa folder dengan akhiran "_OLD" dan "_DELETE" di mana-mana. Banyak folder yang tampaknya tidak memiliki tujuan, atau memiliki nama yang sangat samar. Mungkin ada sejumlah skrip lama dan tidak terpakai yang tergeletak bahkan di folder yang tampak sah. Tidak hanya itu, tetapi ada banyak bagian kode yang tidak diragukan lagi bahkan dalam skrip operasional (masalah yang jauh lebih mendesak).

Ini adalah penyerahan dari pengelola lama, kembali ke pengembang asli / pengelola situs. Seperti dapat dipahami secara umum dalam skenario-skenario semacam ini, pemegang jabatan tidak ingin melakukan apapun selain penyerahan kontrak dan apa yang disyaratkan secara hukum dari mereka untuk mendorongnya kepada pengelola yang baru terpilih. Jadi mengekstraksi informasi tentang struktur situs yang ada dari petahana adalah tidak mungkin.

Satu-satunya pendekatan yang muncul di pikiran untuk masuk ke basis kode adalah mulai di root situs dan perlahan tapi pasti menavigasi melalui skrip yang ditautkan ... dan ada kemungkinan ratusan digunakan, dan ratusan lainnya tidak. Mengingat bahwa sebagian besar situs berada di Flash, ini bahkan lebih mudah karena, terutama di aplikasi Flash yang lebih lama, tautan ke skrip lain dapat disematkan dalam binari (.FLA) daripada dalam file teks (.AS / ActionScript).

Jadi saya bertanya-tanya apakah ada yang punya saran yang lebih baik tentang bagaimana pendekatan mengevaluasi basis kode secara keseluruhan untuk pemeliharaan. Akan luar biasa jika ada beberapa cara untuk melihat grafik frekuensi akses ke file di OS server web (yang saya akses), karena ini mungkin menawarkan wawasan tentang file mana yang paling kritis, meskipun itu tidak akan dapat menghilangkan file-file yang tidak pernah digunakan (karena beberapa file dapat digunakan hanya setahun sekali).

Karena apa yang Anda diminta lakukan adalah memberikan masukan bagi klien Anda untuk menulis proposal yang sesuai kepada klien lain (pemilik kode mimpi buruk) untuk pekerjaan apa pun pada kode itu, saya akan pergi keluar tungkai dan katakan bahwa Anda tidak akan melakukan pengujian menyeluruh atau refactoring atau apa pun di sepanjang garis pada saat ini. Anda mungkin memiliki waktu yang sangat singkat untuk mendapatkan perkiraan kasar. Jawaban saya didasarkan pada pengalaman saya dalam situasi yang sama, dan jadi jika interpretasi saya salah, abaikan saja semua yang mengikuti.

• Gunakan alat spidering untuk mengetahui halaman apa yang ada di sana, dan apa yang masuk. Bahkan alat penghubung tautan dasar - bukan alat khusus "laba-laba untuk tujuan audit" - akan berguna dalam hal ini.
• Buat lembar kerja audit / inventaris dasar. Ini bisa sesederhana daftar file dan waktu modifikasi terakhirnya, diatur oleh direktori. Ini akan membantu Anda mendapatkan ruang lingkup, dan ketika Anda masuk ke direktori seperti _OLD dan _DELETE Anda dapat membuat catatan besar bahwa a) evaluasi Anda didasarkan pada hal - hal yang tidak ada di direktori tersebut b) keberadaan direktori tersebut dan potensi untuk cruft / nightmares tersembunyi membuktikan masalah yang lebih dalam yang harus diperhitungkan dalam tawaran klien Anda , dalam beberapa cara. Anda tidak perlu menghabiskan banyak trilyun tahun untuk menyebutkan kemungkinan masalah dalam _OLD atau _DELETE; info akan dimasukkan ke dalam tawaran akhirnya.
• Mengingat Anda meninjau apa yang terdengar seperti aplikasi yang sepenuhnya berbasis web, bahkan alat penganalisa log standar akan menjadi teman Anda. Anda dapat menambahkan ke spreadsheet beberapa perasaan "ini ada di 10 skrip yang diakses" atau semacamnya. Bahkan jika skrip tertanam dalam file Flash dan karena itu tidak spiderable, ada kemungkinan besar mereka diakses melalui POST atau GET, dan akan muncul di log server. Jika Anda tahu Anda memiliki 10 skrip yang sangat diakses, bukan 100 (atau sebaliknya), ini akan memberi Anda ide yang bagus tentang bagaimana pekerjaan pemeliharaan akan berjalan.

Bahkan di situs yang rumit, apa yang saya uraikan di atas adalah sesuatu yang bisa Anda lakukan dalam satu atau setengah hari. Karena jawaban yang akan Anda berikan kepada klien Anda adalah sesuatu seperti "ini akan sangat menyakitkan di pantat, dan berikut adalah beberapa alasan mengapa Anda hanya akan menggunakan lipstik pada babi, jadi Anda harus menawar sesuai itu "atau" siapa pun yang beralasan akan mengajukan tawaran untuk tidak mempertahankan tetapi memulai dari awal, jadi Anda harus mengajukan penawaran yang sesuai "atau bahkan" ini tidak seburuk itu, tetapi itu akan menjadi aliran pekerjaan yang konsisten selama jangka waktu tertentu, jadi tawaran yang sesuai " , intinya adalah bahwa mereka akan melakukan penawaran dan dengan demikian Anda tidak perlu setepat yang Anda akan lakukan jika Anda dipekerjakan secara langsung untuk melakukan audit konten dan arsitektur lengkap.

Saya sangat merekomendasikan refactoring kode sumber yang ada (sebagai lawan penulisan ulang) menggunakan pola yang ditemukan dalam buku " Bekerja Secara Efektif dengan Kode Warisan ".

Buku ini merinci beberapa mekanisme untuk secara efisien mencakup kode lama dalam pengujian unit, sehingga Anda kemudian dapat mulai dengan aman mengembalikan kode tersebut. Buku ini terpecah menjadi beberapa bagian, satu menggambarkan filosofi di balik pendekatan, dan kemudian beberapa bab yang memecahkan masalah tertentu, seperti "Dibutuhkan selamanya untuk membuat perubahan", "Saya tidak punya banyak waktu dan perlu mengubahnya" , dan "Saya tidak bisa mendapatkan kelas ini ke test harness". Masing-masing bab ini memiliki teknik yang terinci dan terbukti yang membantu Anda mempelajari cara menerapkan praktik terbaik dalam pengujian untuk masalah dunia nyata.

Membaca buku itu meninggalkan saya dengan perasaan yang sangat nyata bahwa "kita tidak sendirian" ... banyak dari kita, atau mungkin kita semua, bekerja dengan basis kode kompleks yang menjadi sulit untuk dikelola. Teknik-teknik yang tercantum dalam buku ini memberi saya banyak harapan, dan saya secara pribadi dapat menerapkannya segera.

Posting blog Joel Spolsky melakukan pekerjaan yang baik untuk menjelaskan mengapa yang terbaik untuk mempertahankan basis kode kerja yang sudah ada sebagai lawan mulai dari awal. Saya telah memilih kutipan dari artikel yang merangkumnya, tetapi ini adalah bacaan yang fantastis.

"Ada alasan halus bahwa pemrogram selalu ingin membuang kode dan memulai lagi. Alasannya adalah mereka berpikir kode lama itu berantakan. Dan di sini adalah pengamatan yang menarik: mereka mungkin salah. Alasan mengapa mereka berpikir yang lama kode berantakan adalah karena hukum utama, pokok pemrograman:

Lebih sulit membaca kode daripada menulisnya. ". - http://www.joelonsoftware.com/articles/fog000000000069.html

Dalam basis kode Java yang khas, saya akan mempertimbangkan menggunakan alat-alat seperti PMD, FindBugs, atau Sonar dan kemudian saya akan mencoba memahami alat pelaporan (kode mati, kode tidak berdokumen, kode duplikat, dll.)

Berdasarkan laporan saya akan mencoba untuk menemukan berbagai lapisan aplikasi / situs (lapisan bisnis, DB, SQL, dll.)

Jika layer digabungkan (html di dalam servlet, sql dalam kode java) Saya akan mulai lebih dulu dengan memisahkan setiap langkah-langkah ini harus dianggap terisolasi dan Anda dapat melakukan di akhir masing-masing (dengan memulai cabang lalu membuat penggabungan) .

Dari uraian Anda, tampaknya kode ini telah mencapai kondisi tidak dapat dipertahankan, yang berarti pendekatan terbaik kemungkinan adalah penulisan ulang lengkap. Pengembang akan memiliki gaji jauh lebih kecil jika ada alat kualitas yang bekerja untuk menjaga basis kode yang berantakan tetap terjaga. Dimungkinkan untuk melalui dan membersihkan kode lama yang tidak dibutuhkan dari folder, tetapi ini merupakan tugas manual dan Anda kemungkinan tidak akan mendapatkan semuanya tanpa jumlah waktu yang tidak masuk akal. Saya hanya menebak-nebak di sini, tapi saya yakin kode kerjanya sendiri sama berantakannya dengan struktur file yang berarti bahkan ketika Anda berhasil mendapatkan basis kode yang dipangkas menjadi kode yang aktif bekerja itu masih akan menjadi mimpi buruk. untuk memperbarui atau memperbaiki apa pun.

Saya akan menekankan bahwa upaya yang diperlukan untuk mendapatkan kode yang ada dalam keadaan terpelihara akan sama atau lebih besar daripada upaya untuk memulai menulis ulang. bagian dari memelihara segala sesuatu adalah mengetahui kapan harus "mengambilnya di belakang gudang dan menembaknya".

Perayap web mungkin membantu Anda menentukan URL mana yang dapat diakses. Terutama jika cukup pintar untuk mengekstrak tautan dari Flash atau JavaScript. Setelah Anda memiliki daftar halaman web, buka dan daftar file yang mereka rujuk. Apa pun yang tersisa setelah proses ini harus dianggap sebagai kode mati.

Catatan: Saya memberi aksen pada penggunaan basis data, sementara Anda bertanya tentang penggunaan kode itu sendiri. Jawabannya masih berlaku untuk kedua kasus di setiap poin yang saya sebutkan.

Anda telah menjawab sebagian pertanyaan Anda sendiri di paragraf terakhir: lihat apa yang diakses saat aplikasi sedang berjalan.

1. Anda mungkin ingin membuat profil basis data dan meminta profiler untuk mencatat semua pertanyaan selama sehari. Ini akan memberi Anda gambaran tentang objek database yang paling sering digunakan, tetapi tidak akan memberi tahu mana yang tidak pernah digunakan. Selain itu, Anda harus tetap berhati-hati dengan hasilnya: misalnya sebuah tabel dapat digunakan secara eksklusif melalui prosedur tersimpan, tetapi ketika Anda akan melihat pertanyaan dari profiler, itu akan tampak seolah-olah tabel tersebut tidak digunakan sama sekali.

2. Meninjau kode sumber, mencari kueri lebih bermanfaat, dan setelah mengumpulkan semua kueri, Anda dapat memiliki pemahaman yang baik tentang penggunaan basis data, bukan dalam hal frekuensi (ini adalah di mana profiler berguna), tetapi dalam hal digunakan / tidak tabel yang digunakan. Sayangnya, untuk database yang ditulis dengan buruk / tidak dikelola selama bertahun-tahun, mungkin sangat sulit dan rawan kesalahan , terutama jika kueri dibuat secara dinamis (bayangkan metode yang, dalam select, menggunakan parameter sebagai nama tabel; bagaimana Anda bisa mungkin tahu apa nilai yang mungkin dari parameter hanya dengan melihat kode sumber?).

3. Analisis statis dan beberapa kompiler juga dapat mengungkapkan kode mati, tetapi masih tidak memberikan jawaban yang Anda inginkan.

4. Analisis data itu sendiri atau database metadata dapat mengungkapkan beberapa info menarik. Sebagai contoh, akan mudah untuk menegaskan bahwa tabel LogonAudit(uniqueidentifier LogonAuditId, datetime LogonEvent, ...)tidak digunakan lagi jika mengandung 10 000 catatan per hari untuk tahun 2006-2009, dan tidak ada catatan dari September, 18 ^th , 2009. Hal yang sama tidak berlaku untuk tabel yang berisi data indentasi sebagian besar hanya baca-saja.

Keempat poin bersama akan memberi Anda daftar tabel yang digunakan. Yang tersisa digunakan atau tidak. Anda dapat membuat pernyataan, dan mengujinya, tetapi tanpa cakupan unit test yang baik, itu tidak akan mudah. Cara "mudah" apa pun akan gagal juga. Misalnya, jika Anda memiliki products_delme_not_usedtabel, Anda dapat menyatakan bahwa tabel tersebut tidak digunakan sama sekali, dan periksa "products_delme_not_used" dalam kode Anda. Ini optimis: tidak biasa menemukan kandidat DailyWTF seperti ini di basis kode lama:

// Warning: WTF code below. Read with caution, never reuse it, and don't trust
// the comments.

private IEnumerable<Product> GetProducts()
{
    // Get all the products.
    return this.GetEntities<Product>("PRODUCT");
}

private IEnumerable<T> GetEntities<T>(string tableName)
{
    // Everyone knows that SQL is case sensitive.
    tableName = tableName.ToLower();

    if (tableName == "user" || tableName == "product")
    {
        // Those tables were renamed recently in the database. Don't have time
        // to refactor the code to change the names everywhere.
        // TODO: refactor the code and remove this `if` block.
        tableName += "s";
    }

    if (this.IsDelme(tableName))
    {
        // We have some tables which are marked for deletion but are still
        // used, so we adjust their name.
        tableName = this.Delme(tableName);
    }

    return this.DoSelectQuery<T>("select top 200 * from " + tableName);
}

private bool IsDelme(string name)
{
    // Find if the table is among candidates for removal.
    List<string> names = this.Query<string>("select Names from DelmeTables");
    return names.Contains(name);
}

private string Delme(string name)
{
    // Return the new name for a table renamed for deletion.
    return string.Join("_", new [] { name, "delme", "not", "used" });
}

Bisakah Anda mengetahui bahwa kode ini benar-benar menggunakan products_delme_not_usedtabel?

Jika saya jadi Anda, saya akan:

1. Simpan semua objek basis data di tempatnya,
2. Refactor seluruh aplikasi (jika itu layak),
3. Dokumentasikan (sambil refactoring) aplikasi dan khususnya penggunaan basis data.

Saat Anda menyelesaikan dua langkah terakhir, Anda mungkin akan memiliki pemahaman yang lebih baik tentang penggunaan database, yang akan membantu mencari nama-nama tabel yang tidak digunakan lagi, dan mungkin lebih atau kurang menghapusnya dengan aman.

Kedengarannya bagi saya Anda perlu mendapatkan informasi yang cukup untuk membuat penawaran jadi saya akan berkonsentrasi pada upaya itu.

Saya akan mencoba menentukan berapa banyak kasus penggunaan yang terlibat dalam situs ini. Ini biasanya memberi Anda gambaran tentang seberapa besar dan rumit situs tersebut dan berapa banyak waktu yang diperlukan untuk membuat kembali atau memelihara situs / aplikasi.

Ya, memang benar bahwa kadang-kadang kode tidak digunakan lagi dan itu akan membuat aplikasi terlihat sedikit lebih besar dari yang sebenarnya, tapi saya tidak berpikir ini akan mempengaruhi angka lebih dari 20% paling banyak , jadi saya tidak akan khawatir tentang bagian itu.

Melihat kode sumber, halaman web dan tabel database akan membantu Anda menemukan ini.

Anda mungkin juga ingin mempertimbangkan untuk membatasi jumlah jam per bulan yang akan Anda habiskan untuk proyek ini dengan biaya yang telah ditentukan sebelumnya untuk melindungi diri Anda.

Sejauh menemukan apa yang sedang digunakan dan tidak digunakan, memang tidak ada cara mudah. Alat analisis kode dapat membantu, tetapi karena Anda berhadapan dengan campuran yang sangat buruk, saya rasa tidak ada alat tunggal yang dapat membantu. Untuk setiap area spesifik Anda mungkin dapat menemukan alat analisis kode yang dapat membantu.