Coffee break #103. Dalam mempertahankan "Kod Bersih": 100 petua abadi

Sumber: Hackernoon “Clean Code” oleh Robert C. Martin ialah buku pengaturcaraan yang paling disyorkan sepanjang zaman. Cari buku menggunakan pertanyaan "buku terbaik untuk pembangun perisian" dan anda hampir dijamin untuk menemui buku ini dalam hasil carian. Dan sementara sesetengah orang merasakan bahawa Kod Bersih tidak patut diberi perhatian, saya berpendapat bahawa sentimen sedemikian adalah sangat tersilap. Ya, beberapa nasihat dalam buku itu boleh dipersoalkan. Ya, sesetengah kandungan kelihatan ketinggalan zaman. Ya, beberapa contoh mengelirukan. Semuanya benar. Tetapi jangan terlalu cepat untuk menolak banyak petua berguna yang ditawarkan oleh buku ini! Mengabaikan Kod Bersih sepenuhnya hanya kerana beberapa idea buruk bukanlah penyelesaian terbaik. Jadi, tanpa berlengah lagi, mari lihat petua terbaik yang ditawarkan oleh Kod Bersih! Kami akan meneliti setiap bab, meringkaskan idea yang Uncle Bob dan pengarang bersamanya tawarkan.

Bab 1: Kod Bersih

1. Jumlah keseluruhan kekacauan meningkat dari semasa ke semasa.

2. Memulihkan sistem yang sudah lapuk dari awal adalah sangat sukar. Pemfaktoran semula dan penambahbaikan tambahan akan menjadi pilihan terbaik untuk ini.

3. Dalam pangkalan kod yang tidak kemas, tugasan yang hanya perlu mengambil masa beberapa jam boleh mengambil masa beberapa hari atau minggu untuk diselesaikan.

4. Luangkan masa untuk bertindak dengan cepat.

5. Kod bersih melakukan satu perkara dengan baik. Kod buruk cuba melakukan terlalu banyak.

6. Kod bersih diuji dengan baik.

7. Apabila membaca kod yang ditulis dengan baik, setiap fungsi melakukan kira-kira apa yang anda harapkan.

8. Jika anda tidak bersetuju dengan prinsip yang diajar oleh seseorang yang berpengalaman bertahun-tahun, anda harus sekurang-kurangnya mempertimbangkan pandangan mereka sebelum mengabaikannya.

9. Kod dibaca lebih kerap daripada yang ditulis.

10. Kod yang lebih mudah dibaca lebih mudah diubah.

11. Tinggalkan pangkalan kod lebih baik daripada semasa anda menemuinya (Peraturan Pengakap Lelaki).

Bab 2: Pengertian Nama

1. Pilih nama pembolehubah anda dengan berhati-hati.

2. Memilih nama yang baik adalah sukar.

3. Nama pembolehubah atau fungsi harus menunjukkan apa itu dan bagaimana ia digunakan.

4. Elakkan menggunakan nama pembolehubah aksara tunggal, kecuali nama yang biasa digunakan, seperti i untuk pembolehubah pembilang dalam gelung.

5. Elakkan menggunakan singkatan dalam nama berubah.

6. Nama boleh ubah harus disebut supaya anda boleh bercakap tentangnya dan menyebutnya dengan kuat.

7. Gunakan nama pembolehubah yang mudah dicari.

8. Kelas dan objek mesti mempunyai nama dalam bentuk kata nama.

9. Nama kaedah dan fungsi mestilah kata kerja atau pasangan kata kerja-kata nama.

Bab 3: Fungsi

1. Fungsi hendaklah kecil.

2. Fungsi mesti melakukan satu tindakan.

3. Fungsi mesti mempunyai nama deskriptif.

4. Ekstrak kod dalam badan if/else atau tukar penyataan kepada fungsi yang dinamakan dengan jelas.

5. Hadkan bilangan hujah yang diambil oleh fungsi.

6. Jika fungsi memerlukan banyak argumen konfigurasi, pertimbangkan untuk menggabungkannya ke dalam pembolehubah parameter konfigurasi tunggal.

7. Fungsi mestilah tulen, yang bermaksud ia tidak mempunyai kesan sampingan dan tidak mengubah suai hujah inputnya.

8. Fungsi tersebut mestilah perintah atau pertanyaan, tetapi bukan kedua-duanya sekali (Pemisahan Pertanyaan Perintah).

9. Adalah lebih baik untuk mengalih keluar ralat dan pengecualian daripada kod daripada meninggalkan ralat dalam kod.

10. Ekstrak kod pendua ke dalam fungsi yang dinamakan dengan jelas (Jangan Ulangi Sendiri).

11. Ujian unit memudahkan pemfaktoran semula.

Bab 4: Ulasan

1. Komen mungkin tidak betul. Ia mungkin salah pada mulanya, atau ia mungkin pada mulanya tepat dan kemudian menjadi lapuk dari semasa ke semasa apabila kod berubah.

2. Gunakan ulasan untuk menerangkan mengapa ia ditulis seperti itu, dan bukannya menerangkan perkara yang sedang berlaku.

3. Komen selalunya boleh dielakkan dengan menggunakan pembolehubah yang dinamakan dengan jelas dan mengekstrak bahagian kod ke dalam fungsi yang dinamakan dengan jelas.

4. Awalan TODO ulasan dengan awalan yang konsisten untuk menjadikannya lebih mudah dicari. Semak dan bersihkan ulasan TODO anda secara berkala.

5. Jangan gunakan Javadocs hanya untuk menggunakannya. Komen yang menerangkan perkara yang dilakukan oleh sesuatu kaedah, hujah yang diperlukan dan perkara yang dipulangkan adalah berlebihan dan paling teruk mengelirukan.

6. Komen harus merangkumi semua maklumat dan konteks yang relevan yang pembaca perlukan. Jangan malas menulis komen.

7. Komen log dan ulasan pengarang fail tidak diperlukan kerana kawalan versi dan git blame.

8. Jangan komen kod mati. Padamkan sahaja. Jika anda fikir anda akan memerlukan kod itu pada masa hadapan, itulah gunanya kawalan versi.

Bab 5: Memformat

1. Sebagai satu pasukan, pilih satu set peraturan untuk memformat kod anda, kemudian gunakan peraturan tersebut secara konsisten. Tidak kira apa peraturan yang anda setujui, anda perlu mencapai persetujuan.

2. Gunakan pemformatan kod automatik dan penganalisis kod. Jangan bergantung pada orang untuk mencari dan membetulkan setiap ralat pemformatan secara manual. Ini tidak cekap, tidak produktif dan membuang masa semasa menyemak kod.

3. Tambahkan ruang menegak antara baris kod untuk memisahkan blok kod yang berkaitan secara visual. Apa yang anda perlukan ialah membuat satu baris baharu antara kumpulan.

4. Fail kecil lebih mudah dibaca, difahami dan dialihkan daripada fail besar.

5. Pembolehubah hendaklah diisytiharkan berhampiran tempat ia digunakan. Untuk fungsi kecil ini biasanya di bahagian atas fungsi.

6. Walaupun untuk fungsi pendek atau jika kenyataan, masih memformatkannya dengan betul daripada menulisnya pada satu baris.

Bab 6: Objek dan Struktur Data

1. Butiran pelaksanaan dalam objek mesti disembunyikan di belakang antara muka objek. Dengan menyediakan antara muka untuk digunakan oleh pengguna sesuatu objek, anda memudahkan untuk memfaktorkan semula butiran pelaksanaan kemudian tanpa menyebabkan perubahan yang rosak. Abstraksi memudahkan pemfaktoran semula.

2. Mana-mana sekeping kod yang diberikan seharusnya tidak mempunyai pengetahuan tentang dalaman objek yang ia beroperasi.

3. Apabila bekerja dengan objek, anda harus memerlukannya untuk melaksanakan arahan atau pertanyaan, dan bukannya bertanya tentang bahagian dalamannya.

Bab 7: Membetulkan Ralat

1. Pengendalian ralat tidak boleh mengganggu seluruh kod dalam modul.

2. Adalah lebih baik untuk mengalih keluar ralat dan pengecualian daripada kod daripada meninggalkan ralat dalam kod.

3. Tulis ujian dengan ralat untuk memastikan kod anda mengenal pastinya dan tidak terlepas.

4. Mesej ralat hendaklah bermaklumat, dengan semua konteks yang diperlukan seseorang mungkin perlu menyelesaikan masalah dengan berkesan.

5. Membungkus API pihak ketiga dalam lapisan abstraksi nipis menjadikannya lebih mudah untuk menggantikan satu pustaka dengan yang lain pada masa hadapan.

6. Membungkus API pihak ketiga dalam lapisan abstraksi nipis menjadikannya lebih mudah untuk mengejek perpustakaan semasa ujian.

7. Gunakan corak Kes Khas atau corak Objek Null untuk mengendalikan tingkah laku luar biasa, seperti apabila data tertentu tidak wujud.

Bab 8: Sempadan

1. Perpustakaan pihak ketiga membantu mempercepatkan penghantaran produk dengan membenarkan anda menggunakan sumber luar pelbagai tugas.

2. Tulis ujian untuk memastikan anda menggunakan pustaka pihak ketiga dengan betul.

3. Gunakan corak penyesuai untuk merapatkan jurang antara API perpustakaan pihak ketiga dan API yang anda ingin miliki.

4. Membungkus API pihak ketiga dalam lapisan abstraksi nipis menjadikannya lebih mudah untuk menggantikan satu pustaka dengan yang lain pada masa hadapan. (Ulang dari Bab 7)

5. Membungkus API pihak ketiga dalam lapisan abstraksi nipis menjadikannya lebih mudah untuk mengejek perpustakaan semasa ujian. (Ulang dari Bab 7)

6. Cuba untuk tidak memberitahu aplikasi anda terlalu banyak maklumat tentang butiran mana-mana perpustakaan pihak ketiga.

7. Lebih baik bergantung pada apa yang anda kawal daripada apa yang anda tidak kawal.

Bab 9: Ujian Unit

1. Kod ujian hendaklah sebersih kod pengeluaran (dengan beberapa pengecualian, biasanya berkaitan dengan ingatan atau kecekapan).

2. Apabila kod pengeluaran berubah, begitu juga kod ujian.

3. Ujian membantu memastikan kod pengeluaran anda fleksibel dan boleh diselenggara.

4. Ujian membolehkan anda membuat perubahan, membolehkan anda memfaktorkan semula dengan yakin tanpa rasa takut untuk tidak menyedarinya sendiri.

5. Susun ujian anda menggunakan corak Arrange-Act-Assert (juga dikenali sebagai Build-Operate-Check, Setup-Exercise-Verify atau Given-When-Then).

6. Gunakan fungsi khusus domain untuk menjadikan ujian lebih mudah untuk ditulis dan dibaca.

7. Skor satu konsep setiap ujian.

8. Ujian mesti cepat.

9. Ujian mesti bebas.

10. Ujian mesti berulang.

11. Ujian tidak sepatutnya memerlukan pengesahan.

12. Ujian hendaklah ditulis tepat pada masanya, sejurus sebelum atau selepas kod pengeluaran ditulis, bukan beberapa bulan kemudian.

13. Jika ujian anda teruk, jangkakan terdapat pepijat dalam kod anda.

Bab 10: Kelas

1. Kelas hendaklah kecil.

2. Kelas hendaklah hanya bertanggungjawab untuk satu perkara dan hanya mempunyai satu sebab untuk berubah (prinsip tanggungjawab tunggal).

3. Jika anda tidak dapat memberikan nama yang jelas untuk kelas itu, ia mungkin terlalu besar.

4. Tugas anda tidak akan tamat apabila anda mendapat sekeping kod untuk berfungsi. Langkah seterusnya ialah memfaktorkan semula dan membersihkan kod.

5. Menggunakan banyak kelas kecil dan bukannya beberapa kelas besar dalam aplikasi anda mengurangkan jumlah maklumat yang mesti difahami oleh pembangun semasa mengerjakan sebarang tugasan.

6. Mempunyai suite ujian yang baik membolehkan anda memfaktorkan semula dengan yakin apabila anda memecahkan kelas yang besar kepada yang lebih kecil.

7. Kelas hendaklah dibuka untuk sambungan, tetapi ditutup untuk pengubahsuaian (prinsip terbuka-tertutup).

8. Antara muka dan kelas abstrak mencipta jahitan yang memudahkan ujian.

Bab 11: Sistem

1. Gunakan suntikan pergantungan untuk memberi pembangun fleksibiliti untuk menghantar sebarang objek dengan antara muka yang sesuai ke kelas lain.

2. Gunakan suntikan pergantungan untuk mencipta antara muka antara objek dalam aplikasi anda untuk memudahkan ujian.

3. Sistem perisian bukan seperti bangunan yang perlu direka bentuk terlebih dahulu. Mereka lebih seperti bandar yang berkembang dan berkembang dari semasa ke semasa, menyesuaikan diri dengan keperluan semasa.

4. Tangguhkan membuat keputusan sehingga saat kritikal terakhir.

5. Gunakan bahasa khusus domain supaya pakar domain dan pembangun menggunakan istilah yang sama.

6. Jangan terlalu merumitkan sistem anda. Gunakan perkara paling mudah yang berfungsi.

Bab 12: Penggunaan

1. Sistem yang tidak boleh diuji tidak boleh disahkan dan sistem yang tidak boleh disahkan tidak boleh digunakan.

2. Ujian penulisan membawa kepada reka bentuk yang lebih baik kerana kod yang mudah diuji selalunya menggunakan suntikan pergantungan, antara muka dan abstraksi.

3. Satu set ujian yang baik akan menghapuskan ketakutan untuk memecahkan permohonan anda semasa pemfaktoran semula.

4. Penduaan kod mewujudkan lebih banyak risiko kerana terdapat lebih banyak tempat dalam kod yang boleh ditukar dan lebih banyak tempat di mana ralat boleh disembunyikan.

5. Kod yang anda tulis sekarang lebih mudah difahami kerana anda terlibat secara mendalam dalam memahaminya. Bukan mudah untuk orang lain cepat mencapai tahap pemahaman yang sama.

6. Kebanyakan kos projek perisian adalah berkaitan dengan penyelenggaraan jangka panjang.

7. Ujian berfungsi sebagai dokumentasi hidup tentang cara permohonan anda harus (dan lakukan) berkelakuan.

8. Jangan bergerak lebih jauh setelah kod anda berfungsi. Luangkan masa untuk menjadikannya lebih jelas dan lebih mudah difahami.

9. Orang seterusnya yang membaca kod anda dalam masa terdekat kemungkinan besar ialah anda. Berbuat baik kepada diri masa depan anda dengan menulis kod yang mudah difahami.

10. Lawan dogma. Mengamalkan pragmatisme.

11. Ia mengambil masa beberapa dekad untuk menjadi seorang jurutera perisian yang sangat baik. Anda boleh mempercepatkan keluk pembelajaran anda dengan belajar daripada pakar di sekeliling anda dan mempelajari corak reka bentuk yang biasa digunakan.

Bab 13: Paralelisme

1. Menulis kod selari adalah sukar.

2. Pepijat dan masalah yang kadang-kadang sukar untuk dihasilkan semula selalunya merupakan masalah bersamaan.

3. Ujian tidak menjamin bahawa aplikasi anda akan bebas pepijat, tetapi ia akan meminimumkan risiko.

4. Ketahui tentang masalah konkurensi biasa dan kemungkinan penyelesaiannya.

Bab 14: Penapisan Berurutan

1. Kod bersih biasanya tidak bermula dengan batu tulis kosong. Anda menulis penyelesaian kasar dahulu dan kemudian memfaktorkannya semula untuk menjadikannya lebih bersih.

2. Adalah satu kesilapan untuk berhenti menggunakan kod sebaik sahaja ia mula berfungsi. Luangkan masa untuk menjadikannya lebih baik selepas ia sudah berfungsi.

3. Pergolakan semakin meningkat secara beransur-ansur.

4. Jika anda mendapati diri anda terikat di mana menambah ciri adalah terlalu sukar atau mengambil masa terlalu lama, berhenti menulis ciri dan mulakan pemfaktoran semula.

5. Perubahan tambahan selalunya lebih baik daripada membina semula dari awal.

6. Gunakan Pembangunan Dipacu Ujian (TDD) untuk membuat sejumlah besar perubahan yang sangat kecil.

7. Reka bentuk perisian yang baik melibatkan pemisahan kebimbangan dalam kod anda dan pemisahan kod kepada modul, kelas dan fail yang lebih kecil.

8. Lebih mudah untuk membersihkan kucar-kacir serta-merta selepas anda membuatnya daripada membersihkannya kemudian.

Bab 15: JUnit Dalaman

1. Nama pembolehubah negatif atau ungkapan bersyarat adalah lebih sukar untuk difahami daripada yang positif.

2. Pemfaktoran semula ialah proses berulang yang penuh dengan percubaan dan kesilapan.

3. Tinggalkan pangkalan kod lebih baik daripada semasa anda menemuinya (Peraturan Pengakap Lelaki). (Diulang dari Bab 1)

Bab 16: Refactoring SerialDate

1. Semakan kod dan kritikan terhadap kod kami menjadikan kami lebih baik, dan kami harus mengalu-alukannya.

2. Mula-mula buat kod itu berfungsi, kemudian betulkannya.

3. Tidak setiap baris kod memerlukan ujian.

Bab 17: Bau dan Heuristik

1. Kod bersih bukanlah satu set peraturan, sebaliknya sistem nilai yang menentukan kualiti kerja anda.

[Dalam bab ini, Uncle Bob menyenaraikan 66 lagi variasi kod dan heuristiknya, yang kebanyakannya dibincangkan dalam buku yang lain. Menghasilkan semula mereka di sini pada asasnya akan menyalin dan menampal nama setiap item, jadi saya telah mengelak daripada berbuat demikian. Saya cadangkan anda membaca buku itu!]

Kesimpulan

Mari kita tamatkan di mana kita bermula: Kod Bersih oleh Robert C. Martin ialah buku pengaturcaraan yang paling disyorkan sepanjang masa. Terdapat sebab yang kukuh untuk ini.