Dalam dunia yang ideal, semua kode yang ditulis oleh pengembang tertentu akan didokumentasikan dengan baik, terstruktur dengan baik dan diuji secara komprehensif, baik dengan alat otomatis seperti tes unit dan menggunakan skrip kasus yang dijalankan pengguna untuk memeriksa apakah Anda mendapatkan hasil yang diharapkan.
Namun, hal pertama yang akan Anda pelajari adalah kita tidak hidup di dunia yang ideal!
Banyak pengembang tidak mendokumentasikan kode mereka dengan benar, jika sama sekali, mereka mencampur logika bisnis dengan kode yang tidak terkait, dan satu-satunya tes yang mereka lakukan adalah menjalankan cepat melalui apa yang mereka harapkan menjadi kasus penggunaan normal.
Ketika bekerja dengan kode seperti ini, hal pertama yang harus Anda lakukan adalah menetapkan apa yang seharusnya dilakukan. Jika ada komentar mereka mungkin memberi Anda petunjuk, tetapi jangan mengandalkannya. Ini pengalaman saya bahwa banyak coders tidak pandai menjelaskan diri mereka sendiri dan bahkan jika mereka meninggalkan komentar mereka mungkin tidak ada artinya. Namun, kecuali jika Anda satu-satunya pembuat kode di perusahaan, seseorang pasti harus memiliki setidaknya ide dasar untuk apa kode ini dan apa yang harus dilakukan. Tanya sekitar!
Jika Anda memiliki tes unit, maka mereka akan membuat hidup Anda jauh lebih mudah. Jika tidak, maka bagian dari mempelajari basis kode mungkin melibatkan penulisan unit test untuk kode yang sudah ada. Biasanya ini tidak dianggap praktik yang baik karena jika Anda menulis unit test agar sesuai dengan kode yang ada, Anda akan berakhir dengan unit test yang menganggap kode berfungsi sebagaimana mestinya (mereka akan ditulis untuk berasumsi bahwa perilaku yang sebenarnya adalah bug adalah benar), tetapi setidaknya itu memberi Anda garis dasar. Jika nanti Anda menemukan bahwa beberapa perilaku yang Anda anggap benar ternyata salah, Anda dapat mengubah unit test untuk menguji apa hasil yang diharapkan daripada hasil yang diberikan kode sekarang. Setelah Anda memiliki unit test, Anda dapat membuat perubahan dan menilai efek samping apa saja yang Anda buat.
Terakhir, sumber daya terbaik yang Anda miliki ketika berhadapan dengan bagian kode yang tidak berdokumen adalah bertanya kepada pengguna akhir. Mereka mungkin tidak tahu apa-apa tentang kode, tetapi mereka tahu apa yang mereka ingin aplikasi lakukan. Pengumpulan persyaratan adalah tahap pertama dalam proyek apa pun, dan berbicara dengan calon pengguna sistem yang akan dikembangkan selalu merupakan bagian penting dari itu. Anggap saja melakukan tahapan penangkapan persyaratan untuk proyek baru yang kebetulan sudah dibangun.
Ingatlah bahwa kode yang ditulis dengan baik dan terdokumentasi dengan baik pun bisa sulit dipahami oleh orang luar. Kode pada dasarnya adalah ekspresi dari bagaimana orang yang menulisnya berpikir pada saat itu, dan setiap orang memiliki proses pemikiran mereka sendiri yang unik. Anda harus belajar menjadi sedikit sabar, dan menjadi seorang detektif. Sulit untuk masuk ke proses pemikiran orang lain itu sulit, tetapi itu adalah keterampilan penting bagi seorang programmer melakukan pemeliharaan pada kode yang ada. Karena kebanyakan pengkodean (sekitar 70%) terkait dengan mempertahankan kode yang ada, ini merupakan keterampilan yang penting untuk dipelajari.
Oh, dan sekarang setelah Anda melihat rasa sakit yang dapat disebabkan oleh kode yang tidak terdokumentasi, tidak teruji, dan campur aduk, Anda tidak akan melakukannya pada pengembang miskin berikutnya, bukan? :) Belajarlah dari kesalahan pendahulu Anda, komentari kode Anda dengan baik, pastikan bahwa setiap modul memiliki tanggung jawab yang jelas, dan pastikan Anda memiliki serangkaian unit test komprehensif yang Anda tulis terlebih dahulu (untuk metodologi TDD) atau setidaknya di samping kode yang sedang dikembangkan.