Varför lära sig Java och hur man gör det effektivt. Yandex rapport

Hur skiljer sig Java från andra populära språk? Varför ska Java vara det första språket att lära sig? Låt oss skapa en plan som hjälper dig att lära dig Java både från grunden och genom att tillämpa programmeringskunskaper på andra språk. Låt oss lista skillnaderna mellan att skapa produktionskod i Java och att utveckla på andra språk. Mikhail Zatepyakin läste denna rapport vid ett möte för framtida deltagare praktikplatser Yandex och andra nybörjarutvecklare - Java Junior meetup.

— Hej alla, jag heter Misha. Jag är en utvecklare från Yandex.Market, och idag kommer jag att berätta varför du ska lära dig Java och hur du gör det effektivt. Du kanske ställer en rimlig fråga: varför kommer jag att berätta den här historien, och inte någon stark utvecklare med många års erfarenhet? Faktum är att jag själv studerade Java nyligen, för ungefär ett och ett halvt år sedan, så jag minns fortfarande hur det var och vilka fallgropar det finns.

För ett år sedan fick jag en praktikplats på Yandex.Market. Jag utvecklade backend för Beru, för själva marknaden, du använde det förmodligen. Nu fortsätter jag att jobba där, i ett annat team. Vi skapar en analytisk plattform för Yandex.Market för affärspartners.

Låt oss börja. Varför lära sig Java ur en praktisk synvinkel? Faktum är att Java är ett mycket känt programmeringsspråk. Den har ett mycket stort samhälle.

Det finns till exempel ett sådant TIOBE-index, ett populärt index över programmeringsspråkens popularitet, och Java rankas först där. På jobbsajter kommer du förmodligen också att märka att de flesta lediga jobb handlar om Java, det vill säga genom att utveckla i Java kan du alltid hitta ett jobb.

Eftersom gemenskapen är mycket stor, kommer alla frågor du har att hitta svar på vissa Stack Overflow eller andra webbplatser. Dessutom, när du utvecklar i Java, skriver du faktiskt kod på JVM, så du kan enkelt byta till Kotlin, Scala och andra språk som använder JVM.

Vad är bra med Java ur ideologisk synvinkel? Det finns olika programmeringsspråk. De löser olika problem, det vet du. Till exempel är Python utmärkt för att skriva enradsskript för att lösa snabba problem.

På plussidan kan du helt kontrollera den körbara koden. Till exempel har vi bilar, Yandex förarlösa bilar, deras kod är skriven med plus. Varför? Java har en sådan sak - Garbage Collector. Det rensar RAM från onödiga föremål. Den här saken startar spontant och stoppar-världen, det vill säga den stoppar resten av programmet och går för att räkna objekt, rensa minnet av objekt. Om något sådant fungerar i en drönare är det inte coolt. Din drönare kommer att köra rakt, i detta ögonblick rensa minnet och inte titta på vägen alls. Därför är drönaren skriven på proffsen.

Vilka problem löser Java? Det är främst ett språk för att utveckla stora program som är skrivna över år, av dussintals eller hundratals personer. I synnerhet är mycket av backend i Yandex.Market skrivet i Java. Vi har ett fördelat team i flera städer, tio personer i varje. Och koden är lätt att underhålla, den har stötts i tio år eller mer, och samtidigt kommer nya människor in och förstår den här koden.

Vilka egenskaper ska ett språk ha så att koden i det lätt stöds och så att det enkelt kan utvecklas i stora team. Först och främst ska det vara läsbar kod och det ska vara lätt att implementera komplexa arkitektoniska lösningar. Det vill säga att det ska vara lätt att skriva abstraktioner på hög nivå etc. Allt detta är vad Java förser oss med. Detta är ett objektorienterat språk. Det är verkligen lätt att implementera abstraktioner på hög nivå och komplexa arkitekturer.

Det finns också en hel del ramverk och bibliotek för Java, eftersom språket är mer än 15 år gammalt. Under den här tiden skrevs allt som kunde skrivas på den, så det finns massor av bibliotek för allt du kan behöva.

Vilka grundläggande färdigheter, enligt min mening, bör en nybörjare JA-spelare ha? Först och främst är detta kunskap om Javas kärnspråk. Nästa är någon form av Dependency Injection-ramverk. Nästa talare, Kirill, kommer att prata mer om detta. Jag ska inte gå för djupt. Nästa är arkitekturen och designmönstren. Vi behöver kunna skriva arkitektoniskt vacker kod för att kunna skriva stora applikationer. Och detta är någon form av SQL eller ORM för uppgifter att arbeta med databasen. Och detta gäller mer för backend.

Gå! Java kärna. Jag kommer inte riktigt att upptäcka Amerika här - du måste kunna språket i sig. Vad du bör vara uppmärksam på. För det första har Java släppt många versioner de senaste åren, det vill säga 2014-2015 släpptes den sjunde, sedan den åttonde, nionde, tionde, många nya versioner, och en massa nya coola saker introducerades i dem t ex Java Stream API , lambda etc. Jättefina, fräscha, coola saker som används i produktionskod, vad de frågar om i intervjuer och som du behöver veta. Därför bör du inte ta en bok från hyllan i Java-4-biblioteket och gå och lära dig den. Det här är vår plan: vi lär oss Java-8 eller högre.

Vi uppmärksammar innovationer som Stream API, var etc. De tillfrågas under intervjuer och används ständigt i produktionen. Det vill säga Stream API är mycket coolare än loopar, i allmänhet en väldigt cool sak. Var noga med att vara uppmärksam.

Och det finns alla möjliga saker som iteratorer, undantag och så vidare. Saker som verkar oviktiga för dig så länge du skriver någon liten kod själv. Du behöver inte dessa undantag, vem behöver dem egentligen? Men de kommer definitivt att tillfrågas vid intervjuer, de kommer definitivt att vara användbara för dig i produktionen. I allmänhet bör du vara uppmärksam på Undantag, iteratorer och andra saker.

Data struktur. Du kan inte gå utan strukturer, men det kommer att vara bra om du inte bara vet att det finns uppsättningar, ordböcker och ark. Och även olika implementeringar av strukturer. Till exempel har samma ordbok i Java många implementeringar, inklusive HashMap och TreeMap. De har olika asymptotik, de är strukturerade olika inuti. Du måste veta hur de skiljer sig och när du ska använda vilken.

Det kommer också att vara väldigt häftigt om du vet hur dessa datastrukturer fungerar internt. Det vill säga, det är inte lätt att veta deras asymptotik - hur mycket insatsen fungerar, hur länge passet fungerar, men hur strukturen fungerar inuti - till exempel vad är en hink i HashMap.

Det är också värt att uppmärksamma träd och grafer. Det här är saker som inte är särskilt vanliga i produktionskod, men de är populära i intervjuer. Därför måste du kunna korsa träd, grafer i bredd och djup. Dessa är alla enkla algoritmer.

Så snart du börjar skriva en stor kod, komplex, med hjälp av bibliotek, flerklasskod, kommer du att inse att det är svårt för dig utan att bygga system och lösa beroenden. Dessa är i första hand Maven och Gradle. De låter dig importera bibliotek till ditt projekt på en rad. Det vill säga du skriver en enrads xml och importerar bibliotek till projektet. Bra system. De är ungefär likadana, använd antingen en - Maven eller Gradle.

Nästa - något slags versionskontrollsystem. Jag rekommenderar Git eftersom det är populärt och det finns massor av tutorials. Nästan alla använder Git, det är en cool grej, du kan inte leva utan det.

Och någon form av utvecklingsmiljö. Jag rekommenderar IntelliJ Idea. Det påskyndar utvecklingsprocessen avsevärt, hjälper dig mycket, skriver all kod för dig, i allmänhet är det coolt.

Länkar från bilden: SQLZOO, habrapost

SQL. Lite om backenders. Det var faktiskt ett roligt fall här. Två dagar innan min andra praktikintervju ringde en HR-tjej mig och sa att om två dagar skulle de fråga mig om SQL och HTTP, jag behövde lära mig det. Och jag visste nästan ingenting om SQL eller HTTP. Och jag hittade den här coola sidan - SQLZOO. Jag lärde mig SQL på det på 12 timmar, jag menar, SQL-syntax, hur man skriver SELECT-frågor, JOIN, etc. Mycket cool sida, jag rekommenderar den starkt. Faktum är att jag på 12 timmar lärde mig 90 % av det jag vet nu.

Och det är också bra att känna till databasarkitektur. Dessa är alla typer av nycklar, index, normalisering. Det finns en rad inlägg om detta på Habré.

I Java finns det förutom SQL alla möjliga objektrelationella kartläggningssystem som JPA. Det finns någon kod. I den första metoden finns det lite SQL-kod - VÄLJ ID-namn FRÅN info.users WHERE id IN userIds. Från användardatabasen, från tabellen, hämtas deras ID och namn.

Därefter finns det en viss kartläggare som förvandlar ett objekt från basen till ett Java-objekt. Och det finns en tredje metod nedan som faktiskt kör den här koden. Allt detta kan ersättas med JPA med en rad, vilket är skrivet nedan. Det gör samma sak - hitta All ByIdIn. Det vill säga, baserat på namnet på metoden genererar den en SQL-fråga åt dig.

Väldigt cool grej. Jag själv, när jag inte kunde SQL, använde JPA. Var uppmärksam i allmänhet. Om du är för lat för att lära dig SQL är det en katastrof. Och i allmänhet eld!

Vår. Vem har hört talas om en sådan sak som Spring-ramverket? Ser ni hur många ni är? Inte utan anledning. Spring ingår i kraven för varannan Java-backend-vakans. Utan det finns det verkligen ingenstans i en stor utveckling. Vad är våren? Först och främst är detta en Dependency Injection-ramverk. Även om detta kommer berätta nästa talare. Men kort sagt, detta är en sak som låter dig göra det lättare att importera beroenden för vissa klasser till andra. Det vill säga att kunskapen om beroenden förenklas.

Spring Boot är en del av Spring som låter dig köra din serverapplikation med en knapp. Du går till THID, trycker på ett par knappar och nu har du din serverapplikation igång på localhost 8080. Det vill säga, du har inte skrivit en enda kodrad än, men det fungerar redan. Väldigt cool grej. Om du skriver något eget, eld!

Våren är en väldigt stor ram. Det plockar inte bara upp din serverapplikation och löser Dependency Injection. Det låter dig göra en massa saker, inklusive att skapa REST API-metoder. Det vill säga, du skrev någon metod och bifogade Get mapping-anteckningen till den. Och nu har du redan någon metod på localhost som skriver Hello world till dig. Två rader kod och det fungerar. Coola saker.

Våren gör också skrivproven lättare. Det går inte att testa i stor utveckling. Koden måste testas. För detta ändamål har Java ett coolt bibliotek JUnit 5. Och JUnit i allmänhet, men den senaste versionen är den femte. Det finns allt för att testa, alla möjliga påståenden och annat.

Och det finns ett fantastiskt Mockito-ramverk. Föreställ dig att du har någon funktionalitet som du vill testa. Funktionaliteten gör många saker, inklusive någonstans i mitten loggar den in på VKontakte med ditt ID, till exempel, och tar emot för- och efternamnet på VKontakte-användaren från ID:t. Du kommer förmodligen inte att inkludera VKontakte i testerna, det är konstigt. Men du måste testa funktionaliteten, så du gjorde den här klassen, med hjälp av Mockito, mok it, imiterade den.

Du kommer att säga att när en förfrågan kommer till den här klassen med ett ID så och så, returnerar det något efternamn, till exempel Vasya Pupkin. Och det kommer att fungera. Det vill säga, du kommer att testa all funktionalitet för mok one class. Väldigt cool grej.

Länk från bild

Design mönster. Vad det är? Det här är mallar för att lösa typiska problem som uppstår i utvecklingen. I utvecklingen uppstår ofta identiska eller liknande problem som det skulle vara bra att lösa på något sätt bra. Därför kom folk på bästa praxis, vissa mallar, för hur man löser dessa problem.

Det finns en webbplats med de mest populära mönstren - refactoring.guru, du kan läsa den, ta reda på vilka mönster det finns, läsa en massa teorier. Problemet är att det praktiskt taget är värdelöst. Faktum är att mönster utan övning inte är särskilt användbara.

Du kommer att höra om några mönster som Singletone eller Builder. Vem hörde dessa ord? Många människor. Det finns så enkla mönster som du kan implementera själv. Men de flesta av mönstren: strategi, fabrik, fasad - det är inte klart var de ska tillämpas.

Och tills du i praktiken i någon annan persons kod ser en plats där detta mönster appliceras, kommer du inte att kunna tillämpa det själv. Därför är övning väldigt viktigt med mönster. Och att bara läsa om dem på refactoring.guru är inte särskilt bra, men det är definitivt värt att göra.

Varför behövs mönster? Låt oss säga att du har en viss användarklass. Den har ett ID och ett namn. Varje användare måste ha både ett ID och ett namn. Längst upp till vänster är klassrummet.

Vilka är sätten att initiera användare? Det finns två alternativ - antingen en konstruktör eller en sättare. Vilka är nackdelarna med båda metoderna?

Konstruktör. ny användare (7, "Bond"), okej. Låt oss nu säga att vi inte har en användarklass, utan någon annan, med sju numeriska fält. Du kommer att ha en konstruktor som innehåller sju på varandra följande nummer. Det är inte klart vilka dessa siffror är och vilka av dem som hör till vilken fastighet. Designern är inte bra.

Det andra alternativet är setter. Du skriver tydligt: ​​setId(7), setName(“Bond”). Du förstår vilken egendom som hör till vilket område. Men setter har ett problem. För det första kan du glömma att tilldela något, och för det andra visar sig ditt objekt vara föränderligt. Detta är inte trådsäkert och minskar kodens läsbarhet något. Det var därför folk kom på ett coolt mönster – Builder.

Vad handlar det här om? Låt oss försöka kombinera fördelarna med båda tillvägagångssätten – sätter och konstruktör – i ett. Vi gör ett visst objekt, Builder, som även kommer att ha Id- och Name-fält, som i sig kommer att byggas utifrån sättaren, och som kommer att ha en Build-metod som ger dig en ny Användare med alla parametrar. Vi får ett oföränderligt föremål och en setter. Häftigt!

Vilka är problemen? Här har vi den klassiska Builder. Problemet är att vi fortfarande kan glömma att checka i något fält. Och om vi glömde att besöka ID:t, i det här fallet i Builder initieras det till noll, eftersom int-typen inte är nullbar. Och om vi gör namnet "Bond" och glömmer att besöka ID-kontoret, kommer vi att ha en ny användare med id "0" och namnet "Bond". Inte coolt.

Låt oss försöka bekämpa detta. I Builder kommer vi att ändra int till int så att det är nullbart. Nu är allt jättebra.

Om vi ​​försöker skapa en användare med namnet "Bond", och glömmer att ange hans ID, kommer vi att få ett undantag för nollpekare, eftersom ID:t inte är nullbart, och byggaren har ett noll, specifikt pekareundantag.

Men vi kan fortfarande glömma att ange ett namn, så vi ställer in objektrespel till noll. Nu, när vi bygger vårt objekt från Builder, kontrollerar det att fältet inte är nullbart. Och det är inte allt.

Låt oss titta på det sista exemplet. I det här fallet, om vi på något sätt sätter null i ID-körtiden, skulle det vara bra att omedelbart veta att du gjorde det och det är inte coolt att du gör ett misstag nu.

Du måste skicka ett fel inte i ögonblicket för användarskapandet, utan när du ställer in null till ID:t. Därför kommer vi i Builder att ändra sättaren Integer till int, och han kommer omedelbart att svära att de kastade ut null.

Kort sagt, vad är poängen? Det finns ett enkelt Builder-mönster, men även dess implementering har några finesser, så det är väldigt coolt att titta på olika implementeringar av mönster. Varje mönster har dussintals implementeringar. Det här är mycket intressant.

Hur skriver vi Builder i produktionskod? Här är vår användare. Vi bifogar en Builder-rotation från Lombok-biblioteket till den, och den skapar själv en Builder åt oss. Det vill säga, vi skriver ingen kod, men Java tror redan att den här klassen har en Builder, och vi kan kalla det så här.

Jag har redan sagt att Java har bibliotek för nästan allt, inklusive Lombok, ett coolt bibliotek som låter dig slippa skriva boilerplate. Byggare, GET.

Mönster kan vara arkitektoniska - relaterade inte bara till en klass, utan till systemet som helhet. Det finns en så cool princip i systemdesign: Single Responsibility Principle. Vad pratar han om? Det faktum att varje klass måste ansvara för en del av sin egen funktionalitet. I det här fallet har vi en Controller som kommunicerar med användare, JSON-objekt. Det finns Facade, som konverterar JSON-objekt till modeller som Java-applikationen sedan kommer att arbeta med. Det finns en tjänst som har komplex logik som fungerar med dessa modeller. Det finns ett Data Access Object som placerar dessa modeller i databasen och hämtar dem från databasen. Och där finns själva databasen. Det är med andra ord inte allt i en klass, men vi gör fem olika klasser, och det är ett annat mönster.

När du mer eller mindre har lärt dig Java är det bra att skriva ditt eget projekt som kommer att ha en databas, arbeta med andra API:er och exponera din serverapplikation för REST API-klienter. Detta skulle vara en bra sak att lägga till i ditt CV, det skulle vara ett coolt avslut på din utbildning. Med detta kan du gå och få ett jobb.

Här är ett exempel på min serverapplikation. Under mitt andra år skrev jag en terminsuppsats med killarna. De skrev en mobilapplikation för att organisera evenemang. Där kunde användare logga in via VKontakte, placera punkter på kartan, skapa evenemang, bjuda in sina vänner till dem, spara bilder på evenemang osv.

Vad gjorde jag i projektet? Skrev en serverapplikation i Spring Boot utan att använda SQL. Jag kände honom inte, jag använde JPA. Vad kunde det göra? Logga in på VK via OAuth-2. Ta användarens token, gå till VK med den, kontrollera att det är en riktig användare. Få information om användare via VKontakte. Den kunde spara information i en databas, även genom JPA. Spara skickligt bilder och andra filer i datorns minne och spara länkar till dem i databasen. Vid den tiden visste jag inte att det fanns CLOB-objekt i databasen, så jag gjorde det på det här sättet. Det fanns ett REST API för användare, klientapplikationer. Och det fanns enhetstester för grundläggande funktionalitet.

[…] Ett litet exempel på min framgångsrika inlärning av Java. Under mitt första år på universitetet lärde jag mig C# och fick en förståelse för OOP-programmering - vad klasser, gränssnitt, abstraktion är och varför de behövs. Det hjälpte mig mycket. Utan detta är det ganska svårt att lära sig Java, det är inte klart varför klasser behövs.

Under mitt andra år på universitetet lärde de återigen Java core, men jag slutade inte där, jag gick själv för att studera Spring och skrev en kursuppsats, mitt projekt, som jag nämnde ovan. Och med allt detta gick jag på praktik på Yandex, klarade en intervju och kom in på Yandex.Market. Där skrev jag backend för Beru, det här är vår marknadsplats, och för själva Yandex.Market.

Efter det, för ett halvår sedan, gick jag över till ett annat team inom samma Market. Vi gör analyser för affärspartners. Vi är i den analytiska plattformen, vi är tre på backend, så jag har en väldigt stor del av inflytandet på projektet. Det är väldigt intressant, faktiskt. Det vill säga, vi tillhandahåller faktiskt data om marknaden - vad försäljningen är, i vilka kategorier, i vilka modeller, för affärspartners, stora välkända företag. Och vi är bara tre, vi skriver den här koden, och den är väldigt cool.

Tack! Användbara länkar:
- "Java 8. Nybörjarguide".
- Data struktur.
- SQLZOO.
- Databasnormalisering.
- Design mönster.
- Design mönster.
- Ren kod.
- Effektiv Java.

Källa: will.com