Hvordan adskiller Java sig fra andre populære sprog? Hvorfor bør Java være det første sprog, man skal lære? Lad os lave en plan, der vil hjælpe dig med at lære Java både fra bunden og ved at bruge programmeringsfærdigheder på andre sprog. Lad os liste forskellene mellem at skabe produktionskode i Java og at udvikle på andre sprog. Mikhail Zatepyakin holdt dette foredrag på et møde for fremtidige deltagere. Yandex og andre håbefulde udviklere - Java Junior meetup.
— Hej alle sammen, mit navn er Misha. Jeg er udvikler fra Yandex.Market, og i dag vil jeg fortælle jer, hvorfor I bør lære Java, og hvordan I gør det effektivt. I stiller måske et rimeligt spørgsmål: hvorfor skulle jeg fortælle jer dette, og ikke en stærk udvikler med en masse års erfaring? Sagen er, at jeg selv studerede Java for nylig, for omkring halvandet år siden, så jeg husker stadig, hvordan det var, og hvilke faldgruber der er.
For et år siden fik jeg en praktikplads hos Yandex.Market. Jeg udviklede backend'en til Beru, til selve markedet, som du sikkert har brugt. Nu fortsætter jeg med at arbejde der, i et andet team. Vi laver en analytisk platform til Yandex.Market for forretningspartnere.
Lad os komme i gang. Hvorfor lære Java fra et praktisk synspunkt? Sagen er, at Java er et meget berømt programmeringssprog. Det har et meget stort fællesskab.
For eksempel er der et TIOBE-indeks, et populært indeks over programmeringssprogs popularitet, og Java rangerer først der. På jobsider vil du sandsynligvis også bemærke, at de fleste ledige stillinger handler om Java, det vil sige, at ved at udvikle i Java vil du altid kunne finde et job.
Da fællesskabet er meget stort, vil ethvert spørgsmål, du måtte have, blive besvaret på nogle Stack Overflow- eller andre websteder. Når du udvikler i Java, skriver du faktisk kode på JVM'en, så du nemt kan skifte til Kotlin, Scala og andre sprog, der bruger JVM'en.
Hvad er godt ved Java fra et ideologisk synspunkt? Der findes forskellige programmeringssprog. De løser forskellige problemer, det ved du godt. For eksempel er Python fantastisk til at skrive scripts på én linje for at løse hurtige problemer.
På plusser kan du fuldt ud kontrollere den eksekverbare kode. For eksempel har vi biler, Yandex førerløse biler, deres kode er skrevet på plusser. Hvorfor? Java har sådan en ting - Garbage Collector. Den rydder RAM fra unødvendige objekter. Denne ting starter spontant og stopper verden, det vil sige, den stopper resten af programmet og går i gang med at tælle objekter, rydder hukommelsen fra objekter. Hvis sådan en ting virker i en førerløs bil, er det ikke cool. Din førerløse bil vil køre ligeud, i dette øjeblik rydde hukommelsen og ikke se på vejen. Derfor er den førerløse bil skrevet på plusser.
Hvilke problemer løser Java? Først og fremmest er det et sprog til udvikling af store programmer, der er skrevet over årene af snesevis eller hundredvis af mennesker. Især er meget af backend'en i Yandex.Market skrevet i Java. Vi har et distribueret team i flere byer, ti personer i hver. Og koden er nem at vedligeholde, den er blevet vedligeholdt i ti år eller mere, og nye mennesker kommer og forstår denne kode.
Hvilke egenskaber skal et sprog have, så koden i det er let at understøtte og let at udvikle 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 i det. Det vil sige, det skal være nemt at skrive abstraktioner på højt niveau i det osv. Java giver os alt dette. Det er et objektorienteret sprog. Det er virkelig nemt at implementere abstraktioner på højt niveau og komplekse arkitekturer i det.
Der findes også mange frameworks og biblioteker til Java, fordi sproget er over 15 år gammelt. I den tid er alt, hvad der kunne skrives, blevet skrevet i det, så der findes mange biblioteker til alt, hvad du måtte have brug for.
Hvad er de vigtigste færdigheder, efter min mening, som en nybegynder Java-udvikler bør have? Først og fremmest er det kendskab til Java-kernesproget. Dernæst er det noget Dependency Injection-framework. Den næste taler, Kirill, vil tale mere detaljeret om dette. Jeg vil ikke gå i detaljer. Dernæst er det arkitektur og designmønstre. Vi skal være i stand til at skrive arkitektonisk smuk kode for at kunne skrive store applikationer. Og det er noget SQL eller ORM til databaseopgaver. Og det handler mere om backend.
Lad os komme i gang! Java-kerne. Jeg vil ikke afsløre noget nyt her - du skal kende selve sproget. Hvad du skal være opmærksom på. For det første har Java udgivet en masse versioner i de senere år, det vil sige i 2014-2015 blev den syvende udgivet, derefter den ottende, niende, tiende, en masse nye versioner, og de introducerede en masse nye fede ting, 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 har brug for at vide. Derfor bør du ikke tage en bog fra hylden i Java-4-biblioteket og gå ud og lære den. Her er en plan: lær Java-8 eller højere.
Vær meget opmærksom på innovationer som Stream API, var osv. De bliver spurgt om i interviews og bruges konstant i produktionen. Det vil sige, at Stream API er meget sejere end cycles, hvilket generelt er en meget cool ting. Sørg for at være opmærksom.
Og der er andre ting som iteratorer, exceptions og så videre. Ting, der virker ligegyldige for dig, når du selv skriver lidt kode. Du har ikke brug for disse exceptions, hvem har brug for dem overhovedet? Men de vil helt sikkert blive spurgt om i interviews, de vil helt sikkert være nyttige for dig i produktionen. Generelt er det værd at være opmærksom på exceptions, iteratorer og andre ting.
Datastrukturer. Man kan ikke undvære strukturer, og det ville være fantastisk, hvis man ikke blot vidste, at der findes sæt, ordbøger og ark. Men også forskellige implementeringer af strukturer. For eksempel har den samme ordbog i Java mange implementeringer, herunder HashMap og TreeMap. De har forskellige asymptotikker, de er arrangeret forskelligt indeni. Man skal vide, hvordan de adskiller sig, og hvornår man skal bruge hvilken en.
Det ville også være fantastisk, hvis du vidste, hvordan disse datastrukturer fungerer internt. Det vil sige, ikke bare at kende deres asymptotik - hvor længe virker et bet, hvor længe virker et pass, men hvordan strukturen fungerer internt - for eksempel hvad er en bucket i HashMap.
Det er også værd at være opmærksom på træer og grafer. Disse er ting, der ikke er særlig almindelige i produktionskode, men de er populære i interviews. Derfor skal du være i stand til at gennemgå træer og grafer i bredde og dybde. Disse er alle simple algoritmer.
Så snart du begynder at skrive stor, kompleks kode ved hjælp af biblioteker, multiklassekode, vil du forstå, at det er svært for dig uden byggesystemer og løsning af afhængigheder. Disse er først og fremmest Maven og Gradle. De giver dig mulighed for at importere biblioteker til dit projekt på én linje. Det vil sige, at du skriver en xml-fil på én linje og importerer biblioteker til projektet. Fremragende systemer. De er omtrent ens, brug hvilken som helst - Maven eller Gradle.
Dernæst noget versionskontrolsystem. Jeg anbefaler Git, fordi det er populært, der er tonsvis af tutorials. Næsten alle bruger Git, det er en fed ting, man kan ikke undvære det.
Og - en eller anden form for udviklingsmiljø. Jeg anbefaler IntelliJ Idea. Det fremskynder udviklingsprocessen meget, hjælper dig meget, skriver alle mulige standardkoder for dig, generelt er det fedt.
Links fra sliden: ,
SQL. Lidt om backend-udviklere. Der var faktisk en sjov sag her. To dage før min anden praktikopholdssamtale ringede en pige fra HR 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 ingenting om SQL eller HTTP. Og jeg fandt denne fede hjemmeside — Jeg lærte SQL på 12 timer på det, altså SQL-syntaks, hvordan man skriver SELECT-forespørgsler, JOIN osv. Meget fed hjemmeside, jeg kan varmt anbefale den. Jeg lærte virkelig 12% af det, jeg ved nu, på 90 timer.
Og det er også godt at kende databasearkitekturen. Det er alle mulige slags nøgler, indekser, normalisering. Der er en række indlæg om dette på Habr.
I Java findes der, udover SQL, forskellige objektrelationelle kortlægningssystemer som f.eks. 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 brugernes database, fra tabellen, hentes deres ID'er og navne.
Så er der en bestemt mapper, der omdanner objektet fra databasen til et Java-objekt. Og der er en tredje metode nedenfor, der rent faktisk udfører denne kode. Alt dette kan erstattes med én linje ved hjælp af JPA, som er beskrevet nedenfor. Den gør det samme - find All ByIdIn. Det vil sige, baseret på metodenavnet genererer den en SQL-forespørgsel for dig.
Meget fed ting. Jeg brugte selv JPA, da jeg ikke kendte til SQL. Generelt, vær opmærksom. Hvis du er for doven til at lære SQL, er det ild. Og generelt, ild!
Spring. Hvem har hørt om sådan noget som Spring-frameworket? Ser I, hvor mange af jer der er? Det er ikke uden grund. Spring er en del af kravene til hver anden ledig stilling til en Java-backend. Man kan virkelig ikke undvære det i storskalaudvikling. Hvad er Spring? Først og fremmest er det et Dependency Injection-framework. Også om dette. næste taler. Men kort sagt, det er en ting, der gør det nemmere at importere afhængigheder fra én klasse til en anden. Så det gør det nemmere at kende afhængighederne.
Spring Boot er et stykke Spring, der giver dig mulighed for at starte din serverapplikation med én knap. Du går til THID, trykker på et par knapper, og nu har du startet din serverapplikation på localhost 8080. Det vil sige, du har ikke skrevet en eneste linje kode endnu, og den virker allerede. En meget fed ting. Hvis du skriver noget af dit eget, er det fantastisk!
Spring er et meget stort framework. Det konfigurerer ikke kun en serverapplikation for dig og løser Dependency Injection. Det giver dig mulighed for at gøre en masse ting, herunder at oprette REST API-metoder. Det vil sige, du skriver en metode, hænger Get mapping-annotationen på den. Og nu har du en metode på localhost, der skriver Hello world til dig. To linjer kode, og det virker. Fedt.
Spring forenkler også skrivning af tests. Der er ingen måde at undvære testning i store udviklingsprogrammer. Kode skal testes. Til dette har Java et fedt bibliotek, JUnit 5. Og JUnit generelt, men den seneste version er den femte. Den har alt til testning, alle mulige assertions og andre ting.
Og der er et fantastisk framework, Mockito. Forestil dig, at du har en funktionalitet, som du vil teste. Funktionaliteten gør en masse ting, herunder, et sted midt i, logger den ind på VKontakte med dit, for eksempel, ID, og henter for- og efternavnet på VKontakte-brugeren via ID. Du vil sandsynligvis ikke logge ind på VKontakte i tests, det er mærkeligt. Men du er nødt til at teste funktionaliteten, så du lavede denne klasse ved hjælp af Mockito, dens mok, dens imitation.
Du vil sige, at når en forespørgsel med det og det ID kommer til denne klasse, returnerer den et efternavn, for eksempel Vasya Pupkin. Og det vil virke. Det vil sige, at du vil teste al funktionaliteten for en simuleret version af én klasse. En meget fed ting.
Designmønstre. Hvad er det? Disse er skabeloner til løsning af typiske problemer, der opstår under udvikling. Under udvikling opstår ofte de samme eller lignende opgaver, som det ville være fantastisk at løse på en eller anden måde godt. Derfor har folk fundet på bedste praksis, nogle skabeloner til, hvordan man løser disse problemer.
Der findes en hjemmeside med de mest populære mønstre — refactoring.guru. Du kan læse den, finde ud af hvilke mønstre der findes, og læse en masse teori. Problemet er, at den praktisk talt er ubrugelig. Faktisk er mønstre uden øvelse ikke særlig nyttige.
Du vil høre om nogle mønstre som Singletone eller Builder. Hvem har hørt disse ord? Mange mennesker. Der er så simple mønstre, at du selv kan implementere. Men de fleste mønstre: strategi, fabrik, facade - det er ikke klart, hvor de skal anvendes.
Og indtil du i praksis ser et sted i en anden persons kode, hvor dette mønster anvendes, vil du ikke selv kunne anvende det. Derfor er øvelse meget vigtigt med mønstre. Og bare det at læse om dem på refactoring.guru er ikke super nyttigt, men det er bestemt nødvendigt at gøre.
Hvorfor har vi brug for mønstre? Lad os sige, at du har en klasse kaldet Bruger. Den har et Id og et Navn. Hver Bruger skal have både et Id og et Navn. Øverst til venstre er klassen.
Hvordan initialiserer man en bruger? Der er to muligheder - enten en konstruktør eller en setter. Hvad er ulemperne ved begge tilgange?
Constructor. new User(7, "Bond"), okay. Lad os nu sige, at vi ikke har en User-klasse, men en anden med syv numeriske felter. Du har en constructor med syv fortløbende tal. Det er ikke klart, hvad disse tal er, og hvilket af dem tilhører hvilken egenskab. En constructor er ikke god.
Den anden mulighed er setter. Du skriver tydeligt: setId(7), setName(«Bond»). Du forstår, hvilken egenskab der hører til hvilket felt. Men setter har et problem. For det første kan du glemme at tjekke noget, og for det andet bliver dit objekt ænbart. Dette er ikke trådsikkert og reducerer kodens læsbarhed en smule. Derfor kom folk op med et fedt mønster — Builder.
Hvad handler det om? Lad os prøve at kombinere fordelene ved begge tilgange - både setteren og konstruktøren - i én. Vi laver et bestemt objekt, Builder, som også vil have felterne Id og Navn, som i sig selv vil blive bygget baseret på setteren, og som vil have en Build-metode, der returnerer dig en ny bruger med alle parametrene. Vi får et uforanderligt objekt og en setter. Fedt!
Hvad er problemerne? Her har vi en klassisk Builder. Problemet er, at vi stadig kan glemme at besøge et felt. Og hvis vi glemmer at besøge ID'et, i dette tilfælde initialiseres det til nul i Builderen, fordi int-typen ikke kan være null. Og hvis vi laver navnet "Bond" og glemmer at besøge ID'et, får vi en ny bruger med id'et "0" og navnet "Bond". Ikke cool.
Lad os prøve at bekæmpe dette. I Builder ændrer vi int til int, så det kan være nullable. Nu er alt perfekt.
Hvis vi forsøger at oprette en bruger med navnet "Bond" uden at angive et ID, får vi en null-pointer-undtagelse, fordi ID'et ikke kan nulliseres, og Builder er null, specifikt en pointer-undtagelse.
Men vi kan stadig glemme at give et navn, så vi sætter objektgengivelse til null. Når vi nu bygger vores objekt fra Builder, kontrollerer den, at feltet ikke kan nulles. Og det er ikke alt.
Lad os se på det sidste eksempel. I dette tilfælde, hvis vi på en eller anden måde indsætter null i ID-runtime'en, ville det være dejligt at vide med det samme, at du har gjort det, og det er ikke fedt, at du laver en fejl nu.
Du skal ikke udløse en fejl i det øjeblik, brugeren oprettes, men når du sætter null til ID'et. Derfor ændrer vi Integer til int i setteren i Builder, og den vil straks klage over, at der blev udløst null.
Kort sagt, hvad er pointen? Der findes et meget simpelt Builder-mønster, men selv implementeringen har nogle finesser, så det er meget fedt at se på forskellige implementeringer af mønstre. Hvert mønster har snesevis af implementeringer. Det er alt sammen meget interessant.
Hvordan skriver vi en Builder i produktionskode? Her er vores User. Vi tilknytter Builder-rotationen fra Lombok-biblioteket til den, og den genererer en Builder for os. Det vil sige, at vi ikke skriver kode, men Java tror allerede, at denne klasse har en Builder, og vi kan kalde den sådan her.
Jeg har allerede sagt, at Java har biblioteker til næsten alt, inklusive Lombok, et fedt bibliotek, der giver dig mulighed for ikke at skrive en standardtekst. Builder, GET.
Mønstre kan være arkitektoniske – relateret ikke kun til én klasse, men til systemet som helhed. Der er et så fedt princip inden for systemdesign: Single Responsibility Principle. Hvad betyder det? At hver klasse skal være ansvarlig for noget af sin funktionalitet. I dette tilfælde har vi en Controller, der kommunikerer med brugerne, JSON-objekter. Der er en Facade, der konverterer JSON-objekter til modeller, som Java-applikationen derefter vil arbejde med. Der er en Service, der har kompleks logik, der arbejder med disse modeller. Der er et Data Access Object, der lægger disse modeller i databasen og henter dem fra databasen. Og der er selve databasen. Med andre ord er ikke alt dette i én klasse, men vi laver fem forskellige klasser, og dette er et andet mønster.
Når du mere eller mindre har lært Java, er det fedt at skrive nogle af dine egne projekter, der har en database, arbejder med andre API'er og leverer din serverapplikation til REST API-klienter. Det er en god ting at skrive på dit CV, det er en fed måde at afslutte din uddannelse på. Du kan gå hen og få et job med det.
Her er et eksempel på min serverapplikation. I mit andet år skrev mine venner og jeg en semesteropgave. De skrev en mobilapplikation til at organisere events. Der kunne brugerne logge ind via VKontakte, placere punkter på kortet, oprette events, invitere deres venner til dem, gemme billeder af events osv.
Hvad gjorde jeg i projektet? Jeg skrev en serverapplikation på Spring Boot uden at bruge SQL. Jeg vidste det ikke, jeg brugte JPA. Hvad kunne den? Log ind på VK via OAuth-2. Tag brugerens token, gå til VK med den, tjek at det er en rigtig bruger. Hent information om brugere via VKontakte. Den kunne gemme information i databasen, også via JPA. Den kunne gemme billeder og andre filer i computerens hukommelse og gemme links til dem i databasen. Jeg vidste ikke dengang, 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 hovedfunktionaliteten.
[…] Et lille eksempel på min succesfulde Java-indlæring. I mit første år på universitetet blev jeg undervist i C# og fik en forståelse af OOP-programmering — hvad klasser, grænseflader, abstraktioner 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 klasser er nødvendige.
I mit andet år på universitetet gav de mig Java Core igen, men jeg stoppede ikke der, jeg begyndte selv at studere Spring og skrev en semesteropgave, mit projekt, som jeg nævnte ovenfor. Og med alt dette tog jeg i praktik hos Yandex, bestod interviewet og kom ind på Yandex.Market. Der skrev jeg backend'en til Beru, vores markedsplads, og til selve Yandex.Market.
Derefter, for seks måneder siden, skiftede jeg til et andet team inden for samme marked. Vi laver analyser for forretningspartnere. Vi er i analyseplatformen, og der er tre af os i backend-afdelingen, så jeg har en meget stor indflydelse på projektet. Det er faktisk meget interessant. Det vil sige, at vi rent faktisk leverer data om markedet - hvilket salg, i hvilke kategorier, i hvilke modeller, for forretningspartnere, store velkendte virksomheder. Og der er kun tre af os, der skriver denne kode, og det er meget fedt.
Tak! Nyttige links:
— .
— .
— .
— .
— .
— .
— .
— .
Kilde: www.habr.com
