Saya terpaksa menulis kode yang buruk. Bagaimana cara menyelamatkan wajah saya? [Tutup]


69

Saya hanya pengembang junior tetapi pekerjaan saya memaksa saya untuk bekerja dengan kode PHP yang sangat buruk (pikirkan kode PHP terburuk yang pernah Anda lihat; lalu pikirkan tentang kode yang dua kali lebih buruk). Saya biasanya mencoba untuk memperbaiki bug dan bertarung dengan basis kode untuk menambahkan fitur baru. Kadang-kadang saya diperintahkan untuk membuat hal-hal bekerja SECEPATNYA yang lebih sering melibatkan hacks kotor.

Produk ini sebelumnya merupakan open source dan saya khawatir produk tersebut akan menjadi open-source di masa depan. Saya akan malu jika seseorang (terutama pengusaha potensial) dapat menemukan nama saya di samping beberapa perubahan. Apa yang bisa saya lakukan untuk melindungi nama baik saya?

Saya tidak yakin apakah ini relevan tetapi saya akan menambahkan bahwa bos saya atau kolega saya tidak mau mengakui bahwa kode itu buruk, tetapi saya tidak yakin saya bisa menyalahkan mereka untuk itu - bagi banyak dari mereka ini adalah milik mereka pekerjaan pertama.


21
Bagaimana Anda dipaksa untuk menulis kode yang buruk? Mengapa Anda tidak bisa berdiri, berhenti memasukkan nama Anda ke kode yang buruk, dan menjelaskan masalah, solusi, biaya dalam hal waktu, tenaga, dan uang, dan manfaat memperbaiki masalah sekarang kepada atasan Anda?
Thomas Owens

17
"mendorong peretasan cepat dan kotor"? Mendorong? Yang lebih buruk. Kebanggaan Anda (dan menemukan pekerjaan baru) atau bertahan dengan pekerjaan ini. Mungkin tidak buruk untuk membela apa yang benar. Apa yang menghentikanmu? Ancaman kekerasan? Pemerasan? Proses pidana? Serius. Apa yang membuat Anda berhenti menulis kode yang bagus? Harap spesifik . Dan jujur.
S.Lott

113
Jika ada penghiburan, bahkan kode bagus yang Anda tulis hari ini akan terlihat buruk bagi Anda dalam lima tahun.
Kyralessa

7
hadapi itu PHP mendorong "cepat dan kotor" dengan tidak mengecilkannya dan membuatnya mudah dilakukan. Sebenarnya saya akan mengatakan PHP unggul di "qucik dan kotor" lebih baik daripada bahasa lain, kecuali mungkin Perl, sekali momentum itu ditetapkan, itu adalah sulit untuk berhenti terutama jika manajemen mendorong perilaku juga. Pada akhirnya kode yang tampaknya berfungsi, terlepas dari praktik lebih berharga bagi perusahaan daripada tidak ada kode sama sekali.

7
Maaf tetapi ada cara yang benar dan salah untuk menulis kode. Cara yang benar menggunakan praktik industri standar; cara buruk hacks bersama-sama dan mengatakan itu "berhasil".
Wayne Molina

Jawaban:


132

Roma tidak dibangun dalam sehari, tetapi Anda bisa menjadi 'Pramuka' yang baik. Setiap kali Anda menyentuh kode, biarkan lebih baik dari sebelumnya. Tidak perlu banyak waktu untuk menggunakan nama fungsi yang masuk akal, standar pengkodean yang baik, dan memberikan komentar yang layak saat Anda bekerja.

Saya pikir bahayanya adalah memikirkan semuanya atau tidak sama sekali. Hanya karena Anda tidak dapat menghabiskan waktu Anda ingin menulis kode yang elegan, tidak berarti Anda harus benar-benar menyerah dan menulis sampah.


2
+1. Anda tidak harus mengorbankan semua yang Anda yakini hanya untuk membuatnya cepat diperbaiki.
Pelaku

4
+1: untuk semua atau tidak sama sekali - sangat benar.
Umber Ferrule

3
Aturan Pramuka di tangan yang salah bisa menjadi penyebab masalah, karena definisi 'nama fungsi yang masuk akal' dari atasannya bisa 'bolChkLst' (notasi hungaria untuk memenuhi styleguide, ChkLst bukannya Checklist karena 'pendek lebih baik lebih baik '). Berikut adalah beberapa implementasi Aturan Kepanduan yang saya temui di pekerjaan yang berbeda yang saya coba tidak ikuti: 'Gabung fungsi, memiliki sesedikit mungkin', 'jangan membawa argumen melalui 3 panggilan, gunakan global', 'gunakan inline SQL dalam pandangan untuk buat lebih cepat '
keppla

40
+1 untukEvery time you touch the code, leave it better than it was before.
Qwerky

3
+1. Jika Anda memiliki banyak perbaikan jelas yang dilakukan, siapa pun yang benar-benar melihat kontribusi Anda tidak akan berpikir Anda seorang programmer yang jelek. Pengusaha potensial yang menganggap Anda jelek karena proyeknya jelek bukan orang yang Anda inginkan.
Matius Baca

59

Setuju dengan S.Lott dari komentar * (untuk sekali :) Tidak ada yang memaksa Anda untuk menulis kode yang buruk. Masalahnya, junior dev. sering (situs ini juga yang harus disalahkan untuk itu) tersesat dalam praktik terbaik, "kode indah", ... apa pun yang Anda ingin menyebutnya ... dan mereka tidak banyak selesai; atau mereka menyelesaikannya tetapi membuang banyak waktu. Dengan menyuruh mereka untuk menulis kode buruk (yang merupakan kode yang juga berfungsi) itu mendapat daripada "melalui itu", hanya membuat mereka memberikan sesuatu. Seiring waktu berlalu yang menghasilkan bahwa (sekarang tidak lagi :) junior dev sangat cepat muncul dengan solusi cepat & kotor, tetapi menghabiskan sisa waktu untuk memperbaikinya. Dan seiring berjalannya waktu, Anda belajar lebih banyak, dan pada titik tertentu Anda mulai memberikan solusi cepat & kotor yang sebenarnya adalah kode yang baik.

Tetapi, jika Anda mengikuti jalan Anda dan mencoba menulis kode yang sempurna dari awal, Anda kemungkinan besar akan menghabiskan banyak waktu, dan tidak melakukan apa-apa.

Jadi ... tulis kode buruk, ... banyak ... kode yang nyaris tidak berfungsi, lalu ITERATE. Setiap iterasi sedikit lebih baik!

Tidak ada yang menulis solusi sempurna pertama kali.

* ini, kalau saja lebih pendek akan menjadi komentar.


1
+1 Saya sangat setuju dengan jawaban ini. Saya akan mendukung Anda dua kali.
Vitor Py

3
Saya setuju. Ini adalah cara yang bagus untuk memotong "analisis kelumpuhan," yang dapat bertahan saat Anda mencoba mencapai solusi "sempurna" untuk suatu masalah. Saya menulis sesuatu yang serupa di StackOverflow .
Kyralessa

4
+1. Saya sudah membaca ini pada programmer (tapi tidak tahu sumbernya): dua kelompok ditugaskan untuk membuat tembikar dalam jangka waktu tertentu. Satu untuk membuat item dengan kualitas terbaik dan satu untuk membuat item sebanyak mungkin. Pada akhirnya, kelompok yang terakhir menyediakan item dengan kualitas yang lebih baik, karena pengulangan adalah jalan menuju penguasaan. Perenungan saja akan membuat Anda ke mana-mana. Pada akhirnya, kita semua belajar dengan melakukan dan ketakutan kita untuk melakukan sesuatu yang salah adalah yang menahan kita dalam mencoba, mungkin gagal, tetapi pasti belajar dari kesalahan kita.
back2dos

1
Sebagai akibat wajar, gunakan repositori! Bahkan jika itu hanya masalah pribadi yang telah Anda atur di komputer Anda sendiri. Setelah Anda mulai menggunakannya, Anda menyadari betapa membebaskannya membuat banyak perubahan, mengetahuinya tidak berhasil, dan memutar balik. Favorit pribadi saya adalah fosil
Spencer Rathbun

1
"Jadi ... tulis kode buruk, ... banyak ... kode yang hampir tidak berfungsi, dan kemudian ITERATE. Setiap iterasi sedikit lebih baik!" Bagaimana jika Anda tidak pernah bisa beralih karena proyek baru terus menumpuk ... dan Anda mulai menyadari bahwa apa yang Anda dorong keluar sebagai alpha cenderung bertahan sampai proyek mati. Yang tentu saja dipercepat sebagai hasil dari kode awalnya menyebalkan dan kurangnya pembaruan. Saya pikir ini adalah situasi seperti ini yang menidurkan banyak devs junior untuk berpikir mereka perlu menulis "kode yang indah" dari awal ...
Serhiy

40

Komentar kode adalah teman Anda di sini.

Setiap kali Anda merasa harus menulis peretasan murah karena tekanan, katakan saja seperti, "Kode ini berlaku X karena kendala waktu. Idealnya, saya akan melakukan Y sebagai gantinya. - Ashamed One, 5 Juli 2011"

Kemudian jika calon pemberi kerja melihatnya, mereka akan menyadari Anda lebih suka menulis kode yang baik, tetapi Anda juga bersedia menyesuaikan gaya pengkodean Anda dengan kebutuhan bisnis. Kebanyakan majikan akan melihat keduanya sebagai hal yang baik.


4
Persis. Komentar dan komit juga. Saya belum pernah melakukannya, tetapi akan menarik untuk mengevaluasi pengembang berdasarkan tidak lain dari perubahan beranotasi yang dikaitkan dengan mereka di beberapa vcs.
timdev

baik, Anda dapat mengatakan sesuatu tentang seseorang yang komentar komitnya "diperbaiki", "selesai", "blahblahblah" :)
gbjbaanb

+1 Saya telah melakukan ini beberapa kali dan dalam kasus rekan pengembang hanya berfungsi.
Jacek Prucia

7
Saya biasanya menghapus komentar seperti itu setiap kali saya menemukannya. Sebuah komentar yang ditandai sebagai TODO atau PERINGKAT MASA DEPAN mungkin layak untuk tinggal, tetapi permintaan maaf hanyalah sampah.
Kristopher Johnson

1
Setuju dengan memasukkan penjelasan mengapa solusi yang kurang optimal diimplementasikan (dan apa solusi itu) saya lakukan ini dari waktu ke waktu. Namun saya tidak berpikir itu sesuatu yang memalukan atau meminta maaf. Itu hanya berarti ada hal-hal yang lebih penting untuk dilakukan pada saat Anda mengerjakan potongan kode itu dan implementasi yang diberikan sudah cukup.
Justin Ohms

10

Itu tergantung pada bagaimana mereka memaksa Anda.

Dalam pengalaman saya, ada dua kemungkinan:

Anda merasa dipaksa oleh jadwal yang ketat, kode lama, dll.

Dalam hal ini, seperti sebagian besar jawaban lain sudah katakan, terserah Anda untuk 'mengoptimalkan kesejukan'. Anda mungkin tidak punya waktu untuk menulis ulang basis kode ke MVC, tetapi sebagai langkah pertama, misalnya, Anda dapat berhenti menempelkan SQL dengan tangan dan alih-alih menulis yang bagus execute_sql($query, $params), yang meletakkan dasar untuk abstraksi seperti fetch_customer($filter_params), dll. Ingat, semua yang terbaik praktik akhirnya ada di mana atasan Anda mendapatkan produk lebih awal, sehingga hanya ada konflik dalam berapa banyak waktu untuk berinvestasi di masa depan vs di saat ini.

Ketika Anda mengatur konteks yang tepat ('dalam 6 bulan, tanpa mendapatkan waktu tambahan, saya refactored kode monolitik ke MVC') Anda harus meninggalkan nama Anda pada kode, dan mencoba untuk menjadi bangga seperti terapis, yang mengajarkan korban stroke untuk ucapkan satu kata lagi.

Anda secara eksplisit diperintahkan untuk mengimplementasikannya dengan cara yang Anda anggap tidak layak

Mencoba memisahkan tampilan dari model tidak bertahan dalam ulasan, karena 'terlalu rumit, mengapa Anda tidak melakukan kueri sql sederhana?'. Anda execute_sqldikalengkan karena 'seorang pembuat kode dengan disiplin tidak membutuhkan itu'.

Kasus ini sangat buruk. Dalam pengalaman saya, biasanya datang dengan manajemen mikro dan pemimpin tim yang dipromosikan di sana karena alasan politik, bukan karena keberhasilan mereka. Masalah sebenarnya adalah, bahwa Anda bertanggung jawab atas sesuatu (kode) yang tidak dapat Anda kontrol (Anda harus melakukannya dengan cara mereka). Solusi terbaik adalah menyelesaikan akar permasalahan (yaitu, bahwa Anda diperlakukan sebagai penggerutu). Solusi terbaik kedua (dan menurut pengalaman saya, yang biasa) adalah berhenti.

Sisi baiknya adalah, bahwa dalam skenario ini, nama Anda kemungkinan besar tidak akan dipublikasikan, karena ketua tim mengambil kredit untuk semua kesuksesan.


8

Saya cukup yakin atasan Anda menuntut Anda memberikan sesuatu dengan cepat, tetapi bukan berarti Anda mengambil upaya ekstra untuk membuatnya dengan sengaja buruk. Yang berarti bahwa setiap kali Anda memiliki pilihan antara kode yang benar-benar buruk dan kode yang sedikit lebih buruk, dan kedua opsi akan membawa Anda sama lama untuk diimplementasikan, Anda memilih opsi yang sedikit kurang buruk. Itu solusi jangka pendek, dan itu tidak membutuhkan usaha sama sekali.

Untuk jangka panjang, bicarakan dengan atasan Anda. Jelaskan bagaimana berinvestasi 15 menit di sini dapat menghemat waktu di sana. Pastikan Anda memiliki contoh yang meyakinkan - bukan tipe "jika saya melakukan ini dan itu di sini, harapan saya adalah bahwa saya akan dapat melakukan hal lain ini tahun depan", tetapi, "lihat, di sini saya melakukan hal ini, dan karena itu, saya butuh tiga jam untuk menemukan masalah di sana; jika saya melakukannya dengan cara ini dan itu, bug akan segera terlihat ". Peringatan di sini: sementara kode yang elegan dan dapat dipelihara terasa jauh lebih baik dan lebih efisien, kadang-kadang tidak. Ada beberapa situasi di mana perbaikan cepat yang ceroboh dibenarkan secara sempurna: kadang-kadang Anda menulis kode sekali pakai, kadang-kadang Anda membiarkan sepotong sampah yang ketinggalan zaman tetap hidup, menunggu hal yang nyata; kadang-kadang, manfaat dari solusi yang tepat tidak

Jika semuanya gagal, cari pekerjaan lain.


3

Tidak ada yang memaksa Anda untuk menulis kode yang buruk. Anda dapat membalikkan situasi ini dan menjadikannya positif. Perubahan pelopor untuk kebijakan dan prosedur. Dan kamu juga tidak bisa selalu menjadi pria / wanita "ya". Jika mereka mengatakan mereka membutuhkan fungsionalitas x sebelum akhir hari, beri tahu mereka itu tidak layak, tetapi berikan alasan mengapa memang tidak layak. Jika ada masalah, tawarkan solusi. Bukan hanya mata yang buta, atau lebih buruk ... menambahnya.

Toko pengembang Anda bukan yang pertama memiliki tenggat waktu yang ketat, namun tetap memiliki keinginan untuk mempertahankan kode yang direkayasa dengan baik.


4
-1: Di AS, jika bos Anda mengatakan "Tulis kode jelek cepat", dan Anda menolak melakukannya, mereka bisa memecat Anda. Tidak mematuhi instruksi langsung untuk melakukan sesuatu yang legal adalah alasan untuk penghentian secara paksa. Jadi sementara itu mungkin tidak "memaksa" Anda, alternatif untuk melakukan apa yang dikatakan atasan Anda mungkin jauh lebih buruk.
Bob Murphy

Itu semua tergantung pada pendekatan Anda. Idealnya Anda akan memiliki sosok unggul yang akan menghargai keahlian Anda dan penilaian Anda harus sangat dihargai. Sering kali orang-orang yang menentukan waktu bukanlah pengembang, dan mereka harus mempertimbangkan apa yang mungkin dan apa yang tidak. Tentu saja Anda dapat menulis kode "jelek" di bawah selimut, tetapi dorongan balik mungkin cukup sehingga semua orang senang: hasil yang baik dari kode yang baik.

1
Angka-angka superior ideal yang tidak benar-benar bekerja untuk Anda itu hebat, tetapi orang yang menandatangani gaji Anda adalah orang yang harus Anda tolong. Memiliki penagih tagihan menelepon setiap saat ketika Anda keluar dari pekerjaan benar-benar menyebalkan.
Bob Murphy

1
Ada lebih dari itu untuk kepentingan pribadi. Saya telah menjadi manajer dan pengusaha, dan saya dapat meyakinkan Anda bahwa jika semua pelanggan membayar dengan cepat dan kotor, melakukan pekerjaan yang baik yang kehilangan uang akan menyebabkan orang-orang diberhentikan. Saya harus memberhentikan seluruh perusahaan sekali, dan saya tidak pernah ingin melakukannya lagi. Jadi, sementara saya jelas mendukung pendirian moral ... menulis kode jelek biasanya bukan masalah moral, dan pada satu titik seseorang harus memilih antara preferensi pribadi dan masalah praktis orang yang memiliki atau tidak memiliki pekerjaan.
Bob Murphy

1
Saya hampir tidak akan pernah menyarankan penulisan ulang besar-besaran dari sistem besar, tetapi itu tidak berarti bahwa kode yang Anda tulis di masa depan harus mengerikan.
PeterAllenWebb

3

Setiap perusahaan perlu menemukan keseimbangan antara menulis kode yang brilian, dengan dokumentasi yang luas dan tes unit dan membawa produk ke pasar dalam anggaran yang wajar dan ruang waktu.

Kode terbaik di dunia tidak masalah jika sudah usang sebelum dirilis.

Menjadi pragmatis adalah tentang mencoba menemukan keseimbangan itu. Memperbaiki fitur-fitur dengan cepat mungkin sangat penting secara komersial saat ini, bukan berarti selalu demikian.

Dibutuhkan banyak pengalaman (Lebih dari kebanyakan coders yang pernah ada), untuk mendapatkan keseimbangan ini dengan benar. Sangat mudah digunakan untuk kedua ekstrim. Menemukan jalan tengah lebih sulit.

Saya tidak mengatakan bos Anda benar. Sebagai seorang pembuat kode, ada godaan untuk mencoba membuat kode-kode indah secara terus-menerus yang tidak layak secara komersial. Menyadari godaan ini dapat membantu Anda menyadari bahwa beberapa peretasan ini tidak terlalu buruk.

Sebagian besar kode setelah waktu yang cukup akan berisi peretasan untuk situasi tertentu yang terlalu mahal untuk diubah menjadi kerangka umum.


2

Saya ingin menambahkan bahwa Anda tidak boleh terus seperti Anda melakukannya sekarang, tidak mengatakan apa-apa dan hanya peretasan dan peretasan.

Anda perlu berdiri dan menunjuk kode konkret dan memberi tahu mereka apa yang menyebalkan tentang itu. Spesifik dan gunakan metrik kode untuk mencadangkan klaim Anda. Tidak ada yang lebih memalukan daripada mengklaim kode itu buruk padahal sebenarnya tidak, Anda hanya tidak mengerti apa yang sedang dilakukan.

Saya yakin ada banyak alat yang tersedia gratis untuk digunakan untuk analisis kode php http://en.wikipedia.org/wiki/Code_analysis

Juga, tentu saja ini http://en.wikipedia.org/wiki/Code_smell

Bacalah, simpulkan apa yang dapat Anda temukan di aplikasi Anda, dan tentu saja daftarkan alternatifnya . Praktek yang buruk untuk hanya berdiri dan berteriak "Saya tidak suka bagaimana ini dilakukan" tanpa menghadirkan alternatif (lebih baik) cara yang lebih baik untuk melakukannya.

Peretasan cepat membutuhkan biaya. Dan jangan melihatnya sepenuhnya negatif - Anda dapat belajar banyak dari pekerjaan ini sekarang dan dapat mengambil manfaat dari pengalaman yang Anda buat di pekerjaan Anda berikutnya.

hth


0

Sebelum hal lain, Anda DO menggunakan kontrol sumber dari beberapa jenis, kan? Jika tidak, mulailah dari sana. Ini akan membantu Anda terlebih dahulu dan diadopsi oleh anggota tim lainnya dengan cepat.

Jika Anda memiliki kontrol sumber, Anda tidak boleh memasukkan nama Anda dalam kode, cukup masukkan nama perusahaan Anda. Adalah umum dalam kode yang buruk untuk menempatkan riwayat revisi di komentar di bagian atas file, ini lebih baik didelegasikan ke kontrol sumber.

Sekarang, mengenai kualitas kode, Anda tidak akan dapat mengubahnya sebagai pendekatan yang hebat. Perlahan, satu per satu, tambahkan pendekatan baru untuk berbagai masalah. Jika Anda melakukannya dengan benar, itu akan menghemat waktu dan Anda akan menggunakannya untuk membuat kualitas keseluruhan menjadi lebih baik.

Sebagai contoh, saya pernah tiba di tengah proyek dengan aplikasi Perl / CGI di mana semua HTML ada dalam kode. Seluruh aplikasi berada dalam satu file tanpa struktur yang jelas. Tidak ada yang versi. Saya mulai dengan mengkonfigurasi repo CVS (tidak ada SVN tersedia pada saat itu), meletakkan antarmuka web untuk pelanggan. Pada awalnya, saya sendiri menangani komit dari rekan-rekan saya. Kemudian, saya membagi semua metode dalam berbagai modul (file). Pada saat itu, para kolega mulai mengadopsi CVS. Lalu, saya memindahkan HTML dari kode. Kemudian, setiap kali saya harus melakukan perubahan pada beberapa bagian kode, saya mengambil sedikit waktu untuk memperbaiki sebagian darinya. Pada akhirnya, kecepatan pengembangan telah meningkat sedemikian rupa sehingga pelanggan sangat senang. Mereka akan meminta perubahan kosmetik dan bukannya kami memberi tahu mereka "itu akan memakan waktu 2 hari",

Namun pendekatan ini hanya akan berfungsi jika Anda menguasai kode keseluruhan dengan cukup baik. Jika Anda tidak memahami gambaran besarnya, jika beberapa bagian aplikasi tetap tidak dapat dipahami, itu akan membuat pekerjaan Anda sangat sulit.

Satu hal lagi, penulisan ulang yang lengkap terkadang merupakan satu-satunya solusi tetapi biasanya sangat sulit untuk membenarkan biayanya kepada manajemen.


0

Karena Anda adalah pengembang junior, ini sebenarnya adalah hal yang baik. Menjadi terlempar ke tengah kekacauan kode besar akan mengajarkan Anda lebih banyak tentang apa yang tidak boleh dilakukan daripada hanya bekerja pada kode 'bersih' yang sempurna. Manfaatkan situasi ini dan pelajari cara memperbaiki kode buruk dan perlahan-lahan mengubahnya menjadi sesuatu yang lebih mudah dikelola. Dan jangan mengeluh tentang itu harus SECEPATNYA. Itulah intinya - belajar memperbaiki dan membersihkan kode sambil melakukan sesuatu di bawah tenggat waktu yang ketat. Lagi pula, siapa pun dapat menulis kode yang sempurna jika mereka memiliki waktu tanpa akhir.

Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.