Hvordan adskiller Java sig fra andre populære sprog? Hvorfor skal Java være det første sprog, man lærer? Lad os lave en plan, der vil hjælpe dig med at lære Java både fra bunden og ved at anvende programmeringsfærdigheder på andre sprog. Lad os liste forskellene mellem at skabe produktionskode i Java og at udvikle på andre sprog. Mikhail Zatepyakin læste denne rapport på et møde for fremtidige deltagere Yandex og andre begyndende udviklere - Java Junior meetup.
– Hej alle sammen, mit navn er Misha. Jeg er en udvikler fra Yandex.Market, og i dag vil jeg fortælle dig, hvorfor du skal lære Java, og hvordan du gør det effektivt. Du kan stille et rimeligt spørgsmål: hvorfor vil jeg fortælle denne historie, og ikke en stærk udvikler med mange års erfaring? Faktum er, at jeg selv studerede Java for nylig, for cirka halvandet år siden, så jeg kan stadig huske, hvordan det var, og hvilke faldgruber der er.
For et år siden kom jeg i praktik hos Yandex.Market. Jeg udviklede backend til Beru, til selve markedet, du har sikkert brugt det. Nu fortsætter jeg med at arbejde der, i et andet team. Vi skaber en analytisk platform til Yandex.Market for forretningspartnere.
Lad os komme igang. Hvorfor lære Java fra et praktisk synspunkt? Faktum er, at Java er et meget berømt programmeringssprog. Det har et meget stort fællesskab.
For eksempel er der sådan et TIOBE-indeks, et populært indeks over programmeringssprogenes popularitet, og Java rangerer først der. Også på jobsider vil du sikkert bemærke, at de fleste af de ledige stillinger handler om Java, det vil sige, at du ved at udvikle i Java altid kan finde et job.
Da fællesskabet er meget stort, vil ethvert spørgsmål, du har, finde et svar på nogle Stack Overflow eller andre websteder. Når du udvikler i Java, skriver du faktisk kode på JVM, så du nemt kan skifte til Kotlin, Scala og andre sprog, der bruger JVM.
Hvad er godt ved Java fra et ideologisk synspunkt? Der er forskellige programmeringssprog. De løser forskellige problemer, det ved du. For eksempel er Python fantastisk til at skrive one-line scripts for at løse hurtige problemer.
På plussiden kan du fuldt ud kontrollere den eksekverbare kode. For eksempel har vi biler, Yandex førerløse biler, deres kode er skrevet med plusser. Hvorfor? Java har sådan en ting - Garbage Collector. Det rydder RAM for unødvendige genstande. Denne ting starter spontant og stopper-verden, det vil sige, den stopper resten af programmet og går til at tælle objekter, rydde hukommelsen af objekter. Hvis sådan noget virker i en drone, er det ikke fedt. Din drone vil køre ligeud, i dette øjeblik rydde dens hukommelse og slet ikke se på vejen. Derfor er dronen skrevet på profferne.
Hvilke problemer løser Java? Det er primært et sprog til at udvikle store programmer, der er skrevet over år, af snesevis eller hundredvis af mennesker. Især meget af backend i Yandex.Market er skrevet i Java. Vi har et fordelt team i flere byer, ti personer i hver. Og koden er nem at vedligeholde, den har været understøttet i ti år eller mere, og samtidig kommer der nye mennesker ind og forstår denne kode.
Hvilke egenskaber skal et sprog have, så koden i det nemt understøttes, og så det nemt kan udvikles i store teams. Først og fremmest skal det være læsbar kode, og det skal være nemt at implementere komplekse arkitektoniske løsninger. Det vil sige, at det skal være nemt at skrive abstraktioner på højt niveau osv. Alt dette giver Java os. Dette er et objektorienteret sprog. Det er virkelig nemt at implementere abstraktioner på højt niveau og komplekse arkitekturer.
Der er også en masse rammer og biblioteker til Java, fordi sproget er mere end 15 år gammelt. I løbet af denne tid blev alt, hvad der kunne skrives, skrevet på det, så der er tonsvis af biblioteker til alt, hvad du måtte have brug for.
Hvilke grundlæggende færdigheder bør en begyndende JA-spiller efter min mening have? Først og fremmest er dette kendskab til Java-kernesproget. Dernæst er en form for afhængighedsinjektionsramme. Den næste taler, Kirill, vil fortælle mere om dette. Jeg vil ikke gå for dybt. Dernæst er arkitekturen og designmønstrene. Vi skal kunne skrive arkitektonisk smuk kode for at kunne skrive store applikationer. Og dette er en slags SQL eller ORM til opgaver med at arbejde med databasen. Og det gælder mere for backend.
Gå! Java kerne. Jeg vil ikke rigtig opdage Amerika her - du skal kende selve sproget. Hvad du skal være opmærksom på. For det første har Java udgivet en masse versioner de seneste år, det vil sige, i 2014-2015 blev den syvende udgivet, derefter den ottende, niende, tiende, en masse nye versioner, og en masse nye fede ting blev introduceret i dem , for eksempel Java Stream API , lambda osv. Meget fede, friske, fede ting, der bruges i produktionskode, hvad de spørger om i interviews og som du skal vide. Derfor bør du ikke tage en bog fra reolen i Java-4-biblioteket og gå og lære den. Dette er vores plan: vi lærer Java-8 eller højere.
Vi er meget opmærksomme på innovationer som Stream API, var osv. De bliver spurgt under interviews og bliver konstant brugt i produktionen. Det vil sige, at Stream API er meget sejere end loops, generelt en meget cool ting. Sørg for at være opmærksom.
Og der er alle mulige ting som iteratorer, undtagelser og så videre. Ting, der virker ligegyldige for dig, så længe du selv skriver noget lille kode. Du har ikke brug for disse undtagelser, hvem har brug for dem alligevel? Men de vil helt sikkert blive spurgt til interviews, de vil helt sikkert være nyttige for dig i produktionen. Generelt bør du være opmærksom på undtagelser, iteratorer og andre ting.
Datastrukturer. Du kan ikke undvære strukturer, men det vil være fantastisk, hvis du ikke bare ved, at der er sæt, ordbøger og ark. Og også forskellige implementeringer af strukturer. For eksempel har den samme ordbog i Java mange implementeringer, herunder HashMap og TreeMap. De har forskellige asymptoter, de er struktureret forskelligt indeni. Du skal vide, hvordan de adskiller sig, og hvornår du skal bruge hvilken.
Det vil også være meget fedt, hvis du ved, hvordan disse datastrukturer fungerer internt. Det vil sige, at det ikke er let at kende deres asymptotik - hvor meget indsatsen virker, hvor længe passet virker, men hvordan strukturen fungerer indeni - for eksempel hvad er en bøtte i HashMap.
Det er også værd at være opmærksom på træer og grafer. Det er ting, der ikke er særlig almindelige i produktionskode, men de er populære i interviews. Derfor skal du kunne krydse træer, grafer i bredde og dybde. Disse er alle simple algoritmer.
Så snart du begynder at skrive en stor kode, kompleks, ved hjælp af biblioteker, multi-klasse kode, vil du indse, at det er svært for dig uden at bygge systemer og løse afhængigheder. Disse er primært Maven og Gradle. De giver dig mulighed for at importere biblioteker til dit projekt på én linje. Det vil sige, at du skriver en one-line xml og importerer biblioteker til projektet. Fantastiske systemer. De er omtrent ens, brug enten en - Maven eller Gradle.
Dernæst - en slags versionskontrolsystem. Jeg anbefaler Git, fordi det er populært, og der er tonsvis af tutorials. Næsten alle bruger Git, det er en fed ting, du kan ikke leve uden det.
Og en form for udviklingsmiljø. Jeg anbefaler IntelliJ Idea. Det fremskynder udviklingsprocessen meget, hjælper dig meget, skriver al boilerplate-koden for dig, generelt er det fedt.
Links fra sliden: ,
SQL. Lidt om backenders. Der var faktisk en sjov sag her. To dage før min anden praktiksamtale ringede en HR-pige til mig og sagde, at om to dage ville de spørge mig om SQL og HTTP, jeg skulle lære det. Og jeg vidste næsten intet om SQL eller HTTP. Og jeg fandt denne seje side - . Jeg lærte SQL på det på 12 timer, altså SQL-syntaks, hvordan man skriver SELECT-forespørgsler, JOIN osv. Meget cool side, jeg kan varmt anbefale det. Faktisk lærte jeg på 12 timer 90 % af det, jeg ved nu.
Og det er også fantastisk at kende databasearkitekturen. Disse er alle slags nøgler, indekser, normalisering. Der er en række indlæg om dette på Habré.
I Java er der udover SQL alle mulige objektrelationelle kortlægningssystemer såsom JPA. Der er noget kode. I den første metode er der noget SQL-kode - SELECT id name FROM info.users WHERE id IN userIds. Fra brugerdatabasen, fra tabellen, hentes deres ID'er og navne.
Dernæst er der en bestemt mapper, der gør et objekt fra basen til et Java-objekt. Og der er en tredje metode nedenfor, der rent faktisk udfører denne kode. Alt dette kan erstattes ved hjælp af JPA med én linje, som er skrevet nedenfor. Den gør det samme - find All ByIdIn. Det vil sige, at baseret på navnet på metoden genererer den en SQL-forespørgsel til dig.
Meget cool ting. Jeg selv, da jeg ikke kendte SQL, brugte JPA. Vær generelt opmærksom. Hvis du er for doven til at lære SQL, er det en katastrofe. Og generelt ild!
Forår. Hvem har hørt om sådan noget som forårets rammer? Kan du se, hvor mange af jer der er? Ikke uden grund. Forår er inkluderet i kravene til hver anden Java-backend ledig stilling. Uden det er der virkelig ingen steder i en stor udvikling. Hvad er forår? Først og fremmest er dette en Dependency Injection-ramme. Også herom næste taler. Men kort sagt, dette er en ting, der giver dig mulighed for at gøre det nemmere at importere nogle klassers afhængigheder til andre. Det vil sige, at viden om afhængigheder forenkles.
Spring Boot er et stykke Spring, der giver dig mulighed for at køre din serverapplikation med én knap. Du går til THID, trykker på et par knapper, og nu har du din serverapplikation oppe og køre på localhost 8080. Det vil sige, at du ikke har skrevet en eneste linje kode endnu, men det virker allerede. Meget cool ting. Hvis du skriver noget af dit eget, så fyr!
Foråret er en meget stor ramme. Det opfanger ikke kun din serverapplikation og løser Dependency Injection. Det giver dig mulighed for at gøre en masse ting, herunder oprettelse af REST API-metoder. Det vil sige, du skrev en metode og vedhæftede Get mapping-annotationen til den. Og nu har du allerede en metode på localhost, der skriver Hello world til dig. To linjer kode og det virker. Seje ting.
Foråret gør det også nemmere at skrive test. Der er ingen vej uden at teste i stor udvikling. Koden skal testes. Til dette formål har Java et cool bibliotek JUnit 5. Og JUnit generelt, men den seneste version er den femte. Der er alt til test, alle mulige påstande og andre ting.
Og der er en fantastisk Mockito-ramme. Forestil dig, at du har en funktionalitet, som du vil teste. Funktionaliteten gør en masse ting, herunder, et sted i midten, logger den for eksempel på VKontakte med dit ID og modtager for- og efternavnet på VKontakte-brugeren fra ID'et. Du vil sandsynligvis ikke inkludere VKontakte i testene, det er mærkeligt. Men du skal teste funktionaliteten, så du lavede denne klasse ved at bruge Mockito, mok det, efterligne det.
Du vil sige, at når en anmodning kommer til denne klasse med et ID sådan og sådan, returnerer det et eller andet efternavn, for eksempel Vasya Pupkin. Og det vil virke. Det vil sige, at du vil teste al funktionaliteten for mok one class. Meget cool ting.
Design mønstre. Hvad er det? Det er skabeloner til at løse typiske problemer, der opstår i udviklingen. I udviklingen opstår ofte identiske eller lignende problemer, som det ville være fantastisk at løse på en eller anden måde godt. Derfor kom folk med bedste praksis, visse skabeloner, til hvordan man løser disse problemer.
Der er en hjemmeside med de mest populære mønstre - refactoring.guru, du kan læse den, finde ud af hvilke mønstre der er, læse en masse teori. Problemet er, at det praktisk talt er ubrugeligt. Faktisk er mønstre uden praksis ikke særligt nyttige.
Du vil høre om nogle mønstre som Singletone eller Builder. Hvem hørte disse ord? Mange mennesker. Der er så simple mønstre, som du selv kan implementere. Men de fleste af mønstrene: strategi, fabrik, facade - det er ikke klart, hvor de skal anvendes.
Og indtil du i praksis ser i en anden persons kode et sted, hvor dette mønster er anvendt, vil du ikke være i stand til at anvende det selv. Derfor er øvelse meget vigtig med mønstre. Og bare at læse om dem på refactoring.guru er ikke super nyttigt, men det er bestemt værd at gøre.
Hvorfor er der brug for mønstre? Lad os sige, at du har en bestemt brugerklasse. Den har et id og et navn. Hver bruger skal have både et id og et navn. Øverst til venstre er klasseværelset.
Hvad er måderne at initialisere bruger på? Der er to muligheder - enten en konstruktør eller en sætter. Hvad er ulemperne ved begge tilgange?
Konstruktør. ny bruger (7, "Bond"), okay. Lad os nu sige, at vi ikke har en brugerklasse, men en anden med syv numeriske felter. Du vil have en konstruktør, der indeholder syv på hinanden følgende numre. Det er ikke klart, hvad disse tal er, og hvilke af dem, der hører til hvilken ejendom. Designeren er ikke fantastisk.
Den anden mulighed er setter. Du skriver tydeligt: setId(7), setName(“Bond”). Du forstår hvilken ejendom der hører til hvilket felt. Men setter har et problem. For det første kan du glemme at tildele noget, og for det andet viser dit objekt sig at være foranderligt. Dette er ikke trådsikkert og reducerer kodens læsbarhed en smule. Derfor fandt folk på et fedt mønster - Builder.
Hvad drejer det sig om? Lad os prøve at kombinere fordelene ved begge tilgange – sætter og konstruktør – i én. Vi laver et bestemt objekt, Builder, som også vil have Id- og Name-felter, som i sig selv vil blive bygget ud fra sætteren, og som vil have en Build-metode, der giver dig en ny bruger med alle parametrene. Vi får en uforanderlig genstand og en sætter. Fedt nok!
Hvad er problemerne? Her har vi den klassiske Builder. Problemet er, at vi stadig kan glemme at tjekke et eller andet felt. Og hvis vi glemte at besøge ID'et, initialiseres det i dette tilfælde til nul i Builder, fordi int-typen ikke er nullbar. Og hvis vi laver navnet "Bond" og glemmer at besøge ID-kontoret, vil vi have en ny bruger med id "0" og navnet "Bond". Ikke sejt.
Lad os prøve at bekæmpe dette. I Builder vil vi ændre int til int, så den er nullbar. Nu er alt fantastisk.
Hvis vi forsøger at oprette en bruger med navnet "Bond", og glemmer at sætte hans ID, vil vi få en null pointer undtagelse, fordi ID'et ikke kan null, og Builder har en null, specifikt pointer undtagelse.
Men vi kan stadig glemme at angive et navn, så vi sætter objektafspilning til null. Nu, når vi bygger vores objekt fra Builder, tjekker det, at feltet ikke er nullbart. Og det er ikke alt.
Lad os se på det sidste eksempel. I dette tilfælde, hvis vi på en eller anden måde sætter null i ID-runtiden, ville det være dejligt med det samme at vide, at du gjorde det, og det er ikke fedt, at du laver en fejl nu.
Du skal smide en fejl ikke i det øjeblik, brugeren oprettes, men når du indstiller null til ID'et. Derfor vil vi i Builder ændre sættet Integer til int, og han vil straks sværge, at de smed null ud.
Kort sagt, hvad er meningen? Der er et simpelt Builder-mønster, men selv dets implementering har nogle finesser, så det er meget fedt at se på forskellige implementeringer af mønstre. Hvert mønster har snesevis af implementeringer. Det hele er meget interessant.
Hvordan skriver vi Builder i produktionskode? Her er vores bruger. Vi knytter en Builder-rotation fra Lombok-biblioteket til den, og den genererer selv en Builder til os. Det vil sige, vi skriver ikke nogen kode, men Java mener allerede, at denne klasse har en Builder, og vi kan kalde det sådan.
Jeg har allerede sagt, at Java har biblioteker til næsten alt, inklusive Lombok, et fedt bibliotek, der giver dig mulighed for at undgå at skrive kedelplade. Bygmester, GET.
Mønstre kan være arkitektoniske - relateret ikke kun til én klasse, men til systemet som helhed. Der er sådan et cool princip i systemdesign: Single Responsibility Principle. Hvad taler han om? Det faktum, at hver klasse skal være ansvarlig for noget af sin egen funktionalitet. I dette tilfælde har vi en controller, der kommunikerer med brugere, JSON-objekter. Der er Facade, som konverterer JSON-objekter til modeller, som Java-applikationen derefter vil arbejde med. Der er en tjeneste, der har kompleks logik, der fungerer med disse modeller. Der er et Data Access Object, som sætter disse modeller ind i databasen og henter dem fra databasen. Og der er selve databasen. Det er med andre ord ikke det hele i én klasse, men vi laver fem forskellige klasser, og det er et andet mønster.
Når du har mere eller mindre lært Java, er det fantastisk at skrive dit eget projekt, der vil have en database, arbejde med andre API'er og udsætte din serverapplikation for REST API-klienter. Dette ville være en fantastisk ting at tilføje til dit CV, det ville være en cool afslutning på din uddannelse. Med dette kan du gå hen og få et job.
Her er et eksempel på min serverapplikation. På mit andet år skrev jeg en semesteropgave med fyrene. De skrev en mobilapplikation til at organisere begivenheder. Der kunne brugere logge ind via VKontakte, placere punkter på kortet, oprette begivenheder, invitere deres venner til dem, gemme billeder af begivenheder osv.
Hvad lavede jeg i projektet? Skrev en serverapplikation i Spring Boot uden at bruge SQL. Jeg kendte ham ikke, jeg brugte JPA. Hvad kunne den gøre? Log ind på VK via OAuth-2. Tag brugerens token, gå til VK med det, tjek at det er en rigtig bruger. Modtag oplysninger om brugere gennem VKontakte. Det var i stand til at gemme oplysninger i en database, også via JPA. Gem dygtigt billeder og andre filer i computerens hukommelse, og gem links til dem i databasen. På det tidspunkt vidste jeg ikke, at der var CLOB-objekter i databasen, så jeg gjorde det på denne måde. Der var en REST API til brugere, klientapplikationer. Og der var enhedstests for grundlæggende funktionalitet.
[…] Et lille eksempel på min succesfulde indlæring af Java. I mit første år på universitetet blev jeg undervist i C# og fik en forståelse af OOP-programmering - hvad klasser, interfaces, abstraktion er, og hvorfor de er nødvendige. Det hjalp mig meget. Uden dette er det ret svært at lære Java; det er ikke klart, hvorfor der er behov for undervisning.
I mit andet år på universitetet underviste de igen i Java core, men jeg stoppede ikke der, jeg gik selv for at studere Spring og skrev en kursusopgave, mit projekt, som jeg nævnte ovenfor. Og med alt dette gik jeg i praktik hos Yandex, bestod et interview og kom ind på Yandex.Market. Der skrev jeg backend til Beru, dette er vores markedsplads, og for Yandex.Market selv.
Efter det, for seks måneder siden, skiftede jeg til et andet team inden for det samme marked. Vi laver analyser for forretningspartnere. Vi er i den analytiske platform, vi er tre på backend, så jeg har en meget stor andel af indflydelse på projektet. Det er faktisk meget interessant. Det vil sige, at vi faktisk leverer data på markedet - hvad salg er, i hvilke kategorier, i hvilke modeller, til samarbejdspartnere, store kendte virksomheder. Og vi er kun tre, vi skriver denne kode, og det er meget fedt.
Tak skal du have! Nyttige links:
— .
— .
— .
— .
— .
— .
— .
— .
Kilde: www.habr.com