Bagaimana untuk menulis kod bersih
Sumber: Dev.to Menulis kod bersih adalah seperti menulis puisi. Ini adalah puisi yang harus ringkas, boleh difahami dan boleh diakses untuk berubah. Kod bersih membayangkan organisasi berskala. Ini bermakna membuat perubahan tidak menyebabkan huru-hara. Keupayaan untuk menulis kod tersebut adalah salah satu kualiti utama pembangun berpengalaman. Selepas beberapa orang mengesyorkan saya membaca buku Kod Bersih, akhirnya saya memberanikan diri untuk membacanya. Ternyata ini adalah salah satu buku di mana kulitnya benar-benar sesuai dengan gembar-gembur di sekelilingnya. Cadangan dalam buku adalah jelas, khusus, praktikal, dan juga disampaikan dengan humor. Hari ini saya ingin berkongsi dengan anda perkara utama daripada buku ini.
1. Kod bukan sahaja berfungsi, tetapi juga boleh dibaca
Kebanyakan kos perisian terikat kepada sokongan jangka panjang. Oleh itu, kod yang anda tulis mesti jelas menyatakan niat anda. Seharusnya pembangun baharu yang menyertai pasukan dapat memahami dengan mudah apa sebenarnya yang berlaku dalam kod dan sebabnya. Semakin mudah difahami kod yang ditulis oleh pengarang, semakin sedikit masa yang diperlukan oleh pembangun lain untuk memahaminya. Ini mengurangkan kecacatan dan kos penyelenggaraan. Bagaimana untuk mencapai ini? Penamaan + kelas dan fungsi yang baik dengan tanggungjawab tunggal + ujian penulisan.2. Nanti bermakna tidak pernah
Sejujurnya: kita semua berjanji kepada diri sendiri kadangkala bahawa kita akan kembali dan membersihkan kod itu kemudian, tetapi kita akhirnya melupakannya. Jangan tinggalkan kepingan kod yang tidak berguna yang tidak diperlukan lagi. Mereka mengelirukan pemaju lain dan tidak mempunyai nilai. Oleh itu, apabila membuat perubahan pada fungsi, sentiasa alih keluar kod lama. Jika sesuatu pecah di suatu tempat, ujian masih akan menunjukkannya serta-merta. Bagaimana untuk mencapai ini? Memadamkan kod boleh menjadi menakutkan, terutamanya dalam seni bina besar. Jadi ujian adalah kunci di sini. Mereka membenarkan anda mengalih keluar kod dengan yakin.3. Ciri hendaklah kecil
Peraturan pertama untuk menulis fungsi ialah ia mestilah kecil, sehingga kira-kira 20 baris . Lebih kecil fungsi dan lebih fokus pada satu tugas, lebih mudah untuk mencari nama yang baik untuknya. Bagi argumen fungsi, nombor idealnya ialah 0. Seterusnya datang 1, 2, tetapi anda harus cuba untuk mempunyai tidak lebih daripada 3 hujah. Bagaimana untuk mencapai ini? Fungsi hendaklah ditulis mengikut prinsip tanggungjawab tunggal dan terbuka/tertutup.4. Penduaan kod adalah buruk
Penduaan adalah musuh kepada sistem yang teratur. Ini adalah kerja tambahan, risiko tambahan dan kerumitan tambahan yang tidak perlu. Apa yang perlu dilakukan mengenainya? Pastikan kod anda ditulis mengikut prinsip DRY, terpencil dan modular.5. Satu-satunya komen yang baik ialah komen yang anda temui cara untuk tidak menulis.
“Tiada yang lebih berguna daripada komen yang baik di tempat yang betul. Tetapi komen, walaupun dalam senario terbaik, adalah kejahatan yang perlu.” Komen bertujuan untuk mengimbangi ketidakupayaan kami untuk menyatakan pemikiran kami dalam kod. Iaitu, ini pada mulanya adalah pengakuan kekalahan. Ya, kita perlu menggunakannya kerana kita tidak boleh sentiasa menjelaskan niat kita dengan kod, tetapi itu bukan sebab untuk meraikannya. Masalahnya, komen sering berbohong. Tidak selalu dan tidak sengaja, tetapi terlalu kerap. Semakin lama komen itu dan semakin jauh ia daripada kod yang diterangkan, semakin besar kemungkinan ia tidak betul. Sebabnya adalah mudah: pengaturcara tidak dapat mengekalkan kedua-dua kod dan semua komen dengan baik. Oleh itu, selalunya komen diasingkan daripada kod yang mereka rujuk dan menjadi anotasi anak yatim dengan ketepatan yang minimum. Apa yang perlu dilakukan mengenainya? Kaedah penamaan deskriptif mesti digunakan. Apabila anda membaca nama pembolehubah, anda harus segera memahami apa itu. Ujian juga diperlukan supaya pembangun lain memahami fungsi mana yang paling penting.6. Objek mendedahkan tingkah laku, tetapi bukan data.
Sesuatu modul tidak sepatutnya mengetahui tentang dalaman objek yang dimanipulasinya. Objek menyembunyikan data mereka dan mendedahkan operasinya. Ini bermakna objek tidak seharusnya mendedahkan struktur dalamannya melalui kaedah pengakses. Tidak semestinya semua orang melihat anda berbogel. Apa yang perlu dilakukan mengenainya? Skop pembolehubah haruslah setempat yang mungkin supaya tidak mendedahkan lebih daripada yang diperlukan.
7. Pengujian
Kod ujian adalah sama pentingnya dengan apa yang masuk ke dalam pengeluaran. Oleh itu, ia mesti berubah dan berkembang apabila projek itu berkembang. Ujian memastikan kod anda fleksibel, boleh diselenggara dan boleh digunakan semula. Tanpa mereka, sebarang perubahan boleh mengakibatkan pepijat. Ujian membolehkan anda membersihkan kod anda tanpa rasa takut sesuatu akan pecah. Oleh itu, menjaga kesucian ujian adalah sangat penting. Kebersihan ujian memastikan kebolehbacaannya. Ujian adalah peluang untuk menerangkan kepada pembangun lain dalam bahasa mudah niat pengarang kod. Oleh itu, kami menguji hanya satu konsep dalam setiap fungsi ujian. Ini menjadikan ujian deskriptif, lebih mudah dibaca dan jika gagal, lebih mudah untuk menjejaki sebabnya. Bagaimana untuk mencapai ini? Seseorang mesti mengikut prinsip ujian PERTAMA yang bersih . Ujian hendaklah:- Cepat. Ujian mesti berjalan dengan cepat. Jika anda perlu menunggu terlalu lama untuk ujian dijalankan, anda kurang berkemungkinan menjalankannya dengan lebih kerap.
- Berdikari / terpencil (Independent). Ujian haruslah terpencil dan bebas antara satu sama lain.
- Boleh diulang. Ujian harus boleh diulang dalam mana-mana persekitaran—pembangunan, pementasan dan pengeluaran.
- Mengesahkan Diri. Keputusan ujian mestilah nilai Boolean. Ujian mesti lulus atau gagal.
- Teliti. Kita harus berusaha untuk merangkumi semua kes kelebihan, semua isu keselamatan, setiap kes penggunaan (kes penggunaan) dan laluan gembira (senario yang paling sesuai untuk kod) dengan ujian.
8. Mengendalikan ralat dan pengecualian
Setiap pengecualian yang anda lemparkan harus menyediakan konteks yang mencukupi untuk menentukan sumber dan lokasi ralat. Biasanya anda mempunyai surih tindanan sebarang pengecualian, tetapi surih tindanan tidak akan memberitahu anda tujuan operasi yang gagal. Jika boleh, elakkan menghantar null dalam kod anda. Jika anda tergoda untuk mengembalikan null daripada kaedah, pertimbangkan untuk membuang pengecualian. Jadikan ralat pengendalian tugas berasingan yang boleh dilihat secara bebas daripada logik utama. Bagaimana untuk mencapai ini? Cipta mesej ralat bermaklumat dan hantarkannya bersama-sama dengan pengecualian anda. Nyatakan operasi yang gagal dan jenis ralat.9. Kelas
Kelas hendaklah kecil. Tetapi bukan baris kod yang perlu dikira, tetapi tanggungjawab. Nama kelas adalah kunci untuk menerangkan perkara yang mereka bertanggungjawab. Sistem kami harus terdiri daripada banyak kelas kecil, bukan beberapa kelas besar. Setiap kelas kecil itu mesti merangkumi satu tanggungjawab. Mesti ada hanya satu sebab khusus untuk setiap kelas wujud, dan setiap kelas mesti "bekerjasama" dengan beberapa kelas lain untuk mencapai gelagat sistem yang diingini. Jarang ada sebab yang baik untuk mencipta pembolehubah awam. Melemahkan enkapsulasi sentiasa menjadi pilihan terakhir. Di samping itu, perlu ada sedikit pembolehubah contoh. Reka bentuk perisian yang baik membolehkan perubahan dibuat tanpa pelaburan besar atau kerja semula. Mengecilkan julat pembolehubah menjadikan tugas ini lebih mudah. Bagaimana untuk mencapai ini? Pengasingan kebimbangan adalah salah satu teknik reka bentuk tertua dan paling penting. Kelas hendaklah dibuka untuk sambungan, tetapi ditutup untuk pengubahsuaian. Dalam sistem yang ideal, kami mendayakan ciri baharu dengan memperluaskan sistem dan bukannya dengan membuat perubahan pada kod sedia ada.10. Memformat
Setiap baris kosong ialah isyarat visual untuk membantu mengenal pasti bahawa konsep baharu yang berasingan telah bermula. Pembolehubah setempat mesti muncul di bahagian atas fungsi. Pembolehubah instance mesti diisytiharkan di bahagian atas kelas. Garis pendek lebih baik daripada garis panjang. Biasanya had ialah 100-120 aksara; anda tidak sepatutnya membuatnya lebih lama. Bagaimana untuk mencapai ini? Kebanyakan parameter boleh dihantar ke linter dalam CI atau editor teks anda. Gunakan alatan ini untuk menjadikan kod anda sebersih mungkin.Prinsip Pembangunan Program
Gunakan teknik berikut dan kod anda akan sentiasa bersih: Menamakan pembolehubah. Memilih nama yang sesuai (penamaan yang baik) adalah penting untuk menjadikan kod itu boleh dibaca dan oleh itu boleh diselenggara. "Anda harus memilih nama untuk pembolehubah dengan bertanggungjawab seperti yang anda lakukan untuk anak sulung anda." Memilih nama yang baik sering menjadi cabaran bagi pembangun. Ini memerlukan kemahiran deskriptif yang baik dan latar belakang budaya yang dikongsi. Kod bersih ialah kod yang dibaca dan diperbaiki oleh pembangun yang berbeza sama sekali. Nama pembolehubah, fungsi atau kelas harus menjawab semua soalan asas: mengapa entiti ini wujud, apa dan bagaimana ia digunakan. Jika nama memerlukan ulasan, ini bermakna ia tidak cukup mendedahkan intipati perkara yang diterangkan. Nama yang lebih panjang adalah lebih penting daripada yang lebih pendek, dan mana-mana nama yang boleh dicari adalah lebih baik daripada pemalar. Nama huruf tunggal hanya boleh digunakan sebagai pembolehubah tempatan dalam kaedah pendek: panjang nama mesti sepadan dengan skop. Nama kaedah mestilah kata kerja atau frasa kata kerja; nama kelas mestilah bukan kata kerja. Kebergantungan hendaklah diminimumkan. Adalah lebih baik untuk bergantung pada apa yang anda kawal daripada pada apa yang anda tidak boleh kawal. Jika tidak, perkara ini akan mengawal anda. Ketepatan. Setiap sekeping kod harus berada di tempat yang pembaca jangkakan untuk mencarinya. Navigasi melalui pangkalan kod hendaklah intuitif dan niat pembangun harus jelas. Pembersihan. Jangan tinggalkan kod yang tidak berguna dalam pangkalan kod (lama dan tidak lagi digunakan atau dicipta "untuk berjaga-jaga"). Kurangkan pertindihan dan buat abstraksi mudah awal. Penyeragaman. Semasa menulis kod, anda harus mengikut gaya dan amalan yang ditetapkan untuk repositori. Disiplin diri. Apabila teknologi terpakai berkembang dan yang baharu muncul, pembangun selalunya mempunyai keinginan untuk mengubah dan menambah baik sesuatu dalam kod sedia ada. Jangan menyerah kepada gembar-gembur terlalu cepat: kaji timbunan baharu dengan teliti dan hanya untuk tujuan tertentu. Menjaga asas kod anda bersih adalah lebih daripada bersikap sopan kepada rakan sekerja semasa dan akan datang anda. Ia adalah penting untuk kelangsungan program jangka panjang. Lebih bersih kod anda, lebih gembira pembangun, lebih baik produk dan lebih lama ia akan bertahan.Mengapa Java lebih baik daripada C++ untuk sistem kependaman rendah
Sumber: StackOverflow Sebagai pembangun, kita semua tahu bahawa terdapat dua cara untuk melakukan sesuatu: secara manual, perlahan-lahan dan menjengkelkan, atau secara automatik, sukar dan cepat. Saya boleh menggunakan kecerdasan buatan untuk menulis artikel ini untuk saya. Ini boleh menjimatkan banyak masa saya - AI boleh menjana beribu-ribu artikel sesaat, tetapi editor saya mungkin tidak gembira untuk mengetahui bahawa ia akan mengambil masa dua tahun untuk menghasilkan artikel pertama.
Situasi yang sama timbul apabila membangunkan sistem perisian dengan kependaman rendah. Kebijaksanaan konvensional adalah bahawa ia akan menjadi gila untuk menggunakan apa-apa selain C++ kerana segala-galanya mempunyai terlalu banyak kependaman. Tetapi saya di sini untuk meyakinkan anda tentang tanggapan yang bertentangan, kontra-intuitif, hampir sesat: apabila ia datang untuk mencapai kependaman rendah dalam sistem perisian, Java adalah lebih baik. Dalam artikel ini, saya ingin mengambil contoh khusus perisian yang menghargai kependaman rendah: sistem perdagangan. Walau bagaimanapun, hujah yang dikemukakan di sini boleh digunakan untuk hampir semua keadaan di mana kependaman rendah diperlukan atau dikehendaki. Lebih mudah untuk membincangkan berkaitan dengan bidang pembangunan di mana saya mempunyai pengalaman. Dan kebenarannya ialah kependaman sukar diukur. Semuanya bergantung kepada apa yang anda maksudkan dengan kependaman rendah. Mari kita fikirkan perkara ini sekarang.
Diperolehi Hikmah
Memandangkan C++ lebih dekat dengan perkakasan, kebanyakan pembangun akan memberitahu anda bahawa pengekodan dalam bahasa ini menawarkan kelebihan kelajuan. Dalam situasi kependaman rendah, seperti perdagangan berkelajuan tinggi, di mana milisaat boleh membuat perbezaan antara perisian yang berdaya maju dan pembaziran ruang cakera warisan, C++ dianggap sebagai standard emas. Sekurang-kurangnya begitulah dulu. Tetapi realitinya ialah banyak bank dan broker besar kini menggunakan sistem yang ditulis dalam Java. Dan saya maksudkan secara asli ditulis dalam Java, tidak ditulis dalam Java dan kemudian ditafsirkan dalam C++ untuk mengurangkan kependaman. Sistem ini menjadi standard walaupun untuk bank pelaburan peringkat 1, walaupun pada hakikatnya ia (kononnya) lebih perlahan. Jadi apa yang berlaku? Ya, C++ mungkin mempunyai "pendaman rendah" apabila ia datang untuk melaksanakan kod, tetapi ia pastinya bukan kependaman rendah apabila ia datang untuk menggunakan ciri baharu atau mencari pembangun yang boleh menulisnya.(Sebenar) perbezaan antara Java dan C++
Isu masa pembangunan hanyalah permulaan apabila ia berkaitan dengan perbezaan antara Java dan C++ dalam sistem dunia sebenar. Untuk memahami nilai sebenar setiap bahasa dalam konteks ini, mari kita mendalami sedikit. Pertama, adalah penting untuk mengingati sebab sebenar C++ lebih pantas daripada Java dalam kebanyakan situasi: penunjuk C++ ialah alamat pembolehubah dalam ingatan. Ini bermakna bahawa perisian boleh mengakses pembolehubah individu secara langsung dan tidak perlu merangkak melalui jadual intensif pengiraan untuk mencarinya. Atau sekurang-kurangnya boleh ditangani dengan menyatakan di mana mereka berada, kerana dengan C++ anda sering perlu menguruskan jangka hayat dan pemilikan objek secara eksplisit. Akibatnya, melainkan anda benar-benar mahir menulis kod (kemahiran yang boleh mengambil masa beberapa dekad untuk dikuasai), C++ akan memerlukan berjam-jam (atau minggu) penyahpepijatan. Dan kerana sesiapa yang telah cuba menyahpepijat enjin Monte Carlo atau alat ujian PDE akan memberitahu anda, cuba menyahpepijat akses memori pada tahap asas boleh memakan masa yang lama. Hanya satu penunjuk yang rosak boleh menurunkan keseluruhan sistem dengan mudah, jadi mengeluarkan versi baharu yang ditulis dalam C++ boleh menjadi sangat menakutkan. Sudah tentu, bukan itu sahaja. Orang yang menikmati pengaturcaraan dalam C++ akan menunjukkan bahawa pengumpul sampah Java mengalami pancang kependaman tidak linear. Ini adalah benar terutamanya apabila bekerja dengan sistem warisan, jadi menghantar kemas kini kepada kod Java tanpa melanggar sistem pelanggan boleh menjadikannya sangat perlahan sehingga ia tidak boleh digunakan. Sebagai tindak balas, saya ingin menyatakan bahawa banyak kerja telah dilakukan sepanjang dekad yang lalu untuk mengurangkan kependaman yang dicipta oleh Java GC. Pengganggu LMAX, sebagai contoh, ialah platform dagangan kependaman rendah yang ditulis dalam Java, juga dibina sebagai rangka kerja yang mempunyai "interaksi mekanikal" dengan perkakasan yang dijalankan dan tidak memerlukan penguncian. Masalah boleh dikurangkan lagi jika anda membina sistem yang menggunakan proses penyepaduan dan penghantaran berterusan (CI/CD), memandangkan CI/CD membenarkan penggunaan automatik bagi perubahan kod yang diuji. Ini kerana CI/CD menyediakan pendekatan berulang untuk mengurangkan kependaman pengumpulan sampah, di mana Java boleh menambah baik dan menyesuaikan diri dengan persekitaran perkakasan tertentu tanpa memerlukan proses intensif sumber untuk menyediakan kod untuk spesifikasi perkakasan yang berbeza sebelum menghantarnya. Memandangkan sokongan Java IDE jauh lebih luas daripada C++, kebanyakan rangka kerja (Eclipse, IntelliJ IDEA) membenarkan anda memfaktorkan semula Java. Ini bermakna IDE boleh mengoptimumkan kod untuk prestasi kependaman rendah, walaupun keupayaan ini masih terhad apabila bekerja dengan C++. Walaupun kod Java tidak sepadan dengan kelajuan C++, kebanyakan pembangun masih mendapati lebih mudah untuk mencapai prestasi yang boleh diterima dalam Java berbanding dalam C++.Apakah yang kita maksudkan dengan "lebih pantas"?
Malah, terdapat sebab yang baik untuk meragui bahawa C++ benar-benar "lebih pantas" atau mempunyai "pendaman yang lebih rendah" daripada Java. Saya sedar bahawa saya akan memasuki perairan yang agak keruh, dan ramai pemaju akan mula mempersoalkan kewarasan saya. Tetapi dengar saya. Mari bayangkan situasi ini: anda mempunyai dua pembangun - satu menulis dalam C++ dan satu lagi dalam Java, dan anda meminta mereka menulis platform dagangan berkelajuan tinggi dari awal. Akibatnya, sistem yang ditulis dalam Java akan mengambil masa yang lebih lama untuk menyelesaikan transaksi perdagangan daripada sistem yang ditulis dalam C++. Walau bagaimanapun, Java mempunyai lebih sedikit contoh tingkah laku yang tidak ditentukan daripada C++. Untuk mengambil hanya satu contoh, pengindeksan di luar tatasusunan ialah pepijat dalam kedua-dua Java dan C++. Jika anda secara tidak sengaja melakukan ini dalam C++, anda mungkin mendapat segfault atau (lebih kerap) anda hanya akan mendapat beberapa nombor rawak. Di Jawa, keluar dari sempadan sentiasa melemparkan ralat ArrayIndexOutOfBoundsException . Ini bermakna penyahpepijatan dalam Java adalah lebih mudah kerana ralat biasanya dikenal pasti serta-merta dan lokasi ralat lebih mudah untuk dikesan. Di samping itu, sekurang-kurangnya dalam pengalaman saya, Java lebih baik dalam mengenali cebisan kod yang tidak perlu dijalankan dan yang penting untuk pengendalian perisian anda. Sudah tentu, anda boleh meluangkan masa berhari-hari untuk mengubah suai kod C++ anda supaya ia sama sekali tidak mengandungi kod luar, tetapi dalam dunia nyata, setiap perisian mengandungi beberapa kembung, dan Java lebih baik untuk mengenalinya secara automatik. Ini bermakna bahawa dalam dunia nyata, Java selalunya lebih pantas daripada C++, walaupun mengikut metrik kependaman standard. Dan walaupun ini tidak berlaku, perbezaan dalam kependaman antara bahasa sering ditenggelami oleh faktor-faktor lain yang tidak cukup besar walaupun dalam perdagangan berkelajuan tinggi.Faedah Java untuk Sistem Latensi Rendah
Kesemua faktor ini, pada pendapat saya, membuat hujah yang cukup menarik untuk menggunakan Java untuk menulis platform dagangan berkelajuan tinggi (dan sistem kependaman rendah secara umum, lebih lanjut mengenainya sebentar lagi). Walau bagaimanapun, untuk mempengaruhi sedikit peminat C++, mari lihat beberapa sebab tambahan untuk menggunakan Java:-
Pertama, sebarang kependaman berlebihan yang diperkenalkan Java ke dalam perisian anda berkemungkinan jauh lebih rendah daripada faktor lain yang mempengaruhi kependaman—seperti masalah internet. Ini bermakna bahawa mana-mana kod Java (ditulis dengan baik) boleh berfungsi dengan mudah serta C++ dalam kebanyakan situasi perdagangan.
-
Masa pembangunan Java yang lebih pendek juga bermakna, dalam dunia nyata, perisian yang ditulis dalam Java boleh menyesuaikan diri dengan perubahan perkakasan (atau strategi dagangan baharu) dengan lebih cepat daripada C++.
-
Jika anda mendalami perkara ini, anda akan melihat bahawa pengoptimuman perisian Java pun boleh menjadi lebih pantas (apabila dipertimbangkan merentas keseluruhan perisian) daripada tugas yang serupa dalam C++.
GO TO FULL VERSION