Kiel Java diferencas de aliaj popularaj lingvoj? Kial Java devus esti la unua lingvo por lerni? Ni kreu planon, kiu helpos vin lerni Java kaj de nulo kaj aplikante programajn kapablojn en aliaj lingvoj. Ni listigu la diferencojn inter krei produktadkodon en Java kaj disvolvi en aliaj lingvoj. Miĥail Zatepyakin legis ĉi tiun raporton en kunveno por estontaj partoprenantoj Yandex kaj aliaj komencaj programistoj - Java Junior-renkontiĝo.
— Saluton al ĉiuj, mia nomo estas Misha. Mi estas programisto de Yandex.Market, kaj hodiaŭ mi rakontos al vi kial lerni Java kaj kiel fari ĝin efike. Vi eble faros prudentan demandon: kial mi rakontos ĉi tiun historion, kaj ne iu forta programisto kun multjara sperto? La fakto estas, ke mi mem studis Javon antaŭ nelonge, antaŭ proksimume jaro kaj duono, do mi ankoraŭ memoras kiel ĝi estis kaj kiaj faŭltoj estas.
Antaŭ unu jaro mi ricevis staĝon ĉe Yandex.Market. Mi evoluigis la backend por Beru, por la Merkato mem, vi verŝajne uzis ĝin. Nun mi daŭre laboras tie, en alia teamo. Ni kreas analizan platformon por Yandex.Market por komercaj partneroj.
Ni komencu. Kial lerni Java el praktika vidpunkto? La fakto estas, ke Java estas tre fama programlingvo. Ĝi havas tre grandan komunumon.
Ekzemple, ekzistas tia TIOBE-indekso, populara indekso de la populareco de programlingvoj, kaj Java estas la unua tie. Ankaŭ, en laborlokoj, vi verŝajne rimarkos, ke la plej multaj vakantaĵoj temas pri Java, tio estas, evoluante en Java, vi ĉiam povas trovi laboron.
Ĉar la komunumo estas tre granda, ajna demando, kiun vi havas, trovos respondon en iu Stack Overflow aŭ aliaj retejoj. Ankaŭ, dum disvolvado en Java, vi efektive skribas kodon sur la JVM, do vi povas facile ŝanĝi al Kotlin, Scala kaj aliaj lingvoj, kiuj uzas la JVM.
Kio estas bona pri Java el ideologia vidpunkto? Estas malsamaj programlingvoj. Ili solvas malsamajn problemojn, vi scias tion. Ekzemple, Python estas bonega por verki unuliniajn skriptojn por solvi rapidajn problemojn.
Sur la plusa flanko, vi povas plene kontroli la plenumeblan kodon. Ekzemple, ni havas aŭtojn, Yandex-senŝoforajn aŭtojn, ilia kodo estas skribita per plusoj. Kial? Javo havas tian aferon - Rubo Kolekto. Ĝi forigas RAM de nenecesaj objektoj. Ĉi tiu afero komenciĝas spontane kaj faras halt-la-mondo, tio estas, ĝi haltigas la reston de la programo kaj iras al nombri objektojn, klara memoro de objektoj. Se tia afero funkcias en drone, ĝi ne estas mojosa. Via virabelo veturos rekte, ĉi-momente purigu sian memoron kaj tute ne rigardos la vojon. Tial, la virabelo estas skribita sur la avantaĝoj.
Kiajn problemojn Java solvas? Ĝi estas ĉefe lingvo por disvolvi grandajn programojn, kiuj estas verkitaj dum jaroj, de dekoj aŭ centoj da homoj. Aparte, multaj el la backend en Yandex.Market estas skribita en Java. Ni havas distribuitan teamon en pluraj urboj, po dek homoj en ĉiu. Kaj la kodo estas facile konservebla, ĝi estas subtenata dum dek jaroj aŭ pli, kaj samtempe novaj homoj venas kaj komprenas ĉi tiun kodon.
Kiajn trajtojn havu lingvo, por ke la kodo en ĝi estu facile subtenata kaj por ke ĝi povu facile disvolviĝi en grandaj teamoj. Antaŭ ĉio, ĝi devus esti legebla kodo, kaj devus esti facile efektivigi kompleksajn arkitekturajn solvojn. Tio estas, devus esti facile verki altnivelajn abstraktaĵojn, ktp. Ĉio ĉi estas tio, kion Java provizas al ni. Ĉi tio estas objekto-orientita lingvo. Estas vere facile efektivigi altnivelajn abstraktaĵojn kaj kompleksajn arkitekturojn.
Ekzistas ankaŭ multaj kadroj kaj bibliotekoj por Java, ĉar la lingvo estas pli ol 15-jara. Dum ĉi tiu tempo, ĉio, kio povus esti skribita, estis skribita sur ĝi, do ekzistas tunoj da bibliotekoj por ĉio, kion vi eble bezonos.
Kiajn bazajn kapablojn, laŭ mi, devus havi komencanta JA-ludanto? Antaŭ ĉio, ĉi tio estas kono de la Java-kernlingvo. Poste estas ia kadro de Dependeco-Injekto. La sekva parolanto, Kirill, parolos pri tio pli plene. Mi ne iros tro profunden. Poste estas la arkitekturo kaj dezajnaj ŝablonoj. Ni devas povi skribi arkitekture belan kodon por skribi grandajn aplikojn. Kaj ĉi tio estas ia SQL aŭ ORM por taskoj labori kun la datumbazo. Kaj ĉi tio validas pli por la backend.
Iru! Java-kerno. Mi ne vere malkovros Amerikon ĉi tie—vi devas scii la lingvon mem. Kion vi devus atenti. Unue, Java publikigis multajn versiojn en la lastaj jaroj, tio estas, en 2014-2015 la sepa estis publikigita, poste la oka, naŭa, deka, multaj novaj versioj, kaj multaj novaj bonegaj aferoj estis enkondukitaj en ili. , ekzemple, la Java Stream API , lambda, ktp. Tre freŝaj, freŝaj aferoj, kiuj estas uzataj en produktadkodo, pri kio ili demandas en intervjuoj kaj kiujn vi bezonas scii. Tial vi ne devas preni libron el la breto en la biblioteko Java-4 kaj iru lerni ĝin. Jen nia plano: ni lernas Java-8 aŭ pli altan.
Ni tre atentas novigojn kiel Stream API, var, ktp. Ili estas demanditaj dum intervjuoj kaj estas konstante uzataj en produktado. Tio estas, la Stream API estas multe pli malvarmeta ol bukloj, ĝenerale, tre bonega afero. Nepre atentu.
Kaj estas ĉiaj aferoj kiel iterantoj, Esceptoj kaj tiel plu. Aferoj, kiuj ŝajnas al vi negravaj, kondiĉe ke vi mem skribas etan kodon. Vi ne bezonas ĉi tiujn Esceptojn, kiu tamen bezonas ilin? Sed ili certe estos demanditaj ĉe intervjuoj, ili certe estos utilaj al vi en produktado. Ĝenerale, vi devus atenti Esceptojn, ripetojn kaj aliajn aferojn.
Datumaj strukturoj. Vi ne povas iri sen strukturoj, sed estos bonege se vi ne nur scias, ke ekzistas aroj, vortaroj kaj folioj. Kaj ankaŭ malsamaj efektivigoj de strukturoj. Ekzemple, la sama vortaro en Java havas multajn efektivigojn, inkluzive de HashMap kaj TreeMap. Ili havas malsamajn asimptotikojn, ili estas strukturitaj malsame interne. Vi devas scii kiel ili diferencas kaj kiam uzi kiun.
Ĝi ankaŭ estos tre mojosa se vi scias kiel ĉi tiuj datumstrukturoj funkcias interne. Tio estas, ne estas facile koni iliajn asimptotikojn - kiom la veto funkcias, kiom longe la enirpermesilo funkcias, sed kiel la strukturo funkcias interne - ekzemple, kio estas sitelo en HashMap.
Ankaŭ indas atenti arbojn kaj grafikaĵojn. Ĉi tiuj estas aferoj ne tre oftaj en produktadkodo, sed ili estas popularaj en intervjuoj. Sekve, vi devas povi trairi arbojn, grafikaĵojn en larĝeco kaj profundo. Ĉi tiuj ĉiuj estas simplaj algoritmoj.
Tuj kiam vi komencos skribi ajnan grandan kodon, kompleksan, uzante bibliotekojn, multklasan kodon, vi rimarkos, ke estas malfacile por vi sen konstrui sistemojn kaj solvi dependecojn. Tiuj estas ĉefe Maven kaj Gradle. Ili permesas vin importi bibliotekojn en vian projekton en unu linio. Tio estas, vi skribas unulinian xml kaj importas bibliotekojn en la projekton. Grandaj sistemoj. Ili estas proksimume la samaj, uzu aŭ unu - Maven aŭ Gradle.
Poste - ia versio-kontrolsistemo. Mi rekomendas Git ĉar ĝi estas populara kaj ekzistas tunoj da lerniloj. Preskaŭ ĉiuj uzas Git, ĝi estas bonega afero, vi ne povas vivi sen ĝi.
Kaj ia disvolva medio. Mi rekomendas IntelliJ Idea. Ĝi multe akcelas la disvolvan procezon, multe helpas vin, skribas la tutan boilerplatan kodon por vi, ĝenerale, ĝi estas bonega.
Ligiloj de la diapozitivo: ,
SQL. Iom pri backenders. Efektive estis amuza kazo ĉi tie. Du tagojn antaŭ mia dua staĝa intervjuo, HR-knabino vokis min kaj diris, ke post du tagoj ili demandos min pri SQL kaj HTTP, mi bezonas lerni ĝin. Kaj mi preskaŭ nenion sciis pri SQL aŭ HTTP. Kaj mi trovis ĉi tiun bonegan retejon - . Mi lernis SQL pri ĝi en 12 horoj, mi volas diri, SQL-sintakso, kiel skribi SELECT-demandojn, JOIN, ktp. Tre bonega retejo, mi tre rekomendas ĝin. Fakte, en 12 horoj mi lernis 90% de tio, kion mi nun scias.
Kaj ankaŭ estas bonege koni datumbazan arkitekturon. Ĉi tiuj estas ĉiaj klavoj, indeksoj, normaligo. Estas serio da afiŝoj pri tio ĉe Habré.
En Java, krom SQL, ekzistas ĉiaj Objekt-rilataj mapaj sistemoj kiel JPA. Estas iu kodo. En la unua metodo estas iu SQL-kodo - SELECT id-nomon FROM info.users WHERE id IN userIds. De la datumbazo de uzantoj, de la tabelo, iliaj identigiloj kaj nomoj estas akiritaj.
Poste, estas certa mapper kiu igas objekton de la bazo en Java objekton. Kaj estas tria metodo sube, kiu efektive efektivigas ĉi tiun kodon. Ĉio ĉi povas esti anstataŭigita uzante JPA per unu linio, kiu estas skribita sube. Ĝi faras la samon - trovu All ByIdIn. Tio estas, surbaze de la nomo de la metodo, ĝi generas SQL-demandon por vi.
Tre mojosa afero. Mi mem, kiam mi ne konis SQL, uzis JPA. Ĝenerale atentu. Se vi estas tro maldiligenta por lerni SQL, ĝi estas katastrofo. Kaj, ĝenerale, fajro!
Printempo. Kiu aŭdis pri tia afero kiel la Printempa kadro? Ĉu vi vidas kiom da vi estas? Ne sen kialo. Printempo estas inkluzivita en la postuloj de ĉiu dua Java backend-vakantaĵo. Sen ĝi, estas vere nenie en granda evoluo. Kio estas Printempo? Antaŭ ĉio, ĉi tio estas Dependeca Injekta kadro. Ankaŭ pri ĉi tio sekva parolanto. Sed mallonge, ĉi tio estas afero, kiu ebligas al vi faciligi importi la dependecojn de iuj klasoj al aliaj. Tio estas, scio pri dependecoj estas simpligita.
Spring Boot estas peco de Spring, kiu ebligas al vi ruli vian servilan aplikaĵon per unu butono. Vi iras al THID, premu kelkajn butonojn, kaj nun vi havas vian servilan aplikaĵon funkcianta sur localhost 8080. Tio estas, vi ankoraŭ ne skribis eĉ unu linion de kodo, sed ĝi jam funkcias. Tre mojosa afero. Se vi skribas ion propran, fajro!
Printempo estas tre granda kadro. Ĝi ne nur prenas vian servilan aplikaĵon kaj solvas Dependecan Injekton. Ĝi permesas vin fari multajn aferojn, inkluzive krei REST-API-metodojn. Tio estas, vi skribis iun metodon kaj alfiksis la Akiri mapan komentarion al ĝi. Kaj nun vi jam havas iun metodon sur localhost, kiu skribas Saluton mondo al vi. Du linioj de kodo kaj ĝi funkcias. Bonegaj aferoj.
Printempo ankaŭ faciligas skribajn testojn. Ne estas maniero sen testado en granda disvolviĝo. La kodo devas esti provita. Por tiu celo, Java havas bonegan bibliotekon JUnit 5. Kaj JUnit ĝenerale, sed la plej nova versio estas la kvina. Estas ĉio por testado, ĉiaj asertoj kaj aliaj aferoj.
Kaj estas mirinda Mockito-kadro. Imagu, ke vi havas iun funkcion, kiun vi volas testi. La funkcio faras multajn aferojn, inkluzive, ie en la mezo, ĝi ensalutas en VKontakte kun via ID, ekzemple, kaj ricevas la unuan kaj familian nomon de la uzanto de VKontakte de la ID. Vi verŝajne ne inkluzivos VKontakte en la testoj, tio estas stranga. Sed vi devas testi la funkciecon, do vi faris ĉi tiun klason, uzante Mockito, mok ĝin, imiti ĝin.
Vi diros, ke kiam peto venas al ĉi tiu klaso kun identigilo tia kaj tia, ĝi resendas iun familian nomon, ekzemple, Vasja Pupkin. Kaj ĝi funkcios. Tio estas, vi provos ĉiujn funkciojn por mok unu klaso. Tre mojosa afero.
Dezajnaj ŝablonoj. Kio ĝi estas? Ĉi tiuj estas ŝablonoj por solvi tipaj problemoj, kiuj aperas en evoluo. En evoluo ofte aperas identaj aŭ similaj problemoj, kiujn estus bonege iel bone solvi. Tial homoj elpensis plej bonajn praktikojn, certajn ŝablonojn, pri kiel solvi ĉi tiujn problemojn.
Estas retejo kun la plej popularaj ŝablonoj - refactoring.guru, vi povas legi ĝin, ekscii, kiaj ŝablonoj ekzistas, legi multajn teoriojn. La problemo estas, ke ĝi estas preskaŭ senutila. Fakte, ŝablonoj sen praktiko ne estas precipe utilaj.
Vi aŭdos pri iuj ŝablonoj kiel Singletone aŭ Builder. Kiu aŭdis ĉi tiujn vortojn? Multaj homoj. Estas tiaj simplaj ŝablonoj, kiujn vi povas efektivigi mem. Sed la plej multaj el la ŝablonoj: strategio, fabriko, fasado - ne estas klare kie apliki ilin.
Kaj ĝis vi vidos praktike en la kodo de iu alia persono lokon al kiu ĉi tiu ŝablono estas aplikata, vi ne povos apliki ĝin mem. Tial, praktiko estas tre grava kun ŝablonoj. Kaj nur legi pri ili ĉe refactoring.guru ne estas tre helpema, sed certe indas fari ĝin.
Kial ŝablonoj bezonas? Ni diru, ke vi havas certan Uzantan klason. Ĝi havas Idaĵon kaj Nomon. Ĉiu Uzanto devas havi kaj Identigon kaj Nomon. Supre maldekstre estas la klasĉambro.
Kiuj estas la manieroj pravalorigi Uzanton? Estas du opcioj - aŭ konstrukciisto aŭ agordilo. Kio estas la malavantaĝoj de ambaŭ aliroj?
Konstruisto. nova Uzanto (7, "Bond"), bone. Nun ni diru, ke ni ne havas Uzantan klason, sed iun alian, kun sep nombraj kampoj. Vi havos konstruilon enhavantan sep sinsekvajn nombrojn. Ne estas klare, kio estas ĉi tiuj nombroj kaj kiu el ili apartenas al kiu posedaĵo. La dezajnisto ne estas bonega.
La dua opcio estas setter. Vi klare skribas: setId(7), setName ("Obligacio"). Vi komprenas, kiu posedaĵo apartenas al kiu kampo. Sed setter havas problemon. Unue, vi eble forgesos asigni ion, kaj due, via objekto montriĝas ŝanĝebla. Ĉi tio ne estas sekura kaj iomete reduktas la legeblecon de la kodo. Tial homoj elpensis bonegan ŝablonon - Konstruisto.
Pri kio ĉi tio temas? Ni provu kombini la avantaĝojn de ambaŭ aliroj - starigisto kaj konstruanto - en unu. Ni faras certan objekton, Builder, kiu ankaŭ havos Id- kaj Nomo-kampojn, kiu mem estos konstruita surbaze de la agordilo, kaj kiu havos Build-metodon kiu resendas al vi novan Uzanton kun ĉiuj parametroj. Ni ricevas neŝanĝeblan objekton kaj starigiston. Bone!
Kio estas la problemoj? Ĉi tie ni havas la klasikan Konstruilon. La problemo estas, ke ni ankoraŭ povas forgesi kontroli en iu kampo. Kaj se ni forgesis viziti la ID, ĉi-kaze en Builder ĝi estas pravigita al nulo, ĉar la int-tipo ne estas nulebla. Kaj se ni faras la Nomon "Bond" kaj forgesos viziti la ID-oficejon, ni havos novan Uzanton kun id "0" kaj la nomo "Bond". Ne malvarmeta.
Ni provu batali ĉi tion. En Builder ni ŝanĝos int al int tiel ke ĝi estu nulebla. Nun ĉio estas bonega.
Se ni provas krei Uzanton kun la nomo "Bond", forgesante meti lian ID, ni ricevos nulan montrilon escepton, ĉar la ID ne estas nulebla, kaj la Konstruisto havas nulan, specife montrilon escepton.
Sed ni ankoraŭ povas forgesi meti nomon, do ni agordas objektan ripeton al nulo. Nun, kiam ni konstruas nian objekton de Builder, ĝi kontrolas, ke la kampo ne estas nulebla. Kaj tio ne estas ĉio.
Ni rigardu la lastan ekzemplon. En ĉi tiu kazo, se ni iel metas nulon en la ID-rultempo, estus bonege tuj scii, ke vi faris ĝin kaj ne estas bone, ke vi nun eraras.
Vi devas ĵeti eraron ne en la momento de kreado de Uzanto, sed kiam vi agordas nulon al la ID. Tial, en Builder ni ŝanĝos la agordilon Entjero al int, kaj li tuj ĵuros, ke ili elĵetis nulon.
Resume, kio estas la afero? Estas simpla Builder-ŝablono, sed eĉ ĝia efektivigo havas kelkajn subtilaĵojn, do estas tre mojose rigardi malsamajn realigojn de ŝablonoj. Ĉiu ŝablono havas dekduojn da efektivigoj. Ĉio ĉi estas tre interesa.
Kiel ni skribas Builder en produktadkodo? Jen nia Uzanto. Ni alfiksas Builder-rotacion de la Lombok-biblioteko al ĝi, kaj ĝi mem generas Builder por ni. Tio estas, ni skribas neniun kodon, sed Java jam pensas, ke ĉi tiu klaso havas Konstruilon, kaj ni povas nomi ĝin tiel.
Mi jam diris, ke Ĝavo havas bibliotekojn por preskaŭ ĉio, inkluzive de Lombok, mojosa biblioteko, kiu ebligas eviti skribi boilerplate. Konstruisto, GET.
Ŝablonoj povas esti arkitekturaj - rilataj ne nur al unu klaso, sed al la sistemo kiel tutaĵo. Estas tia bonega principo en sistema dezajno: Unuopa Principo de Respondeco. Pri kio li parolas? La fakto, ke ĉiu klaso devas respondeci pri iuj el sia propra funkcieco. En ĉi tiu kazo, ni havas Regilon kiu komunikas kun uzantoj, JSON-objektoj. Estas Fasado, kiu konvertas JSON-objektojn en modelojn, kun kiuj la Java-aplikaĵo tiam funkcios. Estas Servo, kiu havas kompleksan logikon, kiu funkcias kun ĉi tiuj modeloj. Estas Data Access Object, kiu metas ĉi tiujn modelojn en la datumbazon kaj prenas ilin de la datumbazo. Kaj estas la datumbazo mem. Alivorte, ĝi ne estas ĉio en unu klaso, sed ni faras kvin malsamajn klasojn, kaj tio estas alia ŝablono.
Post kiam vi pli-malpli lernis Javan, estas bonege verki vian propran projekton, kiu havos datumbazon, laboros kun aliaj API-oj kaj elmontros vian servilan aplikaĵon al REST-API-klientoj. Ĉi tio estus bonega por aldoni al via vivresumo, ĝi estus bonega fino al via edukado. Kun ĉi tio vi povas iri kaj akiri laboron.
Jen ekzemplo de mia servila aplikaĵo. En mia dua jaro, mi verkis terminon kun la uloj. Ili verkis poŝtelefonan aplikaĵon por organizi eventojn. Tie uzantoj povus ensaluti per VKontakte, loki punktojn sur la mapo, krei eventojn, inviti siajn amikojn al ili, konservi bildojn de eventoj ktp.
Kion mi faris en la projekto? Verkis servilan aplikaĵon en Spring Boot sen uzi SQL. Mi ne konis lin, mi uzis JPA. Kion ĝi povus fari? Ensalutu al VK per OAuth-2. Prenu la ĵetonon de la uzanto, iru al VK kun ĝi, kontrolu, ke ĝi estas vera uzanto. Ricevu informojn pri uzantoj per VKontakte. Ĝi povis konservi informojn en datumbazo, ankaŭ per JPA. Lerte konservu bildojn kaj aliajn dosierojn en komputila memoro, kaj konservu ligilojn al ili en la datumbazo. Tiutempe mi ne sciis, ke estas CLOB-objektoj en la datumbazo, do mi faris tion tiel. Estis REST API por uzantoj, klientaj aplikoj. Kaj ekzistis unutestoj por baza funkcieco.
[…] Malgranda ekzemplo de mia sukcesa lernado de Java. En mia unua jaro ĉe universitato, mi estis instruita C# kaj ricevis komprenon pri OOP-programado - kiaj klasoj, interfacoj, abstraktado estas, kaj kial ili estas bezonataj. Ĝi multe helpis min. Sen tio, lernado de Java estas sufiĉe malfacila; estas ne klare kial klasoj estas bezonataj.
En mia dua jaro en la universitato, ili denove instruis Java-kernon, sed mi ne haltis tie, mi mem iris studi Printempon kaj verkis kursverkon, mian projekton, kiun mi supre menciis. Kaj kun ĉio ĉi, mi iris por staĝo ĉe Yandex, pasigis intervjuon kaj eniris Yandex.Market. Tie mi skribis la backend por Beru, ĉi tiu estas nia vendoplaco, kaj por Yandex.Market mem.
Post tio, antaŭ ses monatoj, mi translokiĝis al alia teamo ene de la sama Merkato. Ni faras analizojn por komercaj partneroj. Ni estas en la analiza platformo, estas tri el ni en la backend, do mi havas tre grandan parton de influo sur la projekto. Ĝi estas tre interesa, fakte. Tio estas, ni efektive provizas datumojn pri la merkato - kiaj vendoj estas, en kiaj kategorioj, en kiaj modeloj, por komercaj partneroj, grandaj konataj kompanioj. Kaj estas nur tri el ni, ni skribas ĉi tiun kodon, kaj ĝi estas tre mojosa.
Dankon! Utilaj ligiloj:
- .
- .
- .
- .
- .
- .
- .
- .
fonto: www.habr.com