Hvorfor lære Java og hvordan du gjør det effektivt. Yandex-rapport

Hvordan er Java sammenlignet med andre populære språk? Hvorfor bør Java være det første språket du bør lære? La oss lage en plan som hjelper deg med å lære Java både fra bunnen av og ved å bruke programmeringsferdigheter på andre språk. Vi vil også fremheve forskjellene mellom å lage produksjonskode i Java og å utvikle på andre språk. Mikhail Zatepyakin holdt dette foredraget på et møte for fremtidige deltakere. praksisplasser Yandex og andre håpefulle utviklere – Java Junior-møte.

Hei alle sammen, jeg heter Misha. Jeg er utvikler hos Yandex.Market, og i dag skal jeg fortelle deg hvorfor du bør lære Java og hvordan du gjør det effektivt. Du lurer kanskje på hvorfor jeg skulle fortelle deg dette i stedet for en erfaren utvikler med mange års erfaring? Saken er at jeg lærte Java nylig, for omtrent halvannet år siden, så jeg husker fortsatt hvordan det var og fallgruvene.

For et år siden fikk jeg et internship hos Yandex.Market. Jeg utviklet backend-plattformen for Beru, for selve markedet – du har sikkert brukt den. Jeg jobber fortsatt der nå, i et annet team. Vi bygger Yandex.Markets analyseplattform for forretningspartnere.

La oss komme i gang. Hvorfor lære Java fra et praktisk synspunkt? Faktum er at Java er et veldig kjent programmeringsspråk. Det har et veldig stort fellesskap.

For eksempel finnes det TIOBE-indeksen, en populær indeks over programmeringsspråks popularitet, og Java rangerer først. På jobbsider vil du sannsynligvis også legge merke til at de fleste stillingsutlysningene er i Java, noe som betyr at du alltid vil kunne finne en jobb med utvikling i Java.

Siden fellesskapet er så stort, finner du svar på alle spørsmål du måtte ha på Stack Overflow eller andre nettsteder. Når du utvikler i Java, skriver du faktisk kode på JVM, slik at du enkelt kan gå over til Kotlin, Scala og andre språk som bruker JVM.

Hva er så bra med Java fra et ideologisk perspektiv? Det finnes forskjellige programmeringsspråk. De løser forskjellige problemer, som du vet. For eksempel er Python flott for å skrive enlinjeskript for å løse raske oppgaver.

Du kan kontrollere den kjørbare koden fullt ut ved å bruke "+"-tasten. For eksempel har vi biler, Yandex sine selvkjørende biler, og koden deres er skrevet med "+"-tasten. Hvorfor? Java har en ting som heter Garbage Collector. Den tømmer RAM for unødvendige objekter. Denne tingen kjører spontant og utfører en "stopp-verden"-operasjon, som betyr at den stopper resten av programmet og begynner å telle objekter, og tømmer minnet for objekter. Hvis denne tingen skulle kjøre i en selvkjørende bil, ville det være en stor sak. Din selvkjørende bil ville kjøre rett frem, tømme minnet og ikke følge med på veien i det hele tatt. Det er derfor den selvkjørende bilen er skrevet med "+"-tasten.

Hvilke problemer løser Java? Det er først og fremst et språk for å utvikle store programmer som tar år å skrive, utviklet av dusinvis eller hundrevis av mennesker. Spesielt mye av backend-systemet hos Yandex.Market er skrevet i Java. Vi har et distribuert team på tvers av flere byer, ti personer i hver. Og koden er enkel å vedlikeholde; den har blitt vedlikeholdt i ti år eller mer, og nye folk kommer stadig inn og forstår den.

Hvilke egenskaper bør et språk ha for å gjøre kode lett vedlikeholdbar og enkel å utvikle i store team? Først og fremst bør det være lesbart, og det bør være enkelt å implementere komplekse arkitekturløsninger. Det vil si at det bør være enkelt å skrive abstraksjoner på høyt nivå og så videre. Java tilbyr alt dette. Det er et objektorientert språk. Det er virkelig enkelt å implementere abstraksjoner på høyt nivå og komplekse arkitekturer.

Det finnes også mange rammeverk og biblioteker for Java fordi språket er over 15 år gammelt. I løpet av den tiden har alt som kunne skrives blitt skrevet i det, så det finnes tonnevis av biblioteker for alt du måtte trenge.

Hva er de viktigste ferdighetene, etter min mening, som en spirende Java-utvikler bør ha? Først og fremst kunnskap om kjernespråket Java. Deretter kommer et slags Dependency Injection-rammeverk. Den neste taleren, Kirill, vil dekke dette mer detaljert. Jeg vil ikke gå for mye inn på detaljer. Deretter kommer arkitektur og designmønstre. Vi må kunne skrive arkitektonisk vakker kode for å bygge store applikasjoner. Og så er det en slags SQL eller ORM for databaseoppgaver. Og dette gjelder mer for backend.

La oss komme i gang! Java-kjernen. Jeg skal ikke avsløre mye her – du må kunne selve språket. Her er hva som er verdt å være oppmerksom på. For det første har Java gitt ut mange versjoner de siste årene. Det vil si at i 2014–2015 ble versjon 7 utgitt, deretter 8, 9, 10 – mange nye versjoner, og de introduserte mange kule nye funksjoner, som Java Stream API, lambdaer og så videre. Dette er virkelig kule, nye funksjoner som brukes i produksjonskode, blir spurt om i intervjuer, og som er viktige å vite. Så ikke bare ta en bok fra Java 4-bibliotekhyllen og begynn å lære den. Her er planen: lær Java 8 eller høyere.

Vi følger nøye med på nye funksjoner som Stream API, var og så videre. De blir spurt om i intervjuer og brukes stadig i produksjon. Stream API er mye kraftigere enn looper; det er en skikkelig kul funksjon. Sørg for å følge med.

Og så finnes det alle slags ting som iteratorer, unntak og så videre. Ting som virker uviktige for deg når du skriver litt liten kode selv. Du trenger ikke disse unntakene – hvem trenger dem uansett? Men de vil definitivt bli spurt om i intervjuer, og de vil definitivt komme godt med i produksjon. Alt i alt er det verdt å være oppmerksom på unntak, iteratorer og andre ting.

Datastrukturer. Strukturer er viktige, og det er nyttig å vite mer enn bare eksistensen av sett, ordbøker og ark. Du må også kjenne til de ulike implementeringene av strukturer. Java har for eksempel mange implementeringer av ordbøker, inkludert HashMap og TreeMap. De har ulik asymptotisk oppførsel og er strukturert forskjellig internt. Du må vite forskjellene og når du skal bruke hver av dem.

Det hadde også vært flott om du visste hvordan disse datastrukturene fungerer internt. Det vil si at du ikke bare kjenner til deres asymptotiske oppførsel – hvor lang tid et spill tar, hvor lang tid et pass tar – men hvordan strukturen fungerer internt – for eksempel hva en bøtte er i en HashMap.

Trær og grafer er også verdt å være oppmerksom på. Disse er ikke veldig vanlige i produksjonskode, men de er en favoritt i intervjuer. Derfor må du kunne bevege deg gjennom trær og grafer med bredde først og dybde først. Dette er alle enkle algoritmer.

Så snart du begynner å skrive stor, kompleks, bibliotekbasert kode med flere klasser, vil du innse at du sliter uten byggesystemer og avhengighetsløsning. Disse er primært Maven og Gradle. De lar deg importere biblioteker til prosjektet ditt på én linje. Det vil si at du skriver en XML-fil på én linje og importerer bibliotekene til prosjektet. De er utmerkede systemer. De er omtrent like; bruk enten Maven eller Gradle.

Deretter, litt versjonskontrollsystem. Jeg anbefaler Git fordi det er populært og det finnes massevis av veiledninger. Nesten alle bruker Git; det er en kul ting, du kan ikke klare deg uten det.

Og et slags utviklingsmiljø. Jeg anbefaler IntelliJ IDEA. Det øker hastigheten på utviklingsprosessen, hjelper deg mye, skriver all standardkoden for deg, og alt i alt er det fantastisk.

Lenker fra lysbildet: SQLZOO, habrapost

SQL. Litt om backend-utviklere. Det var faktisk en morsom historie her. To dager før mitt andre internship-intervju ringte HR-jenta meg og fortalte at jeg ville bli spurt om SQL og HTTP om to dager, og at jeg måtte lære det. Jeg visste praktisk talt ingenting om SQL eller HTTP. Så fant jeg denne kule nettsiden— SQLZOOJeg lærte SQL på omtrent 12 timer, altså SQL-syntaks, hvordan man skriver SELECT-spørringer, JOIN-er og så videre. Det er en skikkelig kul nettside, jeg anbefaler den på det sterkeste. Jeg lærte bokstavelig talt 90 % av det jeg kan nå på 12 timer.

Og det er også flott å kunne databasearkitektur. Det inkluderer nøkler, indekser og normalisering. Det finnes en serie innlegg om det på Habr.

I tillegg til SQL har Java diverse objektrelasjonelle kartleggingssystemer som JPA. Det finnes noe kode. I den første metoden finnes det noe SQL-kode: SELECT id name FROM info.users WHERE id IN userIds. Fra brukerdatabasen, fra tabellen, henter vi ID-ene og navnene deres.

Deretter er det en mapper som konverterer databaseobjektet til et Java-objekt. Og under det er det en tredje metode som faktisk kjører denne koden. Ved hjelp av JPA kan alt dette erstattes med den enkle linjen nedenfor. Den gjør det samme: finner All ByIdIn. Det vil si at den genererer en SQL-spørring for deg basert på metodenavnet.

Det er skikkelig kult. Jeg brukte JPA da jeg ikke kunne SQL. Så følg med. Hvis du er for lat til å lære SQL, er dette fantastisk. Og virkelig, fantastisk!

Spring. Hvem har hørt om noe slikt som Spring-rammeverket? Ser du hvor mange av dere det er? Det er ingen tilfeldighet. Spring er oppført i kravene til alle andre Java backend-stillingsutlysninger. Det er virkelig essensielt i storskala utvikling. Hva er Spring? Først og fremst er det et Dependency Injection-rammeverk. Det er også et tema. vil fortelle Neste taler. Men kort sagt, det er en ting som lar deg forenkle import av avhengigheter fra én klasse til en annen. Med andre ord, det forenkler kunnskapen om avhengigheter.

Spring Boot er en del av Spring som lar deg starte serverapplikasjonen din med et enkelt klikk. Du går til THID, klikker på et par knapper, og vips, serverapplikasjonen din er oppe og kjører på localhost 8080. Så du har ikke engang skrevet en linje med kode ennå, og den kjører allerede. Det er en veldig kul funksjon. Hvis du skriver din egen, er det fantastisk!

Spring er et veldig stort rammeverk. Det setter ikke bare opp en serverapplikasjon og løser avhengighetsinjeksjon. Det lar deg gjøre en hel haug med ting, inkludert å lage REST API-metoder. Så du skriver en metode, legger til Get mapping-annotasjonen i den, og så har du en metode på localhost som sier "Hello, World". To linjer med kode, og det fungerer. Ganske kult.

Spring forenkler også skriving av tester. Testing er viktig i storskala utvikling. Kode må testes. Java har et flott bibliotek for dette kalt JUnit 5. Og JUnit generelt, men den nyeste versjonen er versjon 5. Den har alt du trenger for testing, inkludert assersjoner og andre ting.

Og det finnes et fantastisk rammeverk som heter Mockito. Tenk deg at du har en funksjonalitet du vil teste. Funksjonaliteten gjør mange ting, inkludert å logge inn på VKontakte med for eksempel ID-en din, og hente brukerens for- og etternavn fra ID-en. Du vil sannsynligvis ikke logge inn på VKontakte i testene dine; det er rart. Men du må teste funksjonaliteten, så du simulerte denne klassen ved hjelp av Mockito.

Du vil si at når en forespørsel med ID-en «slik og slik» kommer inn i denne klassen, returnerer den et etternavn, som «Vasya Pupkin». Og det vil fungere. Så du vil teste all funksjonaliteten ved hjelp av én enkelt simulert klasse. En veldig kul ting.

Link fra lysbilde

Designmønstre. Hva er det? De er maler for å løse vanlige problemer som oppstår i utvikling. I utvikling møter vi ofte de samme eller lignende oppgavene som det ville vært flott å løse. Så folk har kommet opp med beste praksis, maler for å løse disse problemene.

Det finnes en nettside med de mest populære mønstrene – refactoring.guru. Du kan lese den, lære om de forskjellige mønstrene og lese massevis av teori. Problemet er at den er praktisk talt ubrukelig. Faktisk er ikke mønstre uten øvelse spesielt nyttige.

Du vil høre om mønstre som Singletone eller Builder. Hvem har hørt de ordene? Mange mennesker. Det finnes enkle mønstre som det som du kan implementere selv. Men de fleste mønstre – strategi, fabrikk, fasade – har ingen klar anvendelse.

Før du ser dette mønsteret brukt i andres kode, vil du ikke kunne bruke det selv. Derfor er det så viktig å øve med mønstre. Bare det å lese om dem på refactoring.guru er ikke så nyttig, men det er helt nødvendig.

Hvorfor trenger vi mønstre? La oss si at du har en klasse som heter Bruker. Den har en ID og et navn. Hver bruker må ha både en ID og et navn. Klassen er øverst til venstre.

Hvordan kan man initialisere en bruker? Det finnes to alternativer: en konstruktør eller en setter. Hva er ulempene med begge tilnærmingene?

Constructor.new User(7, "Bond"), ok. La oss nå si at vi ikke har en User-klasse, men noe annet, med syv numeriske felt. Du vil ha en konstruktør med syv påfølgende tall. Det er uklart hva disse tallene er, eller hvilket som tilsvarer hvilken egenskap. En konstruktør er ikke god nok.

Det andre alternativet er en setter. Du skriver tydelig: setId(7), setName("Bond") . Du forstår hvilken egenskap som tilsvarer hvilket felt. Men settere har et problem. For det første kan du glemme å sette noe, og for det andre blir objektet ditt muterbart. Dette er ikke trådsikkert og reduserer lesbarheten til koden litt. Så folk kom opp med et kult mønster – Builder.

Hva handler alt dette om? Vi skal prøve å kombinere fordelene med begge tilnærmingene – setter og konstruktør – til én. Vi skal opprette et objekt, en Builder, som også vil ha feltene Id og Name, som i seg selv vil bli bygget basert på setteren, og som vil ha en Build-metode som returnerer en ny bruker med alle parameterne. Vi vil ende opp med et uforanderlig objekt og en setter. Kult!

Hva er problemene? Her har vi en klassisk Builder. Problemet er at vi fortsatt kan glemme å få tilgang til et felt. Og hvis vi glemmer å få tilgang til ID-en, i dette tilfellet, initialiseres den til null i Builder fordi int-typen ikke kan nullstilles. Og hvis vi lager navnet "Bond" og glemmer å få tilgang til ID-en, vil vi ha en ny bruker med ID-en "0" og navnet "Bond". Ikke kult.

La oss prøve å bekjempe dette. I Builder endrer vi int til int slik at den kan nullstilles. Nå er alt i orden.

Hvis vi prøver å opprette en bruker med navnet «Bond» uten å spesifisere en ID, får vi et nullpekerunntak fordi ID-en ikke kan settes til null, og Builder er null, nærmere bestemt et pekerunntak.

Men vi kan fortsatt glemme å sette navnet, så vi setter objektreplayet til null. Når vi nå konstruerer objektet vårt fra Builder, sjekker den at feltet ikke kan nullstilles. Og det er ikke alt.

La oss se på det siste eksemplet. I dette tilfellet, hvis vi på en eller annen måte setter null i ID-kjøretiden, ville det være fint å vite med en gang at du gjorde det, og det er ikke kult at du nå gjør en feil.

Du må ikke gi en feilmelding når du oppretter brukeren, men når du setter ID-en til null. Så i Builder endrer vi setteren fra Integer til int, og den vil umiddelbart klage om å sette en null.

Så, hva er poenget? Det finnes et veldig enkelt Builder-mønster, men selv implementeringen har sine egne finesser, så det er veldig kult å se på forskjellige mønsterimplementeringer. Hvert mønster har dusinvis av implementeringer. Det er veldig interessant.

Hvordan skriver vi en Builder i produksjonskode? Her er vår User. Vi legger til en Builder-rotasjon fra Lombok-biblioteket til den, og den genererer automatisk en Builder for oss. Så vi skriver ikke noe kode, men Java antar allerede at denne klassen har en Builder, og vi kan kalle den slik.

Jeg har allerede nevnt at Java har biblioteker for nesten alt, inkludert Lombok, et kult bibliotek som lar deg unngå å skrive en standardtekst. Builder, GET.

Det finnes arkitektoniske mønstre – mønstre som ikke bare gjelder for en enkelt klasse, men for systemet som helhet. Det finnes et kult prinsipp innen systemdesign: prinsippet om enkeltansvar. Hva betyr det? Det sier at hver klasse skal være ansvarlig for sin egen funksjonalitet. I dette tilfellet har vi en kontroller som kommuniserer med brukere og JSON-objekter. Det finnes en fasade som konverterer JSON-objekter til modeller, som Java-applikasjonen deretter vil jobbe med. Det finnes en tjeneste som inneholder kompleks logikk som fungerer med disse modellene. Det finnes et datatilgangsobjekt som lagrer disse modellene i og henter dem fra databasen. Og så er det selve databasen. Med andre ord, ikke alt dette er i én klasse; vi lager fem forskjellige klasser, som er et annet mønster.

Når du mer eller mindre har mestret Java, er det flott å skrive ditt eget prosjekt som inkluderer en database, samhandler med andre API-er og leverer serverapplikasjonen din til REST API-klienter. Dette ville være et flott tillegg til CV-en din; det er en kul måte å avrunde læringen din på. Med dette kan du gå og få deg en jobb.

Her er et eksempel på serverapplikasjonen min. I mitt andre år skrev jeg en semesteroppgave med en gruppe studenter. De bygde en mobilapp for å organisere arrangementer. Brukere kunne logge inn via VKontakte, plassere punkter på kartet, opprette arrangementer, invitere vennene sine, lagre arrangementsbilder og så videre.

Hva gjorde jeg i prosjektet? Jeg skrev en serverapplikasjon i Spring Boot, uten å bruke SQL. Jeg visste ikke om det, så jeg brukte JPA. Hva kunne den gjøre? Logge inn på VK via OAuth-2. Ta brukerens token, bruk den til å logge inn på VK, og bekreft at det er en ekte bruker. Hent brukerinformasjon via VKontakte. Den kunne lagre informasjon i databasen, også ved hjelp av JPA. Den kunne lagre bilder og andre filer i datamaskinens minne og lagre lenker til dem i databasen. Jeg visste ikke om CLOB-objekter i databasen den gangen, så jeg gjorde det på den måten. Det fantes et REST API for brukere og klientapplikasjoner. Og det fantes enhetstester for hovedfunksjonaliteten.

[…] Et kort eksempel på min vellykkede Java-læring. I mitt første år på universitetet lærte jeg C# og om OOP-programmering – hva klasser, grensesnitt og abstraksjoner er, og hvorfor de er nødvendige. Dette hjalp meg virkelig. Uten dette er det ganske vanskelig å lære Java; det er uklart hvorfor klasser er nødvendige.

I mitt andre år på universitetet lærte de meg Java Core igjen, men jeg stoppet ikke der. Jeg fortsatte med å lære Spring selv og skrev en semesteroppgave, mitt eget prosjekt, som jeg nevnte ovenfor. Og med alt dette i tankene fikk jeg et internship hos Yandex, bestod intervjuet og ble ansatt hos Yandex.Market. Der skrev jeg backend-delen for Beru, markedsplassen vår, og for selve Yandex.Market.

Etter det, for seks måneder siden, gikk jeg over til et annet team i samme marked. Vi driver med analyser for forretningspartnere. Vi er på analyseplattformen, og vi er tre på backend-plattformen, så jeg har stor innflytelse på prosjektet. Det er veldig interessant. Vi leverer faktisk markedsdata – salgstrender, i hvilke kategorier, for hvilke modeller – for forretningspartnere, store, kjente selskaper. Og det er bare tre av oss som skriver denne koden, og det er veldig kult.

Takk! Nyttige lenker:
- Java 8: En nybegynnerguide.
- Datastrukturer.
- SQLZOO.
- Databasenormalisering.
- Designmønstre.
- Design mønstre.
- Ren kode.
- Effektiv Java.

Kilde: www.habr.com