Kode Tidak Berguna di Sumber Anda

Saya sudah mendengar cerita ini dari coders senior dan saya sudah melihatnya sendiri. Tampaknya ada lebih dari beberapa contoh programmer menulis kode tidak berguna. Saya akan melihat hal-hal seperti:

• Panggilan metode atau fungsi yang tidak ada artinya.
• Pemeriksaan berlebihan dilakukan dalam file, objek, atau metode kelas terpisah.
• if pernyataan yang selalu dievaluasi benar.
• Utas yang berputar dan tidak mencatat.

Hanya untuk beberapa nama. Saya telah diberitahu bahwa ini adalah karena para pemrogram ingin sengaja membuat kode membingungkan untuk meningkatkan nilai mereka sendiri kepada organisasi atau memastikan untuk mengulangi bisnis dalam hal pekerjaan kontraktual atau outsourcing.

Pertanyaanku adalah. Adakah orang lain yang melihat kode seperti ini? Apa kesimpulan Anda mengapa kode itu ada di sana?

Jika ada yang punya kode tertulis seperti ini, dapatkah Anda membagikan alasannya?

Saya telah mendengar pengembang yang mencoba membuat pencapaian coding mereka terdengar lebih kompleks daripada yang sebenarnya. Saya tidak pernah mendengar ada yang mengakui hal ini, tetapi saya telah melihat kode yang memenuhi kriteria Anda yang sengaja dibuat karena praktik yang tergesa-gesa atau buruk dan bukan sabotase. Kode yang mengelilingi kode memfitnah mungkin telah diubah ke titik di mana fungsi tertentu tidak lagi berguna.

Seseorang sebenarnya harus melihat kode ini secara langsung sebelum sampai pada kesimpulan bahwa hanya pengembang ini yang dapat mengelola kompleksitasnya. Sebagian besar manajer dan pebisnis lain sampai pada kesimpulan ini karena mereka tidak mengerti kode apa pun dan tidak ingin mengisi ulang posisi.

Saya belum melihat kode seperti ini tetapi saya telah melihat kode yang terlihat tidak berguna atau tidak ada gunanya karena alasan lain:

1. Kompatibilitas terbalik. Anda menemukan cara yang lebih baik untuk melakukan sesuatu tetapi Anda harus tetap tua (dan sekarang tidak terlalu berguna) API / fungsi karena beberapa modul pihak ketiga di luar sana mungkin menggunakan API / fungsi ini untuk sesuatu. Bahkan jika fungsi tidak melakukan sesuatu yang bermanfaat, tidak adanya itu dapat merusak beberapa kode.

2. Pengodean defensif. Anda tahu pemeriksaan dalam kode ini tidak ada gunanya karena ini sudah diperiksa di tempat lain. Tetapi bagaimana jika seseorang mengubah kode di tempat lain ini dan menghapus atau mengubah cek sehingga mereka tidak lagi cocok dengan prasyarat Anda?

3. Pertumbuhan organik. Dalam proyek-proyek besar, selama bertahun-tahun banyak hal berubah, dan ternyata beberapa metode yang digunakan sebelumnya tidak digunakan lagi, tetapi tidak ada yang mau menghapusnya karena tidak ada yang melacak apakah metode khusus ini digunakan atau tidak, mereka hanya refactored potongan kode mereka dan kebetulan itu mereka semua berhenti untuk menggunakan metode ini. Atau kondisi yang pernah memiliki makna tetapi aplikasi dire-refored di tempat lain sehingga kondisi menjadi selalu benar tetapi tidak ada yang mau menghapusnya.

4. Desain berlebihan. Orang mungkin mengkodekan beberapa hal "kalau-kalau kita membutuhkannya" dan tidak pernah benar-benar membutuhkannya. Seperti "mari kita menelurkan utas kalau-kalau kita harus melakukan pekerjaan offline" dan kemudian tidak ada yang meminta untuk melakukan sesuatu secara offline dan programmer lupa tentang itu dan pindah ke proyek lain (atau mungkin bahkan perusahaan lain) dan kode itu tetap ada selamanya karena tidak ada yang tahu mengapa itu ada di sana atau apakah aman untuk menghapusnya.

Jadi sementara saya belum pernah melihatnya dilakukan karena kedengkian atau pendekatan yang salah terhadap keamanan kerja, saya telah melihat banyak kali ketika itu terjadi sebagai hasil alami dari pengembangan perangkat lunak.

Pertanyaanku adalah. Adakah orang lain yang melihat kode seperti ini? Apa kesimpulan Anda mengapa kode itu ada di sana?

1) Ya.

2) Dalam kasus yang saya lihat, saya meletakkannya dengan berbagai cara ke:

• Programmer tidak berpengalaman
• Programmer tidak memahami desain yang rumit dan / atau tidak dilaksanakan dengan baik yang ia coba modifikasi
• Programmer terganggu di tengah (katakanlah) sebuah refactor.
• Kecerobohan

Sekarang mungkin saya menjadi dermawan tentang hal itu, tetapi pendekatan umum saya adalah bahwa lebih baik untuk memaafkan / tidak konfrontatif tentang hal-hal ini, daripada mengarahkan jari dan melanjutkan kualitas yang buruk. Jelas, hal-hal bisa menjadi cukup buruk sehingga sesuatu harus dilakukan , tetapi dorongan lembut ke arah yang benar biasanya cukup.

Tentu saja, Anda tidak dapat mengambil pendekatan laissez-faire seperti itu jika kualitas / kesalahan akan berdampak serius pada "bisnis". Tetapi dalam situasi itu Anda membutuhkan ulasan kode wajib dan rajin dari semuanya, dikombinasikan dengan prosedur pengujian yang komprehensif.

Dalam pengalaman saya, orang cenderung "terlalu ketat" tentang kode berkualitas buruk (setidaknya sebagian) karena itu menyinggung standar pribadi mereka. Sangat baik untuk (secara pribadi) mengusahakan kesempurnaan, tetapi agak tidak masuk akal untuk memproyeksikan standar pribadi Anda kepada orang lain. Dengan suara hal-hal (misalnya dari sifat contoh Anda), inilah yang Anda lakukan.

IMO, ini tidak produktif, dan tidak kondusif untuk hubungan kerja yang baik dengan rekan kerja Anda.

Semua itu sering merupakan gejala usia proyek.

 1. Panggilan metode atau fungsi yang tidak memiliki nilai. Ada banyak waktu ketika beberapa kode dibiarkan begitu saja (semoga dengan peringatan yang sudah usang , tetapi karena sebagian besar bahasa tidak memiliki peringatan itu, itu tidak selalu diikuti ...) karena, pada satu titik itu melayani beberapa tujuan yang tulus dan tidak ada yang tahu apa yang akan terjadi jika garis pelanggaran dihapus.

Sepertinya saya ingat ini dari dailywtf:

@deprecated // he might have been crazy enough to use reflection...
boolean getTrue() {
    return false; 
}

 2. Pemeriksaan berlebihan dilakukan dalam file, objek atau metode kelas yang terpisah. Lapisan komunikasi juga tidak sempurna (pernah membaca Mythical Man Month? Jika tidak, apa yang Anda lakukan di komputer !? Pergi! BACA!). Seringkali, satu orang akan mengerjakan sesuatu dan kemudian meninggalkan proyek, dan kemudian orang berikutnya, menemukan beberapa bug aneh, melempar cek tambahan di sana-sini untuk mencoba menghilangkannya. Ketika bug dihapus, cek bukan karena, yah, jika tidak rusak, jangan memperbaikinya.

 3. jika pernyataan itu selalu bernilai true. Oh, saya sudah melakukan ini. Saya mendapat satu proyek sekali, itu mungkin memiliki serangkaian 10-15 jika / blok lain . Untuk mengubah perilaku, saya cukup meletakkan true||di blok pertama. Tidak sampai berbulan-bulan (bertahun-tahun?) Kemudian saya kembali dan berkata, "Oh, wow, kode ini seharusnya dihancurkan tetapi tidak pernah ada"

 4. Utas yang terlepas dan tidak mencatat. Saya bisa membayangkan garis pemikiran seperti ini:

1. Aku tahu! Saya bisa menangani dua masalah ini secara asinkron! Saya akan membuat utas foo dan bar.
2. (dua bulan kemudian) Huh, Anda tahu, fungsi dari bar sedikit lebih baik di foo. Saya akan pindah.
3. (satu tahun kemudian) Anda tahu, memasukkan barang-barang lain dari bar ke foo masuk akal.
4. (bertahun-tahun kemudian) "Hei, barutas ini sepertinya tidak melakukan apa-apa, bisakah kita menghapusnya?" "Lebih baik tidak, itu sudah ada bertahun-tahun ..."

Saya sedikit lebih optimis. Saya pikir apa yang telah Anda descried sering terjadi ketika kode refactored dengan ceroboh.

Teman-teman lama memberi tahu saya tentang suatu masa ketika konsultan membayar sejumlah baris kode yang mereka hasilkan. Maka mereka memaksimalkan keuntungan menggunakan konstruksi yang bertele-tele.

Saat ini saya selalu menganggap pria itu masih belajar bahasa sambil melakukan pekerjaan. Dan dia sedang terburu-buru.

Sebagian besar jawaban mengacu pada dua fakta sederhana ini:
[1] Kode mencerminkan sejarah kode, dan
[2] Kode mencerminkan masa depan kode yang diharapkan.

Saya telah menulis fungsi-fungsi yang tidak memiliki nilai, DALAM LINGKUNGAN APLIKASI SAAT INI diberikan SPESIFIKASI SAAT INI, tetapi mungkin diperlukan di masa depan.

Saya telah menulis pernyataan if bahwa, SAAT INI, selalu mengevaluasi kebenarannya. Tapi mungkin di masa lalu itu bisa salah.

Mengenai cek berlebihan, hei, saya tidak percaya kode lain, saya bahkan tidak percaya kode saya sendiri. Jika sebuah modul bergantung pada N menjadi 1 atau 2 atau 3, modul tersebut akan lebih baik memastikannya, dan crash secara informal jika tidak. Adalah ilegal untuk Modul B meledak karena Modul A kacau; Modul B cukup sah untuk mengeluh bahwa Modul A kacau. Dan ingat bahwa, bulan depan, parameter itu mungkin berasal dari Modul C. yang belum ditulis

Saya telah melihat ini beberapa kali, bahkan baru kemarin, saya harus menggabungkan beberapa kode bos saya ke dalam aplikasi baru saya. Dalam kasusnya itu hanya karena kurangnya keterampilan dan pemahaman umum dan keyakinan bahwa dia pikir dia adalah pengembang yang cukup terampil.

"Panggilan metode atau fungsi yang tidak ada artinya." dan 'jika pernyataan yang selalu bernilai true' adalah masalah utama dengan kodenya.

Saya menduga bahwa meskipun banyak yang melihat kode yang memiliki masalah ini, hanya sedikit yang mau menulis yang sama. Dalam semua kemungkinan, apa yang Anda lihat adalah akumulasi perangkat lunak yang membusuk - seseorang menambahkan sesuatu, yang tidak benar-benar berfungsi, pemelihara berikutnya menambahkan kode pelindung lebih jauh di sepanjang rantai untuk menjaga terhadap kondisi yang tidak diperiksa dengan benar di awal. tempat; kemudian seseorang mendapat laporan masalah dan menambahkan lebih banyak pelindung terhadap contoh spesifik masalah; orang lain menambahkan pemeriksaan yang lebih umum dan lupa untuk menghapus beberapa kode lama yang ditambahkan sebelumnya yang berhubungan dengan gejala yang lebih spesifik, dll.

Lalu ada masalah pembersihan kode: tidak ada insentif khusus untuk menghapus apa yang tampak sebagai kode mati, dan insentif luar biasa untuk tidak melakukannya, karena jika Anda tidak memahami kode sepenuhnya, penilaian Anda bahwa kode itu "mati" akan menjadi cacat, dan Anda akhirnya akan merusak sistem.

• Panggilan metode atau fungsi yang tidak ada artinya.

Belum tentu buruk. Metode dalam kelas dasar sering memanggil metode kosong yang dimaksudkan sebagai titik override untuk subclass. Contoh: UIView Cocoa Touch memiliki -didAddSubview:metode yang didokumentasikan sebagai tidak melakukan apa pun dalam versi default. -addSubview:Metode UIView harus memanggil -didAddSubview:meskipun tidak melakukan apa-apa karena subclass dapat mengimplementasikannya untuk melakukan sesuatu. Metode yang tidak melakukan apa-apa dan alasannya harus didokumentasikan, tentu saja.

Jika fungsi / metode yang kosong atau tidak berguna jelas ada karena alasan historis, maka metode tersebut harus dikeluarkan. Lihatlah versi kode yang lebih lama di repositori kode sumber Anda jika Anda tidak yakin.

• Pemeriksaan berlebihan dilakukan dalam file, objek, atau metode kelas terpisah.

Sulit dikatakan kalau tidak apa-apa tanpa konteks. Jika cek jelas dilakukan untuk alasan yang sama, itu mungkin berarti bahwa tidak ada pemisahan tanggung jawab yang jelas dan beberapa refactoring diperlukan, terutama ketika kedua cek menghasilkan tindakan yang sama diambil. Jika tindakan yang dihasilkan dari kedua pemeriksaan tidak sama, maka kedua pemeriksaan tersebut mungkin dilakukan untuk alasan yang berbeda bahkan jika kondisinya sama, dan itu mungkin baik-baik saja.

• jika pernyataan itu selalu dievaluasi benar.

Ada perbedaan besar antara:

if (1) {
    // ...
}

dan:

if (foo() == true) {
    // ...
}

dimana foo()kebetulan selalu kembali true.

Kasus pertama sering terjadi ketika orang sedang melakukan debugging. Sangat mudah untuk menggunakan if (0) {...untuk menghapus serangkaian kode sementara saat Anda sedang mencoba untuk mengisolasi bug, dan kemudian mengubah 0untuk 1mengembalikan kode tersebut. The ifharus dihapus setelah Anda selesai, tentu saja, tapi mudah untuk melupakan langkah itu, atau kehilangan satu atau dua jika Anda sudah melakukannya di beberapa tempat. (Adalah ide bagus untuk mengidentifikasi persyaratan seperti itu dengan komentar yang nantinya bisa Anda cari.) Satu-satunya bahaya adalah kebingungan yang mungkin ditimbulkannya di masa depan; jika kompilator dapat menentukan nilai kondisi pada waktu kompilasi, itu akan menghapus seluruhnya.

Kasus kedua bisa diterima. Jika kondisi yang diwakili oleh foo()perlu diuji dari beberapa tempat dalam kode, memasukkannya ke dalam fungsi atau metode terpisah sering kali merupakan hal yang benar untuk dilakukan walaupun foo()selalu benar pada saat ini. Jika foo()mungkin akhirnya akan kembali false, mengisolasi kondisi itu dalam metode atau fungsi adalah salah satu cara untuk mengidentifikasi semua tempat di mana kode bergantung pada kondisi itu. Namun , melakukan hal itu menimbulkan risiko bahwa foo() == falsekondisi tersebut tidak akan diuji dan dapat menyebabkan masalah di kemudian hari; solusinya adalah memastikan bahwa Anda menambahkan unit test yang secara eksplisit menguji falsecase.

• Utas yang berputar dan tidak mencatat.

Ini terdengar seperti artefak sejarah, dan sesuatu yang dapat diidentifikasi baik selama tinjauan kode atau melalui profil periodik dari perangkat lunak. Saya kira itu bisa dibuat dengan sengaja, tetapi saya kesulitan membayangkan bahwa seseorang akan melakukan itu dengan sengaja.

Itu terjadi. Sebenarnya cukup sering.

Kadang-kadang jalan buntu pengkodean ini lebih seperti jalan kambing tua yang telah rusak ketika jalan bebas hambatan yang lebih efisien / modern / cepat telah dipasang di sekitar mereka.

Pada kesempatan lain (dan saya mungkin bersalah akan hal ini), mereka adalah fondasi untuk perpanjangan perangkat lunak ketika diminta penjelasan singkat, tetapi serangkaian fitur / fungsi yang diminta. (Kadang-kadang memasukkan sedikit pekerjaan di build awal menyediakan pegangan dan sejenisnya untuk pekerjaan selanjutnya yang Anda rencanakan untuk "dikunci" dapat membuat hidup lebih mudah, ketika itu terjadi, atau lebih sulit / berantakan jika pekerjaan lebih lanjut tidak berakhir dgn.)

Dan, banyak dari itu secara langsung karena yang lama "Jika tidak rusak, jangan cocok." Terkadang merobek kode yang tidak Anda mengerti, atau percaya tidak digunakan, dapat menyebabkan versi pemrograman "The Butterfly Effect". Pernahkah itu terjadi sekali atau dua kali juga.

Kadang-kadang saya memiliki set global boolean menjadi true, dan kemudian dalam kode saya jika (bool), maka selama runtime, saya mungkin menetapkan breakpoint pada pernyataan if, dan beralih boolean untuk menguji sesuatu.

Saya keberatan dengan if truepernyataan yang diklasifikasikan tanpa pandang bulu sebagai "kode tidak berguna".

Ada kasus yang sah untuk menggunakan if (1) { ... }blok dalam kode C yang ingin kompatibel dengan standar C yang menekankan definisi variabel pada awal fungsi, atau hanya ingin variabel lokal didefinisikan secara lokal mungkin.

switch (i) {
    case 23:
        if (1) {
            /* I can declare a local var here! */
        }
        break;
}

Seorang profesor saya menceritakan sebuah kisah kepada kami suatu hari bahwa majikan sebelumnya akan membayar mereka berdasarkan jumlah baris yang mereka selesaikan. Jadi, mereka menulis beberapa fungsi berjajar multi-lusin yang tidak pernah dipanggil. Sepertinya alasan yang bagus untuk menulis kode tidak berguna.

Seperti yang disebutkan oleh @Andy, komponen besar yang saya lihat melanggar YAGNI .

Seseorang mulai dengan asumsi tentang apa yang akan menjadi semua elemen alih - alih apa yang dibutuhkan banyak elemen , yang merupakan kebingungan dari hubungan "adalah a" dan "memiliki" .

Kebingungan ini mengarah pada struktur pewarisan yang kaku dan kemudian mereka adalah metode yang dibiarkan tidak diterapkan karena mereka tidak pernah benar-benar dipanggil, logika berulang di mana bagian-bagian perlu diubah, dan hanya alur kerja aneh yang umumnya tidak selaras dengan model bisnis.

Seperti banyak orang lain di sini, saya belum melihat ini dilakukan dengan jahat, tetapi karena kurangnya pengetahuan tentang desain yang baik dan upaya untuk membuatnya terlihat seperti itu kepada orang lain. Lucu, tampaknya pengembang bahkan kurang berpengetahuan tampaknya melakukan lebih baik dalam hal ini, karena setidaknya kode mereka tidak berakhir pada iklan yang terlalu banyak direkayasa. ( Prinsip CIUMAN )