Cara nulis kode sing resik
Sumber: Dev.to Nulis kode sing resik kaya nulis puisi. Iki minangka puisi sing kudu ringkes, bisa dingerteni lan bisa diowahi. Kode resik nuduhake organisasi sing bisa diukur. Iki tegese nggawe owah-owahan ora nyebabake kekacauan. Kemampuan kanggo nulis kode kasebut minangka salah sawijining kualitas utama pangembang sing berpengalaman. Sawise sawetara wong menehi saran supaya aku maca buku Kode Bersih, akhire aku wani maca. Ternyata iki minangka salah sawijining buku ing endi tutupe rampung nganti hype ing saubengé. Rekomendasi ing buku kasebut kanthi jelas, spesifik, praktis, lan malah diwenehake kanthi humor. Dina iki aku pengin nuduhake karo sampeyan takeaways utama saka buku iki.
1. Kode ngirim ora mung bisa, nanging uga bisa diwaca
Umume biaya piranti lunak digandhengake karo dhukungan jangka panjang. Mulane, kode sing sampeyan tulis kudu kanthi jelas nyatakake maksud sampeyan. Mesthine, pangembang anyar sing gabung karo tim bisa gampang ngerti apa sing kedadeyan ing kode kasebut lan kenapa. Sing luwih bisa dingerteni kode sing ditulis penulis, luwih sithik wektu sing dibutuhake pangembang liyane kanggo ngerti. Iki nyuda cacat lan biaya pangopènan. Kepiye carane entuk iki? Penamaan apik + kelas lan fungsi kanthi tanggung jawab tunggal + tes nulis.2. Mengko tegese ora tau
Satemene: kita kabeh janji kadang-kadang bakal bali lan ngresiki kode mengko, nanging pungkasane lali. Aja ninggalake potongan kode sing ora ana gunane sing ora dibutuhake maneh. Dheweke mbingungake pangembang liyane lan ora ana regane. Mulane, nalika ngganti fungsi, tansah mbusak kode lawas. Yen ana sing rusak ing endi wae, tes kasebut bakal langsung ditampilake. Kepiye carane entuk iki? Mbusak kode bisa medeni, utamane ing arsitektur gedhe. Dadi tes minangka kunci ing kene. Dheweke ngidini sampeyan mbusak kode kanthi yakin.3. Fitur kudu cilik
Aturan pisanan kanggo nulis fungsi yaiku kudu cilik, nganti udakara 20 baris . Sing luwih cilik fungsi lan luwih fokus ing siji tugas, luwih gampang nemokake jeneng sing apik. Kanggo argumen fungsi, nomer becike yaiku 0. Sabanjure teka 1, 2, nanging sampeyan kudu nyoba ora duwe argumen luwih saka 3. Carane entuk iki? Fungsi kudu ditulis miturut prinsip tanggung jawab tunggal lan mbukak / ditutup.4. Duplikasi kode iku ala
Duplikasi minangka mungsuh saka sistem sing wis diatur kanthi apik. Iku karya ekstra, resiko ekstra, lan kerumitan ekstra rasah. Apa sing kudu ditindakake? Priksa manawa kode sampeyan ditulis miturut prinsip DRY, terisolasi lan modular.5. Komentar sing apik mung sing sampeyan nemokake cara kanggo ora nulis.
"Ora ana sing luwih migunani tinimbang komentar sing apik ing papan sing bener. Nanging komentar, sanajan ing skenario sing paling apik, minangka piala sing dibutuhake. Komentar dimaksudaké kanggo ngimbangi ketidakmampuan kita kanggo nyebut pikiran kita ing kode. Tegese, iki wiwitane ngakoni kekalahan. Ya, kita kudu nggunakake amarga kita ora bisa nggawe maksud sing jelas karo kode, nanging ora ana alesan kanggo ngrayakake. Masalahe, komentar asring ngapusi. Ora mesthi lan ora sengaja, nanging asring banget. Sing luwih tuwa komentar kasebut lan luwih adoh saka kode sing digambarake, luwih akeh manawa komentar kasebut ora bener. Alesan kanggo iki prasaja: programer ora bisa njaga kode lan kabeh komentar kanthi apik. Mulane, komentar asring dipisahake saka kode sing dirujuk lan dadi anotasi yatim piatu kanthi presisi minimal. Apa sing kudu ditindakake? Metodhe penamaan deskriptif kudu digunakake. Nalika maca jeneng variabel, sampeyan kudu langsung ngerti apa iku. Tes uga dibutuhake supaya pangembang liyane ngerti fungsi sing paling penting.6. Objek kasebut nuduhake prilaku, nanging ora data.
Modul ora kudu ngerti babagan internal obyek sing dimanipulasi. Obyek ndhelikake data lan mbukak operasi. Iki tegese obyek ngirim ora mbukak struktur internal liwat cara accessor. Ora perlu saben wong ndeleng sampeyan wuda. Apa sing kudu ditindakake? Ruang lingkup variabel kudu minangka lokal sabisa supaya ora mbukak luwih saka perlu.
7. Testing
Kode tes penting kaya sing ana ing produksi. Mulane, iku kudu ngganti lan tuwuh minangka project develops. Tes supaya kode sampeyan fleksibel, bisa dijaga, lan bisa digunakake maneh. Tanpa ana, owah-owahan apa wae bisa nyebabake kewan omo. Tes ngidini sampeyan ngresiki kode tanpa wedi yen ana sing bakal rusak. Mulane, njaga kemurnian tes iku penting banget. Kebersihan tes njamin keterbacaane. Tes minangka kesempatan kanggo nerangake marang pangembang liyane kanthi basa sing prasaja maksud saka penulis kode. Mulane, kita nyoba mung siji konsep ing saben fungsi test. Iki nggawe deskriptif tes, luwih gampang diwaca, lan yen gagal, luwih gampang kanggo nglacak alesan kasebut. Kepiye carane entuk iki? Siji kudu ngetutake prinsip tes FIRST sing resik . Tes kudu:- Cepet. Tes kudu mlaku kanthi cepet. Yen sampeyan kudu ngenteni suwene tes kanggo mbukak, sampeyan bakal luwih kerep nglakoni.
- Mandhiri / Isolated (Independent). Tes kudu diisolasi lan bebas saka siji liyane.
- Bisa diulang. Tes kudu bisa diulang ing lingkungan apa wae - pangembangan, pementasan, lan produksi.
- Self-Validating. Asil tes kudu dadi nilai Boolean. Ujian kasebut kudu lulus utawa gagal.
- Tuntas. Kita kudu nyoba kanggo nutupi kabeh kasus pinggiran, kabeh masalah keamanan, saben kasus panggunaan (kasus panggunaan) lan dalan seneng (skenario paling apik kanggo kode kasebut) kanthi tes.
8. Nangani kasalahan lan pangecualian
Saben pangecualian sing sampeyan gunakake kudu nyedhiyakake konteks sing cukup kanggo nemtokake sumber lan lokasi kesalahan. Biasane sampeyan duwe tilak tumpukan saka sembarang istiméwa, nanging tilak tumpukan ora bakal pitutur marang kowe tujuan saka operasi sing gagal. Yen bisa, aja null ing kode sampeyan. Yen sampeyan digodha bali null saka cara, nimbang mbuwang pangecualian tinimbang. Nggawe kesalahan nangani tugas kapisah sing bisa dideleng kanthi bebas saka logika utama. Kepiye carane entuk iki? Gawe pesen kesalahan sing informatif lan kirimake kanthi pengecualian sampeyan. Nemtokake operasi sing gagal lan jinis kesalahan.9. Kelas
Kelas kudu cilik. Nanging dudu baris kode sing kudu diitung, nanging tanggung jawab. Jeneng kelas minangka kunci kanggo njlentrehake tanggung jawabe. Sistem kita kudu kalebu akeh kelas cilik, ora sawetara kelas gedhe. Saben kelas cilik kuwi kudu encapsulate tanggung jawab siji. Mung ana siji alesan tartamtu kanggo saben kelas ana, lan saben kelas kudu "kerjasama" karo sawetara kelas liyane kanggo entuk prilaku sing dipengini saka sistem. Jarang ana alesan sing apik kanggo nggawe variabel umum. Weakening enkapsulasi tansah dadi pilihan pungkasan. Kajaba iku, kudu ana sawetara variabel conto. Desain piranti lunak sing apik ngidini owah-owahan bisa ditindakake tanpa investasi utawa rework gedhe. Narrowing sawetara variabel nggawe tugas iki luwih gampang. Kepiye carane entuk iki? Pemisahan masalah minangka salah sawijining teknik desain sing paling tuwa lan paling penting. Kelas kudu mbukak kanggo extension, nanging ditutup kanggo modifikasi. Ing sistem sing becik, kita ngaktifake fitur-fitur anyar kanthi nggedhekake sistem tinimbang nggawe owah-owahan ing kode sing wis ana.10. Formatting
Saben baris kosong minangka isyarat visual kanggo mbantu ngenali yen konsep anyar sing kapisah wis diwiwiti. Variabel lokal kudu katon ing ndhuwur fungsi. Variabel conto kudu diumumake ing ndhuwur kelas. Garis sing cendhak luwih apik tinimbang sing dawa. Biasane watesan 100-120 karakter; sampeyan ora kudu nggawe maneh. Kepiye carane entuk iki? Umume paramèter bisa dikirim menyang linter ing CI utawa editor teks. Gunakake alat iki kanggo nggawe kode dadi resik sabisa.Prinsip Pengembangan Program
Gunakake teknik ing ngisor iki lan kode sampeyan bakal tansah resik: Naming variabel. Milih jeneng sing cocog (jeneng sing apik) penting kanggo nggawe kode bisa diwaca lan mulane bisa dijaga. "Sampeyan kudu milih jeneng kanggo variabel kanthi tanggung jawab kaya kanggo anak sing mbarep." Milih jeneng sing apik asring dadi tantangan kanggo pangembang. Iki mbutuhake katrampilan deskriptif sing apik lan latar mburi budaya sing dienggo bareng. Kode resik yaiku kode sing diwaca lan ditambahake dening pangembang sing beda banget. Jeneng variabel, fungsi utawa kelas kudu njawab kabeh pitakonan dhasar: kok entitas iki ana, apa lan carane digunakake. Yen jeneng mbutuhake komentar, tegese ora cukup ngungkapake inti saka apa sing digambarake. Jeneng sing luwih dawa luwih penting tinimbang sing luwih cendhek, lan jeneng sing bisa ditelusuri luwih apik tinimbang jeneng sing tetep. Jeneng siji-huruf mung bisa digunakake minangka variabel lokal ing cara cendhak: dawa jeneng kudu cocog karo ruang lingkup. Jeneng metode kudu kriya utawa frasa kriya; jeneng kelas kudu ora kriya. Ketergantungan kudu tetep minimal. Iku luwih apik kanggo ngandelake apa sing sampeyan kontrol tinimbang apa sing sampeyan ora bisa ngontrol. Yen ora, iki bakal ngontrol sampeyan. Akurasi. Saben potongan kode kudu ana ing papan sing dikarepake dening pamaca. Navigasi liwat basis kode kudu intuisi, lan maksud pangembang kudu jelas. Reresik. Aja ninggalake kode sing ora ana gunane ing basis kode (lawas lan ora digunakake maneh utawa digawe "ing kasus"). Ngurangi duplikasi lan nggawe abstraksi prasaja ing awal. Standardisasi. Nalika nulis kode, sampeyan kudu ngetutake gaya lan praktik sing ditetepake kanggo repositori. Disiplin dhiri. Nalika teknologi digunakake berkembang lan anyar katon, pangembang asring duwe kepinginan kanggo ngganti lan nambah soko ing kode ana. Aja cepet-cepet nyerah karo hype: sinau tumpukan anyar kanthi tliti lan mung kanggo tujuan tartamtu. Njaga basis kode sampeyan tetep resik ora mung sopan karo kolega saiki lan mbesuk. Iku penting kanggo kaslametané jangka panjang program. Kode sampeyan luwih resik, luwih seneng para pangembang, luwih apik produk kasebut, lan luwih suwe.Apa Java luwih apik tinimbang C ++ kanggo sistem latency kurang
Sumber: StackOverflow Minangka pangembang, kita kabeh ngerti yen ana rong cara kanggo nindakake samubarang: kanthi manual, alon-alon lan ngganggu, utawa kanthi otomatis, angel lan cepet. Aku bisa nggunakake intelijen buatan kanggo nulis artikel iki kanggo aku. Iki bisa nylametake aku akeh wektu - AI bisa ngasilake ewonan artikel per detik, nanging editorku mbokmenawa ora seneng ngerti yen butuh rong taun kanggo ngasilake artikel pisanan.
Kahanan sing padha kedadeyan nalika ngembangake sistem piranti lunak kanthi latensi sing sithik. Kawicaksanan konvensional iku bakal dadi edan kanggo nggunakake apa-apa liyane saka C ++ amarga kabeh liyane wis latensi banget. Nanging aku kene kanggo gawe uwong yakin saka ngelawan, counter-intuisi, meh sesat pemanggih: nalika nerangake entuk latency kurang ing sistem lunak, Jawa luwih apik. Ing artikel iki, aku pengin njupuk conto piranti lunak khusus sing menehi nilai latensi rendah: sistem dagang. Nanging, argumentasi sing disedhiyakake ing kene bisa ditrapake ing meh kabeh kahanan sing mbutuhake latensi sing sithik utawa dikarepake. Iku mung luwih gampang kanggo ngrembug babagan wilayah pembangunan sing aku duwe pengalaman. Lan sejatine latensi angel diukur. Iku kabeh nerangake apa sing sampeyan maksud dening latensi kurang. Ayo dipikirake saiki.
Angsal Kawicaksanan
Wiwit C ++ luwih cedhak karo hardware, umume pangembang bakal ngandhani yen coding ing basa iki menehi kauntungan kacepetan. Ing kahanan latensi kurang, kayata perdagangan kacepetan dhuwur, ing ngendi milidetik bisa nggawe prabédan antarane piranti lunak sing sregep lan sampah papan disk, C ++ dianggep minangka standar emas. Saora-orane wis kaya ngono. Nanging kasunyatane saiki akeh bank lan makelar gedhe sing nggunakake sistem sing ditulis ing basa Jawa. Lan maksudku asli ditulis ing Jawa, ora ditulis ing Jawa banjur diinterpretasikake ing C ++ kanggo ngurangi latensi. Sistem kasebut dadi standar sanajan kanggo bank investasi tingkat 1, sanajan kasunyatane (sing mesthine) luwih alon. Dadi apa sing kedadeyan? Ya, C ++ bisa uga duwe "latensi sing sithik" nalika ngeksekusi kode, nanging mesthine dudu latensi sing sithik nalika nggunakake fitur-fitur anyar utawa malah nemokake pangembang sing bisa nulis.(Real) beda antarane Jawa lan C ++
Masalah wektu pembangunan mung wiwitan nalika nerangake beda antarane Jawa lan C ++ ing sistem donya nyata. Kanggo mangerteni nilai sejati saben basa ing konteks iki, ayo dideleng luwih jero. Pisanan, iku penting kanggo elinga alesan nyata C ++ luwih cepet saka Jawa ing paling kahanan: C ++ pointer alamat variabel ing memori. Iki tegese piranti lunak bisa ngakses variabel individu kanthi langsung lan ora kudu nyusup ing tabel intensif komputasi kanggo nggoleki. Utawa paling ora bisa ditanggulangi kanthi nemtokake panggonane, amarga karo C ++ sampeyan kerep kudu kanthi tegas ngatur umur lan kepemilikan obyek. Akibaté, kajaba sampeyan pancene apik ing nulis kode (skill sing bisa njupuk dekade kanggo master), C ++ mbutuhake jam (utawa minggu) debugging. Lan minangka sapa wae sing wis nyoba debug mesin Monte Carlo utawa alat tes PDE bakal menehi pitutur marang kowe, nyoba debug akses memori ing tingkat dhasar bisa dadi akeh wektu. Mung siji pitunjuk sing salah bisa gampang ngrusak kabeh sistem, mula ngeculake versi anyar sing ditulis ing C ++ bisa dadi medeni banget. Mesthi, ora mung kuwi. Wong sing seneng pemrograman ing C ++ bakal nuduhake manawa pengumpul sampah Jawa ngalami lonjakan latensi non-linear. Iki utamané bener nalika nggarap sistem warisan, supaya ngirim nganyari kanggo kode Jawa tanpa break sistem klien bisa dadi alon supaya padha ora bisa digunakake. Kanggo nanggepi, aku pengin nuduhake manawa akeh karya sing ditindakake sajrone dekade pungkasan kanggo nyuda latensi sing digawe dening Java GC. Pengganggu LMAX, contone, iku platform dagang latensi kurang ditulis ing Jawa, uga dibangun minangka framework sing wis "interaksi mekanik" karo hardware sing mlaku lan ora mbutuhake ngunci. Masalah bisa dikurangi luwih yen sampeyan mbangun sistem sing nggunakake proses integrasi lan pangiriman terus (CI / CD), amarga CI / CD ngidini panyebaran otomatis owah-owahan kode sing dites. Iki amarga CI/CD nyedhiyakake pendekatan iteratif kanggo nyuda latensi pengumpulan sampah, ing ngendi Jawa bisa nambah lan adaptasi menyang lingkungan hardware tartamtu tanpa proses nyiapake kode kanggo spesifikasi hardware sing beda sadurunge dikirim. Wiwit dhukungan Jawa IDE luwih jembar tinimbang C ++, umume kerangka kerja (Eclipse, IntelliJ IDEA) ngidini sampeyan refactor Java. Iki tegese IDE bisa ngoptimalake kode kanggo kinerja latensi kurang, sanajan kemampuan iki isih winates nalika nggarap C ++. Sanajan kode Jawa ora cocog karo kacepetan C ++, akeh pangembang isih luwih gampang entuk kinerja sing bisa ditampa ing Jawa tinimbang ing C ++.Apa tegese "luwih cepet"?
Nyatane, ana alesan sing apik kanggo mangu-mangu manawa C ++ pancen "luwih cepet" utawa malah duwe "latensi sing luwih murah" tinimbang Jawa. Aku éling sing aku njupuk menyang sawetara cantik murky Waters, lan akeh pangembang bakal miwiti pitakonan sandi waras. Nanging krungu aku metu. Ayo mbayangno kahanan iki: sampeyan duwe loro pangembang - siji nulis ing C ++ lan liyane ing Jawa, lan sampeyan njaluk wong-wong mau nulis platform dagang kanthi kacepetan dhuwur saka awal. Akibaté, sistem sing ditulis ing Jawa bakal njupuk wektu maneh kanggo ngrampungake transaksi perdagangan saka sistem ditulis ing C++. Nanging, Jawa duwe luwih sithik kedadeyan prilaku sing ora ditemtokake tinimbang C++. Kanggo njupuk mung siji conto, ngindeks ing njaba array minangka bug ing Jawa lan C++. Yen sampeyan ora sengaja nindakake iki ing C ++, sampeyan bisa njaluk segfault utawa (luwih kerep) sampeyan mung bakal mungkasi munggah karo sawetara nomer acak. Ing Jawa, metu saka wates tansah mbuwang ArrayIndexOutOfBoundsException kesalahan . Iki tegese debugging ing Jawa luwih gampang amarga kesalahan biasane langsung diidentifikasi lan lokasi kesalahan luwih gampang dilacak. Kajaba iku, paling ora ing pengalamanku, Jawa luwih ngerti babagan potongan kode sing ora perlu digunakake lan sing penting kanggo operasi piranti lunak sampeyan. Sampeyan bisa, mesthi, nglampahi dina tweaker C ++ kode supaya ora ngemot kode extraneous, nanging ing donya nyata, saben Piece saka piranti lunak ngemot sawetara bloat, lan Jawa luwih apik kanggo ngenali kanthi otomatis. Iki tegese ing donya nyata, Jawa asring luwih cepet saka C ++, malah dening metrik latensi standar. Lan sanajan ora kaya ngono, bedane latensi ing antarane basa asring dikalahake dening faktor liya sing ora cukup gedhe sanajan ing dagang kanthi kacepetan dhuwur.Wuku Jawa kanggo Sistem Low Latency
Kabeh faktor kasebut, miturut pendapatku, nggawe argumentasi sing cukup menarik kanggo nggunakake Jawa kanggo nulis platform dagang kanthi kacepetan dhuwur (lan sistem latensi rendah umume, luwih akeh babagan kasebut). Nanging, kanggo narik kawigaten para penggemar C++, ayo goleki sawetara alasan tambahan kanggo nggunakake Jawa:-
Kaping pisanan, keluwihan latensi sing diwenehake Jawa menyang piranti lunak sampeyan bakal luwih sithik tinimbang faktor liyane sing mengaruhi latensi - kayata masalah internet. Iki tegese kode Jawa (ditulis kanthi apik) bisa ditindakake kanthi gampang kaya C++ ing umume kahanan dagang.
-
Wektu pangembangan Java sing luwih cendhek uga tegese, ing donya nyata, piranti lunak sing ditulis ing Jawa bisa adaptasi karo owah-owahan hardware (utawa malah strategi dagang anyar) luwih cepet tinimbang C++.
-
Yen digali luwih jero, sampeyan bakal weruh manawa ngoptimalake piranti lunak Java bisa luwih cepet (yen dianggep ing kabeh piranti lunak) tinimbang tugas sing padha ing C ++.
GO TO FULL VERSION