9 kļūdas, no kurām jāizvairās, programmējot Java valodā

Java ir populāra valoda ar stabilu pozīciju pasaulē. programmatūras izstrāde. Tā ir spēcīga un daudzpusīga programmēšanas valoda. Aptuveni 3 miljardi ierīču visā pasaulē izmanto Java un tāpēc, to izmantojot, tika pieļautas vismaz 3 miljardi kļūdu. Šajā rakstā pievērsīsimies tam, kā to vairs nedarīt.

1. Vienlaicīgas modifikācijas izņēmuma saņemšana

Šī ir visbiežāk pieļautā kļūda, ar kuru es saskāros. Savas karjeras sākumā arī es to pieļāvu daudzas reizes. Šī kļūda rodas, kad jūs mēģināt mainīt kolekciju, kamēr to iterējat. Uz ConcurrentModificationException var rasties arī tad, ja strādājat ar vairākiem pavedieniem, bet pagaidām pievērsīsimies pamata scenārijam.

Pieņemsim, ka jums ir Kolekcija lietotāju, no kuriem daži ir pieaugušie, bet daži nav. Jūsu uzdevums ir nofiltrēt bērnus.

for (Lietotājs : lietotāji) {

   if (!user.isAdult()) {

       users.remove(user);

   }

}

Iepriekš minētās programmas palaišana kods beidzas ar to, ka ConcurrentModificationException. Kur mēs kļūdījāmies? Pirms iterācijas pabeigšanas mēs mēģinājām noņemt dažus elementus. Tas arī izraisīja izņēmumu.

Kā no tā izvairīties?

Šādā gadījumā ir vairākas pieejas, kas var palīdzēt. Pirmkārt un galvenokārt, izmantojiet Java 8's labestība - Straume.

List adults = users.stream()

       .filter(User::isAdult)

       .toList();

Izmantojot Predikāts filtrs, mēs esam izpildījuši iepriekšējam nosacījumam apgriezto darbību - tagad mēs nosakām elementus, kas jāiekļauj. Šādas pieejas priekšrocība ir tā, ka pēc izņemšanas ir viegli ķēdē pieslēgt citas funkcijas, piem. karte. Bet labestības dēļ. lūdzu, nemēģiniet darīt kaut ko līdzīgu zemāk:

users.stream()

       .filter(v -> !v.isAdult())

       .forEach(users::remove);

Tas varētu nonākt arī ConcurrentModificationException jo tiek mainīts plūsmas avots. Tas var arī radīt vēl dažus izņēmumus, kurus nebūs viegli atkļūdot.

Lai atrisinātu ConcurrentModificationException vienpavediena scenārijā. jūs varētu arī pārslēgties uz tiešu Iterators un tās noņemt() metodi, vai arī varat vienkārši neizdzēst elementus iterācijas laikā. Tomēr mans ieteikums ir izmantot Straumes - 2022. gads.

2. Paroļu glabāšana kā virknes

Tā kā arvien vairāk un vairāk nodarbojos ar kiberdrošību, es nebūtu patiess pret sevi, ja nepieminētu vismaz vienu. Java kļūda kas var radīt drošības problēmu. No lietotājiem saņemto paroļu glabāšana Virkne objekts ir tieši tas, no kā jums vajadzētu baidīties.

Jautājums (vai varbūt priekšrocība) par Virkne ir tas, ka tā ir nemainīga. Kibernoziegumu pasaulē tas rada potenciālu apdraudējumu, jo nav iespējams izdzēst reiz izveidotas vērtības. Virkne objekts. Uzbrucējs, kas piekļūst datora atmiņai, tur var atrast vienkārša teksta paroles.

Otrkārt, virknes Java tiek internedēti JVM un glabāti PermGen telpā vai kaudzes telpā. Kad izveidojat Virkne objekts tiek ievietots kešatmiņā, un tas tiek noņemts tikai tad, kad atkritumu savācējs sāk veikt savu darbu. Jūs nevarat būt pārliecināts, kad jūsu parole tiks dzēsta no virkņu pūla, jo atkritumu savācējs darbojas nedeterministiski.

Kā no tā izvairīties?

Ieteicamā pieeja ir izmantot char[] vai, vēl labāk, bibliotēka, kas atbalsta paroļu glabāšanu kā char[], piem.Password4j. Portāls char[] masīvs ir mainīgs, un pēc tā inicializēšanas to var mainīt. Pēc paroles apstrādes var vienkārši izdzēst char[] paroles masīvu, ierakstot tajā izlases rakstzīmes. Ja uzbrucēji piekļūs jūsu datora atmiņai, viņi redzēs tikai dažas nejaušas vērtības, kurām nav nekāda sakara ar lietotāju paroli.

3. Izņēmumu (ne)apstrāde

Iesācēji un arī pieredzējušāki programmētāji nezina, kā pareizi rīkoties ar izņēmumiem. Viņu galvenais grēks šajā jautājumā ir to ignorēšana. TĀ NEKAD NAV LABA PIEEJA.

Diemžēl mēs nevaram piedāvāt risinājumu, kas būtu piemērots ikvienam klientam. Izņēmumss" scenāriju, ar ko saskaraties. Par katru gadījumu ir jādomā atsevišķi. Tomēr mēs varam sniegt dažus padomus, kā sākt darbu pie šī temata.

Kā no tā izvairīties?

1. ignorēšana Izņēmumss nekad nav laba prakse. Izņēmumsir ievietoti kāda iemesla dēļ, tāpēc tos nevajadzētu ignorēt.

2. try {...} catch(Izņēmums e) { log(e); } reti kad ir pareiza pieeja Izņēmums apstrāde.

3. Rethrow Izņēmums, lietotājam parādīt kļūdas dialoglodziņu vai vismaz pievienot visaptverošu ziņojumu žurnālam.

4. Ja izņēmumus atstājāt neapstrādātus (ko nevajadzētu darīt), vismaz paskaidrojiet komentārā.

4. Nulles izmantošana

Diemžēl ir diezgan bieži sastopama Java funkcija, kas dažos gadījumos atgriež null. Problēma ir tā, ka šāda funkcija liek klientam veikt rezultāta nulles pārbaudi. Bez tās NullPointerException tiek izmests.

Otra lieta ir iet null vērtība. Kāpēc jūs par to vispār domājāt? Šādā gadījumā funkcijai ir jāveic nulles pārbaude. Izmantojot trešo pušu bibliotēkas, jūs nevarat mainīt funkciju iekšpusi. Ko tad darīt?

Vēl svarīgāk ir tas, ka citi izstrādātāji, kas lasa jūsu kodu un redz, ka jūs nododat null droši vien būs neizpratnē par to, kāpēc izvēlējāties tik dīvainu veidu, kā īstenot savu funkciju.

Kā no tā izvairīties?

Neatgrieziet null vērtība! Nekad! Ja jūsu funkcija atgriež kāda veida Kolekcija, varat vienkārši atgriezt tukšu Kolekcija. Ja strādājat ar atsevišķiem objektiem, varat izmantot nulles objekta projektēšanas modeli. Tā kā Java 8, tas tiek īstenots kā Pēc izvēles. Cita, vismazāk ieteicamā pieeja ir paaugstināt Izņēmums.

5. Smagā virknes savienošana

Cerams, ka tā nav jūsu kļūda, jo tas ir vispopulārākais (vai varbūt otrs populārākais pēc FizzBuzz) intervijas jautājums. Kā jums jau vajadzētu zināt, a Virkne objekts ir nemainīgs Java - pēc izveidošanas to nevar mainīt. Tātad savienošana Virkne literāli nozīmē daudz nevajadzīgas atmiņas piešķiršanas. Saskaitīšana Virkne objektiem katru reizi ir jāizveido pagaidu StringBuilder objektu un mainot to atpakaļ uz virkni. Tāpēc šis risinājums ir pilnīgi nepiemērots, ja vēlamies apvienot lielu skaitu rakstzīmju.

Kā no tā izvairīties?

Lai atrisinātu šo problēmu, izmantojiet StringBuilder. Tas rada maināmu objektu, ar kuru var viegli manipulēt. Protams, vienmēr varat izmantot StringBuffer ja jūsu projekts tiek izmantots vienlaicīgā kontekstā.

6. Esošo risinājumu neizmantošana

Izstrādājot programmatūru, ir obligāti jāzina valodas, kurā rakstāt, pamati, taču ar to vien nepietiek. Daudzas algoritmiskās problēmas, ar kurām saskārāties, ieviešot jaunu funkciju, jau ir atrisinājis kāds cits. Pārāk daudz reižu esmu redzējis, kā kāds īsteno drošības algoritmu no nulles. Šāda pieeja ir pakļauta kļūdām. Viens cilvēks nevar rūpīgi pārbaudīt tik sarežģītu risinājumu. Kolektīvās zināšanas komanda kas sastāv no vidēji progresējušiem programmētājiem, gandrīz vienmēr ir labāka nekā viena brīnumbērna diženums. Java izstrādātājs. Jums nav jāizgudro ritenis no jauna - jums tikai jāpielāgo esošais risinājums, lai tas atbilstu jūsu vajadzībām.

Kā no tā izvairīties?

Mēģiniet meklēt bibliotēkas, kurās tiek risināta problēma, ar kuru strādājat. Mēģiniet atrast līdzīgus risinājumus. Daudzas no bibliotēkām, kas ir pieejamas vietnē tīmekļa vietne ir bezmaksas, un tās ir uzlabojuši un pārbaudījuši pieredzējuši izstrādātāji un visa Java kopiena. Nebaidieties tās izmantot.

7. Neatrod pietiekami daudz laika testu rakstīšanai

Ir vilinoši ticēt, ka mūsu kods vienmēr darbosies perfekti. Kodam testu nerakstīšana ir vislielākais grēks. Java programmatūras izstrādātāji. Daudzi no mums dod priekšroku manuālajiem un izpētes testiem, nevis vienības testiem, kas ir neprātīgi. Kāpēc tērēt laiku testu rakstīšanai, ja var koncentrēties uz pasaulē labākā koda nodrošināšanu savam projektam, kurā noteikti nav kļūdu?&ltjoke>. Izrādās, realitāte ir nežēlīga, un mēs nevaram nodrošināt augstas kvalitātes kodu bez testu rakstīšanas.

Kā no tā izvairīties?

Jums vienmēr ir jāsagatavo sava koda testi. Es zinu, ka TDD pieeju nav tik viegli uzturēt, bet jums vismaz vajadzētu nodrošināt testus, kas aptver visus nosacījumus, kādos var palaist jūsu kodu. Tas ietver arī ārkārtas situāciju testēšanu. Vienības testi ir nepieciešami. Jums tie jānodrošina katrai projekta funkcijai, ja vēlaties, lai jūsu kods būtu viegli refaktorificējams un paplašināms turpmākajā attīstībā. 

Vēl viena lieta. Uzturiet augstu testēšanas koda standartu - tas būs tā vērts. Tas ir tēvoča Boba padoms, un es tam pilnībā piekrītu.

Turklāt neaizmirstiet arī par citiem testu veidiem. Integrācijas testi ir lieta, kas jāņem vērā katrā projektā.

8. Aizmiršana par piekļuves modifikatoriem

Privāts un publisks, vai ne? Kā mēs varam par tiem aizmirst. Izrādās, to ir vairāk. Kad pirmo reizi sākāt mācīties Java, jūs noteikti uzzinājāt par aizsargātiem piekļuves modifikatoriem. Dažos gadījumos tie var būt noderīgi, tāpēc ir vērts zināt par to esamību.

Java izstrādātāji bieži vien aizmirst par paketes darbības jomu. To ir viegli nepieminēt, jo tā ir netieša un neprasa nekādu Java atslēgvārdi. Svarīga ir paketes darbības joma. Tā ļauj testēt aizsargātu metodi. Aizsargātie elementi ir pieejami no testa klases ceļa, ja vien pakete ir tāda pati.

Kā no tā izvairīties?

Atcerieties par aizsargāto modifikatoru un to, ka paketes darbības joma ļauj to pārbaudīt.

9. Tīras JavaEE, nevis Spring izmantošana

Nākamais solis pēc mācīšanās Java SE ir iemācīties, kā palaist Java serveros, kā izveidot uzņēmuma līmeņa lietojumprogrammu.

Jaunpienācēji nereti nokļūst JavaEE apgūšanas slazdā, jo par to ir ļoti daudz mācību materiālu. Pat "Thinking in Java Java programmētāji' bībelē ir minēta JavaEE un nekas nav teikts par citām iespējām.

Kā no tā izvairīties?

JavaEE ir pagātnes dziesma. Mūsdienās pavasaris ir kļuvis par ikdienišķu lietu, un Java EE ir tikai jauka lieta. Katrā modernā uzņēmuma līmeņa lietojumprogrammā tiek izmantots Spring, tāpēc jums noteikti vajadzētu apsvērt iespēju apgūt to šeit.

Lasīt vairāk:

Pareizais veids, kā atrast labākos Java izstrādātājus

Labākais Java projektu veids

Labākās programmēšanas valodas finanšu tehnoloģiju uzņēmumiem