Menjadikan kod anda bersih dan cantik ialah cara terbaik untuk memenuhi tarikh akhir. Robert Martin memukul kepala dengan salah satu kenyataan bernasnya: "Satu-satunya ukuran sebenar kualiti kod ialah unit What-The-F**ks/Minute .” " dalam asalnya). Biar saya terangkan apa maksudnya. Setiap kali saya menyemak kod, otak saya melalui satu daripada tiga emosi:
“WTF?! Apa kejadahnya?!" (dengan jijik) - ini bukan... semuanya sangat teruk....
“WTF?! Apa kejadahnya?!" (dengan rasa kagum) - hmm, seorang yang bijak melakukannya!
“WTF?! Apa kejadahnya?!" (dengan kerengsaan) - agak kekeliruan, apa yang kita bincangkan?!
Jadi apakah yang paling penting dan apakah sebenarnya yang kita nilai apabila kita melihat beberapa kod? Itu sahaja: kesucian dan keindahannya. Keupayaan untuk menulis kod yang bersih dan cantik adalah penunjuk pembangun yang sangat profesional. Latihan dalam kemahiran ini adalah berdasarkan dua komponen - pengetahuan dan kerja. Pengetahuan mengajar anda corak, prinsip, amalan, heuristik. Anda memerlukan mereka untuk berkembang secara profesional. Hanya anda mesti menyerap pengetahuan ini seperti span melalui latihan berterusan dan kerja keras. Pendek kata, menulis kod bersih bukanlah mudah. Ini adalah kerja keras dan susah payah, dan anda perlu bekerja keras untuk melakukannya. Melalui percubaan dan kesilapan, anda akan bertambah baik dengan mengulangi langkah yang sama berulang kali sehingga anda menemui penyelesaian yang anda inginkan. Tidak ada cara yang lebih mudah. Di bawah ialah beberapa petua untuk membantu anda mempelajari cara menulis kod bersih.
Apa ada pada nama
Kendrick Lamar (artis hip-hop Amerika - nota editor) pernah menyatakan dengan tepat: "Jika saya akan menceritakan kisah sebenar, saya harus bermula dengan nama saya." Nama-nama dalam pembangunan perisian ada di mana-mana. Kami menamakan fungsi, kelas, hujah, pakej, program—segala-galanya. Kami menamakan fail sumber dan buku rujukan serta semua yang berkaitan dengannya. Kami menamakan perkara tanpa henti, dan ini menjadi bahagian penting dalam usaha ke arah mencipta kod bersih. Nama yang anda berikan sesuatu harus mencerminkan niat. Mencari nama yang baik bukan mudah, ia memerlukan masa, tetapi ia juga menjimatkan banyak masa apabila anda perlu berurusan dengan kod dan keadaan menjadi rumit. Jadi berhati-hati dengan proses ini dan jangan takut untuk menukar nama kemudian jika anda mendapati sesuatu yang lebih sesuai. Semua orang yang berurusan dengan kod anda akan sangat berterima kasih kepada anda.
Ingat bahawa nama mana-mana pembolehubah, kelas, fungsi mesti menjawab tiga soalan utama: mengapa ia (pembolehubah, fungsi, dll.) wujud, untuk apa ia berfungsi dan untuk apa ia digunakan.
Ini memerlukan bukan sahaja kemahiran deskriptif yang baik, tetapi juga pengetahuan umum dan pandangan yang luas. Dan tiada siapa yang boleh mengajar anda ini lebih baik daripada diri anda sendiri.
"Satu fungsi" - satu perkara
Louis Henry Sullivan (arkitek rasionalis dan modenis Amerika) pernah berkata: "fungsi menentukan bentuk . " Beliau berkata demikian mengenai seni bina rumah, tetapi ini tidak mengubah intipati. Setiap sistem dibina pada beberapa bahasa khusus domain yang dibuat oleh pengaturcara untuk menerangkannya dengan tepat. Fungsi bertindak sebagai kata kerja bahasa, dan kelas adalah kata nama. Selalunya, fungsi adalah yang paling penting dalam organisasi bahasa pengaturcaraan, dan menulisnya dengan betul adalah intipati mencipta kod yang baik. Terdapat hanya dua peraturan emas untuk menulis fungsi kualiti:
Mereka sepatutnya kecil
Mereka mesti melakukan satu perkara, satu tugas, dan melakukannya dengan baik
Iaitu, fungsi anda hendaklah kecil dan tidak boleh mengandungi struktur bersarang. Oleh itu, tahap lekukan fungsi tidak boleh lebih daripada satu atau dua. Pendekatan ini menjadikan kod lebih mudah dibaca, difahami dan difahami. Di samping itu, kita mesti memastikan bahawa ungkapan dalam fungsi berada pada tahap abstraksi yang sama. Mencampurkan tahap abstraksi dalam fungsi sentiasa mewujudkan banyak kekeliruan dan akhirnya membawa kepada kod yang tidak terurus. Pengaturcara terbaik menganggap fungsi sebagai cerita untuk diberitahu, bukan hanya kod untuk ditulis. Mereka menggunakan alatan bahasa pengaturcaraan pilihan mereka untuk mencipta blok kod yang kaya, ekspresif dan lebih bersih yang pada asasnya boleh bertindak sebagai pencerita yang hebat.
“Ulasan tidak menggantikan kod buruk”
Venus Williams, pemain tenis Amerika dan juara Wimbledon lima kali, terkena paku di kepala apabila dia berkata: “Semua orang meninggalkan komen mereka. Beginilah khabar angin muncul . " Komen adalah seperti pedang bermata dua. Komen yang diletakkan dengan baik adalah perkara yang sangat berguna. Sebaliknya, tiada apa yang mengacaukan ruang lebih daripada komen remeh dan tidak berguna. Tetapi komen yang paling merosakkan adalah mereka yang menyebarkan maklumat salah dan pembohongan. Pendek kata, komen adalah sejenis kejahatan yang perlu. Tidak selalu, tetapi untuk sebahagian besar. kenapa? Ia mudah, semakin lama ulasan, semakin sukar untuk dikekalkan, dan kebanyakan pengaturcara, seperti yang anda tahu, tidak selalu menukar komen bersama-sama dengan perubahan dalam kod. Kod bergerak dan berkembang. Bahagian kod dialihkan ke sana ke mari, tetapi tiada ulasan. Dan ini menjadi masalah!
Ingat: kod yang bersih dan jelas dengan sedikit ulasan adalah lebih baik daripada kod yang rumit dan bersepah. Jangan bazirkan tenaga anda untuk menerangkan kekecohan yang anda buat dalam ulasan. Lebih baik luangkan masa itu untuk membersihkan kekacauan itu.
"Pemformatan kod sentiasa menjadi keutamaan"
Ini dikatakan oleh tidak lain daripada Robert C. Martin (Robert Cecil Martin), aka Uncle Bob, pembangun, pengarang banyak buku mengenai pembangunan perisian, perunding, pengarang bersama manifesto Agile, dan sebagainya. Dan dia menambah: "Memformat kod adalah sejenis komunikasi. Dan komunikasi adalah keutamaan bagi mana-mana pembangun profesional.” Pernyataan di atas tidak boleh dipandang remeh, kerana ia merujuk kepada salah satu ciri terpenting pembangun yang cemerlang. Kod terformat membolehkan anda melihat jauh ke dalam fikiran anda. Kami ingin menarik perhatian orang ramai dengan kekemasan kami, perhatian terhadap perincian, keupayaan untuk mengatur dan menyatakan fikiran kami dengan jelas. Tetapi jika, apabila orang melihat kod itu, mereka melihat beberapa jenis kekeliruan, mengingatkan kepada vinaigrette, tanpa permulaan atau penghujung, ini menafikan usaha anda dan merendahkan reputasi pembangun. Jangan ragu-ragu! Anda sangat jauh daripada kebenaran jika anda berpendapat bahawa perkara utama dalam perniagaan ini ialah "kod itu hanya berfungsi". Fungsi yang anda buat hari ini berkemungkinan besar akan ditukar dalam keluaran seterusnya, tetapi kebolehbacaan kod tidak akan berubah. Gaya kod dan kebolehbacaannya yang baik menjadikannya lebih mudah untuk mengekalkan kod untuk masa yang lama, walaupun selepas kod asal telah ditukar tanpa dapat dikenali.
Jangan sekali-kali lupa bahawa pada masa hadapan, perkara yang berkemungkinan besar akan diingati bukanlah kod anda sendiri, tetapi gaya dan konsistensi anda. Oleh itu, pastikan kod diformat dengan baik dan mengikut peraturan mudah yang boleh difahami oleh semua ahli pasukan.
Mula-mula buat blok "cuba-tangkap-akhirnya".
Georges Canguilhem (sejarawan sains, ahli falsafah) betul-betul menyatakan: "Melakukan kesilapan adalah lumrah bagi seseorang, tetapi bertegas pada kesilapan adalah daripada syaitan . " Penyelesaian masalah adalah sesuatu yang dilakukan oleh semua pengaturcara. Data tidak sah boleh memasukkan input dan peranti mungkin gagal. Dan sebagai pembangun, kita perlu memastikan kod itu melakukan perkara yang sepatutnya dilakukan. Isunya bukan hanya pengendalian ralat, tetapi pengendalian ralat "bersih dan mudah dibaca". Banyak program menyesuaikan diri dengan pengendalian ralat. Jika anda melakukan ini, semuanya menjadi huru-hara sehingga tujuan dan logik kod utama dimusnahkan. Ini salah, tidak sepatutnya begini. Kod itu hendaklah bersih dan boleh dipercayai, dan pengendalian ralat hendaklah dijalin dengan lancar dan semula jadi ke dalam kod. Ini adalah penunjuk pengaturcara kelas tinggi. Dan satu cara untuk mencapai ini adalah melalui sarang dan liputan yang betul bagi semua ralat dalam blok cuba-tangkap. Blok ini menentukan skop kod anda. Apabila anda melaksanakan kod dalam bahagian cuba blok try-catch-finally, anda menyatakan bahawa pelaksanaan boleh dibatalkan pada bila-bila masa dan kemudian menyambung semula dalam tangkapan. Oleh itu, kami mengesyorkan bermula dengan try-catch-finally apabila anda menulis kod. Ini akan membantu menentukan apa yang pengguna boleh jangkakan daripada kod, tanpa mengira apa yang salah dengan kod semasa percubaan.
Sentiasa ingat bahawa setiap pengecualian yang anda lemparkan mesti mengandungi konteks yang mencukupi untuk menentukan lokasi dan sumber ralat. Mesej ralat kreatif dan bermaklumat diingati lama selepas kod itu ditulis, walaupun ketika pengaturcara sudah sibuk dengan tugas yang berbeza sama sekali.
Mari kita ringkaskan
Satu frasa yang luar biasa akan membantu kami meringkaskan semua perkara di atas. Ini ialah deria kod atau "rasa kod biasa," sejenis pengaturcara yang setara dengan akal sehat. Dalam kata-kata Robert Martin: "Menulis kod bersih memerlukan penggunaan sistematik banyak teknik kecil, digunakan sebagai hasil daripada rasa "kebersihan" yang teliti dan agak menyakitkan. Teknik kecil ini secara kolektif dipanggil code-sense . " Sesetengah daripada kita mempunyai "deria kod bunyi" ini sejak awal, manakala yang lain perlu membangunkannya melalui amalan yang berterusan. Naluri ini membantu bukan sahaja untuk mengenali perbezaan antara kod buruk dan baik, tetapi juga membantu dalam pembentukan strategi yang bertujuan mengubah kod buruk kepada baik. Kod buruk merosakkan segala-galanya. Bercakap secara kiasan, jika anda membekukan kek yang paling lazat dengan tahi anjing, maka... eh... hampir tidak sesiapa akan menyukainya. Pengertian kod membantu pengaturcara menggunakan alatan yang betul untuk mencapai matlamatnya mencipta kod bersih. Seorang pengaturcara yang memahami maksud code-sense ialah seorang artis yang boleh mencipta karya seni pada skrin kosong yang akan diingati selama bertahun-tahun. Sebagai Harold "Hal" Abelson, profesor sains komputer di Mit dan pengarah pengasas Creative Commons dan Yayasan Perisian Percuma, merumuskannya: "Program perlu ditulis terlebih dahulu supaya orang boleh membacanya, dan kemudian supaya mereka boleh dilaksanakan.” kereta” . Perkara yang boleh anda baca mengenai topik: "Buku panduan Ketukangan Perisian Agile" - Robert Martin. “Buku panduan anggaran Agile” - Mike Cohn Mengenai pengarang: Ravi Shankar Rajan ialah Pengurus Program IT Global dari Mumbai (India). Blogger terkenal, penyair haiku, gemar arkeologi dan peminat sejarah. Anda boleh berhubung dengannya di Twitter , Medium , LinkedIn
GO TO FULL VERSION