Bagaimana Anda menangani kode yang sengaja buruk?

21

Ada banyak cerita tentang kode yang sengaja buruk, tidak hanya di TheDailyWTF tetapi juga di SO. Kasus-kasus umum meliputi:

  • Memiliki konstruksi pemborosan waktu yang tidak berguna (mis. Loop kosong yang menghitung nilai sangat besar) sehingga programmer dapat dengan mudah "mempercepat" aplikasi dengan menghapusnya ketika mereka ditugaskan.
  • Memberikan dokumentasi yang sengaja menyesatkan, salah atau tidak ada untuk menghasilkan permintaan dukungan yang mahal.
  • Mudah membuat kesalahan, atau lebih buruk, menghasilkan meskipun semuanya bekerja dengan baik, mengunci aplikasi sehingga panggilan dukungan yang mahal diperlukan untuk membuka kunci.

Poin-poin ini menunjukkan sikap yang kurang lebih jahat (meskipun kadang-kadang secara tidak sengaja), terutama poin pertama terjadi agak sering.

Bagaimana seharusnya seseorang berurusan dengan konstruksi seperti itu? Abaikan masalahnya, atau hapus saja kode yang menyinggung itu? Beri tahu manajer mereka, atau berbicara dengan orang yang memperkenalkan "fitur"?

bad-code mafu
sumber
10
Apakah "kadang-kadang secara tidak sengaja" atau "sengaja buruk"? Saya tidak mengerti bagaimana itu bisa menjadi keduanya.

Jawaban:

7

Sebagian besar kode yang buruk adalah karena kurangnya pemahaman dan solusinya adalah pendidikan.

Kode buruk yang disengaja sama sekali berbeda, karena sesuatu yang sama sekali tidak berhubungan dengan pengalaman pembuat kode atau proyek lainnya. Karena itu, Anda harus mencari tahu mengapa mereka menyabot kode dengan sengaja dan menangani masalah itu. Ini berarti, lebih sering daripada tidak, politik kantor, dan itu jarang situasi yang menyenangkan bagi siapa pun.

Bagaimana saya menangani sisi politik tergantung pada banyak keadaan (yang tidak disebutkan di atas). Cara saya menangani kode adalah pertama-tama memastikan bahwa saya bukan orang yang salah paham — bahwa itu benar-benar kode yang buruk — kemudian memperbaiki kekurangan yang jelas. Jika memungkinkan, tulis tes yang salah kode akan gagal. Memeriksa ulang yang saya pahami dengan benar berarti berbicara dengan orang yang menulis kode. Itu harus dilakukan dengan cara yang sangat baik, sopan, tanpa mengandaikan niat, dan dapat membantu menemukan alasan mendasar (politis) yang diperlukan nanti.

Pengiriman lebih penting daripada kesempurnaan menara gading, tetapi ada dua hal yang perlu diperhatikan. Memperbaiki kekurangan yang jelas membuat Anda mendapatkan 80% dari hasil dengan 20% dari upaya, dan jenis buah yang tergantung rendah jarang layak diabaikan. Tetapi yang lebih penting, jika Anda tidak membahas alasan (politis) yang mendasarinya, kemungkinan kode yang lebih sengaja buruk akan ditulis dan menyebabkan masalah lebih lanjut — dan mungkin mencegah pengiriman.


sumber
28

Saya tidak pernah (dalam 20-tahun aneh) menemukan kode yang sengaja buruk, tetapi contoh yang Anda kutip tampaknya (setidaknya bagi saya, tapi IANAL) adalah upaya untuk menipu baik majikan atau pelanggan, sehingga Anda mungkin memiliki hukum kewajiban untuk menunjukkannya kepada manajer Anda.

gkrogers
sumber
2
Sepakat. Tidak ada yang menulis kode yang sengaja buruk. Mereka memecahkan masalah, dan mereka memecahkannya dengan cara terbaik yang mereka tahu. Mereka mungkin salah arah, tidak berpendidikan, tidak tahu apa-apa, dll. Tapi saya tidak bisa membayangkan seorang pengembang yang sengaja menulis sesuatu yang mereka tahu buruk.
Dan Ray
8
Sekalipun tidak legal, setidaknya ada kewajiban etis.
Chris Farmer
@ChrisFarmer Anda tidak dapat memisahkan kewajiban etis dari konteks yang lebih luas - ada beberapa konteks di mana kode buruk yang sengaja mewakili perlawanan kolektif yang sah, baik ekonomi maupun politik. (Dan kontrak kerja hanya layak untuk dihormati dengan itikad baik ketika hubungan yang diformalkannya tidak bersifat eksploitatif baik secara individu maupun struktural.)
user234461
11

Tergantung pada budaya perusahaan. Lebih sering daripada tidak, itu bukan tugas Anda untuk memperbaiki dan membersihkan semua kode buruk.

Dari Coders at Work , pemikiran Jamie Zawinski tentang overengineering, yang juga dapat diterapkan dalam situasi ini:

Pada akhirnya, kirimkan benda sialan itu! Sangat bagus untuk menulis ulang kode Anda dan membuatnya lebih bersih dan pada ketiga kalinya itu akan benar-benar cantik. Tapi bukan itu intinya — Anda di sini bukan untuk menulis kode; Anda di sini untuk mengirimkan produk.

Ada banyak coders dan kode buruk di luar sana, dan hanya mencoba untuk memperbaikinya saat Anda menemukannya, dengan mengorbankan proyek / tugas saat ini, mungkin tidak akan sepadan jika produk "berfungsi". Terlalu sering, kita semua hanyalah programmer lakban.

Juga lihat posting Joel Spolsky: The Duct Tape Programmer

sepon
sumber
+1 Saya benar-benar penggemar konsep produk pengiriman. Saya pikir terlalu banyak profil teknis hanya melewatkan konsep itu.
+1 Saya juga. Ada terlalu banyak "kode bersih" -baik buku dll di luar sana yang mendukung pandangan miring tentang apa yang penting. Kualitas kode hanya sangat penting. Para pemenang bukanlah mereka yang memiliki produk terbaik. Mereka yang memiliki produk yang cukup bagus dikirim dengan cukup cepat.
Joonas Pulakka
4
Saya pikir Anda melewatkan poin dalam pertanyaan - orang itu berbicara tentang kode yang sengaja buruk , bukan hanya kode yang ditulis oleh programmer yang buruk.
Hila
@Hila saya percaya poin saya masih memegang apakah kode yang buruk disengaja atau tidak. Kecuali itu masalah yang ada di proyek / daftar tugas yang ditetapkan, itu bukan tanggung jawab programmer lakban untuk memperbaiki dan membersihkan semua kode buruk . Budaya di luar sana tidak akademis dan menulis kode bersih / indah. Ini tentang pengiriman dan mendukung produk / bisnis. Saya pribadi akan senang untuk memperbaiki semua kode buruk yang saya temui, tetapi saya tidak bisa mendedikasikan 100% waktu saya untuk itu - saya tidak akan pernah bisa menyelesaikan tugas / proyek yang ditugaskan kepada saya saat itu.
Spong
3
@sunpech Tapi membersihkan kode yang buruk tidak sama dengan hanya membersihkan kode apa pun. Ini bukan tentang membuat aplikasi Anda lebih "indah", ini tentang memperbaiki kode berbahaya yang sengaja dibuat di sana. Ini seperti mengatakan bahwa seorang dokter tidak boleh mengambil gunting yang seorang kolega lupa di dalam seorang pasien karena operasi kardiotoraks adalah tentang menyelamatkan hidup dan bukan tentang seberapa cantik jahitannya.
Hila
4

Sikap itu adalah gejala dari sesuatu yang lebih buruk.

  • Apakah manajemen mendorong kompetisi pengembang?

  • Di mana semangat tim?

  • Apakah tugas diberikan oleh orang lain daripada tim itu sendiri?

  • ...

Bagaimanapun, menghapus kode yang menyinggung tidak cukup. Mengeluh kepada manajernya tentu tidak akan membantu meningkatkan semangat tim.

Saya akan mencoba untuk berbicara dengan orang itu secara langsung dan mencoba memahami mengapa dengan mengajukan banyak pertanyaan tanpa menghakimi dia. Seluruh tim harus melakukannya tanpa agresivitas.

Dalam kebanyakan kasus, perilaku konstruktif itu menempatkan masalah nyata (yang lebih buruk) di bawah cahaya, dan kemudian Anda dapat mengatasinya.

Jika itu benar-benar tidak berhasil. Hapus pengembang itu dari tim.


sumber
4

Jika saya pikir itu disengaja saya mungkin akan memecat orang itu! Jika itu adalah hasil dari seseorang yang tidak menjadi programmer yang cukup baik, saya akan mengerjakan keterampilannya. Jika didorong dari atas, saya mungkin akan mulai mencari pekerjaan baru.

Zachary K
sumber
2

Bagaimana seharusnya seseorang berurusan dengan konstruksi seperti itu? Abaikan masalahnya, atau hapus saja kode yang menyinggung itu? Beri tahu manajer mereka, atau berbicara dengan orang yang memperkenalkan "fitur"?

Tergantung pada konteksnya, salah satu dari itu mungkin yang paling tepat. Kemungkinan lain termasuk, meminta untuk pindah ke proyek yang berbeda, mendapatkan pekerjaan baru, dan berbagai tindakan moralitas yang dipertanyakan dan / atau legalitas.

Namun, mengingat bahwa kita tidak tahu fakta sebenarnya dan orang-orang nyata yang terlibat, tidak mungkin seseorang dalam posisi yang Anda gambarkan harus memperhatikan saran kami / senilai 2 sen.

Jika ini adalah situasi nyata yang Anda bicarakan, mungkin ada baiknya berbicara dengan manajer Anda , meminta nasihat mereka tentang apa yang harus Anda lakukan. Jika mungkin cobalah untuk melakukan pembicaraan tentang apa yang dapat / harus Anda lakukan, bukan tentang mengarahkan jari. Jika memungkinkan, jangan menyebutkan nama. Ada kemungkinan yang adil bahwa manajer Anda sudah memiliki firasat tentang masalah tersebut.

Tetapi sisi sebaliknya adalah bahwa Anda mungkin meniup ini keluar dari proporsi. Berpikir panjang dan keras tentang itu sebelum Anda melakukan apa pun. Pikirkan konsekuensinya, termasuk kemungkinan bahwa langkah apa pun yang Anda ambil mungkin menjadi bumerang bagi Anda ... buruk.

Stephen C
sumber