Dengan pengalaman muncul penilaian untuk mengetahui kapan kode benar-benar buruk, dan kapan kode itu ditulis dengan gaya yang berbeda. Jika ini berfungsi dengan baik dan mudah dirawat dan ada cakupan tes otomatis yang baik , maka itu tidak buruk dan Anda hanya perlu membuka pikiran Anda. Anda mungkin akan belajar sesuatu. Kode yang buruk tidak berfungsi dan dapat dikelola.
Berikut ini beberapa penanda kode yang benar-benar buruk:
- Blok logika besar telah digandakan alih-alih dihidupkan kembali.
- Ketergantungan melingkar antara kelas atau paket
- Kopling tinggi; kohesi rendah
- Variabel yang tidak digunakan, menulis ke variabel yang tidak pernah dibaca, kode yang tidak terjangkau.
- Implementasi ulang fungsi perpustakaan standar, misalnya pemformatan tanggal.
- Logika kompleks yang tidak perlu; yaitu 50 baris kode di mana 10 akan melakukannya dengan baik.
- Tidak ada komentar yang menjelaskan tujuan kelas atau metode.
- Komentar yang menyesatkan.
Kurangnya tes otomatis tidak berarti kode itu buruk, tetapi itu berarti proyek itu buruk.
Ini bukan masalah selera; praktik-praktik ini membuat pemeliharaan program jauh lebih mahal.
Bagaimana Anda mempersiapkan diri?
Terima kenyataan bahwa perlu beberapa saat untuk dapat berhasil bekerja pada basis kode baru. Jika "dipelihara dengan sempurna" dan ada cakupan tes yang tinggi, itu membutuhkan waktu lebih sedikit tetapi itu masih tidak akan terjadi segera. Jika kode itu buruk, maka hal pertama yang saya lakukan adalah memperingatkan para pemangku kepentingan bahwa itu dalam kondisi yang buruk dan kemajuan awal akan lambat. Jika mereka skeptis, maka saya mendukung klaim saya dengan menunjukkan kepada mereka contoh masalah dalam kode aktual dan menjelaskan perbedaannya dari praktik terbaik industri.