Sebagai pengembang kita, pola pikir harus tetap terbuka dan skeptis pada saat yang sama.
Terbuka, karena kita tidak tahu kapan pengembang mungkin mengejutkan kita, dan skeptis tentang ide kita sendiri karena kita sering lupa bahwa dalam rekayasa perangkat lunak tidak ada satu pun cara yang benar untuk mengimplementasikan solusi. Alasan di balik solusi kami bisa masuk akal bagi kami dan tidak membuat yang lain untuk yang lain. Di balik bau kode mungkin ada ide bagus. Mungkin, pengembang tidak menemukan cara untuk mengekspresikannya dengan benar.
Karena kami (manusia) sangat buruk dalam berkomunikasi, jangan membuat asumsi yang salah, berkeinginan untuk bertanya kepada pemilik kode tentang kode yang Anda tinjau. Jika dia gagal dalam mengkode ide di bawah standar perusahaan, karena pengembang utama bersedia membimbingnya juga.
Di sini pendekatan subyektif. Pendekatan objektif, IMO, dijelaskan dengan sangat baik dalam pertanyaan ini .
Selain tautan di atas, serangkaian tujuan yang harus dicapai (rawatan, keterbacaan, portabilitas, kohesi tinggi, kopling longgar, dll.) Tidak harus Sepuluh Perintah. Anda (tim) harus dapat menyesuaikan tujuan-tujuan ini ke titik di mana keseimbangan antara kualitas dan produktivitas membuat pekerjaan lebih nyaman dan "layak huni bagi pengembang".
Saya akan menyarankan penggunaan alat analisis kode statis untuk mengukur kemajuan kualitas sesuai dengan tujuan ini. Alat-alat seperti SonarQube memberi kami Gerbang Kualitas dan Profil Kualitas yang dapat disesuaikan sesuai dengan prioritas kami. Ini juga memberi kami pelacak masalah, di mana pengembang dapat ditargetkan dengan masalah yang terkait dengan bau kode, bug, praktik yang meragukan, dll.
Alat semacam ini bisa menjadi titik awal yang baik, tetapi seperti yang saya katakan tetap skeptis. Anda dapat menemukan beberapa aturan di Sonar menjadi tidak berarti bagi Anda, jadi silakan mengabaikannya atau menghapusnya dari profil kualitas Anda.