Hvordan er Java forskjellig fra andre populære språk? Hvorfor skal Java være det første språket å lære? La oss lage en plan som vil hjelpe deg å lære Java både fra bunnen av og ved å bruke programmeringsferdigheter på andre språk. La oss liste opp forskjellene mellom å lage produksjonskode i Java og å utvikle på andre språk. Mikhail Zatepyakin leste denne rapporten på et møte for fremtidige deltakere Yandex og andre begynnende utviklere - Java Junior meetup.
— Hei alle sammen, jeg heter Misha. Jeg er en utvikler fra Yandex.Market, og i dag vil jeg fortelle deg hvorfor du skal lære Java og hvordan du gjør det effektivt. Du kan stille et rimelig spørsmål: hvorfor skal jeg fortelle denne historien, og ikke en sterk utvikler med mange års erfaring? Faktum er at jeg selv studerte Java nylig, for omtrent et og et halvt år siden, så jeg husker fortsatt hvordan det var og hvilke fallgruver det er.
For et år siden fikk jeg praksisplass hos Yandex.Market. Jeg utviklet backend for Beru, for selve markedet, du har sikkert brukt det. Nå fortsetter jeg å jobbe der, i et annet team. Vi lager en analytisk plattform for Yandex.Market 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. Den har et veldig stort fellesskap.
For eksempel er det en slik TIOBE-indeks, en populær indeks over programmeringsspråkens popularitet, og Java rangerer først der. Også på jobbsider vil du sannsynligvis legge merke til at de fleste ledige stillingene handler om Java, det vil si at ved å utvikle i Java kan du alltid finne en jobb.
Siden fellesskapet er veldig stort, vil alle spørsmål du har, finne svar på noen Stack Overflow eller andre nettsteder. Når du utvikler i Java, skriver du faktisk kode på JVM, slik at du enkelt kan bytte til Kotlin, Scala og andre språk som bruker JVM.
Hva er bra med Java fra et ideologisk synspunkt? Det finnes forskjellige programmeringsspråk. De løser forskjellige problemer, det vet du. For eksempel er Python ypperlig for å skrive én-linjes skript for å løse raske problemer.
På plussiden kan du kontrollere den kjørbare koden fullt ut. For eksempel har vi biler, Yandex førerløse biler, koden deres er skrevet med plusser. Hvorfor? Java har en slik ting - Garbage Collector. Den sletter RAM for unødvendige gjenstander. Denne tingen starter spontant og stopper-verden, det vil si at den stopper resten av programmet og går til å telle objekter, fjerne hukommelsen til objekter. Hvis noe slikt fungerer i en drone, er det ikke kult. Dronen din vil kjøre rett, i dette øyeblikk fjerne hukommelsen og ikke se på veien i det hele tatt. Derfor er dronen skrevet på proffene.
Hvilke problemer løser Java? Det er først og fremst et språk for å utvikle store programmer som er skrevet over år, av dusinvis eller hundrevis av mennesker. Spesielt mye av backend i Yandex.Market er skrevet i Java. Vi har et distribuert team i flere byer, ti personer i hver. Og koden er enkel å vedlikeholde, den har vært støttet i ti år eller mer, og samtidig kommer nye folk inn og forstår denne koden.
Hvilke egenskaper bør et språk ha slik at koden i det lett støttes og slik at det enkelt kan utvikles i store team. Først av alt skal det være lesbar kode, og det skal være enkelt å implementere komplekse arkitektoniske løsninger. Det vil si at det skal være enkelt å skrive abstraksjoner på høyt nivå osv. Alt dette er hva Java gir oss. Dette er et objektorientert språk. Det er veldig enkelt å implementere abstraksjoner på høyt nivå og komplekse arkitekturer.
Det finnes også mange rammeverk og biblioteker for Java, fordi språket er mer enn 15 år gammelt. I løpet av denne tiden ble alt som kunne skrives skrevet på den, så det er tonnevis med biblioteker for alt du måtte trenge.
Hvilke grunnleggende ferdigheter, etter min mening, bør en begynnende JA-spiller ha? For det første er dette kunnskap om kjernespråket Java. Neste er en slags avhengighetsinjeksjonsramme. Den neste foredragsholderen, Kirill, vil snakke mer om dette. Jeg vil ikke gå for dypt. Neste er arkitekturen og designmønstrene. Vi må kunne skrive arkitektonisk vakker kode for å kunne skrive store applikasjoner. Og dette er en slags SQL eller ORM for oppgaver med å jobbe med databasen. Og dette gjelder mer for backend.
Gå! Java kjerne. Jeg vil egentlig ikke oppdage Amerika her - du må kunne språket i seg selv. Hva du bør 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 den syvende utgitt, deretter den åttende, niende, tiende, mange nye versjoner, og mange nye kule ting ble introdusert i dem , for eksempel Java Stream API , lambda osv. Veldig kule, friske, kule ting som brukes i produksjonskode, hva de spør om i intervjuer og som du trenger å vite. Derfor bør du ikke ta en bok fra hyllen i Java-4-biblioteket og lære den. Dette er planen vår: vi lærer Java-8 eller høyere.
Vi følger nøye med på innovasjoner som Stream API, var osv. De blir spurt under intervjuer og blir stadig brukt i produksjonen. Det vil si at Stream API er mye kulere enn loops, generelt sett en veldig kul ting. Pass på å være oppmerksom.
Og det er alle slags ting som iteratorer, unntak og så videre. Ting som virker uviktige for deg så lenge du skriver en liten kode selv. Du trenger ikke disse unntakene, hvem trenger dem likevel? Men de vil definitivt bli spurt på intervjuer, de vil definitivt være nyttige for deg i produksjonen. Generelt bør du være oppmerksom på unntak, iteratorer og andre ting.
Datastrukturer. Du kan ikke gå uten strukturer, men det vil være flott hvis du ikke bare vet at det er sett, ordbøker og ark. Og også ulike implementeringer av strukturer. For eksempel har den samme ordboken i Java mange implementeringer, inkludert HashMap og TreeMap. De har forskjellige asymptoter, de er strukturert annerledes innvendig. Du må vite hvordan de er forskjellige og når du skal bruke hvilken.
Det vil også være veldig kult om du vet hvordan disse datastrukturene fungerer internt. Det vil si at det ikke er lett å vite deres asymptotikk - hvor mye innsatsen fungerer, hvor lenge passet fungerer, men hvordan strukturen fungerer inne - for eksempel hva er en bøtte i HashMap.
Det er også verdt å ta hensyn til trær og grafer. Dette er ting som ikke er veldig vanlig i produksjonskode, men de er populære i intervjuer. Følgelig må du kunne krysse trær, grafer i bredde og dybde. Disse er alle enkle algoritmer.
Så snart du begynner å skrive stor kode, kompleks, ved hjelp av biblioteker, multi-klasse kode, vil du innse at det er vanskelig for deg uten å bygge systemer og løse avhengigheter. Disse er først og fremst Maven og Gradle. De lar deg importere biblioteker til prosjektet ditt på én linje. Det vil si at du skriver en enlinjes xml og importerer biblioteker inn i prosjektet. Flotte systemer. De er omtrent like, bruk enten en - Maven eller Gradle.
Neste - et slags versjonskontrollsystem. Jeg anbefaler Git fordi det er populært og det er tonnevis av opplæringsprogrammer. Nesten alle bruker Git, det er en kul ting, du kan ikke leve uten det.
Og et slags utviklingsmiljø. Jeg anbefaler IntelliJ Idea. Det øker hastigheten på utviklingsprosessen, hjelper deg mye, skriver all koden for deg, generelt sett er det kult.
Lenker fra lysbildet: ,
SQL. Litt om backenders. Det var faktisk en morsom sak her. To dager før mitt andre praksisintervju ringte en HR-jente meg og sa at om to dager skulle de spørre meg om SQL og HTTP, jeg trengte å lære det. Og jeg visste nesten ingenting om SQL eller HTTP. Og jeg fant denne kule siden - . Jeg lærte SQL på det på 12 timer, altså SQL-syntaks, hvordan skrive SELECT-spørringer, JOIN, osv. Veldig kult nettsted, jeg anbefaler det på det sterkeste. Faktisk, på 12 timer lærte jeg 90% av det jeg vet nå.
Og det er også flott å kjenne til databasearkitektur. Dette er alle slags nøkler, indekser, normalisering. Det er en rekke innlegg om dette på Habré.
I Java, i tillegg til SQL, er det alle slags objektrelasjonelle kartleggingssystemer som JPA. Det er noe kode. I den første metoden er det litt SQL-kode - VELG id-navn FRA info.users WHERE id IN userIds. Fra brukerdatabasen, fra tabellen, hentes deres IDer og navn.
Deretter er det en bestemt kartlegger som gjør et objekt fra basen til et Java-objekt. Og det er en tredje metode nedenfor som faktisk utfører denne koden. Alt dette kan erstattes ved hjelp av JPA med én linje, som er skrevet nedenfor. Den gjør det samme - finn All ByIdIn. Det vil si at basert på navnet på metoden genererer den en SQL-spørring for deg.
Veldig kul ting. Jeg selv, da jeg ikke kunne SQL, brukte JPA. Generelt, vær oppmerksom. Hvis du er for lat til å lære deg SQL, er det en katastrofe. Og generelt brann!
Vår. Hvem har hørt om noe slikt som Spring-rammeverket? Ser du hvor mange av dere er? Ikke uten grunn. Spring er inkludert i kravene til annenhver Java-backend-stilling. Uten det er det egentlig ingen steder i en stor utvikling. Hva er våren? Først av alt er dette et rammeverk for avhengighetsinjeksjon. Om dette også neste taler. Men kort fortalt er dette en ting som lar deg gjøre det enklere å importere avhengighetene til noen klasser til andre. Det vil si at kunnskap om avhengigheter forenkles.
Spring Boot er et stykke Spring som lar deg kjøre serverapplikasjonen din med én knapp. Du går til THID, trykker på et par knapper, og nå har du serverapplikasjonen din oppe og kjører på localhost 8080. Det vil si at du ikke har skrevet en eneste linje med kode ennå, men det fungerer allerede. Veldig kul ting. Hvis du skriver noe eget, fyr!
Våren er en veldig stor ramme. Det plukker ikke bare opp serverapplikasjonen din og løser Dependency Injection. Det lar deg gjøre en haug med ting, inkludert å lage REST API-metoder. Det vil si at du skrev en metode og la ved Get mapping-kommentaren til den. Og nå har du allerede en metode på localhost som skriver Hello world til deg. To linjer med kode og det fungerer. Kule ting.
Våren gjør det også lettere å skrive tester. Det er ingen vei uten å teste i stor utvikling. Koden må testes. For dette formålet har Java et kult bibliotek JUnit 5. Og JUnit generelt, men den nyeste versjonen er den femte. Det er alt for testing, alle mulige påstander og andre ting.
Og det er et fantastisk Mockito-rammeverk. Tenk deg at du har en funksjonalitet du vil teste. Funksjonaliteten gjør mange ting, inkludert, et sted i midten, logger den for eksempel på VKontakte med ID-en din, og mottar for- og etternavnet til VKontakte-brukeren fra ID-en. Du vil sannsynligvis ikke inkludere VKontakte i testene, det er rart. Men du må teste funksjonaliteten, så du laget denne klassen ved å bruke Mockito, mok it, imiter den.
Du vil si at når en forespørsel kommer til denne klassen med en ID slik og slik, returnerer den et eller annet etternavn, for eksempel Vasya Pupkin. Og det vil fungere. Det vil si at du vil teste all funksjonalitet for mok one class. Veldig kul ting.
Design mønstre. Hva det er? Dette er maler for å løse typiske problemer som oppstår i utviklingen. I utviklingen oppstår ofte identiske eller lignende problemer som det ville vært fint å løse på en eller annen måte godt. Derfor kom folk opp med beste praksis, visse maler, for hvordan de skulle løse disse problemene.
Det er en nettside med de mest populære mønstrene - refactoring.guru, du kan lese den, finne ut hvilke mønstre det er, lese en haug med teorier. Problemet er at det er praktisk talt ubrukelig. Faktisk er mønstre uten praksis ikke spesielt nyttige.
Du vil høre om noen mønstre som Singletone eller Builder. Hvem hørte disse ordene? Mange folk. Det er så enkle mønstre som du kan implementere selv. Men de fleste av mønstrene: strategi, fabrikk, fasade - det er ikke klart hvor de skal brukes.
Og før du i praksis ser i en annen persons kode et sted som dette mønsteret brukes på, vil du ikke kunne bruke det selv. Derfor er øvelse veldig viktig med mønstre. Og bare å lese om dem på refactoring.guru er ikke veldig nyttig, men det er definitivt verdt å gjøre.
Hvorfor trengs mønstre? La oss si at du har en viss brukerklasse. Den har en ID og et navn. Hver bruker må ha både en ID og et navn. Øverst til venstre er klasserommet.
Hva er måtene å initialisere bruker på? Det er to alternativer - enten en konstruktør eller en setter. Hva er ulempene med begge tilnærmingene?
Konstruktør. ny bruker (7, "Bond"), ok. La oss nå si at vi ikke har en brukerklasse, men en annen, med syv numeriske felt. Du vil ha en konstruktør som inneholder syv påfølgende tall. Det er ikke klart hva disse tallene er og hvilke av dem som tilhører hvilken eiendom. Designeren er ikke stor.
Det andre alternativet er setter. Du skriver tydelig: setId(7), setName(“Bond”). Du forstår hvilken eiendom som tilhører hvilket felt. Men setter har et problem. For det første kan du glemme å tildele noe, og for det andre viser objektet ditt seg å være foranderlig. Dette er ikke trådsikkert og reduserer kodens lesbarhet noe. Derfor kom folk opp med et kult mønster – Byggmester.
Hva handler dette om? La oss prøve å kombinere fordelene med begge tilnærmingene – setter og konstruktør – i en. Vi lager et bestemt objekt, Builder, som også vil ha Id- og Name-felt, som i seg selv skal bygges basert på setteren, og som vil ha en Build-metode som gir deg en ny bruker med alle parameterne. Vi får en uforanderlig gjenstand og en setter. Kul!
Hva er problemene? Her har vi den klassiske Builder. Problemet er at vi fortsatt kan glemme å sjekke inn et felt. Og hvis vi glemte å besøke ID-en, i dette tilfellet initialiseres den til null i Builder, fordi int-typen ikke er nullbar. Og hvis vi lager navnet "Bond" og glemmer å besøke ID-kontoret, vil vi ha en ny bruker med id "0" og navnet "Bond". Ikke kult.
La oss prøve å bekjempe dette. I Builder vil vi endre int til int slik at den er nullbar. Nå er alt flott.
Hvis vi prøver å opprette en bruker med navnet "Bond", og glemmer å angi ID-en hans, vil vi få et null-pekerunntak, fordi ID-en ikke er nullbar, og Byggeren har et null, spesielt pekerunntak.
Men vi kan fortsatt glemme å sette et navn, så vi satte objektreplay til null. Nå, når vi bygger objektet vårt fra Builder, sjekker det at feltet ikke er nullbart. 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øringstiden, ville det være flott å umiddelbart vite at du gjorde det, og det er ikke kult at du gjør en feil nå.
Du må sende en feil ikke i øyeblikket av brukeropprettelse, men når du setter null til ID-en. Derfor vil vi i Builder endre setteren Integer til int, og han vil umiddelbart sverge at de kastet ut null.
Kort sagt, hva er poenget? Det er et enkelt Builder-mønster, men selv implementeringen har noen finesser, så det er veldig kult å se på forskjellige implementeringer av mønstre. Hvert mønster har dusinvis av implementeringer. Alt dette er veldig interessant.
Hvordan skriver vi Builder i produksjonskode? Her er brukeren vår. Vi knytter en Builder-rotasjon fra Lombok-biblioteket til den, og den genererer selv en Builder for oss. Det vil si at vi ikke skriver noen kode, men Java tror allerede at denne klassen har en Builder, og vi kan kalle det slik.
Jeg har allerede sagt at Java har biblioteker for nesten alt, inkludert Lombok, et kult bibliotek som lar deg unngå å skrive kjele. Byggmester, GET.
Mønstre kan være arkitektoniske - relatert ikke bare til én klasse, men til systemet som helhet. Det er et så kult prinsipp i systemdesign: Single Responsibility Principle. Hva snakker han om? Det faktum at hver klasse må være ansvarlig for noe av sin egen funksjonalitet. I dette tilfellet har vi en kontroller som kommuniserer med brukere, JSON-objekter. Det er Facade, som konverterer JSON-objekter til modeller som Java-applikasjonen vil jobbe med. Det er en tjeneste som har kompleks logikk som fungerer med disse modellene. Det er et datatilgangsobjekt som legger disse modellene inn i databasen og henter dem fra databasen. Og det er selve databasen. Det er med andre ord ikke alt i én klasse, men vi lager fem forskjellige klasser, og det er et annet mønster.
Når du har mer eller mindre lært Java, er det flott å skrive ditt eget prosjekt som vil ha en database, jobbe med andre APIer og eksponere serverapplikasjonen din for REST API-klienter. Dette ville være en flott ting å legge til CV-en din, det ville være en kul avslutning på utdannelsen din. Med dette kan du gå og få deg en jobb.
Her er et eksempel på serverapplikasjonen min. På mitt andre år skrev jeg semesteroppgave med gutta. De skrev en mobilapplikasjon for å organisere arrangementer. Der kunne brukere logge inn via VKontakte, plassere punkter på kartet, opprette arrangementer, invitere venner til dem, lagre bilder av hendelser, etc.
Hva gjorde jeg i prosjektet? Skrev en serverapplikasjon i Spring Boot uten å bruke SQL. Jeg kjente ham ikke, jeg brukte JPA. Hva kunne den gjøre? Logg på VK via OAuth-2. Ta brukerens token, gå til VK med det, sjekk at det er en ekte bruker. Motta informasjon om brukere gjennom VKontakte. Den var i stand til å lagre informasjon i en database, også gjennom JPA. Lagre bilder og andre filer dyktig i datamaskinens minne, og lagre lenker til dem i databasen. På den tiden visste jeg ikke at det var CLOB-objekter i databasen, så jeg gjorde det på denne måten. Det var en REST API for brukere, klientapplikasjoner. Og det var enhetstester for grunnleggende funksjonalitet.
[…] Et lite eksempel på min vellykkede læring av Java. I mitt første år på universitetet ble jeg undervist i C# og fikk en forståelse av OOP-programmering - hva klasser, grensesnitt, abstraksjon er, og hvorfor de trengs. Det hjalp meg mye. Uten dette er det ganske vanskelig å lære Java; det er ikke klart hvorfor kurs er nødvendig.
I mitt andre år på universitetet lærte de igjen Java-kjerne, men jeg stoppet ikke der, jeg gikk for å studere Spring selv og skrev en kursoppgave, prosjektet mitt, som jeg nevnte ovenfor. Og med alt dette gikk jeg på et internship hos Yandex, bestod et intervju og kom inn på Yandex.Market. Der skrev jeg backend for Beru, dette er vår markedsplass, og for Yandex.Market selv.
Etter det, for seks måneder siden, gikk jeg over til et annet team innenfor samme marked. Vi gjør analyser for forretningspartnere. Vi er i den analytiske plattformen, vi er tre på backend, så jeg har veldig stor innflytelse på prosjektet. Det er veldig interessant, faktisk. Det vil si at vi faktisk gir data om markedet - hva salg er, i hvilke kategorier, i hvilke modeller, for forretningspartnere, store kjente selskaper. Og det er bare tre av oss, vi skriver denne koden, og den er veldig kul.
Takk skal du ha! Nyttige lenker:
- .
- .
- .
- .
- .
- .
- .
- .
Kilde: www.habr.com