Bagaimana cara "menetralisir" mereka yang menulis kode buruk di tim?

Saya selalu menyukai artikel ini di JoelOnSoftware yang disebut "Mendapatkan Segala Sesuatu Saat Anda Hanya Mendengus". Saya terutama bisa berhubungan ketika saya masih pemula (dan masih merasa saya akan SELALU menjadi).

Tentang # 4, menetralisir bozo. Apa saran yang Anda miliki untuk benar-benar menerapkan ini dalam situasi nyata di tempat kerja? Tampaknya tidak semudah itu (setidaknya di tim kami) hanya dengan mencatat bug terhadap kode buruk seseorang. Apa yang berhasil untuk Anda semua di luar sana?

team bug

— C Johnson
sumber

Senjata. Banyak dari mereka.

— CodesInChaos

Jawaban:

Evaluasi permanen.

Hanya pada akhir setiap hari, luangkan 30 menit untuk meninjau kembali apa yang telah mereka tulis. Jika mereka melakukan kesalahan, buat mereka menulis ulang.

Kecuali jika Anda melakukan ini, suatu hari Anda akan menyadari bahwa sebagian dari aplikasi Anda, walaupun tampaknya mampu melakukan pekerjaan itu, sama sekali tidak dapat dipertahankan, direkayasa secara tidak patut, dan akan menyebabkan banyak masalah di masa depan — atau bahkan besok.

Bahkan jika itu akan membuat mereka kurang produktif, masih akan jauh lebih baik jika mereka menghasilkan beberapa kode yang bagus terhadap ukuran dua kali lebih banyak tetapi mengasapi bug yang tidak dapat dipelihara.

— P Shved
sumber

Jawaban yang bagus Jika saya bisa menambahkannya, jika orang ini adalah rekan, maka itu paling baik dilakukan oleh pemimpin tim. Dengan begitu, responsnya yang tidak baik itu akan jauh lebih efektif jika diperintahkan oleh hierarki toko.

@Surfer, justru sebaliknya. Anda menjadi pemimpin tim dengan melakukan hal-hal seperti ini, dengan mengusulkan solusi yang lebih baik, dengan memperhatikan apa yang dilakukan tim. Bukan sebaliknya. (Tapi, tentu saja, mendapatkan bantuan dari tingkat hierarki yang lebih tinggi membantu).

— P Shved

Jadi pertanyaannya menjadi, siapa yang memiliki wewenang untuk membuat mereka menulis ulang? Saya kira jawabannya adalah, otoritas moral seluruh tim, jika masalahnya disiarkan ke seluruh tim.

— C Johnson

Dengan tidak adanya mekanisme peninjauan kode yang kuat untuk setiap anggota tim, ini sesuai. Ini juga tepat untuk memastikan bozo tidak menggali lubang yang sangat dalam (bahkan tidak sebanding dengan biaya perbaikan) sebelum diperintahkan untuk memperbaikinya.

— mattnz

Jika orang itu tidak tahu apa-apa, tetapi ingin belajar, berikan beberapa bimbingan dan review kode. Pastikan mereka terkena kode yang baik.

Pengembang yang benar-benar miskin adalah mereka yang berada di jalan yang buruk dan berjuang mempelajari hal baru. Satu-satunya harapan Anda adalah membiarkan mereka menderita dengan mempertahankan kekacauan mereka sendiri atau beberapa hal yang lebih sederhana. Idealnya, seseorang yang berwenang berdiri dan mengatakan menyesuaikan diri atau pergi.

— JeffO
sumber

Sikap itu sangat penting. Saya biasanya menemukan pemula lebih rendah hati, dan terbuka untuk ulasan kode dan kritik. Orang-orang ini mudah diajak bicara. Dan Anda dapat dengan mudah berbicara dengan mereka tentang kelemahan mereka. Para veteran yang sombong, yang akan hancur seperti sejuta keping kaca ketika mereka dikritik atas pekerjaan mereka.

— C Johnson