Ngopi #103. Ing nimbali saka "Clean Code": 100 tips langgeng

Sumber: Hackernoon "Kode Bersih" dening Robert C. Martin minangka buku pemrograman sing paling disaranake ing kabeh wektu. Telusuri buku nggunakake pitakon "buku paling apik kanggo pangembang piranti lunak" lan sampeyan meh dijamin nemokake buku iki ing asil panelusuran. Lan nalika sawetara wong ngrasa yen Kode Bersih ora pantes digatekake, aku bakal mbantah manawa sentimen kasebut salah banget. Ya, sawetara saran ing buku kasebut bisa dipertanyakan. Ya, sawetara isi katon ketinggalan jaman. Ya, sawetara conto sing mbingungake. Iku kabeh bener. Nanging aja cepet-cepet menehi diskon akeh tips migunani sing ditawakake buku iki! Rampung nglirwakake Clean Code mung amarga sawetara gagasan ala dudu solusi sing paling apik. Dadi, tanpa ado maneh, ayo goleki tips paling apik sing ditawakake Kode Bersih! Kita bakal nliti saben bab, ngringkes ide sing ditawakake Pakdhe Bob lan rekan-rekane.

Bab 1: Kode resik

1. Jumlah sakabèhé saka keruwetan mundhak liwat wektu.

2. Mulihake sistem sing wis lawas saka ngeruk angel banget. Refactoring lan dandan tambahan bakal dadi pilihan sing paling apik kanggo iki.

3. Ing basis kode sing ora apik, tugas sing mung butuh sawetara jam bisa njupuk sawetara dina utawa minggu kanggo rampung.

4. Njupuk wektu kanggo tumindak kanthi cepet.

5. Kode resik nindakake siji bab uga. Kode ala nyoba nindakake kakehan.

6. Kode resik diuji kanthi apik.

7. Nalika maca kode sing ditulis kanthi apik, saben fungsi nindakake apa sing dikarepake.

8. Yen sampeyan ora setuju karo prinsip sing diwulangake dening wong sing duwe pengalaman pirang-pirang taun, paling ora sampeyan kudu nimbang sudut pandang sadurunge ora nggatekake.

9. Kode diwaca luwih kerep tinimbang sing ditulis.

10. Kode sing luwih gampang diwaca luwih gampang diganti.

11. Ninggalake basis kode luwih apik tinimbang nalika sampeyan nemokake (Aturan Pramuka).

Bab 2: Tegese Jeneng

1. Pilih jeneng variabel kanthi teliti.

2. Milih jeneng apik iku angel.

3. Jeneng variabel utawa fungsi kudu nuduhake apa iku lan carane digunakake.

4. Aja nggunakake jeneng variabel siji-karakter, kajaba jeneng sing umum digunakake, kayata i kanggo variabel counter ing daur ulang.

5. Aja nggunakake singkatan ing jeneng variabel.

6. Jeneng variabel kudu bisa diucapake supaya sampeyan bisa ngomong lan ngomong kanthi banter.

7. Gunakake jeneng variabel sing gampang ditemokake.

8. Kelas lan obyek kudu duwe jeneng ing wangun nouns.

9. Jeneng metode lan fungsi kudu dadi pasangan kriya utawa tembung kriya.

Bab 3: Fungsi

1. Fungsi kudu cilik.

2. Fungsi kasebut kudu nindakake siji tumindak.

3. Fungsi kudu duwe jeneng deskriptif.

4. Ekstrak kode ing awak yen / liya utawa ganti statement kasebut dadi fungsi sing dijenengi kanthi jelas.

5. Matesi jumlah argumen fungsi njupuk.

6. Yen fungsi mbutuhake akeh argumen konfigurasi, coba gabungke dadi variabel parameter konfigurasi siji.

7. Fungsi kudu murni, tegese ora duwe efek samping lan ora ngowahi argumen input.

8. Fungsi kasebut kudu dadi prentah utawa pitakon, nanging ora loro-lorone bebarengan (Pemisahan Query Command).

9. Iku luwih apik kanggo mbusak kasalahan lan pangecualian saka kode saka ninggalake kasalahan ing kode.

10. Ekstrak kode duplikat menyang fungsi sing dijenengi kanthi jelas (Aja Baleni Dhewe).

11. Tes unit nggawe refactoring luwih gampang.

Bab 4: Komentar

1. Komentar bisa uga salah. Bisa uga salah ing wiwitan, utawa bisa uga akurat lan banjur dadi ketinggalan jaman amarga kode kasebut diganti.

2. Gunakake komentar kanggo njlèntrèhaké apa iku ditulis ing cara iku, tinimbang nerangake apa kedados.

3. Komentar asring bisa nyingkiri kanthi nggunakake variabel sing dijenengi kanthi jelas lan ngekstrak bagean kode menyang fungsi sing dijenengi kanthi jelas.

4. Ater-ater TODO komentar kanthi ater-ater sing konsisten supaya luwih gampang ditemokake. Deleng lan ngresiki komentar TODO sampeyan kanthi periodik.

5. Aja nggunakake Javadocs mung kanggo nggunakake. Komentar sing njlèntrèhaké apa cara, apa bantahan sing dibutuhake, lan apa sing bakal dibalèkaké, sing paling apik lan mblusukake.

6. Komentar kudu nyakup kabeh informasi lan konteks sing relevan sing dibutuhake kanggo maca. Aja kesed nalika nulis komentar.

7. Komentar log lan komentar penulis file ora dibutuhake amarga kontrol versi lan nyalahke git.

8. Aja komentar metu kode mati. Mbusak wae. Yen sampeyan mikir sampeyan butuh kode kasebut ing mangsa ngarep, iku kanggo kontrol versi.

Bab 5: Formatting

1. Minangka tim, pilih sakumpulan aturan kanggo ngowahi format kode, banjur aplikasi aturan kasebut kanthi konsisten. Ana prakara apa aturan sampeyan setuju karo, sampeyan kudu teka menyang persetujuan.

2. Gunakake format kode otomatis lan analisa kode. Aja ngandelake wong kanggo nemokake lan ndandani saben kesalahan format kanthi manual. Iki ora efisien, ora produktif lan mbuwang wektu nalika mriksa kode.

3. Tambah spasi vertikal ing antarane baris kode kanggo misahake blok kode sing gegandhengan. Sampeyan mung kudu nggawe siji baris anyar ing antarane grup.

4. File cilik luwih gampang diwaca, dingerteni, lan dipindhah tinimbang file gedhe.

5. Variabel kudu diumumake ing cedhak ngendi digunakake. Kanggo fungsi cilik iki biasane ing ndhuwur fungsi.

6. Malah kanggo fungsi cendhak utawa yen statements, isih format bener tinimbang nulis ing siji baris.

Bab 6: Obyek lan Struktur Data

1. Rincian implementasine ing obyek kudu didhelikake ing mburi antarmuka obyek kasebut. Kanthi nyediakake antarmuka kanggo digunakake dening konsumen saka obyek, sampeyan wis luwih gampang kanggo mengko rinci implementasine refactor tanpa nyebabake owah-owahan bejat. Abstraksi nggawe refactoring luwih gampang.

2. Sembarang potongan kode kudu ora ngerti babagan internal obyek sing dioperasikake.

3. Nalika nggarap obyek, sampeyan kudu nindakake prentah utawa pitakon, tinimbang takon babagan internal.

Bab 7: Mbenerake Kasalahan

1. Penanganan kesalahan ngirim ora ngganggu liyane saka kode ing modul.

2. Iku luwih apik kanggo mbusak kasalahan lan pangecualian saka kode saka ninggalake kasalahan ing kode.

3. Tulis tes kanthi kesalahan kanggo mesthekake yen kode sampeyan bisa ngenali lan ora kantun.

4. Pesen kesalahan kudu informatif, kanthi kabeh konteks sing dibutuhake wong bisa uga kudu ngatasi masalah kanthi efektif.

5. Bungkus API pihak katelu ing abstraksi lapisan tipis nggampangake ngganti perpustakaan siji karo perpustakaan liyane ing mangsa ngarep.

6. Bungkus API pihak katelu ing lapisan abstraksi tipis nggampangake moyoki perpustakaan sajrone tes.

7. Gunakake pola Kasus Khusus utawa pola Obyek Null kanggo nangani prilaku sing luar biasa, kayata nalika data tartamtu ora ana.

Bab 8: Watesan

1. Pustaka pihak katelu mbantu nyepetake pangiriman produk kanthi ngidini sampeyan nggawe outsourcing macem-macem tugas.

2. Tulis tes kanggo mesthekake yen sampeyan nggunakake perpustakaan pihak katelu kanthi bener.

3. Gunakake pola adaptor kanggo nyepetake longkangan antarane API perpustakaan pihak katelu lan API sing pengin duwe.

4. Bungkus API pihak katelu ing abstraksi lapisan tipis nggampangake ngganti perpustakaan siji karo perpustakaan liyane ing mangsa ngarep. (Baleni saka Bab 7)

5. Bungkus API pihak katelu ing lapisan abstraksi tipis nggampangake moyoki perpustakaan sajrone tes. (Baleni saka Bab 7)

6. Coba aja ngandhani aplikasi sampeyan akeh banget informasi babagan rincian perpustakaan pihak katelu.

7. Iku luwih apik kanggo gumantung ing apa sing sampeyan kontrol tinimbang apa sing ora sampeyan kontrol.

Bab 9: Tes Unit

1. Kode test kudu resik minangka kode produksi (karo sawetara pangecualian, biasane related kanggo memori utawa efficiency).

2. Nalika kode produksi diganti, uga kode tes.

3. Tes mbantu supaya kode produksi sampeyan fleksibel lan bisa dijaga.

4. Tes ngidini sampeyan nggawe owah-owahan, ngidini sampeyan kanthi yakin refactor tanpa wedi ora nggatekake dhewe.

5. Susun tes sampeyan nggunakake pola Arrange-Act-Assert (uga dikenal minangka Build-Operate-Check, Setup-Exercise-Verify, utawa Given-When-Then).

6. Gunakake fungsi khusus domain kanggo nggawe tes luwih gampang ditulis lan diwaca.

7. Skor siji konsep saben tes.

8. Tes kudu cepet.

9. Tes kudu mandiri.

10. Tes kudu bisa diulang.

11. Tes kudu ora mbutuhake konfirmasi.

12. Tes kudu ditulis kanthi pas wektune, sakcepete sadurunge utawa sawise kode produksi ditulis, ora sasi mengko.

13. Yen tes sampeyan ala, ngarepake ana bug ing kode sampeyan.

Bab 10: Kelas

1. Kelas kudu cilik.

2. Kelas kudu mung tanggung jawab kanggo siji bab lan kudu mung siji alesan kanggo ngganti (prinsip tanggung jawab tunggal).

3. Yen sampeyan ora bisa nggawe jeneng sing jelas kanggo kelas kasebut, mesthine gedhe banget.

4. Tugas sampeyan ora bakal rampung yen sampeyan entuk potongan kode. Langkah sabanjure yaiku refactor lan ngresiki kode kasebut.

5. Nggunakake akeh kelas cilik tinimbang sawetara kelas gedhe ing aplikasi sampeyan nyuda jumlah informasi sing kudu dingerteni pangembang nalika nggarap tugas apa wae.

6. Nduwe suite tes sing apik ngidini sampeyan refactor kanthi yakin nalika sampeyan ngilangi kelas gedhe dadi kelas sing luwih cilik.

7. Kelas kudu mbukak kanggo extension, nanging ditutup kanggo modifikasi (prinsip mbukak-tutup).

8. Antarmuka lan kelas abstrak nggawe jahitan sing nggawe tes luwih gampang.

Bab 11: Sistem

1. Gunakake injeksi dependensi kanggo menehi pangembang keluwesan kanggo pass sembarang obyek karo antarmuka cocok kanggo kelas liyane.

2. Gunakake injeksi dependensi kanggo nggawe antarmuka antarane obyek ing aplikasi sampeyan supaya luwih gampang tes.

3. Sistem piranti lunak ora kaya bangunan sing kudu dirancang luwih dhisik. Padha luwih kaya kutha-kutha sing tuwuh lan berkembang liwat wektu, adaptasi karo kabutuhan saiki.

4. Nundha nggawe keputusan nganti wektu kritis pungkasan.

5. Gunakake basa khusus domain supaya ahli domain lan pangembang nggunakake terminologi sing padha.

6. Aja overcomplicate sistem sampeyan. Gunakake sing paling gampang sing bisa digunakake.

Bab 12: Panyebaran

1. Sistem sing ora bisa dites ora bisa diverifikasi, lan sistem sing ora bisa diverifikasi ora bakal bisa digunakake.

2. Tes nulis nyebabake desain sing luwih apik amarga kode sing gampang dites asring nggunakake injeksi dependensi, antarmuka, lan abstraksi.

3. Tes sing apik bakal ngilangi rasa wedi ngrusak aplikasi nalika refactoring.

4. Kode duplikat nggawe risiko luwih akeh amarga ana luwih akeh panggonan ing kode sing bisa diganti lan luwih akeh panggonan sing bisa didhelikake kesalahan.

5. Kode sing sampeyan tulis saiki luwih gampang dingerteni amarga sampeyan melu ngerti. Ora gampang wong liya cepet-cepet nggayuh tingkat pemahaman sing padha.

6. Umume biaya proyek piranti lunak ana gandhengane karo pangopènan jangka panjang.

7. Tes dadi dokumentasi urip babagan cara aplikasi sampeyan kudu (lan ditindakake).

8. Aja pindhah maneh yen kode sampeyan bisa digunakake. Njupuk wektu kanggo nggawe luwih cetha lan luwih dingerteni.

9. Wong sabanjure sing maca kode sampeyan ing mangsa ngarep bakal dadi sampeyan. Dadi apik kanggo masa depan dhewe kanthi nulis kode sing gampang dingerteni.

10. Nolak dogma. Nganggo pragmatisme.

11. Perlu pirang-pirang dekade dadi insinyur piranti lunak sing apik banget. Sampeyan bisa nyepetake kurva sinau kanthi sinau saka ahli ing sekitar sampeyan lan sinau pola desain sing umum digunakake.

Bab 13: Paralelisme

1. Nulis kode paralel angel.

2. Kewan omo sok-sok lan masalah sing angel kanggo ngasilake asring masalah concurrency.

3. Tes ora njamin yen aplikasi sampeyan bakal bebas bug, nanging bakal nyuda resiko.

4. Sinau babagan masalah konkurensi umum lan solusi sing bisa ditindakake.

Bab 14: Refinement Urutan

1. Kode resik ora biasane diwiwiti kanthi slate kosong. Sampeyan nulis solusi sing kasar dhisik banjur refactor supaya luwih resik.

2. Iku salah kanggo mungkasi nggarap kode yen wis wiwit digunakake. Njupuk wektu kanggo nggawe luwih apik sawise wis bisa digunakake.

3. Kerusuhan mundhak alon-alon.

4. Yen sampeyan nemokake dhewe ing ikatan ngendi nambah fitur banget angel utawa njupuk dawa banget, mungkasi nulis fitur lan miwiti refactoring.

5. Owah-owahan tambahan asring luwih apik tinimbang mbangun maneh saka awal.

6. Gunakake Test-Driven Development (TDD) kanggo nggawe akeh owah-owahan cilik banget.

7. Desain piranti lunak sing apik kalebu misahake masalah ing kode sampeyan lan misahake kode kasebut dadi modul, kelas, lan file sing luwih cilik.

8. Luwih gampang kanggo ngresiki kekacoan sanalika sampeyan wis rampung saka kanggo ngresiki mengko.

Bab 15: JUnit Internal

1. Jeneng variabel negatif utawa ekspresi kondisional luwih angel dingerteni tinimbang sing positif.

2. Refactoring minangka proses iteratif sing kebak nyoba lan kesalahan.

3. Ninggalake basis kode luwih apik tinimbang nalika sampeyan nemokake (Aturan Pramuka). (Baleni saka Bab 1)

Bab 16: Refactoring SerialDate

1. Review kode lan kritik kode kita nggawe kita luwih apik, lan kita kudu nampa iku.

2. Pisanan gawe kode kasebut, banjur ndandani.

3. Ora saben baris kode mbutuhake tes.

Bab 17: Bau lan Heuristik

1. Kode resik dudu sakumpulan aturan, nanging sistem nilai sing nemtokake kualitas karya sampeyan.

[Ing bab iki, Pakdhe Bob nyathet 66 variasi liyane saka kode lan heuristike, akeh sing dibahas ing buku liyane. Reproduksi ing kene mesthine bakal nyalin lan nempel jeneng saben item, mula aku ora nindakake. Aku menehi saran supaya sampeyan maca buku kasebut!]

Kesimpulan

Ayo dadi mungkasi ngendi kita miwiti: Kode resik dening Robert C. Martin buku program paling dianjurake kabeh wektu. Ana alesan sing apik kanggo iki.