Hoe verskil Java van ander gewilde tale? Waarom moet Java die eerste taal wees om te leer? Kom ons skep 'n plan wat jou sal help om Java van nuuts af te leer en deur programmeringsvaardighede in ander tale toe te pas. Kom ons lys die verskille tussen die skep van produksiekode in Java en die ontwikkeling in ander tale. Mikhail Zatepyakin het hierdie verslag op 'n vergadering vir toekomstige deelnemers gelees Yandex en ander begin-ontwikkelaars - Java Junior ontmoeting.
— Hallo almal, my naam is Misha. Ek is 'n ontwikkelaar van Yandex.Market, en vandag sal ek jou vertel hoekom om Java te leer en hoe om dit effektief te doen. Jy mag dalk 'n redelike vraag vra: hoekom sal ek hierdie storie vertel, en nie 'n sterk ontwikkelaar met baie jare se ondervinding nie? Die feit is dat ek self onlangs, so 'n jaar en 'n half gelede, Java bestudeer het, so ek onthou nog hoe dit was en watter slaggate daar is.
'n Jaar gelede het ek 'n internskap by Yandex.Market gekry. Ek het die backend vir Beru ontwikkel, vir die mark self, jy het dit waarskynlik gebruik. Nou gaan ek voort om daar te werk, in 'n ander span. Ons skep 'n analitiese platform vir Yandex.Market vir sakevennote.
Laat ons begin. Hoekom leer Java vanuit 'n praktiese oogpunt? Die feit is dat Java 'n baie bekende programmeertaal is. Dit het 'n baie groot gemeenskap.
Daar is byvoorbeeld so 'n TIOBE-indeks, 'n gewilde indeks van die gewildheid van programmeertale, en Java is eerste daar. Ook op werkwebwerwe sal jy waarskynlik agterkom dat die meeste van die vakatures oor Java handel, dit wil sê, deur in Java te ontwikkel, kan jy altyd werk kry.
Aangesien die gemeenskap baie groot is, sal enige vraag wat jy het 'n antwoord op sommige Stack Overflow of ander webwerwe vind. Ook, wanneer jy in Java ontwikkel, skryf jy eintlik kode op die JVM, sodat jy maklik kan oorskakel na Kotlin, Scala en ander tale wat die JVM gebruik.
Wat is goed aan Java vanuit 'n ideologiese oogpunt? Daar is verskillende programmeertale. Hulle los verskillende probleme op, jy weet dit. Python is byvoorbeeld wonderlik om eenreëlskrifte te skryf om vinnige probleme op te los.
Aan die positiewe kant kan jy die uitvoerbare kode ten volle beheer. Ons het byvoorbeeld motors, Yandex-bestuurderlose motors, hul kode is in pluspunte geskryf. Hoekom? Java het so 'n ding - Garbage Collector. Dit maak die RAM skoon van onnodige voorwerpe. Hierdie ding begin spontaan en stop-die-wêreld, dit wil sê, dit stop die res van die program en gaan om voorwerpe te tel, skoon geheue van voorwerpe. As so iets in 'n hommeltuig werk, is dit nie cool nie. Jou hommeltuig sal reguit ry, op hierdie oomblik sy geheue skoonmaak en glad nie na die pad kyk nie. Daarom word die hommeltuig op die voordele geskryf.
Watter probleme los Java op? Dit is hoofsaaklik 'n taal vir die ontwikkeling van groot programme wat oor jare geskryf word, deur dosyne of honderde mense. In die besonder, baie van die backend in Yandex.Market is in Java geskryf. Ons het 'n verspreide span in verskeie stede, tien mense in elk. En die kode is maklik om te onderhou, dit word vir tien jaar of meer ondersteun, en terselfdertyd kom nuwe mense in en verstaan hierdie kode.
Watter eienskappe moet 'n taal hê sodat die kode daarin maklik ondersteun word en sodat dit maklik in groot spanne ontwikkel kan word. Eerstens moet dit leesbare kode wees, en dit moet maklik wees om komplekse argitektoniese oplossings te implementeer. Dit wil sê, dit moet maklik wees om hoëvlak abstraksies te skryf, ens. Dit alles is wat Java ons voorsien van. Dit is 'n objekgeoriënteerde taal. Dit is regtig maklik om hoëvlak abstraksies en komplekse argitekture te implementeer.
Daar is ook baie raamwerke en biblioteke vir Java, want die taal is meer as 15 jaar oud. Gedurende hierdie tyd is alles wat geskryf kon word daarop geskryf, so daar is tonne biblioteke vir alles wat jy dalk nodig het.
Watter basiese vaardighede, na my mening, moet 'n begin JA-speler hê? Eerstens is dit kennis van die Java-kerntaal. Volgende is 'n soort afhanklikheidsinspuitingsraamwerk. Die volgende spreker, Kirill, sal meer volledig hieroor praat. Ek sal nie te diep gaan nie. Volgende is die argitektuur en ontwerppatrone. Ons moet argitektonies pragtige kode kan skryf om groot toepassings te kan skryf. En dit is 'n soort SQL of ORM vir take om met die databasis te werk. En dit geld meer vir die agterkant.
Gaan! Java kern. Ek sal Amerika nie regtig hier ontdek nie—jy moet die taal self ken. Waaraan jy moet aandag gee. Eerstens het Java die afgelope jare baie weergawes vrygestel, dit wil sê, in 2014-2015 is die sewende vrygestel, dan is die agtste, negende, tiende, baie nuwe weergawes, en baie nuwe oulike dinge daarin bekendgestel. , byvoorbeeld die Java Stream API , lambda, ens. Baie oulike, vars, koel goed wat in produksiekode gebruik word, waaroor hulle in onderhoude vra en wat jy moet weet. Daarom moet jy nie 'n boek van die rak in die Java-4-biblioteek neem en dit gaan leer nie. Dit is ons plan: ons leer Java-8 of hoër.
Ons gee baie aandag aan innovasies soos Stream API, var, ens. Dit word tydens onderhoude gevra en word voortdurend in produksie gebruik. Dit wil sê, die Stream API is baie koeler as lusse, oor die algemeen 'n baie oulike ding. Maak seker dat jy aandag gee.
En daar is allerhande dinge soos iterators, Uitsonderings en so aan. Dinge wat vir jou onbelangrik lyk solank jy self 'n klein kode skryf. Jy het nie hierdie Uitsonderings nodig nie, wie het hulle in elk geval nodig? Maar hulle sal beslis by onderhoude gevra word, hulle sal beslis vir jou nuttig wees in produksie. Oor die algemeen moet u aandag gee aan uitsonderings, iterators en ander dinge.
Datastrukture. Jy kan nie sonder strukture gaan nie, maar dit sal wonderlik wees as jy nie net weet dat daar stelle, woordeboeke en blaaie is nie. En ook verskillende implementerings van strukture. Byvoorbeeld, dieselfde woordeboek in Java het baie implementerings, insluitend HashMap en TreeMap. Hulle het verskillende asimptotika, hulle is anders gestruktureer binne. Jy moet weet hoe hulle verskil en wanneer om watter een te gebruik.
Dit sal ook baie gaaf wees as jy weet hoe hierdie datastrukture intern werk. Dit wil sê, dit is nie maklik om hul asimptotika te ken nie - hoeveel die weddenskap werk, hoe lank die pas werk, maar hoe die struktuur binne werk - byvoorbeeld, wat is 'n emmer in HashMap.
Dit is ook die moeite werd om aandag te skenk aan bome en grafieke. Dit is dinge wat nie baie algemeen in produksiekode voorkom nie, maar dit is gewild in onderhoude. Gevolglik moet jy bome, grafieke in breedte en diepte kan deurkruis. Dit is alles eenvoudige algoritmes.
Sodra jy enige groot kode, kompleks, met behulp van biblioteke, multi-klas kode begin skryf, sal jy besef dat dit vir jou moeilik is sonder om stelsels te bou en afhanklikhede op te los. Dit is hoofsaaklik Maven en Gradle. Hulle laat jou toe om biblioteke in een reël in jou projek in te voer. Dit wil sê, jy skryf 'n eenlyn xml en voer biblioteke in die projek in. Groot stelsels. Hulle is ongeveer dieselfde, gebruik een - Maven of Gradle.
Volgende - 'n soort weergawe beheer stelsel. Ek beveel Git aan omdat dit gewild is en daar tonne tutoriale is. Byna almal gebruik Git, dit is 'n gawe ding, jy kan nie daarsonder lewe nie.
En 'n soort ontwikkelingsomgewing. Ek beveel IntelliJ Idee aan. Dit versnel die ontwikkelingsproses baie, help jou baie, skryf al die boilerplate-kode vir jou, in die algemeen is dit cool.
Skakels vanaf die skyfie: ,
SQL. 'N bietjie oor backenders. Hier was eintlik 'n snaakse geval. Twee dae voor my tweede internskap-onderhoud het 'n HR-meisie my gebel en gesê dat hulle my oor twee dae oor SQL en HTTP sal vra, ek moet dit leer. En ek het amper niks geweet van SQL of HTTP nie. En ek het hierdie oulike webwerf gevind - . Ek het SQL daarop geleer in 12 uur, ek bedoel, SQL sintaksis, hoe om SELECT navrae te skryf, JOIN, ens. Baie oulike webwerf, ek beveel dit sterk aan. Trouens, in 12 uur het ek 90% geleer van wat ek nou weet.
En dit is ook wonderlik om databasisargitektuur te ken. Dit is allerhande sleutels, indekse, normalisering. Daar is 'n reeks plasings hieroor op Habré.
In Java, benewens SQL, is daar allerhande objek-relasionele karteringstelsels soos JPA. Daar is 'n kode. In die eerste metode is daar 'n paar SQL-kode - KIES ID-naam FROM info.users WHERE id IN gebruiker-ID's. Van die gebruikersdatabasis, uit die tabel, word hul ID's en name verkry.
Vervolgens is daar 'n sekere karteerder wat 'n voorwerp van die basis in 'n Java-voorwerp verander. En daar is 'n derde metode hieronder wat hierdie kode eintlik uitvoer. Dit alles kan vervang word met behulp van JPA met een reël, wat hieronder geskryf is. Dit doen dieselfde ding - vind All ByIdIn. Dit wil sê, gebaseer op die naam van die metode, genereer dit 'n SQL-navraag vir jou.
Baie cool ding. Ek het self, toe ek nie SQL geken het nie, JPA gebruik. Gee oor die algemeen aandag. As jy te lui is om SQL te leer, is dit 'n ramp. En, in die algemeen, vuur!
Lente. Wie het al gehoor van iets soos die Lente-raamwerk? Sien jy hoeveel van julle daar is? Nie sonder rede nie. Lente is ingesluit by die vereistes van elke tweede Java-backend-vakature. Daarsonder is daar regtig nêrens in 'n groot ontwikkeling nie. Wat is Lente? Eerstens, dit is 'n afhanklikheidsinspuitingsraamwerk. Ook hieroor volgende spreker. Maar in kort, dit is 'n ding wat jou toelaat om dit makliker te maak om die afhanklikhede van sommige klasse na ander in te voer. Dit wil sê, kennis van afhanklikhede word vereenvoudig.
Spring Boot is 'n stuk Spring waarmee u u bedienertoepassing met een knoppie kan laat loop. Jy gaan na THID, druk 'n paar knoppies, en nou het jy jou bedienertoepassing aan die gang op localhost 8080. Dit wil sê, jy het nog nie 'n enkele reël kode geskryf nie, maar dit werk reeds. Baie cool ding. As jy iets van jou eie skryf, vuur!
Lente is 'n baie groot raamwerk. Dit tel nie net u bedienertoepassing op en los Afhanklikheidsinspuiting op nie. Dit laat jou toe om 'n klomp dinge te doen, insluitend die skep van REST API-metodes. Dit wil sê, jy het een of ander metode geskryf en die Kry kartering-aantekening daaraan geheg. En nou het jy reeds 'n metode op localhost wat Hallo wêreld vir jou skryf. Twee reëls kode en dit werk. Lekker dinge.
Lente maak ook die skryf van toetse makliker. Daar is geen manier sonder toetsing in groot ontwikkeling nie. Die kode moet getoets word. Vir hierdie doel het Java 'n koel biblioteek JUnit 5. En JUnit in die algemeen, maar die nuutste weergawe is die vyfde. Daar is alles om te toets, allerhande bewerings en ander dinge.
En daar is 'n wonderlike Mockito-raamwerk. Stel jou voor dat jy een of ander funksionaliteit het wat jy wil toets. Die funksionaliteit doen baie dinge, insluitend, iewers in die middel, meld dit byvoorbeeld by VKontakte aan met jou ID, en ontvang die voor- en achternaam van die VKontakte-gebruiker vanaf die ID. U sal waarskynlik nie VKontakte by die toetse insluit nie, dit is vreemd. Maar jy moet die funksionaliteit toets, so jy het hierdie klas gemaak deur Mockito te gebruik, dit te mok, dit na te boots.
Jy sal sê dat wanneer 'n versoek na hierdie klas kom met 'n ID so en so, dit 'n van terugstuur, byvoorbeeld Vasya Pupkin. En dit sal werk. Dit wil sê, jy sal al die funksionaliteit vir mok een klas toets. Baie cool ding.
Ontwerp patrone. Wat dit is? Dit is sjablone vir die oplossing van tipiese probleme wat tydens ontwikkeling ontstaan. In ontwikkeling ontstaan dikwels identiese of soortgelyke probleme wat dit wonderlik sal wees om op een of ander manier goed op te los. Daarom het mense vorendag gekom met beste praktyke, sekere sjablone, oor hoe om hierdie probleme op te los.
Daar is 'n webwerf met die gewildste patrone - refactoring.guru, jy kan dit lees, uitvind watter patrone daar is, 'n klomp teorie lees. Die probleem is dat dit feitlik nutteloos is. Trouens, patrone sonder oefening is nie besonder nuttig nie.
Jy sal hoor van sommige patrone soos Singletone of Builder. Wie het hierdie woorde gehoor? Baie mense. Daar is sulke eenvoudige patrone wat jy self kan implementeer. Maar die meeste van die patrone: strategie, fabriek, fasade - dit is nie duidelik waar om dit toe te pas nie.
En totdat jy in die praktyk in 'n ander persoon se kode 'n plek sien waarop hierdie patroon toegepas word, sal jy dit nie self kan toepas nie. Daarom is oefening baie belangrik met patrone. En om net oor hulle op refactoring.guru te lees, is nie baie nuttig nie, maar dit is beslis die moeite werd om te doen.
Hoekom is patrone nodig? Kom ons sê jy het 'n sekere gebruikersklas. Dit het 'n ID en 'n Naam. Elke gebruiker moet beide 'n ID en 'n naam hê. Links bo is die klaskamer.
Wat is die maniere om gebruiker te inisialiseer? Daar is twee opsies - óf 'n konstruktor óf 'n opsteller. Wat is die nadele van beide benaderings?
Konstrukteur. nuwe gebruiker (7, "Bond"), goed. Kom ons sê nou dat ons nie 'n gebruikersklas het nie, maar 'n ander een, met sewe numeriese velde. Jy sal 'n konstruktor hê wat sewe opeenvolgende getalle bevat. Dit is nie duidelik wat hierdie getalle is en watter van hulle aan watter eiendom behoort nie. Die ontwerper is nie wonderlik nie.
Die tweede opsie is setter. Jy skryf duidelik: setId(7), setName(“Bond”). Jy verstaan watter eiendom aan watter veld behoort. Maar setter het 'n probleem. Eerstens kan jy vergeet om iets toe te wys, en tweedens blyk jou voorwerp veranderlik te wees. Dit is nie draad veilig nie en verminder die leesbaarheid van die kode effens. Dit is hoekom mense met 'n koel patroon vorendag gekom het - Bouwer.
Waaroor gaan dit? Kom ons probeer om die voordele van beide benaderings - die opsteller en die konstruktor - in een te kombineer. Ons maak 'n sekere objek, Bouer, wat ook Id- en Naam-velde sal hê, wat self gebou sal word op grond van die opsteller, en wat 'n Bou-metode sal hê wat vir jou 'n nuwe Gebruiker met al die parameters gee. Ons kry 'n onveranderlike voorwerp en 'n setter. Koel!
Wat is die probleme? Hier het ons die klassieke bouer. Die probleem is dat ons steeds kan vergeet om in een of ander veld na te gaan. En as ons vergeet het om die ID te besoek, word dit in hierdie geval in Builder na nul geïnisialiseer, want die int-tipe is nie nulbaar nie. En as ons die Naam "Bond" maak en vergeet om die ID-kantoor te besoek, sal ons 'n nuwe Gebruiker hê met id "0" en die naam "Bond". Nie koel nie.
Kom ons probeer dit beveg. In Builder sal ons int na int verander sodat dit nul is. Nou is alles wonderlik.
As ons probeer om 'n gebruiker met die naam "Bond" te skep, en vergeet om sy ID te plaas, sal ons 'n nulwyser-uitsondering kry, want die ID is nie nulbaar nie, en die bouer het 'n nul, spesifiek wyseruitsondering.
Maar ons kan nog steeds vergeet om 'n naam te plaas, so ons stel voorwerpherhaling op nul. Nou, wanneer ons ons voorwerp vanaf Builder bou, kontroleer dit dat die veld nie nulbaar is nie. En dit is nie al nie.
Kom ons kyk na die laaste voorbeeld. In hierdie geval, as ons op een of ander manier nul in die ID-looptyd plaas, sal dit wonderlik wees om dadelik te weet dat jy dit gedoen het en dit is nie cool dat jy nou 'n fout maak nie.
U moet 'n fout gooi nie op die oomblik van die skep van die gebruiker nie, maar wanneer u die ID nul stel. Daarom, in Builder sal ons die setter Integer verander na int, en hy sal dadelik sweer dat hulle nul uitgegooi het.
Kortom, wat is die punt? Daar is 'n eenvoudige Bouer-patroon, maar selfs die implementering daarvan het 'n paar subtiliteite, so dit is baie gaaf om na verskillende implementerings van patrone te kyk. Elke patroon het dosyne implementerings. Dit is alles baie interessant.
Hoe skryf ons Bouwer in produksiekode? Hier is ons gebruiker. Ons heg 'n Bouer-rotasie van die Lombok-biblioteek daaraan, en dit genereer self 'n Bouer vir ons. Dit wil sê, ons skryf geen kode nie, maar Java dink reeds dat hierdie klas 'n bouer het, en ons kan dit so noem.
Ek het al gesê Java het biblioteke vir byna alles, insluitend Lombok, 'n gawe biblioteek wat jou toelaat om te vermy om boilerplate te skryf. Bouer, GET.
Patrone kan argitektonies wees - nie net verband hou met een klas nie, maar met die stelsel as 'n geheel. Daar is so 'n koel beginsel in stelselontwerp: Enkelverantwoordelikheidsbeginsel. Waarvan praat hy? Die feit dat elke klas verantwoordelik moet wees vir sommige van sy eie funksionaliteit. In hierdie geval het ons 'n kontroleerder wat met gebruikers, JSON-voorwerpe kommunikeer. Daar is Facade, wat JSON-voorwerpe omskep in modelle waarmee die Java-toepassing dan sal werk. Daar is 'n diens wat komplekse logika het wat met hierdie modelle werk. Daar is 'n Data Access Object wat hierdie modelle in die databasis plaas en dit van die databasis af haal. En daar is die databasis self. Met ander woorde, dit is nie alles in een klas nie, maar ons maak vyf verskillende klasse, en dit is 'n ander patroon.
Sodra jy Java min of meer geleer het, is dit wonderlik om jou eie projek te skryf wat 'n databasis sal hê, met ander API's sal werk en jou bedienertoepassing aan REST API-kliënte blootstel. Dit sal 'n wonderlike ding wees om by jou CV te voeg, dit sal 'n koel einde aan jou opleiding wees. Hiermee kan jy gaan werk kry.
Hier is 'n voorbeeld van my bedienertoepassing. In my tweede jaar het ek 'n kwartaalvraestel saam met die ouens geskryf. Hulle was besig om 'n mobiele toepassing te skryf om geleenthede te organiseer. Daar kon gebruikers via VKontakte aanmeld, punte op die kaart plaas, gebeurtenisse skep, hul vriende na hulle nooi, beelde van gebeurtenisse stoor, ens.
Wat het ek in die projek gedoen? Het 'n bedienertoepassing in Spring Boot geskryf sonder om SQL te gebruik. Ek het hom nie geken nie, ek het JPA gebruik. Wat kon dit doen? Meld aan by VK via OAuth-2. Neem die gebruiker se teken, gaan daarmee na VK, kyk of dit 'n regte gebruiker is. Ontvang inligting oor gebruikers deur VKontakte. Dit kon inligting in 'n databasis stoor, ook via JPA. Stoor prente en ander lêers vaardig in rekenaargeheue, en stoor skakels daarna in die databasis. Op daardie tydstip het ek nie geweet dat daar CLOB-voorwerpe in die databasis was nie, so ek het dit so gedoen. Daar was 'n REST API vir gebruikers, kliënttoepassings. En daar was eenheidstoetse vir basiese funksionaliteit.
[…] 'n Klein voorbeeld van my suksesvolle leer van Java. In my eerste jaar op universiteit is ek C# geleer en 'n begrip van OOP-programmering gekry - wat klasse, koppelvlakke, abstraksie is, en hoekom dit nodig is. Dit het my baie gehelp. Sonder dit is dit baie moeilik om Java te leer; dit is nie duidelik waarom klasse nodig is nie.
In my tweede jaar by die universiteit het hulle weer Java core geleer, maar ek het nie daar gestop nie, ek het self Lente gaan studeer en 'n kursusvraestel geskryf, my projek, wat ek hierbo genoem het. En met dit alles het ek vir 'n internskap by Yandex gegaan, 'n onderhoud geslaag en by Yandex.Market ingekom. Daar het ek die backend vir Beru geskryf, dit is ons markplek, en vir Yandex.Market self.
Daarna het ek ses maande gelede na 'n ander span binne dieselfde Mark oorgeplaas. Ons doen ontledings vir sakevennote. Ons is in die analitiese platform, daar is drie van ons op die agterkant, so ek het 'n baie groot deel van die invloed op die projek. Dit is eintlik baie interessant. Dit wil sê, ons verskaf eintlik data oor die mark - wat verkope is, in watter kategorieë, in watter modelle, vir sakevennote, groot bekende maatskappye. En daar is net drie van ons, ons skryf hierdie kode, en dit is baie cool.
Dankie! Nuttige skakels:
- .
- .
- .
- .
- .
- .
- .
- .
Bron: will.com