🤡 🙇🏾 💇🏽 Apa "kode bersih" pada tahun 2020? 📆 👂🏻 🗨️

^{"Kode bersih" dan kucing bersih.}

Jangan memberi makan roti pengembang, mari kita berdebat tentang kebersihan kode: misalnya, posting Dan Abramov "Selamat tinggal, Kode Bersih" baru-baru ini membuat keributan .

Tetapi pada saat yang sama, konsep "kode bersih" tidak memiliki definisi yang jelas. Buku utama tentang masalah ini adalah "Kode Bersih" , di mana Robert "Paman Bob" Martin segera menyatakan: "berapa banyak programmer, begitu banyak definisi". Namun, dari sini ia tidak menyimpulkan "membicarakannya sia-sia", tetapi kesimpulan "layak membandingkan berbagai definisi". Karena itu, dalam buku itu ia mengutip pandangan beberapa programmer terkemuka tentang apa kode bersih itu.

Itu menjadi menarik bagi kami: pada tahun 2020, ide-ide umat manusia tentang kode bersih tetap sama, atau apakah mereka entah bagaimana berubah sejak buku itu dirilis? Apakah pendapat berbagai pakar IT berbeda: mungkin para backender melihat semuanya dari satu sudut, dan penguji dari sudut lain?

Pada bulan April, Paman Bob akan terbang ke St. Petersburg untuk berbicara di tiga konferensi kami, dan mereka hanya berada di tiga arah yang berbeda ( tentang pengembangan .NET , tentang pengujian, dan tentang JavaScript ). Oleh karena itu, kami bertanya kepada beberapa pembicara konferensi ini apa kode bersih bagi mereka untuk membandingkan pendapat para pakar industri pada tahun 2020.

Dan karena topiknya kosong, pasti salah satu dari Anda tidak akan setuju dengan pendapat tersebut. Kalau begitu, ayo berdebat dalam komentar, ini juga menyenangkan!

UPD: , . , . - . . 13 , .

DotNext

John adalah legenda Stack Overflow, penulis C # in Depth, dan salah satu donor paling terkenal di planet ini. Dia memberi kami definisi ini:

“Bagi saya, kode bersih adalah kode yang membosankan, dari sudut pandang implementasi. Satu-satunya kejutan dalam dirinya adalah seberapa banyak dia tanpa kejutan. Saya harus merasa, "Ya, saya bisa menulis ini", bahkan jika saya benar-benar tidak bisa - dengan seberapa baik dirancangnya itu.

Ketika abstraksi dipilih dengan benar, implementasi diturunkan secara alami. Idealnya, abstraksi ini juga harus terasa sederhana dan jelas - walaupun pada kenyataannya, membawanya ke keadaan seperti itu bisa memakan waktu berjam-jam, berminggu-minggu, berbulan-bulan refleksi dan eksperimen.

Kurangnya kejutan yang disebutkan kemudian berlanjut untuk digunakan: ketika saya menulis kode menggunakan API yang dirancang dengan baik, kode saya juga menjadi jelas dan membosankan. "

Andrey Akinshin

Pengunjung DotNext tidak perlu memperkenalkan Andrei, tetapi untuk sisanya kami akan memberi tahu Anda bahwa ia dikenal karena karyanya di IDE Rider , perpustakaan BenchmarkDotNet , laporan yang jelas, dan buku "Pro .NET Benchmarking".

Ketika kami bertanya apa pendapatnya tentang kode bersih, Andrei merujuk ke dua habrapost lamanya: "Kode sempurna dan proyek nyata" dan "Komentar atau tidak komentar" . Dan kami telah memilih untuk Anda beberapa paragraf dari sana, yang dengannya seseorang mungkin ingin berdebat:

“Saya suka kode yang sempurna. Bagaimanapun, ini bukan hanya pendekatan yang tepat untuk program penulisan, tetapi juga seni yang nyata. Dari membaca daftar yang baik, saya mendapatkan kesenangan sama seperti membaca buku yang bagus. Mendesain arsitektur sebuah proyek besar tidak lebih mudah daripada merancang arsitektur sebuah bangunan besar, dan jika itu bekerja dengan baik, hasilnya tidak kalah indah. Kadang-kadang itu membuat saya kagum betapa indahnya jalinan pola desain dalam menciptakan sistem perangkat lunak yang sempurna. Saya mengagumi perhatian terhadap detail ketika benar-benar setiap metode sangat sederhana dan mudah sehingga diklaim sebagai contoh klasik kode sempurna.

Tapi, sayangnya, semua keindahan ini terpecah pada kenyataan pahit dan proyek nyata. Jika kita berbicara tentang proyek produksi, pengguna tidak peduli seberapa cantik kode Anda dan seberapa bagus arsitekturnya, mereka peduli sehingga proyek bekerja dengan baik. Tetapi saya masih berpikir bahwa bagaimanapun juga, Anda harus berusaha untuk menulis dengan benar, hanya saja tidak boleh ada fanatisme. ”

Dylan Beatty

Habrachitateli dapat mengingat Dylan dalam laporannya yang jelas dan gamblang tentang bekerja dengan kode warisan: untuk Habr kami melakukan decoding . Dan ketika kami menoleh ke Dylan tentang kode bersih, dia menulis teks yang begitu terperinci dan penuh perhatian yang menerbitkannya di setidaknya satu pos terpisah:

"Sangat menarik bagi saya bahwa konsep" kode bersih "telah menyebar jauh melampaui lingkaran orang yang telah membaca buku Robert Martin. Saya berbicara dengan banyak, banyak pengembang yang mendengar kata-kata "kode bersih" tetapi tidak membaca buku itu. Saya bahkan bertemu mereka dalam codrev: "Semuanya cukup bagus di sini, tetapi bisakah Anda membersihkannya sedikit?" - dan permintaan semacam itu bisa sangat tidak akurat dan menjengkelkan jika tidak jelas apa arti "murni" dalam konteks khusus ini.

Dalam bahasa Inggris ada kata-kata yang sering ditemukan bersama - "bersih", "rapi", "terorganisir", "rapi" - dan bagi saya sebagai penutur asli bahasa Inggris, mereka semua memiliki arti yang sedikit berbeda. Saya pikir berguna untuk mempertimbangkan beberapa konotasi dari kata-kata ini sehubungan dengan pengembangan perangkat lunak.

Bayangkan, misalnya, dapur sebuah restoran. Kata clean dalam konteks ini akan memiliki konotasi yang sangat spesifik. Semuanya dicuci, disterilkan, tidak ada ancaman infeksi karena makanan mentah, dan sejenisnya.

Tetapi ini tidak secara otomatis berarti bahwa semuanya diatur dengan baik di sini. Jika Anda pernah mencoba memasak dengan teman atau di apartemen yang disewa di Airbnb, Anda tahu betapa menyebalkannya ketika ada hal-hal yang tidak pada tempatnya. Deterjen pencuci piring ada di prasmanan, di mana Anda berharap melihat pot, dan pemeras bawang putih umumnya tidak jelas di mana. Ya, semuanya bersih - tidak ada ancaman bahwa seseorang akan menyukai makanan yang dimasak di dapur ini - tetapi bekerja dalam kondisi seperti itu mengganggu.

Sekarang bayangkan sebuah bengkel pertukangan. Di tempat ini, kotoran juga dapat menyebabkan masalah, tetapi di sini Anda tidak memiliki definisi yang sama tentang "kebersihan" seperti di dapur. Anda dapat membersihkan pahat hingga mulai berkilau, tetapi Anda tetap tidak akan bisa memotong sosis dengannya. Jadi kata "bersih" bisa sangat subjektif.

Tetapi bagi saya, kata-kata seperti "rapi" dan "terorganisir" berfungsi dalam konteks di mana "bersih" tidak bekerja dengan baik. "Terorganisir" berarti bahwa seseorang telah memikirkan dengan seksama tentang bagaimana mengatur unsur-unsur tempat kerja tertentu, dan "rapi" berarti bahwa unsur-unsur ini benar-benar ada di tempat yang dialokasikan untuk mereka. Seperti kata pepatah lama, "semuanya memiliki tempatnya dan segalanya ada di tempatnya."

Mungkin, dalam kasus kode, kita harus memikirkan kata-kata "bersih" , "rapi" dan "terorganisir" sebagai tiga konsep yang berbeda. "Bersih"berarti Anda melihat komponen basis kode - metode, fungsi, antarmuka - dan Anda tidak melihat alasan untuk khawatir. Dalam memberi nama mematuhi konvensi; nama variabel dan metode ditulis tanpa kesalahan; dalam detail seperti lekukan dan tanda kurung mematuhi gaya tunggal; dimanapun Anda melihat, Anda melihat bukti bahwa pada tingkat dasar ini dijalankan oleh orang-orang yang serius tentang bisnis. Ini kebalikan dari "kode kotor" - kode di mana banyak kesalahan ketik, kurung kurawal, dan lekukan diinginkan dalam nama, nama file yang tidak sesuai. Ini adalah hal-hal yang secara ajaib diperbaiki ketika Anda memanggil alat pembersihan kode dalam sesuatu seperti ReSharper.

"Terorganisir"- Ini tentang arsitektur. Ini tentang bagaimana Anda bisa terjun ke basis kode asing dan menemukan hal-hal di mana Anda berharap melihatnya. Batas antarmuka dan domain membantu, bukan mengganggu; metode dan variabel yang dinamai tidak hanya dinamai dengan benar dari sudut pandang bahasa, tetapi juga mencerminkan bahasa tunggal dari bisnis tempat Anda bekerja.

Dan "rapi" adalah tentang menghormati konvensi lokal ... basis kode di mana Anda dapat menemukan hal-hal yang benar di tempat mereka, bahkan jika model organisasi spesifik tidak begitu jelas bagi Anda pada saat itu.

Saya pikir ketika mereka berbicara tentang perjuangan untuk "kode bersih," ini biasanya berarti ketiga hal ini. Tetapi menetapkan tujuan untuk menjadi "kode bersih" sepenuhnya, terutama ketika bekerja dengan proyek warisan yang kompleks, bisa menjadi prospek yang cukup menakutkan. Mungkin akan berguna bagi kita semua untuk berpikir sedikit lebih dalam dan mencari tahu komponen mana dari "kode bersih" yang benar-benar akan menguntungkan proyek yang sedang kita kerjakan. "

Heisenbug

Ini adalah "konferensi pengujian tidak hanya untuk penguji": ini di persimpangan pengujian dan pengembangan. Oleh karena itu, banyak dari penuturnya memahami secara spesifik kedua dunia ini sekaligus.

Ivan Krutov dan Anna Chernysheva

Ivan dan Anna bekerja di perusahaan yang berbeda, tetapi ada sesuatu yang menyatukan mereka: keduanya tahu banyak tentang Selenium. Kami berbicara dengan mereka pada saat yang sama, jadi kami mendapat definisi bersama:

Ivan: “Bagi saya, definisi paling sederhana dari kode bersih adalah kode yang dapat dimengerti tanpa komentar,“ mendokumentasikan sendiri ”. Kode yang penuh dengan komentar yang mencoba menjelaskan apa yang dilakukannya bukan kode murni. "

Anna: "Bagi saya: ini adalah kode yang dapat Anda temukan dengan cepat, perbaiki bug, mudah kembangkan, tambah itu."

Ivan: "Anda juga bisa mengatakan bahwa ini adalah" kode yang membuat Anda tidak malu. " Secara umum mereka mengatakan bahwa jika Anda melihat kode yang Anda tulis enam bulan lalu dan tidak takut, maka Anda tidak berkembang. Ternyata setiap tahun kode Anda harus menjadi lebih bersih. "

Sebastian Dashner

Sebastian adalah Advokat Pengembang Java Lead IBM, dan sering dapat dilihat di konferensi Java. Tetapi karena dia terbang ke Heisenbug sekarang, kami bertanya kepadanya tentang kode bersih dalam konteks pengujian, dan dia menjawab:

“Dalam pengalaman saya, kualitas kode penting tidak hanya dalam hal kode produksi, tetapi juga untuk pengujian kami. Dalam tes, kode bersih, abstraksi yang benar, dan delegasi sering diabaikan, yang mengarah pada kode uji yang tidak dapat Anda dukung. Ketika kami memperbaiki kode produksi dan mengubah perilakunya, menjadi jelas apakah kami telah melakukan pekerjaan yang baik dalam memodelkan dan mengimplementasikan pengujian kami. "

Andrey Lushnikov

Andrey sedang mengerjakan alat otomatisasi browser Playwright, yang baru-baru ini kami tulis . Definisinya menjadi yang paling ringkas:

“Kode bersih adalah kode bodoh, sangat bisa dimengerti. Dan kayu itu lebih baik. "

Alexandra Svatikova

Alexandra adalah seorang pakar keamanan informasi di Odnoklassniki, yang "memulai dalam IT sebagai pengembang Java, tetapi berbalik dengan cara yang salah." Definisinya berubah menjadi:

"Kode murni memiliki tiga properti: pengembang lain dapat dengan mudah membaca dan memahaminya, perbaikan kecil memerlukan upaya yang sepadan, dan efek perubahan tertentu dapat diprediksi.

Bahkan, ini berarti bahwa kode terstruktur, ringkas, mengikuti praktik yang diterima secara umum untuk bahasa yang ditulisnya, tidak mengandung dependensi implisit atau efek samping dan dicakup oleh tes. "

Holyjs

Andrey Melikhov

Andrei dikenal banyak orang untuk proyek Devshakhta . Tidak mengherankan bahwa seseorang yang terus-menerus merumuskan pikirannya di Devshacht Podcast dengan jelas menyatakan posisinya:

"Robert" Paman "Martin dengan tiga buku utamanya (" Kode Bersih "," Kode Bersih "dan" Arsitektur Bersih "), Tampak bagi saya bahwa ia mencoba menjawab pertanyaan untuk dirinya sendiri: siapa, apa dan bagaimana harus menulis. Seseorang dapat berdebat tentang kebenaran dari beberapa kesimpulannya, tetapi inilah yang tidak dapat disangkal - buku-buku ini didasarkan pada pengalaman pribadi yang kaya dan akal sehat. Dan dalam kerangka ide ini, saya dapat mengatakan bahwa bagi saya kode yang bersih adalah kode yang akan ditulis oleh seseorang yang tersandung banyak jebakan dalam hidupnya dan dalam proses yang menyakitkan ini belajar berjalan dengan gaya berjalan yang hati-hati yang memungkinkan mereka untuk dihindari.

Anda mungkin tidak nyaman dengan gaya orang ini, tetapi jika Anda mengikutinya, Anda pasti akan aman. Anda dapat mengambil gaya ini dan mendaur ulangnya, membuatnya nyaman untuk Anda sendiri. Atau Anda bisa mati-matian menyelam ke sungai untuk mengisi kerucut Anda sendiri, mengembangkan gaya Anda sendiri, sementara sisanya akan memandang Anda dengan tak percaya, bergerak di bawah pengawasan kawan-kawan yang lebih tua.

Kode murni adalah kode yang mudah dibaca, mudah dirawat, dan mudah diperluas. Tiga aspek inilah yang meletakkan dasar yang kuat untuk aplikasi yang harus hidup bertahun-tahun dalam menghadapi persyaratan eksternal yang tidak stabil. Yaitu, aplikasi seperti itu yang kami tulis di perusahaan besar "

Alexandra Kalinina

Alexandra adalah anggota komite program HolyJS, ia memiliki pengalaman luas dalam pemrograman - dan meskipun ia tidak bersama Heisenbug, ia juga mengetahui tes secara langsung (unit, integrasi, E2E, B2B). Berikut ini teksnya:

“Kode bersih sekarang adalah konsep yang sederhana, tetapi agak sulit untuk dipahami. Menurut saya, kode bersih dapat diperoleh dengan mematuhi aturan berikut:

- setiap bagian kode harus dapat menskalakan atau menumbuhkan / meningkatkan secara terpisah dari bagian lain, tetapi pada saat yang sama tetap mempertahankan ide asli / integrasi dengan bagian lain (SOLID banyak membantu, dan juga aturan "semua keputusan yang mungkin diambil kemudian harus dibuat kemudian").
- Kode harus dibaca sebagai buku yang menarik, dengan nama dan sebutan khas yang dapat dimengerti. Misalnya, jika Anda memutuskan untuk menulis sebuah cerita, maka kemungkinan besar akan memiliki struktur yang khas seperti pengantar, plot, klimaks, dan kesudahan. Bahkan jika Anda adalah satu-satunya yang mengerjakan suatu proyek, kode tersebut harus mudah dibaca oleh Anda kapan saja, terlepas dari arsitektur, bahasa, atau kerangka kerja yang dipilih.
- Kode harus memiliki struktur yang jelas. Itu alasan mengapa ini atau itu kode dalam proyek harus dipahami.
“Setiap baris kode harus dibenarkan dari perspektif bisnis”

Nicolò Ribaudo

Nicolo, ketika masih mahasiswa, menjadi salah satu pengembang kunci dari kompiler Babel (kami sudah menanyakan hal ini secara terpisah). Versinya ternyata adalah ini:

"Kode bersih adalah kode yang dapat dengan mudah dibagi menjadi komponen atom kecil.

"Atom kode" adalah sekumpulan instruksi terkecil yang mungkin memiliki makna independen dan tidak perlu tergantung pada konteks sekitarnya: nama-nama variabel dan operasi cukup deskriptif sehingga pembaca tidak perlu mengalokasikan memori tambahan di kepala mereka untuk menyimpan nilai-nilai mereka dan kemungkinan modifikasi, serta tidak perlu untuk mencari di tempat lain dalam kode untuk memahami apa arti dari "atom" ini. Semakin kecil atom, semakin mudah untuk memahami apa yang dilakukan oleh kode.

Kode dapat bersih terlepas dari bahasa pemrograman atau paradigma: atom dapat diimplementasikan sebagai objek kecil, fungsi, atau bahkan sebagai potongan kecil kode yang tidak terisolasi secara sintaksis. "

Kesimpulan

Akhirnya, ketika pendapat dikumpulkan, kami menunjukkannya kepada Paman Bob sendiri dan bertanya apakah dia ingin mengatakan sesuatu. Jawabannya ternyata:

“Saya sepenuhnya mendukung para komentator di atas. Saya hanya akan menambahkan satu hal yang pernah dikatakan Michael Feathers: "Kode bersih selalu terlihat seperti ditulis oleh orang yang peduli."

Kesimpulannya terdengar sangat ramah. Tapi kode bersih adalah topik yang bisa diperdebatkan sehingga ketika salah satu dari Anda mengangguk, orang lain mungkin sedang terbakar, merasakan sesuatu seperti ini:

« : „ , ”. , , : . , !»
« „ ”? „” , — , , „” — !»
"Kata-kata" kamu bisa mengisi gundukanmu sementara yang lain terlihat dengan bingung "terdengar menghina, seolah-olah hanya orang bodoh yang melakukannya. Tetapi semua yang terbaik dan inovatif muncul ketika Anda mengisi kerucut Anda dan memahami alasannya, dan tidak hanya mengikuti buku-buku lama! "

UPD 12 Maret: Meskipun Paman Bob tidak dapat terbang ke kami, konferensi St. Petersburg kami ( untuk pengembang .NET , penguji, dan pengembang JavaScript ) tidak mungkin membantah dengan kode bersih. Di situs konferensi - selalu versi terbaru dari program. Tetap disini dan berlangganan buletin kami - seminggu sekali kami akan membicarakan perubahannya.

Apa "kode bersih" pada tahun 2020?