Paano magsulat ng malinis na code
Source: Dev.to Ang pagsulat ng malinis na code ay parang pagsulat ng tula. Ito ay tula na dapat ay maigsi, naiintindihan at naa-access sa pagbabago. Ang malinis na code ay nagpapahiwatig ng isang nasusukat na organisasyon. Nangangahulugan ito na ang paggawa ng mga pagbabago ay hindi nagdudulot ng kaguluhan. Ang kakayahang magsulat ng naturang code ay isa sa mga pangunahing katangian ng isang may karanasang developer. Matapos irekomenda ng ilang tao na basahin ko ang aklat na Clean Code, sa wakas ay nakakuha ako ng lakas ng loob na basahin ito. Ito pala ay isa sa mga libro kung saan ang pabalat ay ganap na nabubuhay hanggang sa hype sa paligid nito. Ang mga rekomendasyon sa aklat ay malinaw, tiyak, praktikal, at iniharap pa na may katatawanan. Ngayon gusto kong ibahagi sa iyo ang mga pangunahing takeaways mula sa aklat na ito.
1. Ang code ay hindi lamang dapat gumana, ngunit nababasa rin
Karamihan sa halaga ng software ay nakatali sa pangmatagalang suporta. Samakatuwid, ang code na iyong isusulat ay dapat na malinaw na ipahayag ang iyong mga intensyon. Dapat na ang mga bagong developer na sumali sa koponan ay madaling maunawaan kung ano ang eksaktong nangyayari sa code at kung bakit. Kung mas naiintindihan ang code na isinusulat ng may-akda, mas kaunting oras ang aabutin ng ibang mga developer upang maunawaan ito. Binabawasan nito ang mga depekto at gastos sa pagpapanatili. Paano ito makakamit? Magandang pagbibigay ng pangalan + mga klase at function na may iisang responsibilidad + mga pagsusulit sa pagsulat.2. Ang ibig sabihin ng huli ay hindi kailanman
Maging tapat tayo: lahat tayo ay nangangako sa ating sarili kung minsan na babalik tayo at linisin ang code sa ibang pagkakataon, ngunit nalilimutan natin ito. Huwag mag-iwan ng mga piraso ng walang kwentang code na hindi na kailangan. Nalilito nila ang ibang mga developer at walang halaga. Samakatuwid, kapag gumagawa ng mga pagbabago sa functionality, palaging alisin ang lumang code. Kung may masira sa isang lugar, ipapakita pa rin ito kaagad ng mga pagsubok. Paano ito makakamit? Maaaring nakakatakot ang pagtanggal ng code, lalo na sa malalaking arkitektura. Kaya ang pagsubok ay susi dito. Pinapayagan ka nitong alisin ang code nang may kumpiyansa.3. Dapat maliit ang mga feature
Ang unang tuntunin ng mga function ng pagsulat ay dapat na maliit ang mga ito, hanggang sa humigit-kumulang 20 linya . Kung mas maliit ang function at mas nakatutok ito sa isang gawain, mas madaling makahanap ng magandang pangalan para dito. Tulad ng para sa mga argumento ng pag-andar, ang kanilang ideal na numero ay 0. Susunod ang 1, 2, ngunit dapat mong subukang magkaroon ng hindi hihigit sa 3 argumento. Paano ito makakamit? Dapat isulat ang mga function alinsunod sa mga prinsipyo ng solong responsibilidad at bukas/sarado.4. Masama ang pagdoble ng code
Ang pagdoble ay ang kaaway ng isang maayos na sistema. Ito ay dagdag na trabaho, dagdag na panganib, at dagdag na hindi kinakailangang kumplikado. Ano ang gagawin tungkol dito? Tiyaking nakasulat ang iyong code ayon sa prinsipyo ng DRY, nakahiwalay at modular.5. Ang magandang comment lang ay yung nakahanap ka ng paraan para hindi magsulat.
"Walang mas kapaki-pakinabang kaysa sa isang magandang komento sa tamang lugar. Ngunit ang mga komento, kahit na sa pinakamagandang senaryo, ay isang kinakailangang kasamaan. Ang mga komento ay inilaan upang mabayaran ang aming kawalan ng kakayahan na ipahayag ang aming mga saloobin sa code. Ibig sabihin, ito ay sa una ay pag-amin ng pagkatalo. Oo, kailangan nating gamitin ang mga ito dahil hindi natin laging malinaw ang ating mga intensyon gamit ang code, ngunit hindi iyon dahilan para magdiwang. Ang bagay ay, ang mga komento ay madalas na nagsisinungaling. Hindi palagi at hindi sinasadya, ngunit madalas. Kung mas luma ang komento at mas malayo ito sa code na inilalarawan nito, mas malamang na mali ito. Ang dahilan para dito ay simple: hindi mapanatili ng mga programmer ang parehong code at lahat ng mga komento nang maayos. Samakatuwid, kadalasan ang mga komento ay inihihiwalay sa code na kanilang tinutukoy at nagiging mga orphan annotation na may kaunting katumpakan. Ano ang gagawin tungkol dito? Dapat gamitin ang mga pamamaraang deskriptibong pagbibigay ng pangalan. Kapag nabasa mo ang pangalan ng isang variable, dapat mong maunawaan kaagad kung ano ito. Kailangan din ang mga pagsubok upang maunawaan ng ibang mga developer kung aling functionality ang pinakamahalaga.6. Ang bagay ay nagpapakita ng gawi, ngunit hindi data.
Hindi dapat malaman ng isang module ang tungkol sa mga panloob ng mga bagay na minamanipula nito. Itinatago ng mga bagay ang kanilang data at ibinubunyag ang kanilang mga operasyon. Nangangahulugan ito na hindi dapat ilantad ng isang bagay ang panloob na istraktura nito sa pamamagitan ng mga pamamaraan ng accessor. Hindi kailangan na makita ka ng lahat na nakahubad. Ano ang gagawin tungkol dito? Ang saklaw ng mga variable ay dapat na lokal hangga't maaari upang hindi maglantad ng higit sa kinakailangan.
7. Pagsubok
Ang code ng pagsubok ay kasinghalaga ng kung ano ang napupunta sa produksyon. Samakatuwid, dapat itong magbago at lumago habang umuunlad ang proyekto. Pinapanatili ng mga pagsubok ang iyong code na flexible, maintainable, at magagamit muli. Kung wala ang mga ito, ang anumang pagbabago ay maaaring magresulta sa mga bug. Nagbibigay-daan sa iyo ang mga pagsubok na linisin ang iyong code nang walang takot na may masisira. Samakatuwid, ang pagpapanatili ng kadalisayan ng mga pagsubok ay napakahalaga. Ang kalinisan ng mga pagsubok ay nagsisiguro sa kanilang pagiging madaling mabasa. Ang mga pagsubok ay isang pagkakataon upang ipaliwanag sa ibang mga developer sa simpleng wika ang mga intensyon ng may-akda ng code. Samakatuwid, sumusubok lamang kami ng isang konsepto sa bawat function ng pagsubok. Ginagawa nitong mapaglarawan ang pagsubok, mas madaling basahin, at kung nabigo ito, mas madaling masubaybayan ang dahilan nito. Paano ito makakamit? Dapat sundin ng isa ang mga prinsipyo ng malinis na UNANG mga pagsusulit . Ang mga pagsusulit ay dapat na:- Mabilis. Ang mga pagsubok ay dapat tumakbo nang mabilis. Kung kailangan mong maghintay ng masyadong mahaba para sa isang pagsubok na tumakbo, mas malamang na mas madalas mong patakbuhin ito.
- Independent / isolated (Independent). Ang mga pagsusulit ay dapat na ihiwalay at independyente sa isa't isa hangga't maaari.
- Nauulit. Dapat na paulit-ulit ang mga pagsubok sa anumang kapaligiran—pag-unlad, pagtatanghal, at produksyon.
- Self-Validating. Ang resulta ng pagsubok ay dapat na isang Boolean na halaga. Ang pagsusulit ay dapat pumasa o mabigo.
- lubusan. Dapat nating pagsikapang masakop ang lahat ng edge case, lahat ng isyu sa seguridad, bawat use case (use case) at happy path (ang pinaka-kanais-nais na senaryo para sa code) na may mga pagsubok.
8. Pangangasiwa sa mga error at exception
Ang bawat exception na ihahagis mo ay dapat magbigay ng sapat na konteksto upang matukoy ang pinagmulan at lokasyon ng error. Kadalasan mayroon kang stack trace ng anumang exception, ngunit hindi sasabihin sa iyo ng stack trace ang layunin ng operasyon na nabigo. Kung maaari, iwasang magpasa ng null sa iyong code. Kung natutukso kang ibalik ang null mula sa isang pamamaraan, isaalang-alang ang paglalagay ng exception sa halip. Gumawa ng error sa paghawak ng isang hiwalay na gawain na maaaring matingnan nang hiwalay sa pangunahing lohika. Paano ito makakamit? Gumawa ng mga mensahe ng error na nagbibigay-kaalaman at ipasa ang mga ito kasama ng iyong mga pagbubukod. Tukuyin ang operasyon na nabigo at ang uri ng error.9. Mga klase
Dapat maliit ang mga klase. Ngunit hindi ang mga linya ng code ang kailangang bilangin, ngunit ang responsibilidad. Ang mga pangalan ng klase ay susi sa paglalarawan kung ano ang kanilang pananagutan. Ang aming mga sistema ay dapat na binubuo ng maraming maliliit na klase, hindi ilang malalaking klase. Ang bawat ganoong maliit na klase ay dapat maglaman ng isang solong responsibilidad. Dapat ay mayroon lamang isang tiyak na dahilan para umiral ang bawat klase, at ang bawat klase ay dapat "makipagtulungan" sa ilang iba pang mga klase upang makamit ang nais na pag-uugali ng system. May bihirang magandang dahilan upang lumikha ng pampublikong variable. Ang pagpapahina ng encapsulation ay palaging isang huling paraan. Bilang karagdagan, dapat mayroong ilang mga variable na halimbawa. Ang mahusay na disenyo ng software ay nagbibigay-daan sa mga pagbabago na magawa nang walang malalaking pamumuhunan o muling paggawa. Ang pagpapaliit sa hanay ng mga variable ay nagpapadali sa gawaing ito. Paano ito makakamit? Ang paghihiwalay ng mga alalahanin ay isa sa pinakaluma at pinakamahalagang diskarte sa disenyo. Dapat bukas ang mga klase para sa extension, ngunit sarado para sa pagbabago. Sa isang perpektong sistema, pinapagana namin ang mga bagong feature sa pamamagitan ng pagpapalawak ng system sa halip na sa pamamagitan ng paggawa ng mga pagbabago sa umiiral na code.10. Pag-format
Ang bawat bakanteng linya ay isang visual cue upang makatulong na matukoy na nagsimula na ang isang bago at hiwalay na konsepto. Dapat lumitaw ang mga lokal na variable sa tuktok ng function. Dapat ideklara ang mga variable ng instance sa tuktok ng klase. Ang mga maikling linya ay mas mahusay kaysa sa mahahabang linya. Karaniwan ang limitasyon ay 100-120 character; hindi mo dapat patagalin. Paano ito makakamit? Karamihan sa mga parameter ay maaaring ipasa sa isang linter sa iyong CI o text editor. Gamitin ang mga tool na ito para gawing malinis ang iyong code hangga't maaari.Mga Prinsipyo sa Pagbuo ng Programa
Gamitin ang mga sumusunod na diskarte at ang iyong code ay palaging magiging malinis: Pagpangalan ng mga variable. Ang pagpili ng naaangkop na mga pangalan (magandang pagpapangalan) ay kritikal sa paggawa ng code na nababasa at samakatuwid ay mapanatili. "Dapat kang pumili ng isang pangalan para sa isang variable bilang responsable tulad ng gagawin mo para sa iyong panganay." Ang pagpili ng magagandang pangalan ay kadalasang isang hamon para sa mga developer. Nangangailangan ito ng mahusay na mga kasanayan sa paglalarawan at isang nakabahaging kultural na background. Ang malinis na code ay code na binabasa at pinahusay ng ganap na magkakaibang mga developer. Ang pangalan ng isang variable, function o klase ay dapat sumagot sa lahat ng mga pangunahing tanong: bakit umiiral ang entity na ito, ano at paano ito ginagamit. Kung ang isang pangalan ay nangangailangan ng komento, nangangahulugan ito na hindi ito sapat na nagpapakita ng kakanyahan ng kung ano ang inilalarawan nito. Ang mas mahahabang pangalan ay mas mahalaga kaysa sa mas maikli, at anumang mahahanap na pangalan ay mas mahusay kaysa sa isang pare-pareho. Ang mga pangalan ng isang titik ay maaari lamang gamitin bilang mga lokal na variable sa loob ng maiikling pamamaraan: ang haba ng pangalan ay dapat tumugma sa saklaw. Ang mga pangalan ng pamamaraan ay dapat na mga pandiwa o mga parirala ng pandiwa; ang pangalan ng klase ay hindi dapat isang pandiwa. Ang mga dependency ay dapat panatilihin sa isang minimum. Mas mabuting umasa sa kung ano ang kinokontrol mo kaysa sa hindi mo makontrol. Kung hindi, ang mga bagay na ito ang magkokontrol sa iyo. Katumpakan. Ang bawat solong piraso ng code ay dapat na nasa isang lugar kung saan inaasahan ng mambabasa na mahanap ito. Ang pag-navigate sa codebase ay dapat na intuitive, at dapat na malinaw ang mga intensyon ng developer. Paglilinis. Huwag mag-iwan ng walang kwentang code sa codebase (luma at hindi na ginagamit o nilikha "kung sakali"). Bawasan ang pagdoble at gumawa ng mga simpleng abstraction nang maaga. Standardisasyon. Kapag nagsusulat ng code, dapat mong sundin ang istilo at mga kasanayang itinatag para sa repositoryo. Disiplina sa sarili. Habang umuunlad ang mga ginamit na teknolohiya at lumalabas ang mga bago, kadalasang may pagnanais ang mga developer na baguhin at pagbutihin ang isang bagay sa umiiral na code. Huwag magpadala sa hype nang masyadong mabilis: pag-aralan ang mga bagong stack nang maigi at para lamang sa isang partikular na layunin. Ang pagpapanatiling malinis ng iyong codebase ay higit pa sa pagiging magalang sa iyong kasalukuyan at hinaharap na mga kasamahan. Ito ay mahalaga para sa pangmatagalang kaligtasan ng programa. Kung mas malinis ang iyong code, mas masaya ang mga developer, mas maganda ang produkto, at mas magtatagal ito.Bakit mas mahusay ang Java kaysa sa C++ para sa mga low latency system
Source: StackOverflow Bilang mga developer, alam nating lahat na may dalawang paraan para gawin ang mga bagay: manu-mano, dahan-dahan at nakakainis, o awtomatiko, mahirap at mabilis. Maaari akong gumamit ng artificial intelligence upang isulat ang artikulong ito para sa akin. Ito ay maaaring makatipid sa akin ng maraming oras - ang AI ay maaaring makabuo ng libu-libong mga artikulo sa bawat segundo, ngunit ang aking editor ay malamang na hindi magiging masaya na malaman na aabutin ng dalawang taon upang mabuo ang unang artikulo.
Ang isang katulad na sitwasyon ay lumitaw kapag bumubuo ng mga sistema ng software na may mababang latency. Ang kumbensyonal na karunungan ay na ito ay mabaliw na gumamit ng anumang bagay maliban sa C++ dahil lahat ng iba pa ay may sobrang latency. Ngunit narito ako upang kumbinsihin ka sa kabaligtaran, kontra-intuitive, halos heretikal na paniwala: pagdating sa pagkamit ng mababang latency sa mga software system, ang Java ay mas mahusay. Sa artikulong ito, gusto kong kumuha ng partikular na halimbawa ng software na pinahahalagahan ang mababang latency: mga sistema ng pangangalakal. Gayunpaman, ang mga argumentong ipinakita dito ay maaaring ilapat sa halos anumang sitwasyon kung saan kinakailangan o nais ang mababang latency. Mas madaling pag-usapan ang tungkol sa lugar ng pag-unlad kung saan mayroon akong karanasan. At ang totoo ay mahirap sukatin ang latency. Ang lahat ay bumaba sa kung ano ang ibig mong sabihin sa mababang latency. Alamin natin ito ngayon.
Nakamit ang Karunungan
Dahil mas malapit ang C++ sa hardware, sasabihin sa iyo ng karamihan sa mga developer na ang coding sa wikang ito ay nag-aalok ng isang kalamangan sa bilis. Sa mga sitwasyong mababa ang latency, gaya ng high-speed trading, kung saan ang mga millisecond ay maaaring gumawa ng pagkakaiba sa pagitan ng isang mabubuhay na piraso ng software at isang legacy na pag-aaksaya ng espasyo sa disk, ang C++ ay itinuturing na gold standard. Sabagay, ganyan din naman ang dating. Ngunit ang katotohanan ay maraming malalaking bangko at broker ang gumagamit na ngayon ng mga sistemang nakasulat sa Java. At ang ibig kong sabihin ay katutubong nakasulat sa Java, hindi nakasulat sa Java at pagkatapos ay binibigyang kahulugan sa C++ upang mabawasan ang latency. Ang mga sistemang ito ay nagiging pamantayan kahit para sa tier 1 na mga investment bank, sa kabila ng katotohanan na sila ay (parang) mas mabagal. Kaya ano ang nangyayari? Oo, ang C++ ay maaaring may "mababang latency" pagdating sa pag-execute ng code, ngunit tiyak na hindi ito mababang latency pagdating sa pag-deploy ng mga bagong feature o kahit na paghahanap ng mga developer na makakasulat nito.(Real) mga pagkakaiba sa pagitan ng Java at C++
Ang isyu sa oras ng pag-unlad ay simula pa lamang pagdating sa mga pagkakaiba sa pagitan ng Java at C++ sa mga real-world system. Upang maunawaan ang tunay na halaga ng bawat wika sa kontekstong ito, suriin natin nang mas malalim. Una, mahalagang tandaan ang tunay na dahilan kung bakit mas mabilis ang C++ kaysa sa Java sa karamihan ng mga sitwasyon: ang C++ pointer ay ang address ng isang variable sa memorya. Nangangahulugan ito na direktang maa-access ng software ang mga indibidwal na variable at hindi na kailangang mag-crawl sa mga computationally intensive table upang hanapin ang mga ito. O hindi bababa sa maaaring matugunan sa pamamagitan ng pagtukoy kung nasaan sila, dahil sa C++ madalas mong kailangang tahasang pamahalaan ang buhay at pagmamay-ari ng mga bagay. Bilang resulta, maliban kung talagang mahusay ka sa pagsusulat ng code (isang kasanayang maaaring tumagal ng ilang dekada upang makabisado), mangangailangan ang C++ ng mga oras (o linggo) ng pag-debug. At gaya ng sasabihin sa iyo ng sinumang sinubukang i-debug ang isang Monte Carlo engine o isang tool sa pagsubok ng PDE, ang pagsisikap na i-debug ang pag-access sa memorya sa isang pangunahing antas ay maaaring napakatagal. Ang isang maling pointer lamang ay madaling makapagpabagsak sa isang buong sistema, kaya ang paglabas ng bagong bersyon na nakasulat sa C++ ay maaaring maging tunay na nakakatakot. Siyempre, hindi lang iyon. Ang mga taong nag-e-enjoy sa programming sa C++ ay ituturo na ang garbage collector ng Java ay dumaranas ng mga non-linear latency spike. Ito ay totoo lalo na kapag nagtatrabaho sa mga legacy na system, kaya ang pagpapadala ng mga update sa Java code nang hindi sinisira ang mga system ng kliyente ay maaaring maging napakabagal sa mga ito na hindi na magagamit. Bilang tugon, nais kong ituro na maraming gawain ang nagawa sa nakalipas na dekada upang bawasan ang latency na ginawa ng Java GC. LMAX Disruptor, halimbawa, ay isang low-latency trading platform na nakasulat sa Java, na binuo din bilang isang framework na may "mechanical interaction" sa hardware na pinapatakbo nito at hindi nangangailangan ng lock. Mas mapapagaan ang mga problema kung bubuo ka ng system na gumagamit ng tuluy-tuloy na proseso ng pagsasama at paghahatid (CI/CD), dahil pinapayagan ng CI/CD ang awtomatikong pag-deploy ng mga nasubok na pagbabago sa code. Ito ay dahil ang CI/CD ay nagbibigay ng isang umuulit na diskarte sa pagbabawas ng latency ng koleksyon ng basura, kung saan ang Java ay maaaring unti-unting pagbutihin at iakma sa mga partikular na kapaligiran ng hardware nang walang resource-intensive na proseso ng paghahanda ng code para sa iba't ibang mga detalye ng hardware bago ito ipadala. Dahil ang suporta sa Java ng IDE ay mas malawak kaysa sa C++, karamihan sa mga frameworks (Eclipse, IntelliJ IDEA) ay nagbibigay-daan sa iyo na i-refactor ang Java. Nangangahulugan ito na maaaring i-optimize ng mga IDE ang code para sa mababang pagganap ng latency, bagama't limitado pa rin ang kakayahang ito kapag nagtatrabaho sa C++. Kahit na ang Java code ay hindi masyadong tumutugma sa C++ sa bilis, karamihan sa mga developer ay mas madaling makamit ang katanggap-tanggap na pagganap sa Java kaysa sa C++.Ano ang ibig sabihin ng "mas mabilis"?
Sa katunayan, may magandang dahilan para magduda na ang C++ ay tunay na "mas mabilis" o kahit na may "mas mababang latency" kaysa sa Java. Napagtanto ko na pumapasok ako sa medyo madilim na tubig, at maraming mga developer ang magsisimulang magtanong sa aking katinuan. Pero pakinggan mo ako. Isipin natin ang sitwasyong ito: mayroon kang dalawang developer - ang isa ay nagsusulat sa C++ at ang isa sa Java, at hinihiling mo sa kanila na magsulat ng isang high-speed trading platform mula sa simula. Bilang resulta, ang isang system na nakasulat sa Java ay magtatagal upang makumpleto ang mga transaksyon sa kalakalan kaysa sa isang sistema na nakasulat sa C++. Gayunpaman, ang Java ay may mas kaunting mga pagkakataon ng hindi natukoy na pag-uugali kaysa sa C++. Upang kumuha lamang ng isang halimbawa, ang pag-index sa labas ng isang array ay isang bug sa parehong Java at C++. Kung hindi mo sinasadyang gawin ito sa C++, maaari kang makakuha ng segfault o (mas madalas) magkakaroon ka lang ng ilang random na numero. Sa Java, ang pag-out of bounds ay palaging nagdudulot ng ArrayIndexOutOfBoundsException error . Nangangahulugan ito na ang pag-debug sa Java ay mas madali dahil ang mga error ay kadalasang natutukoy kaagad at ang lokasyon ng error ay mas madaling masubaybayan. Bilang karagdagan, hindi bababa sa aking karanasan, ang Java ay mas mahusay sa pagkilala kung aling mga piraso ng code ang hindi kailangang tumakbo at kung alin ang kritikal sa pagpapatakbo ng iyong software. Siyempre, maaari kang gumugol ng mga araw sa pag-aayos ng iyong C++ code para wala itong extraneous na code, ngunit sa totoong mundo, ang bawat piraso ng software ay naglalaman ng ilang bloat, at mas mahusay ang Java sa awtomatikong pagkilala nito. Nangangahulugan ito na sa totoong mundo, ang Java ay madalas na mas mabilis kaysa sa C++, kahit na sa mga karaniwang sukatan ng latency. At kahit na hindi ito ang kaso, ang pagkakaiba sa latency sa pagitan ng mga wika ay madalas na nalulula sa iba pang mga kadahilanan na hindi sapat na malaki upang mahalaga kahit na sa high-speed trading.Mga Benepisyo ng Java para sa Mababang Latency System
Ang lahat ng mga salik na ito, sa aking opinyon, ay gumagawa ng isang medyo nakakahimok na argumento para sa paggamit ng Java upang magsulat ng mga high-speed trading platform (at mga low-latency system sa pangkalahatan, higit pa tungkol doon sa isang sandali). Gayunpaman, para maimpluwensyahan ng kaunti ang mga mahilig sa C++, tingnan natin ang ilang karagdagang dahilan para gamitin ang Java:-
Una, ang anumang labis na latency na ipinapasok ng Java sa iyong software ay malamang na mas mababa kaysa sa iba pang mga salik na nakakaapekto sa latency—gaya ng mga problema sa internet. Nangangahulugan ito na ang anumang (mahusay na pagkakasulat) Java code ay madaling gumanap pati na rin ang C++ sa karamihan ng mga sitwasyon sa pangangalakal.
-
Ang mas maikling oras ng pag-develop ng Java ay nangangahulugan din na, sa totoong mundo, ang software na nakasulat sa Java ay maaaring umangkop sa mga pagbabago sa hardware (o kahit na mga bagong diskarte sa pangangalakal) nang mas mabilis kaysa sa C++.
-
Kung maghuhukay ka ng mas malalim dito, makikita mo na kahit na ang pag-optimize ng Java software ay maaaring maging mas mabilis (kapag isinasaalang-alang sa buong software) kaysa sa isang katulad na gawain sa C++.
GO TO FULL VERSION