Aturan tidak tertulis untuk menulis ulang kode anggota tim lain [ditutup]


40

Kami mempraktikkan kepemilikan kode kolektif. Untuk pemahaman saya ini berarti bahwa setiap pengembang dapat mengubah setiap baris kode untuk menambah fungsionalitas, untuk memperbaiki, memperbaiki bug atau meningkatkan desain.

Tapi bagaimana dengan penulisan ulang kode dari pengembang yang masih dalam tim? Haruskah saya bertanya padanya dulu? Apa praktik terbaik?


5
Saya tidak dapat melihat ada salahnya menghapus kode jika perlu - asalkan Anda menggunakan kontrol sumber. Jawaban lain untuk pertanyaan ini menggambarkan etika menghapus kode orang lain dengan cukup baik.
Anonim

9
Saya tidak berpikir ini secara khusus disebutkan dalam salah satu jawaban [luar biasa]: bahkan jika kode yang sudah ada layak untuk ditulis ulang, jika bekerja sekarang, sangat mungkin buang-buang waktu [uang] untuk menulis ulang. Saya telah belajar bahwa dalam banyak skenario, cepat dan kotor adalah jalan yang harus ditempuh. Anda dibayar untuk menulis kode, jadi Anda harus seefisien mungkin. Anda tidak perlu kerangka kerja yang dirancang dengan baik untuk sesuatu yang hanya akan dijalankan beberapa kali. Anda tidak ingin menghabiskan waktu seminggu untuk melakukan sesuatu yang bisa dilakukan dalam sehari menggunakan praktik desain yang buruk. Banyak kali manajer lebih suka pendekatan ini.
taz

9
@taz - Ini adalah dasar dari pola Big Ball of Mud ( laputan.org/mud ).
Matius Flynn

@ MatthewFlynn - Artikel bagus. Ungkapan "Big Ball of Mud" muncul berkali-kali, rasanya seperti pengalaman deja vu dari "Latihan" Allan Iverson ( youtube.com/watch?v=eGDBR2L5kzI ). ;-)
Happy Green Kid Naps

3
Membutuhkan lebih banyak konteks. Mengapa Anda mengubah kode, apa cakupan perubahan - jam, hari, minggu, bulan kerja. Siapa yang membayar perubahan dan apakah itu benar-benar dibutuhkan. Siapa yang menyetujui perlunya perubahan. Apa yang Anda proses dan bagaimana itu gagal sehingga Anda masuk ke kekacauan ini untuk memulai.
mattnz

Jawaban:


62

Saya pikir komunikasi yang baik selalu merupakan praktik terbaik. Bicaralah dengan pengembang dan lihat apakah ada alasan mengapa dikodekan seperti itu. Mungkin saja mereka bermaksud untuk kembali dan memperbaikinya selama bertahun-tahun, mungkin mereka melakukannya dengan alasan yang sangat bagus, atau mungkin Anda berdua dapat belajar sesuatu dari percakapan.

Masuk dan menulis ulang tanpa komunikasi sebelumnya adalah resep untuk niat buruk.


1
Yap, saya telah belajar dari pengalaman bahwa beberapa pengembang bisa sangat gelisah jika Anda bahkan memperbaiki bug dalam kode mereka tanpa bertanya. Tentu saja, ini pada proyek tanpa pelacakan masalah atau perencanaan tugas, dan saya kagum bahkan pernah dikirimkan.
halus

+1 untuk "berbicara dengan pengembang" - kami memiliki bug (well, setidaknya satu, mungkin lebih) yang pelanggan harapkan ... Dan sejauh ini terkubur bahwa saya adalah satu-satunya yang samar-samar tahu mengapa dibiarkan sendirian.
Izkata

3
Saya tidak setuju dengan "komunikasi yang baik" pada prinsipnya, tetapi saya pikir jawaban ini sedikit basi. Dengan mengabaikan semua pertanyaan sulit tentang keadaan apa yang menyebabkan pertanyaan ini ditanyakan, sama sekali tidak masalah apakah pengembang menjawab "ya" atau "tidak" untuk pertanyaan "haruskah saya menulis ulang kode Anda?" , karena itu belum tentu akan menjadi jawaban yang terbaik untuk tim atau produk. Tentu, kita harus mencoba menemukan semua yang bisa tentang asumsi dan keputusan semula, tetapi bagaimana kita tahu bahwa OP belum melakukan itu?
Aaronaught

2
@Aaronaught - Pertanyaan apakah akan menanyakan pengembang asli terlebih dahulu menyiratkan bahwa OP belum berbicara dengan pengembang asli dan dengan demikian belum mencoba menemukan semua yang dia bisa. Saya harap jawabannya adalah kebalikan dari basi - itu mendasar.
Matthew Flynn

1
Jika Anda benar-benar mempraktikkan kepemilikan kode kolektif, maka Anda memiliki hak untuk mengubah, menulis ulang, atau menghapus kode apa pun kapan pun Anda anggap pantas. Ini terutama benar jika Anda melakukan pemrograman berpasangan. Sekarang, setelah mengatakan itu, sebelum perubahan besar (seperti penulisan ulang) kode yang telah ditulis beberapa orang tertentu, akan lebih bijak untuk membicarakannya dengan mereka. Dalam kebanyakan kasus saya telah melihat (termasuk dengan kode saya sendiri), tanggapan mereka adalah, "Oh ya; maaf! Kode itu adalah bencana; Saya hanya tidak melakukannya dengan benar. Berikut adalah beberapa ide tentang bagaimana memperbaikinya Silakan jalankan dengan itu! "
Jeff Grigg

35

Dasar pemikiran dari pertanyaan ini menimbulkan sejumlah kekhawatiran bagi saya bahwa saya tidak berpikir ada jawaban yang ada yang cukup untuk diatasi. Izinkan saya mengajukan beberapa pertanyaan lanjutan di sini:

  1. Apakah Anda benar-benar yakin bahwa Anda sedang berbicara tentang menulis ulang dan bukan refactoring? Menurut definisi, perubahan gaya atau struktur kode yang menghasilkan implementasi yang ditingkatkan (atau hanya berbeda) tanpa perubahan pada perilaku eksternal adalah refactor, bukan penulisan ulang. Memecah rutin 500-baris monolitik menjadi satu set 50 subrutin mungkin melibatkan penulisan sedikit kode baru, tetapi itu bukan penulisan ulang. Istilah rewrite menyiratkan membuang seluruh produk atau fitur dan memulai dari awal; itu bukan sesuatu yang bisa dianggap enteng.

  2. Jika perilaku kode asli sangat salah, atau implementasinya sangat tidak praktis sehingga memerlukan penulisan ulang yang lengkap, mengapa tidak ditangkap oleh proses tim Anda dan ditangani dalam konteks yang tepat (yaitu secara teknis daripada sosial)? Kode yang buruk atau patut dipertanyakan harus terbuka dengan cepat pada tim yang sehat melalui tes, ulasan kode, ulasan desain, dll. Apakah Anda memilikinya?

  3. Apakah manajer / pimpinan teknologi mengetahui masalahnya, dan jika tidak, mengapa tidak? Apa pun jenis proses yang Anda miliki, kualitas kode biasanya merupakan tanggung jawab manajer pengembangan. Dia adalah orang pertama yang Anda harus tanyakan - jelas bukan dalam konteks "begitu dan begitu menulis kode omong kosong" tetapi hanya "Saya pikir saya melihat masalah besar di sini, dapatkah kita berbicara tentang penulisan ulang?" Jika tidak menjamin jenis diskusi ini, maka mungkin itu tidak menjamin penulisan ulang juga?

  4. Jika ukuran dan ruang lingkup kode yang menyinggung cukup besar untuk menjamin diskusi serius tentang penulisan ulang, mengapa itu secara eksklusif dimiliki oleh satu pengembang? Sebagian besar jika tidak semua waktu ketika saya telah melihat kode dan berpikir "menulis ulang", itu telah diinjak-injak oleh selusin orang yang berbeda dan keburukan adalah akibat langsung dari akumulasi inkonsistensi gaya, asumsi yang salah atau diubah, dan asumsi lama yang baik peretasan yang dibuat-buat. Kode tumbuh duri dari waktu ke waktu justru karena kepemilikannya bersama.

    Maksud saya di sini adalah, aneh bahwa satu orang akan memiliki petak kode yang sedemikian besar di lingkungan yang seharusnya mempraktikkan kepemilikan kolektif. Apakah orang lain takut menyentuh kode pengembang ini? Apakah mereka takut membicarakan hal itu? Mungkin ada masalah mendasar dengan dinamika grup Anda, atau dengan pengembang ini secara khusus; jika ada, jangan abaikan saja. Atau, alternatif, mungkin itu adalah Anda pertama kali bekerja pada proyek ini, dan jika demikian, mengapa Anda berpikir tentang penulisan ulang sehingga di awal permainan? Sesuatu tentang situasi sepertinya tidak cocok untuk saya.

  5. Pertanyaannya menyatakan, dalam paragraf pertama any developer can change any line of code to add functionality, to refactor, fix bugs or improve designs,. Akankah penulisan ulang tidak melakukan hal-hal ini? Atau akankah ia melakukan sesuatu yang ekstra - dan jika demikian, apa? Pada dasarnya, apa yang alasan Anda untuk ingin melakukan penulisan ulang, dan bagaimana yakin Anda bahwa mereka akan mendapatkan keuntungan produk atau tim? Anda tidak perlu menjawab untuk saya, tetapi Anda sebaiknya memiliki beberapa poin obyektif untuk membuat jika dan ketika Anda memilih untuk mendiskusikannya dengan tim.

Saya benar-benar merasa bahwa pertanyaan ini memerlukan sejumlah besar konteks dan tidak boleh dijawab tanpa pemahaman yang sangat jelas tentang konteks itu. Jawaban "benar" sepenuhnya tergantung pada tim Anda, produk Anda, organisasi Anda, kepribadian Anda, proses Anda, ruang lingkup kode asli, ruang lingkup perubahan, dan sebagainya dan seterusnya. Ini, IMO, masalah yang harus Anda ambil bersama tim Anda , bukan di situs tanya jawab online.


3
+1 Satu-satunya jawaban yang benar dalam diskusi ini.
mattnz

Dalam pengalaman saya tentang tim XP dengan kepemilikan kode kolektif (dan pemrograman pasangan) adalah bahwa perubahan besar pada desain atau "penulisan ulang" bagian-bagian dari sistem biasanya melibatkan diskusi dengan sebagian besar tim (semua orang yang peduli). Dengan fungsionalitas inti kritis, desain yang ada adalah yang terbaik yang bisa dilakukan tim saat itu. Jika tidak mudah diubah, akan sangat membantu untuk mendapatkan ide semua orang tentang apa yang menurut mereka harus dilakukan, dan berbagai cara agar dapat ditingkatkan. Jika Anda tidak dapat memperoleh konsensus, cobalah beberapa "paku" atau eksperimen untuk mengumpulkan informasi.
Jeff Grigg

11

Mengapa Anda mengedit kode?

Apakah ada bug atau itu cacat desain yang lebih mendasar?

Dalam kasus sebelumnya, saya khawatir tentang penulisan ulang untuk memperbaiki apa yang bisa menjadi bug kecil dalam kode.

Dalam kasus yang terakhir, sementara saya mengharapkan head-up bahwa kode "saya" berpotensi ditulis ulang, saya akan sangat senang hal itu terjadi.

Itulah poin kepemilikan kode kolektif - kode yang Anda tulis ada untuk dimodifikasi atau bahkan diganti jika ada sesuatu yang lebih baik datang.


3
Ini adalah satu-satunya jawaban sejauh ini yang bisa saya setujui. Jika sesuatu perlu ditulis ulang, saya menulis ulang. Saya bahkan tidak melihat siapa penulis aslinya; kenapa harus saya? Dengan asumsi ada tes (ada yang tes, kan?), Dan dengan asumsi tujuannya adalah cukup jelas atau dijelaskan oleh komentar (jika tidak, maka pasti perlu pergi), maka saya akan tahu cukup cepat jika saya sudah rusak apa-apa. Tentu saja saya berbicara tentang menulis ulang beberapa kelas, bukan keseluruhan kerangka kerja, tetapi jika penulisan ulang itu besar maka itu lebih merupakan masalah penjadwalan / perencanaan proyek daripada masalah kepemilikan bersama.
Aaronaught

6

Secara umum, jika Anda semua setuju bahwa Anda semua bertanggung jawab atas kode tersebut, maka boleh saja untuk menulis ulang kode apa pun jika ini merupakan peningkatan. Diskusikan dengan pengembang lain terlebih dahulu sebagai rasa hormat. Mungkin ada alasan yang sah bahwa itu ditulis dengan cara tertentu. Pada tingkat pribadi banyak pengembang secara emosional berinvestasi dalam apa yang mereka hasilkan dan, seperti yang dikatakan orang lain, Anda tidak menginginkan niat buruk.

Khususnya itu tergantung pada dinamika tim. Pengembang senior yang akan menulis ulang kode pengembang junior mungkin harus melakukan tinjauan kode (situs saya) dengan mereka sebelum hanya menulis ulang. Dengan begitu pengembang junior dapat belajar dari situasinya.


5

Tidak masalah apakah pengembang asli ada di tim atau tidak, atau bahkan jika Anda adalah pengembang asli. Penulisan ulang lengkap kode apa pun yang dibagikan harus dijalankan oleh tim Anda, karena alasan berikut:

  • Dibutuhkan banyak waktu. Jika orang lain mengerjakan perubahan terkait, Anda tidak ingin membuang waktu.
  • Orang lain memiliki perspektif yang berbeda. Bahkan jika Anda telah memprogram 20 tahun, orang lain mungkin mengetahui hal-hal tentang interaksi dengan kode yang jarang Anda sentuh.
  • Pengembang lain adalah "pelanggan" dari kode sumber. Kode sumber ditulis untuk dibaca pengembang lain. Mereka mungkin memiliki persyaratan arsitektur, input gaya, atau permintaan fitur yang mereka inginkan dalam kode itu, tetapi belum sempat. Anda tidak ingin menyelesaikan refactor hanya untuk mengetahui pengembang lain membutuhkan refactored dengan cara yang berbeda.

4

Seperti yang dikatakan Matthew Flynn, perlu berbicara dengan pengembang terlebih dahulu. Pengembang awal mungkin memberi tahu hal-hal penting tentang fungsionalitas dan menjelaskan mengapa solusi ini atau itu diberikan.

Tetapi sebelum refactoring atau menulis ulang kode, buat cadangan atau cabang yang berisi kode itu. Jika kode lama berfungsi dengan baik, masih ada kemungkinan bahwa kode tersebut dapat dipulihkan.

Jika Anda memiliki sistem kontrol sumber (yang saya anggap Anda miliki), maka, jika mungkin, perbaiki seluruh kode dan hanya setelah itu, ketika Anda yakin itu berfungsi dengan baik, periksa di.

Jangan hapus kode lama, setidaknya sebelum Anda yakin kode baru itu berfungsi dengan baik. Tetapi meninggalkan kode lama di sana selamanya juga bukan hal yang baik. Saya sarankan Anda menghapus kode beberapa waktu kemudian, seperti dalam sebulan setelah lulus pengujian.


2
"Saya sarankan Anda menghapus kode beberapa waktu kemudian" - di mana harus tetap sementara? Di blok komentar? Itulah gunanya kontrol sumber, untuk menjaga salinan cadangan dari semua kode yang diubah / dihapus agar mudah diambil, sambil menjaga kode sumber saat ini bersih.
Dj18

@ Dj18, saya biasanya membiarkan kode berkomentar sebentar untuk membuatnya lebih jelas, dan agar semua orang yang berurusan dengan kode dapat melihat bahwa itu diubah sekaligus. Selain itu, lebih mudah untuk mencari dengan cara ini ketika kode baru saja diedit
superM

1
Itu fungsi lain dari sistem kontrol versi yang tepat: Anda dapat melihat kapan perubahan diperiksa, membandingkan versi untuk melihat apa yang berubah dari satu checkin ke yang berikutnya, dan mengaitkan komentar dengan checkin untuk menjelaskan mengapa modifikasi dibuat. Jika sangat penting bagi orang lain untuk segera mengetahui bahwa sepotong kode telah diubah, mungkin mengirimkan pemberitahuan e-mail alih-alih menunggu pengembang lain memberi kesempatan pada komentar Anda.
dj18

2
Pengetahuan yang diklaim oleh jawaban ini harus diperoleh dari pengembang asli harus dalam kode , atau setidaknya dalam komentar atau dokumentasi yang menyertainya. Jika ini adalah informasi penting maka itu tidak boleh dibungkam di otak seseorang, dan kebijakan pembangunan tidak boleh mendorong ini. Juga, mengapa tidak menghapus kode lama? Anda bisa mendapatkannya kembali jika benar-benar perlu; itulah yang kontrol revisi adalah untuk .
Aaronaught

1
@Aaronaught: Saya pikir apa superm dimaksudkan untuk mengatakan itu dari "di sini menjadi naga" jenis, atau "pelajaran". Sementara jebakan harus cukup jelas bagi programmer berpengalaman, pilihan halus kurang jelas dan mungkin tidak didokumentasikan dengan baik. (Saya setuju bahwa itu adalah pertanda buruk yang perlu diatasi.)
rwong

2

Apa ruang lingkupnya?

  • Jika Anda mengerjakan ulang beberapa baris agar lebih efisien, lakukan saja. Mungkin tanyakan apakah ada bahaya Anda menghapus perilaku halus. Laporkan perubahan selama scrum atau melalui email setelah selesai, kecuali benar-benar sepele (memperbaiki kesalahan ketik).

  • Jika Anda mengerjakan ulang kelas berukuran layak, Anda mungkin harus meminta untuk memastikan Anda memahami desain / perilaku. Biarkan orang lain tahu sebelumnya sehingga siapa pun yang mungkin bekerja di area yang sama dapat mengetahui dan berkoordinasi dengan Anda.

  • Jika Anda mengerjakan ulang sistem yang lebih besar, Anda harus bekerja dengan tim Anda untuk membuat mereka sadar akan perubahan dan merencanakan desain.


1

Jika penulis asli Anda ada di sana, berkomunikasi dengan mereka. Bukan HANYA untuk ettiquette, tetapi untuk informasi tambahan, jika ada kasus atau keadaan yang tidak Anda sadari. Terkadang, mereka akan memberi tahu Anda sesuatu yang berharga.

Kami memiliki kontrol kode yang sangat buruk. Saat ini saya memiliki banyak hal yang perlu ditinjau dan dirawat, dan bahkan tidak ada orang yang melakukan tinjauan kode. Para penulis sebelumnya (selain dari moi) tidak repot-repot berkomentar kode apa pun. Dan, mereka sudah pergi dari perusahaan. Tidak ada yang bertanya tentang kode itu.

Ketika saya menulis ulang, saya berkomentar, dengan komentar yang saya komentari, serta tanggal dan nama / inisial, dan mengapa itu dikomentari. Saya berkomentar kode baru, dengan nama atau inisial, tanggal, alasan ditambahkan, dll.

Komentar tambahan dibuat di kepala paket (eh, biasanya), menunjukkan fungsi apa / procs / SQL / dll. diubah, dengan tanggal. Memudahkan mencari bagian yang telah diubah, dan bagian tersebut memiliki dokumentasi lengkap.

Komentarnya murah. Tanggal akan menjadi indikator dari apa yang berubah, dan setelah x-number (hari / revisi / karyawan baru / pensiun) maka kode dapat dibersihkan dari komentar lama dan sisanya adalah baseline baru.


1

Dari pengamatan saya praktik umum adalah: Jangan pernah menghapus kode. Komentari dan simpan saja.

Praktik saya adalah berkomentar sambil menggantinya. (Terutama untuk referensi.) Kemudian hapus pada komit akhir dari perubahan yang berfungsi. (Ini membutuhkan kontrol versi dan pemahaman tentang cara mengembalikan perubahan.)

Ketika saya menemukan kode komentar lama, saya mencoba menghapusnya dalam komit terpisah dengan komentar yang sesuai. Ini membuatnya lebih mudah untuk mengembalikan atau memeriksa perubahan jika diperlukan.

Untuk semua perubahan, Anda harus dapat menggunakan riwayat revisi untuk menentukan pengembang yang membuat kode. (Riwayat revisi beranotasi membantu di sini.) Hubungi mereka jika mungkin untuk mengetahui mengapa kode itu sebagaimana adanya. Pada banyak proyek, waktu pembersihan tidak terjadi dan banyak hal tertinggal. Periksa pelacak bug untuk melihat apakah ada catatan pembersihan yang diperlukan. Terkadang perubahan perlu dibersihkan satu atau dua rilis kemudian.

Jika Anda mengubah kode, harus ada alasan Anda bekerja dengan kode itu. Periksa dengan pengembang asli untuk mencari tahu mengapa kodenya seperti itu. Jika ada alasan yang sah untuk tidak memperbaikinya, tambahkan komentar yang menjelaskan mengapa itu tidak diperbaiki, atau mengapa tidak boleh diubah. Ini akan menghemat waktu pengembang berikutnya.

Tag seperti FixMe, ToDo, Bug, dan Hack dapat digunakan untuk menunjukkan kode yang dapat diubah nanti. (Dapat diterima untuk menandai batasan sebagai Bug dan tidak memperbaikinya jika tidak akan dipicu dalam kondisi yang disyaratkan.) Mungkin bug jika program akuntansi rumah meluap pada 20 juta dolar, tetapi saya tidak akan membuang banyak waktu untuk memperbaiki saya t.

Perubahan tinjauan kode harus dilakukan oleh pengembang asli jika sesuai untuk memodifikasi kode.


2
Hampir downvoted ini, sampai saya melihat "Kemudian hapus pada komit terakhir".
Joshua Drake

1

Itu mungkin tergantung pada mengapa penulisan ulang itu perlu. Jika itu karena ada masalah dengan apa yang ditulis, dan selalu ada masalah dengan itu, maka membicarakannya diperlukan, jika hanya untuk meminimalkan seberapa sering kode perlu diperbaiki di masa depan.

Saran saya dalam hal ini adalah memasangkan ketika memperbaiki kode. Dengan cara ini, ini memberikan contoh yang baik dari negara perantara, dan (mudah-mudahan), beberapa konteks tentang mengapa kode yang ditulis ulang lebih baik. Juga (jika hanya sebagai latihan pribadi), cobalah refactoring kode menjadi lebih baik tanpa menulis ulang total. Ini akan lebih sulit, tetapi itu baik untuk Anda.

Di sisi lain, ada saat-saat ketika penulisan ulang diperlukan:

  • Tim telah belajar banyak sejak kode ditulis, dan dev (s) yang menulisnya akan menulisnya secara berbeda sekarang, bahkan tanpa masukan Anda.

  • Persyaratan fitur baru mengubah situasi sehingga mini-rewrite yang ditargetkan sesuai.

Dalam kasus ini, saya mungkin tidak akan repot-repot mengobrol.

Memikirkan hal itu, menurut saya semakin lama kode itu ada, semakin kecil kemungkinan percakapan diperlukan.


1

Saya pikir @ aaronaught membuat beberapa poin bagus, yang benar-benar mengarah pada jawaban yang ingin saya berikan, yaitu tergantung pada siapa yang membuat perubahan (dan mengapa) dan siapa yang menulis kode.

Dalam pengalaman pribadi saya, kode biasanya diubah karena tidak berfungsi sebagaimana dimaksud, atau Anda hanya perlu memperluas apa yang sebenarnya dilakukannya.

Dalam lingkungan Tim dev, Anda tidak harus (dan mungkin tidak dapat) berbicara dengan pembuat kode asli, semuanya harus jelas dari kode.

Itu kemudian mengarah ke pertanyaan yang menghabiskan sebagian besar waktu saya, yang adalah apa yang dimaksudkan oleh programmer asli, dan itu adalah pertanyaan yang paling sering menyebabkan kode dihapus, dan itulah mengapa kita harus berkomentar semuanya, dan di mana programmer junior yang paling berpengalaman sering jatuh busuk.

Setiap programmer yang mengubah kode orang lain (refactoring) benar-benar harus dengan hormat dan berlatih menyalin gaya pengkodean yang sama dari kode yang sudah ada, dan pertama-tama mengambil langkah-langkah untuk mencari tahu bagaimana kode asli bekerja, dan apa yang dicoba untuk, dan benar-benar akan mencapai. Seringkali ini dengan sendirinya mengidentifikasi bug, tetapi tentu saja memaksa orang untuk menanggung rasa sakit yang orang lain akan melihat kode Anda.

Di tim saya, siapa pun dapat menghapus, menolak, atau menulis ulang apa pun, dan saya melihat 'kepemilikan' sebagai praktik yang melahirkan kemalasan, seolah-olah satu orang pasti akan diberitahu tentang perubahan apa pun, mengapa mereka perlu membuat kode itu dapat dibaca.

Jadi singkatnya, tidak, Anda tidak perlu bertanya pada pembuat kode asli, dan jika melihat kode yang Anda lakukan, maka itu adalah tanda bahwa kodenya tidak cukup mudah dibaca, atau Anda perlu meningkatkan keahlian Anda. Namun, saya merasa ini adalah bentuk yang baik untuk membiarkan kode asli tetap di tempatnya, dikomentari, sampai Anda benar-benar yakin bahwa dalam penulisan ulang, Anda tidak sengaja menghapus fungsionalitas yang diperlukan. Tidak ada yang sempurna.


-2

Seringkali kode ditulis dengan cara tertentu karena suatu alasan. Mengkomunikasikan perubahan kepada penulis selalu berhasil untuk yang terbaik.

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.