Manifesto Programmer Bersih atau Ringkasan Buku Kode Pendek Robert Martin

Artikel ini adalah sinopsis buku Clean Code Robert Martin dan pemahaman saya tentang bagaimana seharusnya Clean Code. Tidak ada bagian pengujian, TDD, arsitektur apa yang seharusnya, dll. Di sini semuanya hanya tentang apa yang seharusnya menjadi Kode Bersih.

Ya, mungkin topik Kode Bersih sudah usang, namun demikian, tidak semua orang mengenalnya dan, apalagi, saya belum menemukan analog dari konten yang terkandung dalam artikel saya.

Jenderal

Tidak ada cara dan solusi yang benar. Ada satu yang paling cocok untuk tugas tertentu.

Saat memecahkan masalah, cobalah untuk mereproduksi secara absolut semua kasus yang dapat memengaruhi tugas ini dan mengimplementasikan tugas dengan memperhitungkan sepenuhnya semua kasus.

Juga, ketika memecahkan masalah, cobalah untuk pergi dari yang sebaliknya. Pahami hasil seperti apa yang ingin Anda dapatkan pada akhirnya dan buatlah berdasarkan algoritma ini tugas yang akan dilakukan.

Sebelum mengirim tugas untuk dirilis, periksa apakah itu berfungsi dengan benar. Apakah ada kesalahan di dalamnya. Ini berlaku bahkan untuk komitmen yang dikirim ke cabang Anda. Skenario paling ideal adalah skenario di mana tidak ada yang bisa menemukan kesalahan dalam fungsionalitas yang Anda kembangkan.

Selalu pikirkan tentang bagaimana Anda dapat membuat kode Anda lebih sederhana, lebih bersih dan lebih mudah dibaca.

• Kasing apa yang bisa dimiliki suatu tugas?
• Sudahkah saya mempertimbangkan semuanya?
• Apa yang bisa salah?
• Apa yang bisa digabungkan?
• Apakah ada fungsi serupa?
• Apa yang berlebihan di sini?
• Bagaimana cara membuatnya lebih mudah?
• Bagaimana membuatnya lebih mudah dibaca?
• Bagaimana membuatnya lebih jelas?

Kode bersih

Bagaimana cara menulis kode yang bersih dan bagus? Itu seperti menulis buku. Pertama Anda membuat konsep dan kemudian menyisirnya ke keadaan di mana Anda akan senang membacanya. Ingatlah selalu bahwa kode Anda harus menceritakan sebuah kisah sehingga pembaca dapat memahaminya.

Entitas dipahami - antarmuka, kelas, metode, variabel, objek, dll.

• Kode bersih sederhana, ekspresif, dan fokus pada tugas tertentu.
• Kode bersih mudah dibaca, seperti prosa. Jika ini bukan masalahnya, maka ada baiknya refactoring.
• Kode bersih mudah dimodifikasi. Seharusnya tidak terikat dengan tumpukan entitas. Entitas apa pun dapat dengan mudah diubah.
• Kode bersih melewati ulasan jauh lebih baik. Jika ulasan berjalan dengan banyak komentar, maka itu tidak bersih dan perlu di refactored.
• Kode bersih selalu terlihat seperti sudah dikerjakan untuk waktu yang sangat lama. Apa pun cara Anda berusaha untuk meningkatkannya, Anda masih akan sampai pada kesimpulan bahwa kode ini adalah yang terbaik. Karenanya, kode bersih dipikirkan hingga detail terkecil.
• Aturan Kepramukaan: Tinggalkan tempat parkir lebih bersih daripada sebelumnya. Ini dengan mudah bergeser ke pemrograman. Lihat kode kotornya? Jadikan lebih bersih saat Anda memecahkan masalah Anda. Anda tidak boleh terbawa oleh ini, dan jika kode kotor sangat kotor, maka Anda harus mengalokasikan tugas dan waktu terpisah untuk membersihkannya.
• Jangan takut untuk melakukan perubahan. Jika Anda ingin membuatnya, maka Anda memiliki alasan untuk itu, yang berarti Anda akan membuat kodenya lebih baik dan bersih. Selain itu, tes akan menunjukkan apakah ada kesalahan dalam kode Anda (asalkan ada sama sekali).
• Entitas apa pun harus bertanggung jawab atas satu fungsional dan hanya untuk itu. Dan dia harus melakukannya dengan baik. Tanggung jawab tunggal.
• Jika suatu entitas bertanggung jawab dengan segera untuk dua tindakan atau lebih, maka fungsinya harus dipisahkan.
• Kode harus dibaca dari atas ke bawah.
• Dalam arsitektur yang baik dan kompeten, membuat perubahan tanpa biaya dan upaya yang signifikan.
• Hapus kode mati. Kode mati adalah kode yang tidak akan dipanggil dalam kondisi apa pun atau kode yang tidak digunakan di mana pun.

Nama dan divisi

• Gunakan nama yang jelas dan mudah diucapkan untuk entitas apa pun. Mereka harus menjelaskan mengapa entitas ini ada, apa yang dilakukannya, dan bagaimana entitas itu digunakan.
• Jangan takut membuang waktu untuk memilih nama terbaik dan ramah. Anda akan menang di masa depan dengan bekerja atau membaca kode ini.
• Jika nama entitas tidak sesuai dengan fungsinya atau nama tidak mengerti apa yang entitas lakukan, maka harus diganti namanya menjadi nama yang paling dimengerti. Jika ini tidak mungkin, maka ada sesuatu yang salah dengan fungsionalnya dan perlu direaktor ulang.
• Entitas, yang memiliki nama "Dan", "Dengan" - melanggar Tanggung Jawab Tunggal. Fungsionalitas entitas semacam itu layak dibagikan. Namun aturan ini terkadang diabaikan.
• Teks-teks yang tidak dapat dipahami, garis-garis harus dimasukkan ke dalam variabel dan memberi mereka nama yang jelas.
• Nama metode harus berisi kata kerja yang menjelaskan apa yang dilakukan metode ini dan kata kunci yang digunakan metode ini. Jika nama metode tidak memiliki kata kerja, maka entitas ini tidak boleh menjadi metode atau harus diberi nama yang benar.
• Nama yang sama harus dihindari untuk dua tujuan berbeda.
• Jika suatu entitas memiliki nama yang mirip dengan entitas lain, maka kemungkinan besar fungsinya sangat mirip dan mereka perlu digabungkan? Jika tidak, nama mereka perlu diubah agar tidak mirip.
• Jika Anda secara mental mengubah nama entitas ketika Anda membaca kode sehingga Anda dapat lebih memahami fungsinya, maka ganti namanya menjadi nama mental ini.
• Pilih satu kata untuk satu konsep. Akan sulit untuk memahami fungsionalitas saat Anda mengambil, mengambil, dan mendapatkan nama. Lebih baik kemana-mana.
• Nama yang panjang dan mudah dimengerti lebih baik daripada yang pendek tapi tidak bisa dipahami.

Fungsi

• Fungsinya harus pendek dan padat.
• Fungsinya harus sangat pendek dan sangat kompak.
• Perkiraan maksimum 20 baris dan 150 karakter dalam satu baris, jika tidak cocok, maka Anda perlu memisahkan.
• Suatu fungsi harus melakukan hanya satu operasi.
  
  • Dia harus melakukannya dengan baik dan dia tidak boleh melakukan hal lain.
  • Jika suatu fungsi hanya melakukan tindakan-tindakan yang berada pada level abstraksi yang sama, maka fungsi tersebut melakukan satu operasi.
  • Untuk menentukan apakah suatu fungsi melakukan lebih dari satu operasi, cobalah mengekstrak fungsi lain darinya, yang tidak akan menjadi rumusan ulang implementasi yang sederhana.
• Pernyataan bersyarat apa pun dengan pilihan panjang melalui sakelar, jika-lain harus dibelah atau digabungkan tanpa duplikasi, mungkin ke dalam kelas dengan implementasi, dan mentransfer pilihan implementasi ke kelas dasar, pabrik, atau orang lain.
• Jika, yang lain, sementara, dll. harus mengandung panggilan ke satu fungsi. Ini akan lebih mudah dibaca, lebih jelas dan lebih mudah.
• Jumlah ideal argumen input untuk fungsi = 0. Jika ada lebih dari tiga argumen input, maka ada baiknya mempertimbangkan cara terbaik untuk menghilangkannya, misalnya, membuat kelas untuk argumen ini.
• Semakin banyak input argumen, semakin sulit fungsi tersebut dipahami.
• Fungsi yang dilewati argumen argumen, di mana operasi fungsi tergantung, menunjukkan bahwa fungsi melakukan lebih dari satu operasi. Fungsi seperti itu harus dibagi menjadi dua dan menyebutnya tingkat yang lebih tinggi.
• Fungsi yang mengubah argumen input harus memberikan referensi ke objek yang diubah, dan tidak hanya memodifikasinya tanpa kembali. String transform(String text)
• Jika fungsi harus mengubah argumen input, maka biarkan itu mengubah keadaan objek pemiliknya.
• Jika argumen input fungsi tidak boleh berubah (dan digunakan lebih lanjut dalam kode), maka Anda harus menyalin nilai argumen dan bekerja dengan salinan di dalam fungsi.
• Alih-alih mengembalikan nol, lebih baik menggunakan objek kosong - Collection.empty() atau objek null - EmptyObject() .
• Usahakan selalu menggunakan fungsi non-statis. Jika ini tidak memungkinkan, maka gunakan statis.
• Jika ada kode yang harus mengikuti satu demi satu, maka meneruskan hasil dari fungsi pertama ke yang kedua sehingga seseorang tidak mengubah urutan panggilan.
• Gunakan polimorfisme alih-alih jika / else atau beralih / case atau kapan.
• Hindari kondisi negatif.

Komentar

• Jangan menggunakan komentar jika Anda bisa menggunakan fungsi atau variabel sebagai gantinya.
• Jangan mengomentari kode yang buruk - tulis ulang. Tidak ada gunanya menjelaskan apa yang terjadi pada kode yang buruk, lebih baik membuatnya eksplisit dan mudah dimengerti.
• Komentar dapat digunakan untuk menyampaikan beberapa informasi, peringatan tentang konsekuensinya, tetapi tidak untuk menjelaskan cara kerja kode.
• Gunakan TODO dan FIXME dalam kasus di mana Anda perlu mencatat bahwa kode perlu ditingkatkan, tetapi sekarang tidak ada sumber daya untuk ini.
• Gunakan //region REGIONNAME //endregion REGIONNAME , dan jika Anda gunakan, maka pikirkan apakah mungkin untuk membagi wilayah menjadi entitas.
• Kode dokumen yang rumit tetapi bersih.
• Jangan tinggalkan kode komentar lama. Anda dapat menemukannya di histori komit, jika perlu.
• Komentar harus singkat dan jelas. Komentar informasi tidak boleh memiliki banyak informasi. Semuanya harus singkat dan to the point.

Pemformatan dan aturan

• Ikuti kode gaya yang diadopsi pada proyek.
• Ikuti aturan yang diterima di tim.
• Tunduk pada format dan gaya kode, kode akan lebih mudah dibaca dan lebih baik. Tidak sia-sia bahwa buku itu diberikan kepada editor sebelum menerbitkannya.
• Anda perlu memiliki alat otomatis yang akan memformat kode untuk Anda.
• File sumber harus seperti artikel surat kabar. Ada tajuk, deskripsi singkat dalam bentuk parameter dan konten dalam bentuk fungsi. Jika ini bukan masalahnya, maka Anda harus mengubah formatnya.
• Entitas yang terkait satu sama lain harus dekat, misalnya, dalam satu paket, sehingga lebih mudah untuk menavigasi kode.
• Variabel kelas (bidang) harus di bagian atas kelas.
• Variabel metode harus lebih dekat ke tempat penggunaannya.
• Fungsinya harus sesuai urutan panggilan. Jika satu memanggil yang lain, maka fungsi panggilan harus di atas yang dipanggil. Di sisi lain, fungsi pribadi level rendah mungkin ada di bagian bawah file dan tidak mengganggu pemahaman kode level tinggi. Tapi saya lebih suka cara pertama.

Objek dan Struktur Data

• Anda harus bekerja dengan abstraksi sehingga implementasinya dapat dengan mudah diubah.
• Anda harus bekerja dengan abstraksi, karena klien yang menggunakan fungsionalitas tidak boleh tahu tentang detail implementasi, ia harus tahu implementasi mana yang digunakan dalam hal ini.
• Anda harus memberikan API tempat Anda bekerja dan menyembunyikan detail implementasi, struktur. Jadi akan lebih mudah untuk bekerja dengan entitas seperti itu dan menambahkan tipe perilaku, fungsi, dan implementasi baru.
• DTO - Obyek Transfer Data. Kelas yang hanya berisi data dan tanpa fungsi. Ini diperlukan untuk mentransfer beberapa data. Objek dari kelas ini harus tidak berubah.

Kelas

• Kelas harus kompak.
• Kelas harus lebih padat.
• Nama kelas harus menjelaskan tanggung jawabnya. Dari sini Anda dapat menghitung ukuran kelas.
• Fungsionalitas kelas harus dengan jelas sesuai dan sesuai dengan nama kelas.
• Membagi keterhubungan ke dalam kelas-kelas kecil. Seharusnya tidak ada kohesi yang kaku dan berlimpah - ini mempersulit dukungan dan pengembangan proyek.
• Ingat Tanggung Jawab Tunggal. Entitas harus memiliki satu dan hanya satu alasan untuk perubahan.
• Amati enkapsulasi. Enkapsulasi yang lemah harus selalu menjadi pilihan terakhir.
• Biasanya kita mendeklarasikan variabel dan fungsi tambahan pribadi, tetapi kadang-kadang mereka perlu dinyatakan terlindungi dan dapat mengaksesnya dari tes.
• Jika sekelompok fungsi milik fungsional tertentu, maka kelompok fungsi ini dapat dan harus dialokasikan ke kelas yang terpisah dan menggunakan instance-nya.

Menangani kesalahan

• Gunakan Pengecualian alih-alih mengembalikan kode kesalahan.
• Penanganan kesalahan adalah satu operasi. Jika ada try kata kunci dalam fungsi, maka setelah catch/finally blok seharusnya tidak ada hal lain dalam fungsi.
• Jika Anda memiliki enum yang mencantumkan kesalahan, maka lebih baik menyingkirkannya dan menggunakan pengecualian.
• Gunakan pengecualian yang tidak dicentang untuk secara eksplisit menunjukkan tempat di mana ada masalah. Kesalahan semacam itu tidak perlu ditangkap, sebaliknya Anda perlu menulis kode agar kesalahan ini tidak pernah ada.
• Berikan informasi yang cukup bersama dengan melemparkan pengecualian sehingga nantinya pengguna kode Anda dapat memahami apa yang sebenarnya terjadi.
• Alih-alih pernyataan bersyarat dengan penanganan kesalahan, lebih baik untuk melemparkan pengecualian dan menanganinya.
• Jangan lulus nol di mana pun. Cobalah untuk menghindari ini sebanyak mungkin.
• Penanganan kesalahan adalah tugas yang terpisah dan tidak berlaku untuk logika utama program.

Perbatasan

• Kami selalu menggunakan beberapa perpustakaan yang paling sering memberi kami fungsi yang terlalu luas, terlalu kecil atau bertentangan dengan fungsionalitas yang diharapkan, yang membuat kode lebih berantakan dalam penggunaan akhirnya. Anda dapat menghindari ini dengan hanya menerapkan pola seperti Dekorator, Adaptor, Fasad, atau lainnya.
• Ada situasi ketika Anda perlu bekerja dengan fungsionalitas yang sedang dikembangkan atau belum diadaptasi untuk digunakan dalam kode produksi. Dalam hal ini, Anda harus membayangkan apa yang Anda harapkan dari perpustakaan / fungsi ini dan menulis antarmuka Anda atau membuat entitas yang dengannya Anda akan bekerja dalam proyek Anda seperti yang Anda butuhkan. Ketika perpustakaan selesai dan menjadi stabil, Anda menyesuaikannya dengan struktur yang sudah jadi dan menggunakan fungsi yang sudah jadi.

Kata penutup

Artikel ini hanya menyediakan pedoman untuk menulis Kode Bersih. Tentu saja, mereka bisa diabaikan. Anda hanya perlu memahami bahwa setiap keputusan Anda harus memiliki argumen yang mendukungnya.