Bagaimana programmer cepat & kotor tahu mereka melakukannya dengan benar?


166

Jika Anda bertanya kepada programmer mengapa mereka harus menulis kode bersih, jawaban nomor satu yang Anda dapatkan adalah rawatan. Sementara itu ada di daftar saya, alasan utama saya lebih cepat dan kurang altruistik: Saya tidak tahu apakah kode baru saya benar jika terlalu kotor. Saya menemukan bahwa saya telah fokus pada fungsi individu dan baris kode begitu banyak sehingga ketika saya menyelesaikan konsep pertama saya dan melangkah mundur untuk melihat gambaran besar lagi kadang-kadang tidak cocok bersama dengan sangat rapi. Menghabiskan satu atau dua jam refactoring untuk kebersihan sering mengungkap kesalahan copy / paste atau kondisi batas yang sangat sulit dideteksi dalam konsep kasar.

Namun, beberapa orang merasa kadang-kadang tidak apa-apa untuk sengaja memeriksa kode kotor demi kepentingan pengiriman perangkat lunak, dengan rencana untuk "membersihkannya nanti." Apakah ada beberapa teknik praktis yang memberi mereka kepercayaan pada kebenaran kode mereka ketika keterbacaan kurang dari ideal? Apakah keterampilan ini layak untuk dikembangkan? Atau apakah kurang percaya diri pada kode sesuatu yang oleh beberapa orang lebih mudah diterima?


40
Teori saya adalah bahwa semua coders berada di antara "memorizer" dan "dimengerti", dan sedikit yang bisa melakukan keduanya dengan baik. Semakin banyak omong kosong yang dapat Anda ingat sekaligus, semakin berantakan Anda mampu membuat kode Anda. Apakah kodenya bersih atau tidak, buat itu berfungsi, ujilah!
Pekerjaan

35
Namun, beberapa orang merasa kadang-kadang tidak apa-apa untuk sengaja memeriksa kode kotor demi kepentingan pengiriman perangkat lunak, dengan rencana untuk "membersihkannya nanti." heh ... neraka akan membeku sebelum " nanti " ...
Carlos Campderró

28
Tidak semua programmer berpikir sama - saya telah diberi kode untuk mempertahankan yang tidak masuk akal bagi saya selama berbulan-bulan, sampai suatu hari, rasanya seperti saklar lampu dibalik, ketika saya menyadari apa struktur pengorganisasian secara keseluruhan, dan itu semua masuk akal mengapa mereka melakukannya seperti yang mereka lakukan. Apakah saya akan melakukannya dengan cara itu? Tidak, tapi berhasil.
Joe

12
@ jo - +1 - beberapa programmer terlalu cepat untuk mengabaikan kode yang tidak sesuai dengan ide pribadi "kode yang baik". Anda harus selalu mencoba memahami pemikiran di balik tubuh kode dan gaya kodenya, sering kali Anda akan belajar sesuatu yang bermanfaat.
James Anderson

10
How do quick & dirty programmers know they got it right?Karena berhasil :)
Rachel

Jawaban:


100

Kode itu mungkin tidak benar.

Namun, itu mungkin tidak masalah.

Cepat dan kotor mungkin cara yang tepat untuk pergi dalam situasi di mana:

  • Kode ini memiliki masa pakai yang singkat . Misalnya, Anda mengubah banyak data menjadi format standar dengan program ad-hoc.
  • Dampak negatif kegagalan adalah rendah :
    • Data yang Anda transformasikan tidak kritis, dan kesalahan di dalamnya dapat dengan mudah diperbaiki
    • Pengguna akhir adalah pemrogram yang simpatik, yang akan memberi alasan tentang pesan kesalahan dan mengatasinya dengan, katakanlah, memijat input.

Terkadang tidak penting bahwa kode itu kuat dan menangani setiap input yang mungkin. Terkadang hanya perlu menangani data yang diketahui yang Anda miliki.

Dalam situasi itu, jika unit test membantu Anda mendapatkan kode yang ditulis lebih cepat (ini adalah kasus saya), maka gunakanlah. Kalau tidak, kode cepat dan kotor, selesaikan pekerjaan. Bug yang tidak memicu tidak masalah. Bug yang Anda perbaiki atau atasi saat bepergian tidak masalah.

Apa yang sangat penting adalah Anda tidak salah mendiagnosis situasi ini. Jika Anda mengkode dengan cepat dan kotor karena kode itu hanya akan digunakan satu kali, maka seseorang memutuskan untuk menggunakan kembali kode dalam beberapa proyek yang pantas mendapatkan kode yang lebih baik, kode itu layak mendapat perhatian lebih.


24
+1 untuk "dampak kegagalan rendah." Perhitungan risiko matematika favorit saya adalah risiko = konsekuensi aktual dari kegagalan x probabilitas kegagalan x anggapan konsekuensi kegagalan (Dalam pengalaman saya, risiko yang dirasakan para pemangku kepentingan sering terjebak)
Trav

7
"Kode ini memiliki masa pakai yang singkat. Misalnya, Anda mengubah banyak data menjadi format standar dengan program ad-hoc." Bagaimana jika transformasi tidak dilakukan dengan benar, tetapi perbedaan dalam data tidak diketahui sampai nanti?
Joey Adams

3
@ Trrav Jadi, hanya untuk mengonfirmasi, jika konsekuensi aktual dari kegagalan sangat besar, tetapi konsekuensi yang saya rasakan dari kegagalan adalah nol, tidak ada risiko sama sekali?
Christian Stewart

3
@ChristianStewart Dari sudut pandang matematika murni, pernyataan Anda akan benar. Namun, dalam praktiknya, persepsi konsekuensi menjadi nol tidak akan meniadakan bobot probabilitas x konsekuensi aktual. Persepsi ditempatkan ke dalam formula untuk memperhitungkan ketakutan organisasi yang sering memengaruhi keputusan mitigasi. Kurangnya ketakutan semacam itu tidak mengurangi probabilitas atau konsekuensi aktual. Dengan demikian, kita harus mengasumsikan bahwa persepsi selalu setidaknya sama dengan 1 (karena dapat memperbesar tetapi tidak meniadakan risiko yang sebenarnya)
Trav

1
@ Trus Atau, ganti nama satu. Yaitu, risiko harus ditukar dengan risiko yang dirasakan , karena jika kita percaya bahwa tidak ada konsekuensi kegagalan, kita kemungkinan juga percaya bahwa tidak ada risiko.
Delioth

237

Mereka tidak melakukannya. Saat ini saya sedang mengerjakan basis kode yang dibuat oleh programmer "cepat dan kotor" yang akan "membersihkannya nanti." Mereka sudah lama hilang, dan kodenya hidup terus, berderit menuju terlupakan. Cowboy coders , secara umum, sama sekali tidak memahami semua mode kegagalan potensial yang mungkin dimiliki perangkat lunak mereka, dan tidak memahami risiko yang mereka hadapi pada perusahaan (dan klien).


31
Setiap kali saya mendengar "bersihkan nanti" atau "kita akan melakukannya ketika segalanya melambat sedikit" Saya selalu tergoda untuk mulai bernyanyi "Besok, Besok, aku akan mencintaimu besok. Itu selalu sehari-hari awaayyyyy." Tapi itu bisa saja aku.
JohnFx

8
Banyak dari kita berada dalam posisi yang agak disayangkan. Sangat tidak menyenangkan diwariskan hutang teknis orang lain .
Mark Booth

34
Masalah sebenarnya adalah mengklasifikasikan pemrogram lain menjadi koboi atau judul cepat & kotor atau lainnya. Setiap programmer memiliki beberapa mode kegagalan, dan membaca kode orang lain sangat sulit, dan menemukan kegagalan Anda sendiri sangat sulit. Semua ini bersama-sama berarti bahwa orang terlalu mudah memberi label programmer lain sebagai yang buruk, sambil berpikir bahwa kode mereka sendiri sempurna
tp1

3
@ tp1: Pemrogram yang baik dapat menulis kode yang mudah dibaca. Mereka melakukan ini dengan meminta orang lain membacanya, dan mengklarifikasi apa pun yang tidak jelas. Dengan latihan, bagian yang tidak jelas pada bacaan pertama akan menyusut.
kevin cline

9
@ Jim Thio, apakah Anda serius berpikir bahwa salah satu programmer yang disebutkan di atas pernah sengaja menulis kode buruk? Pernahkah Anda membaca kode yang ditulis sendiri beberapa tahun yang lalu? Apakah menurut Anda itu baik? Kemungkinannya adalah, Anda melakukan yang terbaik saat itu, dan Anda masih melihat banyak hal yang harus diperbaiki dalam kode itu sekarang.
Péter Török

103

Oke, dengan risiko menjadi umpan balik yang sempurna, aku akan "mendukung setan" pandangan yang berlawanan.

Saya mengusulkan agar kita para pengembang memiliki kecenderungan untuk terlalu khawatir tentang hal-hal seperti praktik yang tepat dan kebersihan kode. Saya menyarankan bahwa, sementara hal-hal itu penting, tidak ada yang penting jika Anda tidak pernah mengirim .

Siapa pun yang pernah berkecimpung dalam bisnis ini mungkin akan setuju bahwa mungkin saja mengutak-atik perangkat lunak kurang lebih tanpa batas. Duke Nukem Forever, teman-temanku. Ada saatnya ketika fitur yang bagus untuk dimiliki atau pekerjaan refactoring yang sangat mendesak harus dikesampingkan dan hal itu harus disebut DONE.

Saya sudah sering bertengkar dengan rekan kerja tentang hal ini. Ada SELALU satu tweak lagi, sesuatu yang "harus" dilakukan agar itu menjadi "benar". Anda SELALU dapat menemukannya. Pada titik tertentu, di dunia nyata, cukup baik harus cukup baik. Tidak ada perangkat lunak pengiriman dunia nyata, aktual, yang sempurna. Tidak ada Paling-paling, ini cukup bagus.


9
Atau mungkin jika itu digunakan, sulit, selama beberapa dekade, itu kemungkinan akan berakhir tampak berantakan. Jika tidak digunakan (sama sekali, atau lama), itu tidak akan memiliki kesempatan untuk mengakumulasi cruft.
berguna

7
"Siapa pun yang pernah berkecimpung dalam bisnis ini mungkin akan setuju bahwa mungkin saja bermain-main dengan perangkat lunak kurang lebih tanpa batas." Itu mungkin, tetapi mengapa melakukannya? Setelah Anda menetapkan standar kualitas Anda, Anda mendesainnya, mengimplementasikannya, mengujinya, memperbaiki bug, mengujinya lagi, dan kemudian tidak menyentuhnya lagi. Dibutuhkan lebih lama dari sekadar meretasnya, tetapi begitu Anda telah mencapai tujuan Anda (fungsionalitas yang diperlukan diimplementasikan dan diuji) cukup jelas bahwa Anda tidak boleh lagi mengutak-atik kode. Hanya 2 sen saya.
Giorgio

7
+1 - di dunia nyata akan selalu ada pertukaran antara kualitas kode dan tenggat waktu rapat. Saya lebih suka memiliki seorang programmer yang dapat menghasilkan kode yang masuk akal dengan cepat daripada seorang perfeksionis yang menghabiskan waktu berbulan-bulan untuk menyiksa apakah ia harus memanggil metode "serialisasi" atau "writeToFile".
James Anderson

3
kamu mengatakannya. Saya telah bekerja di sebuah organisasi di mana di ruangan sebelah adalah sebuah tim yang telah bekerja pada persyaratan fungsional untuk sistem baru selama 5 tahun terakhir, tidak ada baris kode yang pernah ditulis untuk itu. Banyak coder yang sama (terutama junior, baru lulus dari perguruan tinggi dengan ide-ide tinggi tentang kode harus cantik dan memenuhi "standar" tertentu kalau tidak buruk) dan akan, kecuali dihentikan, bermain-main tanpa henti dengan sesuatu yang berfungsi sempurna beberapa bulan yang lalu (saya terkadang masih memiliki kecenderungan itu, saya pikir kita semua punya). Tetapi pada akhirnya, yang penting adalah mengeluarkannya.
jwenting

6
@Iorgio: Saya tidak setuju dengan "takhayul" Anda bahwa pekerjaan berkualitas membutuhkan waktu lebih lama dari sekadar meretasnya. Itu mungkin benar jika Anda menyamakan pemrograman dengan mengetik. Mempertimbangkan seluruh siklus hidup perangkat lunak, banyak hal berjalan lebih lancar dan karenanya lebih cepat jika Anda peduli dengan kualitas.
ThomasX

85

Pemrogram seperti itu hampir tidak pernah tahu mereka melakukannya dengan benar, hanya percaya begitu. Dan perbedaannya mungkin tidak mudah dipahami.

Saya ingat bagaimana dulu saya memprogram sebelum saya belajar tentang pengujian unit. Dan saya ingat perasaan percaya diri dan kepercayaan pada tingkat yang sama sekali berbeda setelah saya menjalankan serangkaian tes unit pertama yang layak. Saya belum tahu tingkat kepercayaan seperti itu pada kode saya yang ada sebelumnya.

Untuk seseorang yang tidak memiliki pengalaman ini, tidak mungkin untuk menjelaskan perbedaannya. Jadi mereka bahkan dapat terus berkembang dalam mode kode-dan-berdoa sepanjang hidup mereka, dengan penuh belas kasih (dan bodoh) percaya bahwa mereka melakukan yang terbaik dengan mempertimbangkan keadaan.

Yang mengatakan, memang bisa ada programmer hebat dan kasus luar biasa, ketika seseorang benar-benar berhasil memegang seluruh ruang masalah dalam pikirannya, dalam keadaan aliran penuh. Saya telah mengalami saat-saat langka seperti ini, ketika saya benar-benar tahu apa yang harus ditulis, kode hanya terbang keluar dari saya dengan mudah, saya bisa melihat semua kasus khusus dan kondisi batas, dan kode yang dihasilkan hanya berfungsi . Saya tidak ragu ada jenius pemrograman di luar sana yang dapat tetap dalam keadaan aliran untuk waktu yang lama atau bahkan sebagian besar waktu mereka, dan apa yang mereka hasilkan adalah kode yang indah, tampaknya tanpa usaha. Saya kira orang-orang seperti itu mungkin merasa tidak perlu menulis tes unit kecil untuk memverifikasi apa yang sudah mereka ketahui. Dan jika Anda benar-benar jenius, itu mungkin baik-baik saja (meskipun demikian, Anda tidak akan berada di sekitar proyek itu selamanya, dan Anda harus memikirkan penerus Anda ...). Tetapi jika tidak ...

Dan mari kita hadapi itu, kemungkinan Anda tidak. Aku, untuk diriku sendiri, tahu aku bukan. Saya mengalami saat-saat mengalir yang langka - dan kesedihan dan kesedihan yang tak terhitung jumlahnya, biasanya disebabkan oleh kesalahan saya sendiri. Lebih baik jujur ​​dan realistis. Bahkan, saya percaya para programmer terbesar sepenuhnya menyadari kesalahan mereka sendiri dan kesalahan masa lalu, sehingga mereka secara sadar mengembangkan kebiasaan mengecek asumsi mereka dan menulis unit test kecil itu, untuk menjaga diri mereka di sisi yang aman. ( "Saya bukan programmer yang hebat - hanya programmer yang baik dengan kebiasaan yang hebat." - Kent Beck.)


8
"Dengan penuh belas kasihan (dan bodoh) percaya bahwa mereka melakukan yang terbaik dengan mempertimbangkan keadaan." Ringkasan masalah yang sempurna. # 1 bergegas karena kendala dan melakukan yang terbaik yang dia bisa. # 2 datang dan telah mewarisi kekacauan ditambah tenggat waktu baru dan melakukan yang terbaik juga. Semua jalan ke jiwa miskin ke-20 yang tidak bisa melakukan yang terbaik jika dia punya tahun untuk memperbaiki kerusakan. Itu sebabnya saya mempraktikkan aturan Pramuka, "biarkan lebih bersih daripada yang Anda temukan." Berikan kesempatan getah berikutnya untuk bertarung - mungkin Anda.
Steve Jackson

1
Lucu, saya merasakan hal yang sebaliknya sejak saya mulai unit menguji kode saya (di tempat kerja). Ini seperti menjadi malas; tidak ada alasan untuk benar - benar memahami kode Anda, karena kode lain akan menangkap kesalahan untuk Anda
Izkata

8
Anda menulis unit test sebagian untuk membuktikan bahwa kode Anda sendiri berfungsi. Lebih penting lagi, Anda menulis unit test sehingga pengembang lain dapat mengubah kode Anda dengan percaya diri.
Stephen Gross

4
Donald Knuth: "Waspadalah terhadap bug dalam kode di atas; Saya hanya membuktikannya benar, tidak mencobanya." haacked.com/archive/2007/11/29/…
MarkJ

1
@Izkata - jika Anda tidak mengerti apa yang Anda lakukan, tes unit mungkin rusak, dan memvalidasi bahwa kode memiliki kesalahan yang sama dengan tes. Juga, bahkan dengan cakupan keputusan 100% dan pengujian unit yang akurat, dimungkinkan (meskipun tidak biasa) memiliki bug yang tidak diungkapkan oleh pengujian.
Steve314

33

Tes unit . Ini satu-satunya cara untuk memiliki kepercayaan pada kode apa pun (kotor atau tidak).

Di samping catatan;

jalan pintas membuat penundaan lama (Pippin)


6
Kutipan yang bagus, tapi itu bukan Gandalf. Itu adalah Pippin, berdebat mengapa dia, Frodo dan Sam tidak boleh melintasi negara ke Buckleberry Ferry, tepat di perjalanan awal dari Hobbiton.
Daniel Roseman

22
Koreksi: "Tes unit. Satu-satunya cara untuk memiliki rasa aman palsu dalam kode (kotor atau tidak)". Tes unit bagus untuk dimiliki, tetapi tidak menjamin apa pun.
Coder

8
Ketika saya ingin mengungkap bug tersembunyi, saya menunjukkan aplikasi kepada bos saya. Saya menyebutnya tes bos, itu harus dilakukan setelah pengujian unit. Dia memiliki aura magnetisme yang menarik semua jenis bug aneh serta sinar kosmik langsung ke register CPU.
Tuan Smith

8
Sementara kami mengutip, Anda mungkin juga menyukai "Pengujian menunjukkan keberadaan, bukan ketiadaan bug" - Edsger Dijkstra
Timothy Jones

2
-1 tes tidak akan membuktikan kode berantakan benar - unit test tidak MEMBERIKAN apa-apa, mereka memberi Anda kepercayaan diri tetapi tidak bernilai lebih dari itu. Mereka adalah ukuran yang baik, hanya saja jangan anggap mereka berarti lebih dari itu sub-bagian kecil dari kode bekerja persis seperti yang Anda tulis, itu tidak mengatakan Anda menulisnya dengan benar atau bahwa itu akan berinteraksi dengan benar dengan hal lain. Meskipun mereka pada umumnya ukuran yang baik tetapi mereka tidak membantu dengan kode jelek dan benar-benar akan memperburuk dengan memberi Anda lebih banyak kode untuk diubah dengan masing-masing refactor.
Bill K

15

Adalah baik untuk belajar menerima bahwa tidak ada sistem perangkat lunak dengan kompleksitas yang masuk akal akan sempurna tidak peduli berapa banyak pengujian unit dan penyesuaian kode yang dilakukan. Beberapa tingkat kekacauan dan kerentanan terhadap yang tak terduga akan selalu mengintai di dalam kode. Ini tidak berarti bahwa seseorang tidak boleh mencoba untuk menghasilkan kode yang baik atau melakukan tes unit. Ini tentu saja penting. Ada keseimbangan yang harus dicari dan ini akan bervariasi dari proyek ke proyek.

Keterampilan yang akan dikembangkan adalah pemahaman tentang tingkat 'kesempurnaan' apa yang perlu digunakan untuk proyek tertentu. Misalnya, jika Anda menulis aplikasi rekam medis elektronik dengan jangka waktu proyek 12 bulan, Anda akan ingin mencurahkan lebih banyak waktu untuk pengujian dan memastikan kode Anda dapat dipertahankan daripada yang Anda lakukan untuk aplikasi web pendaftaran konferensi konferensi satu kali yang harus dikerahkan pada hari Jumat. Masalah muncul ketika seseorang yang melakukan aplikasi EMR menjadi ceroboh atau aplikasi pendaftaran tidak dapat digunakan tepat waktu karena programmer terlalu sibuk mengutak-atik kode.


1
+1 untuk menunjukkan bahwa keputusan tentang ukuran kualitas harus dibenarkan oleh kebutuhan bisnis.
Stephen Gross

+1 untuk * "Keterampilan yang akan dikembangkan adalah pemahaman tentang tingkat 'kesempurnaan' apa yang perlu digunakan untuk proyek tertentu." ... Tetapkan standar minimum untuk berapa banyak "penyesuaian" yang menurut perusahaan Anda akan dapat diterima risiko dalam hal kualitas, kemudian patuhi itu.
S.Robins

11

Cepat dan kotor baik-baik saja dalam suatu subsistem . Jika Anda memiliki antarmuka yang terdefinisi dengan baik antara omong kosong Anda dan seluruh sistem, dan satu set unit tes yang baik yang memverifikasi bahwa Anda kode cepat dan kotor jelek melakukan hal yang benar, mungkin baik-baik saja.

Misalnya, mungkin Anda memiliki peretas mengerikan ekspresi reguler dan offset byte untuk mem-parsing beberapa file yang berasal dari pihak ketiga. Dan anggap Anda memiliki tes yang mengatakan bahwa hasil yang Anda dapatkan dari parsing file contoh adalah apa yang Anda harapkan. Anda dapat membersihkan ini sehingga Anda bisa ... Saya tidak tahu, bereaksi lebih cepat ketika pihak ketiga mengubah format file? Itu tidak cukup sering terjadi. Kemungkinan besar mereka akan berubah menjadi API yang sama sekali baru dan Anda akan membuang parser lama dan memasukkan yang baru yang sesuai dengan API yang sama, dan voila, Anda sudah selesai.

Di mana cepat dan kotor menjadi masalah adalah ketika arsitektur Anda cepat dan kotor. Objek domain inti Anda perlu dipikirkan dengan baik, dan antarmuka Anda, tetapi ujung-ujung sistem Anda biasanya dapat berantakan tanpa harus membayar piper.


1
Untuk mengatakan dengan kata lain - modul bisa Q&D, tetapi arsitekturnya harus bersih.
Kromster

9

Inilah kisah tentang seorang programmer yang cepat dan kotor yang saya tahu.

Saya kenal seseorang yang menganggap unit test hanya buang-buang waktu. Setelah banyak perdebatan, dia akhirnya menulis satu. Itu terdiri dari satu metode panjang yang ditaburi dengan && dan || dan mengembalikan boolean ke assertTrue. Pernyataan ini mencakup 20 baris. Kemudian lagi, ia menulis sebuah kelas di mana setiap metode memiliki satu baris dan yang utama memiliki lebih dari 1000 baris tanpa spasi putih. Itu adalah dinding teks. Ketika saya meninjau kodenya dan memasukkan beberapa baris baru, dia bertanya 'mengapa'. Saya berkata 'Karena keterbacaan'. Dia menghela nafas dan menghapusnya. Dia memberi komentar di atas, "Jangan menyentuhnya, itu berhasil!"

Terakhir kali saya berbicara dengannya, dia membuat kode sebuah situs web untuk sebuah perusahaan. Dia sedang berusaha menemukan bug. Dia menghabiskan 3 hari terakhir melakukan itu selama 8 jam sehari. Beberapa saat kemudian saya berbicara dengannya lagi, dan ternyata rekan setimnya mengubah nilai literal dan tidak memperbaruinya di tempat lain. Itu tidak konstan. Jadi dia mengubah literal lainnya juga sehingga bug nya diperbaiki. Dia mengeluh tentang kode spageti rekan setimnya. Dia mengatakan kepada saya 'Haha, tidakkah kita semua tahu bagaimana rasanya begadang sepanjang malam dengan debugger, tidak tidur dengan satu bug jahat "Dia pikir ini adalah sesuatu yang benar-benar baik dilakukan oleh programmer dan dia benar-benar merasa senang tentang hal itu.

Juga, menurutnya membaca buku dan blog pemrograman tidak berguna. Dia berkata, 'mulailah pemrograman'. Dia telah melakukannya selama 12 tahun dan dia pikir dia adalah programmer yang sangat baik. /Telapak tangan


Ini beberapa lagi.

Lain waktu kami menulis kelas DatabaseManager untuk aplikasi web kami. Dia memasukkan semua panggilan basis data ke dalamnya. Itu adalah kelas Dewa dengan lebih dari 50 metode untuk setiap hal yang dapat dibayangkan. Saya menyarankan kita memecahnya menjadi subclass karena tidak setiap controller perlu tahu tentang setiap metode database. Dia tidak setuju, karena 'mudah' hanya memiliki satu kelas untuk seluruh database dan 'cepat' untuk menambahkan metode baru kapan pun kami membutuhkannya. Pada akhirnya, DatabaseManager memiliki lebih dari 100 metode publik dari mengautentikasi pengguna ke pengurutan lokasi situs arkeologi.


1
+1. Untuk beberapa alasan saya suka membaca cerita-cerita itu. Mereka bahkan tidak membuat saya sedih atau marah lagi.
sam hocevar

-1 untuk menulis segala jenis _______ kelas Manajer.
Brian Driscoll

@SamHocevar Lari, jangan berjalan, ke thedailywtf.com
Mawg

7

Pelajaran saya dalam menghindari hal-hal yang cepat dan kotor adalah ketika saya memiliki enam bulan untuk menyampaikan apa yang diperkirakan (di bawah perkiraan) sebagai pekerjaan selama satu tahun. Saya memutuskan untuk meneliti metodologi sebelum mulai bekerja. Pada akhirnya saya menginvestasikan tiga bulan penelitian dan dapat menghasilkan dalam tiga bulan yang tersisa.

Kami mendapat keuntungan besar dengan mengidentifikasi fungsionalitas umum dan membangun perpustakaan yang diperlukan untuk menangani persyaratan tersebut. Saya masih melihat coders menulis kode mereka sendiri ketika ada rutinitas perpustakaan yang tersedia. Coder ini sering menulis ulang, atau paling baik memotong dan menempelkan, kode yang sama ketika mereka perlu menyelesaikan masalah yang sama nanti. Perbaikan bug selalu hanya menangkap beberapa salinan kode.

Salah satu pengembang memberi jawaban yang jelas ketika saya memintanya untuk menggunakan kode perpustakaan: "Bukankah itu curang? Saya harus menulis semua kode saya sendiri di sekolah."


1
Cukup pengembang etis yang Anda miliki di sana!
Stephen Gross

6

Dalam beberapa kasus, saya kira mungkin ada serangkaian besar uji regresi yang akan menemukan "semua" bug dan memverifikasi perilaku, sehingga memungkinkan teknik pengkodean yang cepat dan kotor. Tapi sebagian besar itu hanya masalah perencanaan proyek yang buruk dan seorang manajer yang berpikir lebih penting untuk menyelesaikannya, daripada menyelesaikannya dengan benar.

Dan lupakan "bersihkan nanti", itu tidak pernah terjadi. Dalam kasus yang jarang terjadi, programmer akan lupa sebagian besar kode membuat pekerjaan jauh lebih mahal daripada jika dia melakukannya dengan benar pertama kali.


6

Produk dikirimkan.

Kode tidak ada dalam ruang hampa. Saya telah menderita kesengsaraan pemadam kebakaran akibat konsekuensi dari coding cepat dan kotor dan koboi. Tetapi kadang-kadang menyelesaikan produk adalah prioritas, bukan mencari cara untuk menulis kode terbaik. Pada akhirnya, jika produk dikirimkan dan bekerja dengan cukup baik, pengguna dan pelanggan tidak akan tahu atau peduli seberapa "buruk" kode di dalamnya, dan saya akan mengakui ada saat-saat ketika saya tidak peduli sama sekali tentang "mendapatkannya" benar "selama aku mengeluarkannya.

Ya, ini dalam masalah organisasi dan "seharusnya tidak pernah terjadi." Tetapi jika Anda kebetulan menulis kode di organisasi yang tidak dikelola dengan baik dan sangat tenggat waktu, pada level programmer individu pilihan seseorang terbatas.


5

Saya tidak berpikir mereka dapat dengan jujur ​​mengatakan bahwa mereka melakukannya dengan benar jika tidak mudah dipelihara. Jika mereka mengakui bahwa mereka harus "membersihkannya nanti", maka ada kemungkinan sesuatu yang belum cukup mereka pikirkan. Mengujinya secara menyeluruh hanya akan benar-benar mengungkap masalah dengan kode kotor.

Saya pribadi tidak akan bertujuan untuk mengembangkan keterampilan "menulis kode kotor" dan menjadi percaya diri tentang kebenarannya. Saya lebih suka menulis kode yang tepat saat pertama kali.


5

Bagaimana mereka tahu mereka melakukannya dengan benar? Pengujian adalah jawaban sederhana.

Jika kode mereka telah diuji secara menyeluruh oleh tim QA yang baik dan lolos, maka saya akan mengatakan mereka benar.

Menulis kode cepat dan kotor bukanlah sesuatu yang harus dilakukan sebagai kebiasaan tetapi pada saat yang sama ada saat-saat ketika Anda dapat menghabiskan 20 menit menulis kode yang dapat digolongkan sebagai kotor atau 4 jam refactoring banyak kode untuk melakukannya dengan benar. Dalam dunia bisnis terkadang hanya 20 menit yang tersedia untuk melakukan pekerjaan itu dan ketika Anda menghadapi tenggat waktu yang cepat dan kotor mungkin satu-satunya pilihan.

Saya sendiri sudah berada di kedua ujung ini, saya harus memperbaiki kode kotor dan harus menulis sendiri untuk mengatasi keterbatasan sistem yang saya kembangkan. Saya akan mengatakan saya memiliki kepercayaan pada kode I menulis karena walaupun itu kotor dan sedikit peretasan kadang-kadang saya memastikan itu benar-benar diuji dan telah banyak dibangun dalam penanganan kesalahan jadi jika ada sesuatu yang salah itu tidak akan menghancurkan sisa sistem.

Ketika kita melihat ke bawah pada programmer yang cepat dan kotor ini kita perlu mengingat satu hal, pelanggan umumnya tidak membayar sampai mereka memiliki produk, jika itu dikirim dan mereka pergi ke pengujian UAT dan menemukan bug dari kode cepat dan kotor itu adalah jauh lebih kecil kemungkinannya mereka akan keluar ketika mereka memiliki produk yang hampir berfungsi di depan mereka, namun jika mereka tidak memiliki apa-apa dan Anda mengatakan kepada mereka "Anda akan segera mendapatkannya, kami baru saja memperbaiki x" atau "itu tertunda karena kami harus mendapatkan y bekerja dengan sempurna "mereka lebih cenderung menyerah dan pergi dengan pesaing.

Tentu saja seperti yang ditunjukkan gambar ini, tidak seorang pun boleh meremehkan bahaya kode cepat dan kotor! masukkan deskripsi gambar di sini


4

Saya tidak berpikir Anda harus mulai menyusuri jalan itu. Cepat dan kotor mungkin memberi Anda manfaat sementara untuk menyelesaikan lebih cepat, tetapi Anda selalu membayar sepuluh kali lipat untuk melakukan ini pada akhirnya.


5
Kadang-kadang Anda tidak akan punya uang jika Anda tidak mengirim sekarang ... tetapi pengiriman sekarang, memungkinkan Anda membayar "sepuluh kali lipat" untuk membersihkannya, dan kemudian beberapa karena Anda mengalahkan pesaing Anda ke pasar, dan mendapat pengenalan merek terlebih dahulu.
CaffGeek

2
Saya mohon untuk berbeda. Jika uang sudah ketat, Anda membelanjakan penghasilan untuk produk berikutnya dan Anda akan terus melakukannya sampai perusahaan Anda mati atau menjadi cukup besar. Dalam kasus terakhir dan kemungkinan besar, pengembang asli tidak akan ada lagi untuk memperbaiki kode lama.
Raku

Mengalahkan orang lain ke pasar bukan jaminan bahwa publik akan menerima produk Anda. Jika suatu produk mengandung terlalu banyak kekurangan, lebih baik Anda berharap Anda memiliki uang tunai ekstra untuk menerapkan pemasaran asap dan cermin yang baik, dan memiliki hubungan yang cemerlang dan memaafkan dengan basis pelanggan Anda. Ini bukan posisi salah satu / atau ini. Kuncinya adalah menyeimbangkan risiko vs imbalan, dan merilis produk berkualitas tinggi yang dapat Anda berikan tepat waktu. Keahlian Anda akan dinilai oleh kualitas produk yang Anda rilis, dan kerusakan yang dapat dilakukan oleh perangkat lunak yang cacat terhadap gambar Anda tidak dapat diperbaiki.
S.Robins

1
Mohon untuk berbeda semua yang Anda suka, tetapi sejarah penuh dengan contoh di mana berada di sana pada waktu yang tepat, tersedia untuk siapa pun yang menginginkannya, lebih penting daripada menjadi produk terbaik. Selalu ada biaya peluang, selalu selalu.
Warren P

1
Warren, pada dasarnya itulah yang saya katakan. Di mata saya biaya peluang untuk mendapatkan kode kembali ke yang dapat dipertahankan tumbuh, secara eksponensial, semakin lama Anda menunda itu. Jika perusahaan Anda berada dalam posisi di mana ia dapat selamat dari bencana yang tidak dapat diatasi karena penjualan berjalan dengan baik dan kode tidak terlalu kotor, bagus, tetapi bagaimana jika tidak?
Raku

4

Menurut pendapat saya, belajar menilai kode Q&P untuk kebenaran bukanlah keterampilan yang layak dikembangkan karena itu hanya praktik yang buruk. Inilah alasannya:

Saya sama sekali tidak berpikir "cepat dan kotor" dan "praktik terbaik". Banyak coder (termasuk saya) telah membuat kode cepat dan kotor sebagai akibat dari kemiringan dalam kendala triple . Ketika saya harus melakukannya, itu biasanya merupakan hasil dari creep lingkup dikombinasikan dengan tenggat waktu yang semakin dekat. Saya tahu kode yang saya periksa tersedot, tetapi ia mengeluarkan output yang layak diberikan satu set input. Sangat penting bagi para pemangku kepentingan kami, kami mengirim tepat waktu.

Melihat pada Laporan CHAOS asli membuatnya cukup jelas bahwa Q&D bukan ide yang baik dan akan menghabiskan anggaran nanti (baik dalam pemeliharaan atau selama ekspansi). Mempelajari cara menilai apakah kode Q&P benar atau tidak hanya membuang-buang waktu. Seperti yang dikatakan Peter Drucker, "Tidak ada yang sia-sia daripada melakukan secara efisien apa yang seharusnya tidak dilakukan sama sekali."


3

Saya tidak tahu apakah kode baru saya benar jika terlalu kotor.

"Kotor" artinya berbeda untuk orang yang berbeda. Bagi saya, itu sebagian besar berarti bergantung pada hal-hal yang Anda tahu Anda mungkin tidak harus mengandalkan, tetapi yang Anda juga tahu bahwa Anda dapat berharap untuk bekerja dalam waktu dekat. Contoh: dengan anggapan bahwa tombol tingginya 20 piksel alih-alih menghitung tingginya; mengkodekan alamat IP alih-alih menyelesaikan nama; mengandalkan array yang akan diurutkan karena Anda tahu itu, meskipun metode yang menyediakan array tidak menjaminnya.

Kode kotor itu rapuh - Anda dapat mengujinya dan tahu bahwa itu berfungsi sekarang , tapi ini taruhan yang cukup bagus bahwa itu akan pecah di beberapa titik di masa depan (atau memaksa semua orang berjalan di atas kulit telur karena takut merusaknya).


3

Dengan risiko terdengar sedikit kontroversial, saya berpendapat bahwa tidak ada yang benar-benar TAHU bahwa kode mereka 100% benar dan 100% tanpa kesalahan. Bahkan ketika Anda memiliki cakupan pengujian yang sangat baik dan Anda menerapkan praktik BDD / TDD yang baik, Anda masih dapat mengembangkan kode yang mengandung kesalahan, dan ya itu bahkan dapat mengandung efek samping!

Hanya menulis kode dan menganggapnya berfungsi menyiratkan kepercayaan yang berlebihan pada pihak pengembang atas kemampuan pengembang itu sendiri, dan bahwa ketika masalah muncul (yang pasti akan terjadi) upaya untuk debug dan mempertahankan kode akan mahal, terutama jika pengembang lain membutuhkan untuk mempertahankan kode nanti. Perbedaan nyata dibuat dengan menerapkan praktik rekayasa perangkat lunak yang baik, yang memastikan bahwa Anda dapat benar-benar percaya bahwa kode Anda kemungkinan besar akan berfungsi sebagian besar waktu, dan bahwa jika Anda menemukan kesalahan, lebih mungkin untuk lebih mudah melakukan debug dan jauh lebih murah untuk mengubah dan memelihara terlepas dari orang yang bekerja pada kode itu nanti.

Poin penting adalah bahwa kode yang difaktorkan dengan baik dan teruji dengan baik akan membuat ORANG LAIN memiliki kepercayaan terhadap kode Anda, yang dalam banyak kasus lebih penting daripada kepercayaan diri Anda sendiri.


2

Jika kode kotor diuji dengan baik, itu bisa dipercaya. Masalahnya adalah, unit yang menguji kode kotor biasanya sangat sulit dan rumit. Inilah sebabnya mengapa TDD sangat baik; itu mengungkapkan dan menghilangkan kotoran dan bau. Juga, pengujian unit sering kali merupakan hal pertama yang menderita karena tekanan waktu. Jadi, jika orang terbersih yang pernah membuat kode terbersih yang pernah dia lakukan, saya masih tidak akan mempercayainya sedikit pun, jika dia menghilangkan tes unit karena preassure waktu.


2

Pemrogram yang baik (Cepat & Kotor dan lainnya) tidak memiliki keangkuhan untuk menganggap mereka sudah benar. Mereka berasumsi bahwa semua sistem besar memiliki bug dan kekurangan, tetapi bahwa pada titik tertentu mungkin cukup baik diuji dan ditinjau untuk memiliki risiko yang cukup rendah atau biaya kegagalan yang cukup rendah yang dapat dikirimkan oleh kode.

Jadi mengapa ini, yang disebut Quick & Dirty, programmer, ada? Hipotesis saya adalah seleksi Darwin. Programmer yang mengirimkan kode yang bisa diterapkan dengan cepat, kadang-kadang mengirim sebelum kompetisi dikirimkan, atau anggaran habis, atau perusahaan bangkrut. Oleh karena itu perusahaan mereka masih dalam bisnis mempekerjakan programmer baru untuk mengeluh tentang kekacauan yang harus dibersihkan. Disebut juga kode kapal bersih, tetapi tidak cukup berbeda untuk mendorong koders Quick & Dirty ke kepunahan.


Ini benar. Saya telah melihat setidaknya satu produk yang dapat dikirimkan karena kode Cepat & Kotor, kutil dan semuanya. Kebetulan beberapa hari vs sebulan di depan berarti dua bulan lompatan di kompetisi. Produk menjadi sukses dan kode Cepat & Kotor akhirnya diganti dengan kode yang lebih baik. Sejak melihat bahwa saya mencoba melakukan pekerjaan yang lebih baik untuk melihat kualitas kode saya tidak hanya dari sudut pandang teknik tetapi juga dari sudut pandang bisnis / kompetitif. Catatan: antarmuka kode tersebut baik-baik saja, itu implementasi yang samar.
J Trana

0

Orang mungkin berpikir bahwa bagian yang tidak optimal dari suatu kode tidak dapat membuat perbedaan, karena masa hidup yang singkat, sedikit dampak dalam bisnis, atau sedikit waktu untuk menyelesaikannya. Jawaban yang benar adalah Anda tidak benar-benar tahu. Setiap kali saya mendengarkan seseorang mengatakan bahwa "ini adalah fitur kecil", atau "mari kita buat secepat dan sesederhana mungkin" dan menghabiskan waktu yang tidak cukup untuk memikirkan desain yang tepat, hanya dua hal yang benar-benar terjadi. adalah:

1-) Proyek menjadi lebih besar dan motivasi tim lebih rendah, mengerjakan kode yang penuh "jahitan". Dalam hal ini, proyek akan memungkinkan jalur cepat menuju kekacauan.

2-) Proyek ini dikenal sebagai solusi yang tidak optimal dan penggunaannya mulai tidak disarankan, mendukung solusi baru atau refactoring yang semahal solusi baru.

Coba selalu lakukan kode terbaik yang Anda bisa. Jika Anda tidak punya cukup waktu, jelaskan mengapa Anda membutuhkan lebih banyak. Jangan menempatkan diri Anda dalam risiko dengan pekerjaan yang buruk. Selalu menjadi profesional yang lebih baik. Tidak ada yang bisa menghukum Anda untuk ini jika Anda masuk akal. Jika ya, itu bukan tempat Anda harus bekerja.


0

Diskusikan dengan senior dan nilai dampak kegagalan jika ada. Misalnya situasi di mana Anda dapat memperbaiki kotor membutuhkan waktu 1 hari dan kode yang kuat membutuhkan perubahan desain dan arsitektur yang mungkin memakan waktu 4-6 bulan + waktu validasi tambahan untuk sepenuhnya memvalidasi semua alur kerja yang terkena dampak perubahan desain.

Kita harus mengambil keputusan berdasarkan Waktu + Kapasitas + Prioritas dalam daftar juga. Diskusi yang baik dalam tim dengan senior atau orang-orang dengan pengalaman yang lebih tinggi dapat membantu mengambil keputusan yang paling sesuai dengan tim dan hasilnya.

Kode bersih adalah pendekatan pertama dan terpenting di mana sebagai kode kotor untuk menyimpan eskalasi, keputusan go / no go dari klien, tunjukkan penghenti, reputasi organisasi di tiang pancang dan banyak lagi di mana kode kotor membuatnya menjadi kode bersih.


4
ini tampaknya tidak menawarkan sesuatu yang substansial atas poin yang dibuat dan dijelaskan dalam 23 jawaban sebelumnya
nyamuk
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.