Hoe verschilt Java van andere populaire talen? Waarom zou Java de eerste taal moeten zijn om te leren? Laten we een plan maken waarmee u Java helemaal opnieuw kunt leren en door programmeervaardigheden in andere talen toe te passen. Laten we de verschillen opsommen tussen het maken van productiecode in Java en het ontwikkelen in andere talen. Mikhail Zatepyakin las dit rapport tijdens een bijeenkomst voor toekomstige deelnemers Yandex en andere beginnende ontwikkelaars - Java Junior meetup.
— Hallo allemaal, mijn naam is Misha. Ik ben een ontwikkelaar van Yandex.Market en vandaag zal ik je vertellen waarom je Java moet leren en hoe je het effectief kunt doen. Je kunt een redelijke vraag stellen: waarom vertel ik dit verhaal, en niet een sterke ontwikkelaar met vele jaren ervaring? Feit is dat ik zelf onlangs Java heb gestudeerd, ongeveer anderhalf jaar geleden, dus ik weet nog hoe het was en welke valkuilen er zijn.
Een jaar geleden liep ik stage bij Yandex.Market. De backend voor Beru heb ik ontwikkeld, voor de Market zelf heb je deze waarschijnlijk gebruikt. Nu blijf ik daar werken, in een ander team. We creëren een analytisch platform voor Yandex.Market voor zakelijke partners.
Laten we beginnen. Waarom Java leren vanuit praktisch oogpunt? Feit is dat Java een zeer bekende programmeertaal is. Het heeft een zeer grote gemeenschap.
Er is bijvoorbeeld zo’n TIOBE-index, een populaire index van de populariteit van programmeertalen, en Java staat daar op de eerste plaats. Ook zul je op vacaturesites waarschijnlijk merken dat de meeste vacatures over Java gaan, dat wil zeggen dat je door je in Java te ontwikkelen altijd een baan kunt vinden.
Omdat de community erg groot is, zal elke vraag die je hebt een antwoord vinden op sommige Stack Overflow- of andere sites. Bovendien schrijf je bij het ontwikkelen in Java feitelijk code op de JVM, waardoor je eenvoudig kunt overstappen naar Kotlin, Scala en andere talen die de JVM gebruiken.
Wat is er vanuit ideologisch perspectief goed aan Java? Er zijn verschillende programmeertalen. Ze lossen verschillende problemen op, dat weet je. Python is bijvoorbeeld geweldig voor het schrijven van scripts van één regel om snelle problemen op te lossen.
Aan de positieve kant heeft u volledige controle over de uitvoerbare code. We hebben bijvoorbeeld auto's, zelfrijdende Yandex-auto's, hun code is geschreven in plustekens. Waarom? Java heeft zoiets: Garbage Collector. Het wist RAM van onnodige objecten. Dit ding start spontaan en stopt de wereld, dat wil zeggen, het stopt de rest van het programma en gaat objecten tellen, het geheugen van objecten wissen. Als zoiets werkt in een drone, is dat niet cool. Je drone zal rechtdoor rijden, op dit moment zijn geheugen wissen en helemaal niet naar de weg kijken. Daarom is de drone geschreven voor de profs.
Welke problemen lost Java op? Het is in de eerste plaats een taal voor het ontwikkelen van grote programma's die in de loop der jaren door tientallen of honderden mensen zijn geschreven. Met name een groot deel van de backend in Yandex.Market is in Java geschreven. We hebben een verspreid team in verschillende steden, met in elke stad tien mensen. En de code is gemakkelijk te onderhouden, wordt al tien jaar of langer ondersteund, en tegelijkertijd komen er nieuwe mensen binnen die deze code begrijpen.
Welke eigenschappen moet een taal hebben zodat de code erin makkelijk ondersteund wordt en deze makkelijk in grote teams ontwikkeld kan worden. Allereerst moet het leesbare code zijn en moet het eenvoudig zijn om complexe architecturale oplossingen te implementeren. Dat wil zeggen, het zou gemakkelijk moeten zijn om abstracties op hoog niveau te schrijven, enz. Dit is allemaal wat Java ons biedt. Dit is een objectgeoriënteerde taal. Het is heel eenvoudig om abstracties op hoog niveau en complexe architecturen te implementeren.
Er zijn ook veel frameworks en bibliotheken voor Java, omdat de taal meer dan 15 jaar oud is. Gedurende deze tijd werd alles erop geschreven wat geschreven kon worden, dus er zijn talloze bibliotheken voor alles wat je nodig hebt.
Welke basisvaardigheden moet een beginnende JA-speler naar mijn mening hebben? Allereerst is dit kennis van de Java-kerntaal. Het volgende is een soort Dependency Injection-framework. De volgende spreker, Kirill, zal hier uitgebreider op ingaan. Ik zal niet te diep gaan. Vervolgens volgen de architectuur- en ontwerppatronen. We moeten architectonisch mooie code kunnen schrijven om grote applicaties te kunnen schrijven. En dit is een soort SQL of ORM voor taken die verband houden met het werken met de database. En dit geldt meer voor de backend.
Gaan! Java-kern. Ik zal Amerika hier niet echt ontdekken; je moet de taal zelf kennen. Waar u op moet letten. Ten eerste heeft Java de afgelopen jaren veel versies uitgebracht, dat wil zeggen dat in 2014-2015 de zevende werd uitgebracht, daarna de achtste, negende, tiende, veel nieuwe versies en er veel nieuwe coole dingen in werden geïntroduceerd , bijvoorbeeld de Java Stream API , lambda, etc. Heel coole, frisse, coole dingen die in productiecode worden gebruikt, waar ze naar vragen in interviews en die je moet weten. Daarom moet u geen boek uit de plank in de Java-4-bibliotheek pakken en het gaan leren. Dit is ons plan: we leren Java-8 of hoger.
We besteden veel aandacht aan innovaties zoals Stream API, var, etc. Ze worden gevraagd tijdens interviews en worden voortdurend gebruikt in de productie. Dat wil zeggen, de Stream API is veel cooler dan loops, over het algemeen een heel cool ding. Zorg ervoor dat je oplet.
En er zijn allerlei dingen zoals iterators, uitzonderingen enzovoort. Dingen die voor jou onbelangrijk lijken, zolang je maar zelf wat kleine code schrijft. Je hebt deze uitzonderingen niet nodig, wie heeft ze eigenlijk nodig? Maar ze zullen zeker worden gevraagd tijdens interviews, ze zullen zeker nuttig voor je zijn in de productie. Over het algemeen moet u letten op uitzonderingen, iterators en andere zaken.
Data structuren. Je kunt niet zonder structuren, maar het zal geweldig zijn als je niet alleen weet dat er sets, woordenboeken en bladen zijn. En ook verschillende implementaties van structuren. Hetzelfde woordenboek in Java heeft bijvoorbeeld veel implementaties, waaronder HashMap en TreeMap. Ze hebben verschillende asymptotiek, ze zijn van binnen anders gestructureerd. U moet weten waarin ze verschillen en wanneer u welke moet gebruiken.
Het zal ook heel gaaf zijn als je weet hoe deze datastructuren intern werken. Dat wil zeggen, het is niet eenvoudig om hun asymptotiek te kennen - hoeveel de weddenschap werkt, hoe lang de pas werkt, maar hoe de structuur binnenin werkt - wat bijvoorbeeld een bucket is in HashMap.
Het is ook de moeite waard om aandacht te besteden aan bomen en grafieken. Dit zijn dingen die niet zo vaak voorkomen in productiecode, maar die wel populair zijn in interviews. Daarom moet je bomen en grafieken in de breedte en diepte kunnen doorkruisen. Dit zijn allemaal eenvoudige algoritmen.
Zodra u begint met het schrijven van grote code, complex, met behulp van bibliotheken en code met meerdere klassen, zult u zich realiseren dat het moeilijk voor u is zonder systemen te bouwen en afhankelijkheden op te lossen. Dit zijn voornamelijk Maven en Gradle. Hiermee kunt u in één regel bibliotheken in uw project importeren. Dat wil zeggen dat u een XML van één regel schrijft en bibliotheken in het project importeert. Geweldige systemen. Ze zijn ongeveer hetzelfde, gebruik er één: Maven of Gradle.
Vervolgens - een soort versiebeheersysteem. Ik raad Git aan omdat het populair is en er talloze tutorials zijn. Bijna iedereen gebruikt Git, het is cool, je kunt niet zonder.
En een soort ontwikkelomgeving. Ik raad IntelliJ Idea aan. Het versnelt het ontwikkelingsproces enorm, helpt je veel, schrijft alle standaardcode voor je, over het algemeen is het cool.
Links van de dia: ,
SQL. Iets over backenders. Er was hier eigenlijk een grappig geval. Twee dagen voor mijn tweede stagegesprek belde een HR-meisje me en zei dat ze me over twee dagen zouden vragen over SQL en HTTP, ik moest het leren. En ik wist bijna niets van SQL of HTTP. En ik vond deze coole site - . Ik heb er in 12 uur SQL op geleerd, ik bedoel, SQL-syntaxis, hoe je SELECT-query's schrijft, JOIN, enz. Zeer coole site, ik raad het ten zeerste aan. Sterker nog, in 12 uur heb ik 90% geleerd van wat ik nu weet.
En het is ook geweldig om de databasearchitectuur te kennen. Dit zijn allerlei soorten sleutels, indexen, normalisatie. Op Habré staat hierover een reeks berichten.
In Java zijn er naast SQL allerlei Object-relationele mappingsystemen zoals JPA. Er is een code. In de eerste methode is er een SQL-code: SELECT id-naam FROM info.users WHERE id IN userIds. Uit de gebruikersdatabase, uit de tabel, worden hun ID's en namen verkregen.
Vervolgens is er een bepaalde mapper die een object uit de basis in een Java-object verandert. En er is een derde methode hieronder die deze code daadwerkelijk uitvoert. Dit alles kan worden vervangen door JPA met één regel, die hieronder staat geschreven. Het doet hetzelfde: vind All ByIdIn. Dat wil zeggen dat op basis van de naam van de methode een SQL-query voor u wordt gegenereerd.
Heel cool ding. Zelf heb ik, toen ik SQL niet kende, JPA gebruikt. Let in het algemeen op. Als je te lui bent om SQL te leren, is dat een ramp. En, in het algemeen, vuur!
Lente. Wie heeft er ooit van zoiets als het Spring-framework gehoord? Zie je hoeveel van jullie er zijn? Niet zonder reden. Bij elke tweede Java backend vacature wordt Spring meegenomen in de eisen. Zonder dit is er werkelijk geen sprake van een grote ontwikkeling. Wat is de lente? Allereerst is dit een raamwerk voor afhankelijkheidsinjectie. Ook hierover volgende spreker. Maar kort gezegd is dit iets waarmee u het gemakkelijker kunt maken om de afhankelijkheden van sommige klassen in andere te importeren. Dat wil zeggen, de kennis van afhankelijkheden wordt vereenvoudigd.
Spring Boot is een stukje Spring waarmee u met één knop uw serverapplicatie kunt uitvoeren. Je gaat naar THID, drukt op een paar knoppen en nu heb je je serverapplicatie actief op localhost 8080. Dat wil zeggen, je hebt nog geen enkele regel code geschreven, maar het werkt al. Heel cool ding. Als je zelf iets schrijft, vuur dan!
De lente is een heel groot raamwerk. Het pikt niet alleen uw serverapplicatie op en lost Dependency Injection op. Hiermee kunt u een heleboel dingen doen, waaronder het maken van REST API-methoden. Dat wil zeggen, je hebt een methode geschreven en de annotatie Get mapping eraan toegevoegd. En nu heb je al een methode op localhost die Hallo wereld naar je schrijft. Twee regels code en het werkt. Coole dingen.
De lente maakt het schrijven van toetsen ook gemakkelijker. Er is geen manier zonder testen in grote ontwikkelingen. De code moet worden getest. Voor dit doel heeft Java een coole bibliotheek JUnit 5. En JUnit in het algemeen, maar de nieuwste versie is de vijfde. Er is van alles om te testen, allerlei beweringen en andere dingen.
En er is een geweldig Mockito-framework. Stel je voor dat je een bepaalde functionaliteit hebt die je wilt testen. De functionaliteit doet veel dingen, waaronder ergens in het midden: het logt bijvoorbeeld in op VKontakte met uw ID en ontvangt de voor- en achternaam van de VKontakte-gebruiker van de ID. Waarschijnlijk neem je VKontakte niet mee in de tests, dat is vreemd. Maar je moet de functionaliteit testen, dus heb je deze klasse gemaakt, met behulp van Mockito, mok it, imitatie.
Je zult zeggen dat wanneer er een verzoek naar deze klas komt met een ID zo en zo, het een achternaam retourneert, bijvoorbeeld Vasya Pupkin. En het zal werken. Dat wil zeggen dat u alle functionaliteit voor mok one-klasse gaat testen. Heel cool ding.
Ontwerp patronen. Wat het is? Dit zijn sjablonen voor het oplossen van typische problemen die zich tijdens de ontwikkeling voordoen. Bij de ontwikkeling doen zich vaak identieke of soortgelijke problemen voor die geweldig zouden zijn om op de een of andere manier goed op te lossen. Daarom bedachten mensen best practices, bepaalde sjablonen, voor het oplossen van deze problemen.
Er is een website met de meest populaire patronen - refactoring.guru, je kunt het lezen, ontdekken welke patronen er zijn, een heleboel theorie lezen. Het probleem is dat het praktisch nutteloos is. In feite zijn patronen zonder oefening niet bijzonder nuttig.
Je zult over enkele patronen horen, zoals Singletone of Builder. Wie heeft deze woorden gehoord? Heel veel mensen. Er zijn zulke eenvoudige patronen die je zelf kunt implementeren. Maar de meeste patronen: strategie, fabriek, gevel - het is niet duidelijk waar ze moeten worden toegepast.
En totdat je in de praktijk in de code van iemand anders een plek ziet waarop dit patroon wordt toegepast, zul je het niet zelf kunnen toepassen. Daarom is oefenen met patronen erg belangrijk. En er gewoon over lezen op refactoring.guru is niet super nuttig, maar het is zeker de moeite waard om te doen.
Waarom zijn patronen nodig? Stel dat u een bepaalde gebruikersklasse heeft. Het heeft een ID en een naam. Elke Gebruiker moet zowel een ID als een Naam hebben. Linksboven is het klaslokaal.
Wat zijn de manieren om de gebruiker te initialiseren? Er zijn twee opties: een constructor of een setter. Wat zijn de nadelen van beide benaderingen?
Constructeur. nieuwe gebruiker (7, "Bond"), oké. Laten we nu zeggen dat we geen User-klasse hebben, maar een andere, met zeven numerieke velden. Je hebt een constructor met zeven opeenvolgende getallen. Het is niet duidelijk wat deze getallen zijn en welke bij welk onroerend goed hoort. De ontwerper is niet geweldig.
De tweede optie is setter. Je schrijft duidelijk: setId(7), setName(“Bond”). U begrijpt welke woning bij welk veld hoort. Maar Setter heeft een probleem. Ten eerste vergeet je misschien iets toe te wijzen, en ten tweede blijkt je object veranderlijk te zijn. Dit is niet thread-safe en vermindert de leesbaarheid van de code enigszins. Daarom bedachten mensen een cool patroon: Builder.
Waar gaat dit over? Laten we proberen de voordelen van beide benaderingen (setter en constructor) in één te combineren. We maken een bepaald object, Builder, dat ook de velden Id en Name zal hebben, dat zelf zal worden gebouwd op basis van de setter, en dat een Build-methode zal hebben die u een nieuwe gebruiker oplevert met alle parameters. We krijgen een onveranderlijk object en een setter. Koel!
Wat zijn de problemen? Hier hebben we de klassieke Builder. Het probleem is dat we nog steeds kunnen vergeten een veld in te checken. En als we vergeten zijn de ID te bezoeken, wordt deze in Builder in dit geval op nul geïnitialiseerd, omdat het int-type niet null kan zijn. En als we de naam “Bond” gebruiken en vergeten het ID-kantoor te bezoeken, hebben we een nieuwe gebruiker met ID “0” en de naam “Bond”. Niet cool.
Laten we proberen dit te bestrijden. In Builder zullen we int in int veranderen, zodat het nullable is. Nu is alles geweldig.
Als we proberen een gebruiker aan te maken met de naam “Bond”, waarbij we vergeten zijn ID in te voeren, krijgen we een null pointerexception, omdat de ID niet null kan worden gemaakt, en de Builder een nul heeft, specifiek pointerexception.
Maar we kunnen nog steeds vergeten een naam in te voeren, dus stellen we object replay in op nul. Wanneer we ons object nu vanuit Builder bouwen, wordt gecontroleerd of het veld niet null is. En dat is nog niet alles.
Laten we naar het laatste voorbeeld kijken. Als we in dit geval null in de ID-runtime plaatsen, zou het geweldig zijn om meteen te weten dat je het hebt gedaan en het is niet cool dat je nu een fout maakt.
U hoeft geen fout te genereren op het moment dat de gebruiker wordt gemaakt, maar wanneer u null instelt op de ID. Daarom zullen we in Builder de setter Integer veranderen in int, en hij zal onmiddellijk zweren dat ze nul hebben weggegooid.
Kortom, wat is het punt? Er is een eenvoudig Builder-patroon, maar zelfs de implementatie ervan heeft enkele subtiliteiten, dus het is erg gaaf om naar verschillende implementaties van patronen te kijken. Elk patroon heeft tientallen implementaties. Dit is allemaal erg interessant.
Hoe schrijven we Builder in productiecode? Hier is onze gebruiker. We koppelen er een Builder-rotatie uit de Lombok-bibliotheek aan, en deze genereert zelf een Builder voor ons. Dat wil zeggen, we schrijven geen code, maar Java denkt al dat deze klasse een Builder heeft, en we kunnen deze zo noemen.
Ik heb al gezegd dat Java voor bijna alles bibliotheken heeft, inclusief Lombok, een coole bibliotheek waarmee je het schrijven van standaardteksten kunt vermijden. Bouwer, KRIJG.
Patronen kunnen architectonisch zijn en niet alleen betrekking hebben op één klasse, maar op het systeem als geheel. Er is zo’n cool principe in systeemontwerp: het Single Responsibility Principle. Waar praat hij over? Het feit dat elke klasse verantwoordelijk moet zijn voor een deel van zijn eigen functionaliteit. In dit geval hebben we een controller die communiceert met gebruikers, JSON-objecten. Er is Facade, dat JSON-objecten omzet in modellen waar de Java-applicatie vervolgens mee gaat werken. Er is een service met complexe logica die met deze modellen werkt. Er is een Data Access Object dat deze modellen in de database plaatst en uit de database haalt. En er is de database zelf. Met andere woorden, het zit niet allemaal in één klas, maar we maken vijf verschillende klassen, en dat is een ander patroon.
Als je Java min of meer hebt geleerd, is het geweldig om je eigen project te schrijven dat over een database beschikt, met andere API's werkt en je servertoepassing blootstelt aan REST API-clients. Dit zou geweldig zijn om toe te voegen aan je CV, het zou een coole afsluiting van je opleiding zijn. Hiermee kun je een baan gaan zoeken.
Hier is een voorbeeld van mijn serverapplicatie. In mijn tweede jaar schreef ik een scriptie met de jongens. Ze waren een mobiele applicatie aan het schrijven voor het organiseren van evenementen. Daar konden gebruikers inloggen via VKontakte, punten op de kaart plaatsen, evenementen aanmaken, hun vrienden daarvoor uitnodigen, afbeeldingen van evenementen opslaan, enz.
Wat heb ik gedaan in het project? Schreef een serverapplicatie in Spring Boot zonder gebruik te maken van SQL. Ik kende hem niet, ik gebruikte JPA. Wat zou het kunnen doen? Log in op VK via OAuth-2. Neem het token van de gebruiker, ga ermee naar VK en controleer of het een echte gebruiker is. Ontvang informatie over gebruikers via VKontakte. Het kon informatie opslaan in een database, ook via JPA. Sla vakkundig afbeeldingen en andere bestanden op in het computergeheugen en sla koppelingen ernaar op in de database. Op dat moment wist ik niet dat er CLOB-objecten in de database stonden, dus heb ik het op deze manier gedaan. Er was een REST API voor gebruikers, clientapplicaties. En er waren unit-tests voor basisfunctionaliteit.
[…] Een klein voorbeeld van mijn succesvolle leerproces van Java. In mijn eerste jaar aan de universiteit kreeg ik les in C# en kreeg ik inzicht in OOP-programmeren - wat klassen, interfaces en abstractie zijn en waarom ze nodig zijn. Het heeft mij veel geholpen. Zonder dit is het leren van Java behoorlijk moeilijk; het is niet duidelijk waarom lessen nodig zijn.
In mijn tweede jaar aan de universiteit gaven ze opnieuw Java-kernlessen, maar daar stopte ik niet, ik ging zelf Spring studeren en schreef een cursuswerk, mijn project, dat ik hierboven noemde. En met dit alles ging ik stage lopen bij Yandex, slaagde voor een sollicitatiegesprek en kwam terecht bij Yandex.Market. Daar schreef ik de backend voor Beru, dit is onze marktplaats, en voor Yandex.Market zelf.
Daarna ben ik een half jaar geleden overgestapt naar een ander team binnen dezelfde markt. Wij doen analyses voor zakenpartners. We zitten op het analytische platform, we zijn met z'n drieën aan de backend, dus ik heb een zeer groot deel van de invloed op het project. Het is eigenlijk heel interessant. Dat wil zeggen, we verstrekken feitelijk gegevens over de markt - wat de omzet is, in welke categorieën, in welke modellen, voor zakenpartners, grote bekende bedrijven. En we zijn maar met zijn drieën, we schrijven deze code, en het is erg cool.
Bedankt! Handige links:
- .
- .
- .
- .
- .
- .
- .
- .
Bron: www.habr.com