Miten Java eroaa muista suosituista kielistä? Miksi Java pitäisi olla ensimmäinen kieli, joka opitaan? Tehdään suunnitelma, joka auttaa sinua oppimaan Javaa sekä tyhjästä että soveltamalla ohjelmointitaitoja muilla kielillä. Listataan erot tuotantokoodin luomisen Javalla ja muilla kielillä kehittämisen välillä. Mihail Zatepyakin luki tämän raportin tulevien osallistujien kokouksessa Yandex ja muut aloittelevat kehittäjät - Java Junior -tapaaminen.
– Hei kaikki, nimeni on Misha. Olen Yandex.Marketin kehittäjä, ja tänään kerron sinulle, miksi Javaa on opittava ja kuinka se tehdään tehokkaasti. Saatat kysyä järkevän kysymyksen: miksi minä kerron tämän tarinan, enkä joku vahva kehittäjä, jolla on monen vuoden kokemus? Tosiasia on, että opiskelin itse Javaa äskettäin, noin puolitoista vuotta sitten, joten muistan edelleen, millaista se oli ja mitä sudenkuoppia siinä on.
Vuosi sitten sain harjoittelupaikan Yandex.Marketissa. Kehitin taustaohjelman Berulle, itse Marketille, luultavasti käytit sitä. Nyt jatkan työskentelyä siellä, eri tiimissä. Luomme analyyttisen alustan Yandex.Marketille liikekumppaneille.
Aloitetaan. Miksi oppia Javaa käytännön näkökulmasta? Tosiasia on, että Java on erittäin kuuluisa ohjelmointikieli. Sillä on erittäin laaja yhteisö.
Esimerkiksi on olemassa tällainen TIOBE-indeksi, suosittu ohjelmointikielten suosion indeksi, ja Java on siellä ensimmäisellä sijalla. Myös työmailla varmaan huomaa, että suurin osa avoimista työpaikoista on Java-aiheisia, eli Javalla kehittymällä löytää aina töitä.
Koska yhteisö on erittäin suuri, kaikkiin kysymyksiisi löytyy vastaus joiltakin Stack Overflow -sivustoilta tai muilta sivustoilta. Javalla kehitettäessä kirjoitat myös koodia JVM:ään, joten voit helposti vaihtaa Kotliniin, Scalaan ja muihin JVM:ää käyttäviin kieliin.
Mitä hyvää Javassa on ideologisesta näkökulmasta? Ohjelmointikieliä on erilaisia. Ne ratkaisevat erilaisia ongelmia, tiedät sen. Python sopii esimerkiksi erinomaisesti yksirivisten komentosarjojen kirjoittamiseen nopeiden ongelmien ratkaisemiseksi.
Plussapuolella voit hallita suoritettavaa koodia täysin. Meillä on esimerkiksi autoja, Yandex-kuljettamattomia autoja, niiden koodi on kirjoitettu plussalla. Miksi? Javalla on sellainen asia - Garbage Collector. Se tyhjentää RAM-muistin tarpeettomista kohteista. Tämä asia alkaa spontaanisti ja pysäyttää maailman, eli se pysäyttää muun ohjelman ja menee laskemaan objekteja, tyhjentämään objektien muistia. Jos sellainen toimii dronissa, se ei ole siistiä. Droonisi ajaa suoraan, tyhjentää tällä hetkellä muistinsa eikä katso tietä ollenkaan. Siksi drone on kirjoitettu ammattilaisille.
Mitä ongelmia Java ratkaisee? Se on ensisijaisesti kieli suurten ohjelmien kehittämiseen, joita on kirjoittanut vuosien aikana kymmeniä tai satoja ihmisiä. Erityisesti suuri osa Yandex.Marketin taustaohjelmasta on kirjoitettu Java-kielellä. Meillä on hajautettu tiimi useisiin kaupunkeihin, jokaisessa kymmenen henkilöä. Ja koodia on helppo ylläpitää, sitä on tuettu kymmenen vuotta tai enemmän, ja samalla uusia ihmisiä tulee sisään ja ymmärtävät tämän koodin.
Mitä ominaisuuksia kielellä pitäisi olla, jotta siinä oleva koodi olisi helposti tuettu ja että sitä voidaan helposti kehittää suurissa ryhmissä. Ensinnäkin sen tulee olla luettavaa koodia ja monimutkaisten arkkitehtonisten ratkaisujen toteuttaminen on helppoa. Eli pitäisi olla helppoa kirjoittaa korkean tason abstraktioita jne. Kaiken tämän Java tarjoaa meille. Tämä on oliokieli. Korkean tason abstraktioiden ja monimutkaisten arkkitehtuurien toteuttaminen on todella helppoa.
Javalle on myös paljon kehyksiä ja kirjastoja, koska kieli on yli 15 vuotta vanha. Tänä aikana siihen kirjoitettiin kaikki mitä voi kirjoittaa, joten siellä on tonnia kirjastoja kaikelle mitä tarvitset.
Mitä perustaitoja aloittelevalla JA-pelaajalla minun mielestäni pitäisi olla? Ensinnäkin tämä on Java-ydinkielen tuntemusta. Seuraavaksi on jonkinlainen riippuvuusruiskutuskehys. Seuraava puhuja, Kirill, puhuu tästä täydellisemmin. En mene liian syvälle. Seuraava on arkkitehtuuri ja suunnittelumallit. Meidän on kyettävä kirjoittamaan arkkitehtonisesti kaunista koodia voidaksemme kirjoittaa suuria sovelluksia. Ja tämä on jonkinlainen SQL tai ORM tietokannan kanssa työskentelyyn. Ja tämä pätee enemmän taustajärjestelmään.
Mennä! Java ydin. En todellakaan löydä Amerikkaa täältä – sinun täytyy osata itse kieli. Mihin kannattaa kiinnittää huomiota. Ensinnäkin Java on julkaissut paljon versioita viime vuosina, eli vuosina 2014-2015 julkaistiin seitsemäs, sitten kahdeksas, yhdeksäs, kymmenes, paljon uusia versioita ja paljon uusia hienoja asioita esiteltiin niissä. , esimerkiksi Java Stream API , lambda jne. Todella siistejä, raikkaita, siistejä juttuja, joita käytetään tuotantokoodissa, mistä haastatteluissa kysytään ja jotka sinun tulee tietää. Siksi sinun ei pitäisi ottaa kirjaa Java-4-kirjaston hyllystä ja mennä oppimaan sitä. Tämä on suunnitelmamme: opimme Java-8:n tai uudemman.
Kiinnitämme huomiota innovaatioihin, kuten Stream API, var jne. Niitä kysytään haastatteluissa ja niitä käytetään jatkuvasti tuotannossa. Eli Stream API on paljon viileämpi kuin silmukat, yleensä erittäin siisti asia. Muista kiinnittää huomiota.
Ja on kaikenlaisia asioita, kuten iteraattorit, poikkeukset ja niin edelleen. Asiat, jotka eivät näytä sinulle merkityksellisiltä, kunhan kirjoitat pienen koodin itse. Sinä et tarvitse näitä poikkeuksia, kuka niitä muuten tarvitsee? Mutta heiltä kysytään ehdottomasti haastatteluissa, he ovat varmasti hyödyllisiä sinulle tuotannossa. Yleisesti ottaen kannattaa kiinnittää huomiota poikkeuksiin, iteraattoreihin ja muihin asioihin.
Tietorakenteet. Et voi olla ilman rakenteita, mutta on hienoa, jos et vain tiedä, että on olemassa sarjoja, sanakirjoja ja arkkeja. Ja myös erilaisia rakenteiden toteutuksia. Esimerkiksi samassa Java-sanakirjassa on monia toteutuksia, mukaan lukien HashMap ja TreeMap. Niillä on erilainen asymptotiikka, ne rakentuvat eri tavalla sisältä. Sinun on tiedettävä, miten ne eroavat toisistaan ja milloin kumpaa käyttää.
On myös hienoa, jos tiedät kuinka nämä tietorakenteet toimivat sisäisesti. Eli ei ole helppoa tietää niiden asymptotiikkaa - kuinka paljon veto toimii, kuinka kauan pass toimii, mutta kuinka rakenne toimii sisällä - esimerkiksi mikä on ämpäri HashMapissa.
Myös puihin ja kaavioihin kannattaa kiinnittää huomiota. Nämä ovat asioita, jotka eivät ole kovin yleisiä tuotantokoodissa, mutta ne ovat suosittuja haastatteluissa. Vastaavasti sinun on kyettävä kulkemaan puita, kuvaajia leveydellä ja syvyydellä. Nämä ovat kaikki yksinkertaisia algoritmeja.
Heti kun alat kirjoittaa mitä tahansa suurta, monimutkaista koodia, käyttämällä kirjastoja, moniluokkaista koodia, huomaat, että sinun on vaikeaa ilman järjestelmien rakentamista ja riippuvuuksien ratkaisemista. Nämä ovat ensisijaisesti Maven ja Gradle. Niiden avulla voit tuoda kirjastoja projektiisi yhdellä rivillä. Eli kirjoitat yksirivisen xml-tiedoston ja tuot kirjastoja projektiin. Hienoja järjestelmiä. Ne ovat suunnilleen samat, käytä joko Mavenia tai Gradlea.
Seuraavaksi - jonkinlainen versionhallintajärjestelmä. Suosittelen Gitiä, koska se on suosittu ja opetusohjelmia on paljon. Melkein kaikki käyttävät Gitiä, se on hieno asia, et voi elää ilman sitä.
Ja jonkinlainen kehitysympäristö. Suosittelen IntelliJ Ideaa. Se nopeuttaa huomattavasti kehitysprosessia, auttaa sinua paljon, kirjoittaa kaiken pohjakoodin puolestasi, yleensä se on siistiä.
Linkkejä diasta: ,
SQL. Vähän taustapelaajista. Tässä oli itse asiassa hauska tapaus. Kaksi päivää ennen toista työharjoitteluhaastatteluani HR-tyttö soitti minulle ja sanoi, että kahden päivän kuluttua he kysyvät minulta SQL:stä ja HTTP:stä, minun piti opetella se. En tiennyt melkein mitään SQL:stä tai HTTP:stä. Ja löysin tämän hienon sivuston - . Opin SQL:n siinä 12 tunnissa, tarkoitan SQL-syntaksia, SELECT-kyselyjen kirjoittamista, JOINia jne. Erittäin siisti sivusto, suosittelen sitä lämpimästi. Itse asiassa 12 tunnissa opin 90% siitä, mitä tiedän nyt.
Ja on myös hienoa tuntea tietokanta-arkkitehtuuri. Nämä ovat kaikenlaisia avaimia, indeksejä, normalisointia. Habressa on sarja viestejä tästä.
Javassa on SQL:n lisäksi kaikenlaisia objektirelaatiokartoitusjärjestelmiä, kuten JPA. On jotain koodia. Ensimmäisessä menetelmässä on jokin SQL-koodi - SELECT id name FROM info.users WHERE id IN userIds. Käyttäjien tietokannasta, taulukosta saadaan heidän tunnuksensa ja nimensä.
Seuraavaksi on tietty kartoitusohjelma, joka muuttaa objektin alustasta Java-objektiksi. Ja alla on kolmas menetelmä, joka todella suorittaa tämän koodin. Kaikki tämä voidaan korvata JPA:lla yhdellä rivillä, joka on kirjoitettu alla. Se tekee saman asian - etsi All ByIdIn. Eli menetelmän nimen perusteella se luo SQL-kyselyn sinulle.
Erittäin siisti juttu. Itse käytin JPA:ta, kun en tiennyt SQL:ää. Yleisesti ottaen kiinnitä huomiota. Jos olet liian laiska oppimaan SQL:ää, se on katastrofi. Ja ylipäätään tuli!
Kevät. Kuka on kuullut sellaisesta asiasta kuin kevätkehys? Näetkö kuinka monta teitä on? Ei ilman syytä. Kevät sisältyy joka toisen Java-taustajärjestelmän avoimen työpaikan vaatimuksiin. Ilman sitä ei todellakaan ole mitään suurta kehitystä. Mikä on kevät? Ensinnäkin tämä on Dependency Injection -kehys. Myös tästä seuraava puhuja. Mutta lyhyesti sanottuna, tämä on asia, jonka avulla voit helpottaa joidenkin luokkien riippuvuuksien tuomista muihin. Eli riippuvuuksien tuntemus yksinkertaistuu.
Spring Boot on osa Springistä, jonka avulla voit käyttää palvelinsovellustasi yhdellä painikkeella. Menet kohtaan THID, painat paria painiketta, ja nyt sinulla on palvelinsovelluksesi käynnissä localhost 8080:ssa. Eli et ole vielä kirjoittanut yhtään koodiriviä, mutta se toimii jo. Erittäin siisti juttu. Jos kirjoitat jotain omaa, tule!
Kevät on erittäin laaja kehys. Se ei vain poimi palvelinsovellustasi ja ratkaise riippuvuusruiskeen. Sen avulla voit tehdä joukon asioita, mukaan lukien REST API -menetelmien luominen. Eli kirjoitit jonkin menetelmän ja liitit siihen Hae kartoitus -merkinnän. Ja nyt sinulla on jo jokin menetelmä localhostissa, joka kirjoittaa sinulle Hello world. Kaksi riviä koodia ja se toimii. Hienoja juttuja.
Kevät helpottaa myös kokeiden kirjoittamista. Ei ole mitään keinoa ilman testausta laajassa kehitystyössä. Koodi pitää testata. Tätä tarkoitusta varten Javalla on hieno kirjasto JUnit 5. Ja JUnit yleensä, mutta uusin versio on viides. Siellä on kaikkea testattavaa, kaikenlaisia väitteitä ja muuta.
Ja siellä on mahtava Mockito-kehys. Kuvittele, että sinulla on joitain toimintoja, joita haluat testata. Toiminto tekee paljon asioita, mukaan lukien jossain välissä kirjautuminen VKontakteen esimerkiksi tunnuksellasi ja vastaanottaa VKontakte-käyttäjän etu- ja sukunimen tunnuksesta. Et todennäköisesti sisällytä VKontaktea testeihin, se on outoa. Mutta sinun täytyy testata toimivuutta, joten teit tämän luokan käyttämällä Mockito, mok it, jäljittele sitä.
Sanot, että kun tälle luokalle tulee pyyntö sellaisella ja sellaisella tunnuksella, se palauttaa jonkin sukunimen, esimerkiksi Vasya Pupkin. Ja se toimii. Eli testaat kaikki mok yhden luokan toiminnot. Erittäin siisti juttu.
Suunnittelumalleja. Mikä se on? Nämä ovat malleja tyypillisten kehityksessä esiin tulevien ongelmien ratkaisemiseksi. Kehityksessä tulee usein esiin samanlaisia tai samankaltaisia ongelmia, jotka olisi hienoa ratkaista jotenkin hyvin. Siksi ihmiset keksivät parhaita käytäntöjä, tiettyjä malleja näiden ongelmien ratkaisemiseksi.
Suosituimmilla kaavoilla on verkkosivusto - refactoring.guru, voit lukea sen, selvittää, mitä malleja siellä on, lukea joukon teoriaa. Ongelmana on, että se on käytännössä hyödytön. Itse asiassa mallit ilman harjoittelua eivät ole erityisen hyödyllisiä.
Kuulet joistakin malleista, kuten Singletone tai Builder. Kuka kuuli nämä sanat? Paljon ihmisiä. On niin yksinkertaisia malleja, jotka voit toteuttaa itse. Mutta suurin osa malleista: strategia, tehdas, julkisivu - ei ole selvää, missä niitä sovelletaan.
Ja ennen kuin näet käytännössä jonkun toisen henkilön koodissa paikan, johon tätä mallia sovelletaan, et voi soveltaa sitä itse. Siksi harjoittelu on erittäin tärkeää kuvioiden kanssa. Ja pelkkä niistä lukeminen refaktoring.gurussa ei ole kovin hyödyllistä, mutta se kannattaa ehdottomasti tehdä.
Miksi malleja tarvitaan? Oletetaan, että sinulla on tietty käyttäjäluokka. Sillä on tunnus ja nimi. Jokaisella käyttäjällä on oltava sekä tunnus että nimi. Ylhäällä vasemmalla on luokkahuone.
Millä tavoilla käyttäjä alustetaan? Vaihtoehtoja on kaksi - joko rakentaja tai asettaja. Mitkä ovat kummankin lähestymistavan haitat?
Rakentaja. uusi käyttäjä (7, "Bond"), okei. Oletetaan nyt, että meillä ei ole User-luokkaa, vaan joku muu, jossa on seitsemän numeerista kenttää. Sinulla on konstruktori, joka sisältää seitsemän peräkkäistä numeroa. Ei ole selvää, mitä nämä luvut ovat ja mikä niistä kuuluu mihinkin omaisuuteen. Suunnittelija ei ole loistava.
Toinen vaihtoehto on asettaja. Kirjoitat selvästi: setId(7), setName("Bond"). Ymmärrät, mikä omaisuus mihinkin kentälle kuuluu. Mutta setterillä on ongelma. Ensinnäkin saatat unohtaa määrittää jotain, ja toiseksi objektisi osoittautuu muuttuvaksi. Tämä ei ole säikeen turvallista ja heikentää hieman koodin luettavuutta. Siksi ihmiset keksivät upean mallin - Builder.
Mitä tämä on? Yritetään yhdistää molempien lähestymistapojen – asettajan ja rakentajan – edut yhdeksi. Teemme tietyn objektin, Builderin, jossa on myös Id- ja Name-kentät, joka itse rakennetaan asettajan perusteella ja jossa on Build-metodi, joka palauttaa sinulle uuden käyttäjän kaikkine parametreineen. Saamme muuttumattoman esineen ja asettajan. Viileä!
Mitkä ovat ongelmat? Tässä meillä on klassinen Builder. Ongelmana on, että voimme silti unohtaa tarkistaa jollain kentällä. Ja jos unohdimme vierailla ID:ssä, tässä tapauksessa Builderissa se alustetaan nollaan, koska int-tyyppi ei ole nollattavissa. Ja jos teemme nimeksi "Bond" ja unohdamme vierailla henkilöllisyystodistuksella, saamme uuden käyttäjän, jonka tunnus on "0" ja nimi "Bond". Ei siistiä.
Yritetään taistella tätä vastaan. Muutamme Builderissa int muotoon int, jotta se on mitätöitävissä. Nyt kaikki on hienoa.
Jos yritämme luoda Käyttäjän nimellä "Bond", unohtamatta laittaa hänen tunnuksensa, saamme nollaosoittimen poikkeuksen, koska tunnus ei ole mitätöitävissä ja Builderilla on tyhjä, nimenomaan osoitinpoikkeus.
Mutta voimme silti unohtaa laittaa nimen, joten asetamme objektin toiston arvoksi nolla. Nyt kun rakennamme objektimme Builderista, se tarkistaa, että kenttä ei ole tyhjä. Eikä siinä vielä kaikki.
Katsotaanpa viimeistä esimerkkiä. Tässä tapauksessa, jos laittaisimme jotenkin nollan ID-ajoaikaan, olisi hienoa heti tietää, että teit sen, eikä ole siistiä, että teet nyt virheen.
Sinun ei tarvitse antaa virhettä käyttäjän luomisen yhteydessä, vaan kun asetat tunnukselle nollan. Siksi Builderissa muutamme setterin Kokonaisluvun arvoksi int, ja hän vannoo heti, että he heittivät nollan.
Lyhyesti sanottuna, mitä järkeä on? On olemassa yksinkertainen Builder-kuvio, mutta jopa sen toteutuksessa on joitain hienouksia, joten on erittäin siistiä tarkastella kuvioiden erilaisia toteutuksia. Jokaisella mallilla on kymmeniä toteutuksia. Tämä kaikki on erittäin mielenkiintoista.
Kuinka kirjoitamme Builderin tuotantokoodiin? Tässä on käyttäjämme. Liitämme siihen Builder-kierron Lombok-kirjastosta, ja se itse luo meille Builderin. Eli emme kirjoita mitään koodia, mutta Java luulee jo, että tällä luokalla on Builder, ja voimme kutsua sitä näin.
Olen jo sanonut, että Javassa on kirjastot melkein kaikelle, mukaan lukien Lombok, hieno kirjasto, jonka avulla voit välttää kirjoituslevyn kirjoittamista. Rakentaja, GET.
Kuviot voivat olla arkkitehtonisia - liittyä ei vain yhteen luokkaan, vaan koko järjestelmään. Järjestelmäsuunnittelussa on niin hieno periaate: Yhden vastuun periaate. Mistä hän puhuu? Se, että jokaisen luokan on oltava vastuussa joistakin omista toiminnoistaan. Tässä tapauksessa meillä on ohjain, joka kommunikoi käyttäjien, JSON-objektien kanssa. On Facade, joka muuntaa JSON-objektit malleiksi, joiden kanssa Java-sovellus sitten toimii. On olemassa palvelu, jolla on monimutkainen logiikka ja joka toimii näiden mallien kanssa. On Data Access Object, joka laittaa nämä mallit tietokantaan ja hakee ne tietokannasta. Ja siellä on itse tietokanta. Toisin sanoen, se ei ole kaikki yhdessä luokassa, vaan teemme viisi eri luokkaa, ja se on toinen malli.
Kun olet enemmän tai vähemmän oppinut Javaa, on hienoa kirjoittaa oma projektisi, jossa on tietokanta, joka toimii muiden API:iden kanssa ja paljastaa palvelinsovelluksesi REST API -asiakkaille. Tämä olisi hieno asia lisätä ansioluetteloosi, se olisi siisti loppu koulutuksellesi. Tämän avulla voit mennä ja saada työtä.
Tässä on esimerkki palvelinsovelluksestani. Toisena vuonna kirjoitin tutkielman poikien kanssa. He kirjoittivat mobiilisovellusta tapahtumien järjestämiseen. Siellä käyttäjät voivat kirjautua sisään VKontakten kautta, sijoittaa pisteitä kartalle, luoda tapahtumia, kutsua ystäviään, tallentaa kuvia tapahtumista jne.
Mitä tein projektissa? Kirjoitin palvelinsovelluksen Spring Bootissa käyttämättä SQL:ää. En tuntenut häntä, käytin JPA:ta. Mitä se voisi tehdä? Kirjaudu VK:hen OAuth-2:n kautta. Ota käyttäjän tunnus, mene VK:hen sen kanssa, tarkista, että se on oikea käyttäjä. Vastaanota tietoja käyttäjistä VKontakten kautta. Se pystyi tallentamaan tiedot tietokantaan, myös JPA:n kautta. Tallenna kuvat ja muut tiedostot taitavasti tietokoneen muistiin ja tallenna linkit niihin tietokantaan. Tuolloin en tiennyt, että tietokannassa oli CLOB-objekteja, joten tein sen näin. Siellä oli REST API käyttäjille, asiakassovelluksille. Ja perustoiminnallisuudelle tehtiin yksikkötestejä.
[…] Pieni esimerkki onnistuneesta Java-oppimisestani. Ensimmäisenä yliopistovuotena minulle opetettiin C# ja annettiin ymmärrys OOP-ohjelmoinnista - mitä luokat, rajapinnat, abstraktio ovat ja miksi niitä tarvitaan. Se auttoi minua paljon. Ilman tätä Javan oppiminen on melko vaikeaa, ei ole selvää, miksi luokkia tarvitaan.
Toisena yliopistovuotena taas opetettiin Java-ydintä, mutta en jäänyt siihen, menin itse opiskelemaan kevättä ja kirjoitin kurssipaperin, projektini, josta mainitsin yllä. Ja kaiken tämän myötä menin harjoittelijaksi Yandexiin, läpäisin haastattelun ja pääsin Yandex.Marketille. Siellä kirjoitin taustaohjelman Berulle, tämä on markkinapaikkamme, ja itse Yandex.Marketille.
Sen jälkeen kuusi kuukautta sitten siirryin toiseen tiimiin samalla Marketilla. Teemme analytiikkaa liikekumppaneille. Olemme analyyttisessä alustassa, meitä on kolme taustalla, joten minulla on erittäin suuri vaikutusvalta projektiin. Se on itse asiassa erittäin mielenkiintoista. Toisin sanoen tarjoamme itse asiassa tietoa markkinoista - mitä myynti on, missä kategorioissa, missä malleissa, liikekumppaneille, suurille tunnetuille yrityksille. Ja meitä on vain kolme, me kirjoitamme tämän koodin, ja se on erittäin siistiä.
Kiitos! Hyödyllisiä linkkejä:
- .
- .
- .
- .
- .
- .
- .
- .
Lähde: will.com