En què es diferencia Java d'altres idiomes populars? Per què ha de ser Java el primer llenguatge a aprendre? Creem un pla que us ajudarà a aprendre Java tant des de zero com aplicant habilitats de programació en altres idiomes. Enumerem les diferències entre la creació de codi de producció en Java i el desenvolupament en altres idiomes. Mikhail Zatepyakin va llegir aquest informe en una reunió per a futurs participants Yandex i altres desenvolupadors principiants - Trobada Java Junior.
—Hola a tothom, em dic Misha. Sóc desenvolupador de Yandex.Market i avui us explicaré per què aprendre Java i com fer-ho de manera eficaç. Podeu fer una pregunta raonable: per què explicaré aquesta història, i no un desenvolupador fort amb molts anys d'experiència? El cas és que jo mateix vaig estudiar Java fa poc, fa aproximadament un any i mig, així que encara recordo com era i quines trampes hi ha.
Fa un any vaig fer pràctiques a Yandex.Market. Vaig desenvolupar el backend per a Beru, per al propi Mercat, probablement l'has fet servir. Ara hi continuo treballant, en un equip diferent. Creem una plataforma analítica per a Yandex.Market per a socis comercials.
Comencem. Per què aprendre Java des d'un punt de vista pràctic? El fet és que Java és un llenguatge de programació molt famós. Té una comunitat molt gran.
Per exemple, hi ha un índex TIOBE, un índex popular de la popularitat dels llenguatges de programació, i Java ocupa el primer lloc. A més, als llocs de treball, probablement notareu que la majoria de les vacants són sobre Java, és a dir, desenvolupant-vos en Java, sempre podeu trobar feina.
Com que la comunitat és molt gran, qualsevol pregunta que tingueu trobareu una resposta en alguns Stack Overflow o en altres llocs. A més, quan es desenvolupa en Java, en realitat esteu escrivint codi a la JVM, de manera que podeu canviar fàcilment a Kotlin, Scala i altres idiomes que utilitzen la JVM.
Què té de bo Java des del punt de vista ideològic? Hi ha diferents llenguatges de programació. Solucionen problemes diferents, ja ho sabeu. Per exemple, Python és ideal per escriure scripts d'una línia per resoldre problemes ràpids.
Al costat positiu, podeu controlar completament el codi executable. Per exemple, tenim cotxes, cotxes sense conductor Yandex, el seu codi està escrit en avantatges. Per què? Java té una cosa així: Garbage Collector. Esborra la memòria RAM d'objectes innecessaris. Aquesta cosa comença espontàniament i fa stop-the-world, és a dir, atura la resta del programa i passa a comptar objectes, memòria clara dels objectes. Si una cosa així funciona en un dron, no és genial. El vostre drone conduirà recte, en aquest moment esborrarà la seva memòria i no mirarà gens a la carretera. Per tant, el drone està escrit en els professionals.
Quins problemes soluciona Java? És principalment un llenguatge per desenvolupar grans programes escrits al llarg dels anys, per desenes o centenars de persones. En particular, gran part del backend de Yandex.Market està escrit en Java. Tenim un equip distribuït per diverses ciutats, deu persones a cadascuna. I el codi és fàcil de mantenir, ha estat suportat durant deu anys o més i, al mateix temps, entra gent nova i entén aquest codi.
Quines característiques ha de tenir un llenguatge perquè el codi que hi ha sigui fàcil de suportar i que es pugui desenvolupar fàcilment en grans equips. En primer lloc, hauria de ser un codi llegible i hauria de ser fàcil implementar solucions arquitectòniques complexes. És a dir, hauria de ser fàcil escriure abstraccions d'alt nivell, etc. Tot això és el que ens proporciona Java. Aquest és un llenguatge orientat a objectes. És molt fàcil implementar abstraccions d'alt nivell i arquitectures complexes.
També hi ha molts frameworks i biblioteques per a Java, perquè el llenguatge té més de 15 anys. Durant aquest temps, hi havia escrit tot el que es podia escriure, de manera que hi ha tones de biblioteques per a tot el que necessiteu.
Quines habilitats bàsiques, al meu entendre, hauria de tenir un jugador principiant de JA? En primer lloc, això és el coneixement del llenguatge bàsic de Java. El següent és una mena de marc d'injecció de dependències. El següent ponent, Kirill, en parlarà amb més detall. No aprofundiré massa. El següent és l'arquitectura i els patrons de disseny. Hem de ser capaços d'escriure codi arquitectònicament bonic per escriure aplicacions grans. I això és una mena de SQL o ORM per a tasques de treball amb la base de dades. I això s'aplica més al backend.
Va! Nucli de Java. Realment no descobriré Amèrica aquí; necessiteu conèixer l'idioma en si. En què hauries de parar atenció. En primer lloc, Java ha llançat moltes versions en els últims anys, és a dir, el 2014-2015 es va llançar la setena, després la vuitena, la novena, la desena, moltes versions noves i s'hi van introduir moltes coses interessants. , per exemple, l'API de Java Stream , lambda, etc. Coses molt xules, fresques, genials que s'utilitzen en el codi de producció, què pregunten a les entrevistes i que cal saber. Per tant, no hauríeu d'agafar un llibre de la prestatgeria de la biblioteca Java-4 i anar-lo a aprendre. Aquest és el nostre pla: aprenem Java-8 o superior.
Estem molt atents a les innovacions com Stream API, var, etc. Es demanen durant les entrevistes i s'utilitzen constantment en la producció. És a dir, l'API Stream és molt més genial que els bucles, en general, una cosa molt interessant. Assegureu-vos de parar atenció.
I hi ha tot tipus de coses com iteradors, excepcions, etc. Coses que us semblen poc importants, sempre que escriviu un petit codi vosaltres mateixos. No necessiteu aquestes excepcions, qui les necessita de totes maneres? Però definitivament se'ls demanarà a les entrevistes, segur que us seran útils en la producció. En general, hauríeu de parar atenció a les excepcions, iteradors i altres coses.
Estructures de dades. No us podeu quedar sense estructures, però serà fantàstic si no només sabeu que hi ha conjunts, diccionaris i fulls. I també diferents implementacions d'estructures. Per exemple, el mateix diccionari de Java té moltes implementacions, com HashMap i TreeMap. Tenen diferents asimptòtics, estan estructurats de manera diferent per dins. Heu de saber en què es diferencien i quan utilitzar quins.
També serà molt divertit si sabeu com funcionen aquestes estructures de dades internament. És a dir, no és fàcil conèixer els seus asimptòtics: quant funciona l'aposta, quant de temps funciona el passi, però com funciona l'estructura a l'interior, per exemple, què és una galleda a HashMap.
També val la pena parar atenció als arbres i als gràfics. Són coses que no són molt habituals en el codi de producció, però són populars a les entrevistes. En conseqüència, cal ser capaç de recórrer arbres, gràfics en amplada i profunditat. Tots aquests són algorismes senzills.
Tan bon punt comenceu a escriure qualsevol codi gran, complex, amb biblioteques, codi multiclasse, us adonareu que és difícil per a vosaltres sense construir sistemes i resoldre dependències. Aquests són principalment Maven i Gradle. Us permeten importar biblioteques al vostre projecte en una línia. És a dir, escriviu un xml d'una línia i importeu biblioteques al projecte. Grans sistemes. Són aproximadament els mateixos, utilitzeu-ne un: Maven o Gradle.
A continuació, una mena de sistema de control de versions. Recomano Git perquè és popular i hi ha un munt de tutorials. Gairebé tothom fa servir Git, és una cosa genial, no pots viure sense ell.
I algun tipus d'entorn de desenvolupament. Recomano IntelliJ Idea. Accelera molt el procés de desenvolupament, us ajuda molt, us escriu tot el codi normal, en general, és genial.
Enllaços de la diapositiva: ,
SQL. Una mica sobre els backenders. De fet, hi va haver un cas divertit aquí. Dos dies abans de la meva segona entrevista de pràctiques, una noia de recursos humans em va trucar i em va dir que en dos dies em preguntarien sobre SQL i HTTP, havia d'aprendre-ho. I no sabia gairebé res sobre SQL o HTTP. I he trobat aquest lloc fantàstic - . Vaig aprendre SQL en 12 hores, vull dir, sintaxi SQL, com escriure consultes SELECT, JOIN, etc. Lloc molt xulo, el recomano molt. De fet, en 12 hores vaig aprendre el 90% del que sé ara.
I també és fantàstic conèixer l'arquitectura de bases de dades. Es tracta de tot tipus de claus, índexs, normalització. Hi ha una sèrie de publicacions sobre això a Habré.
A Java, a més d'SQL, hi ha tot tipus de sistemes de mapes relacionats amb objectes com ara JPA. Hi ha algun codi. En el primer mètode hi ha algun codi SQL: SELECT id name FROM info.users WHERE id IN userIds. De la base de dades d'usuaris, de la taula, s'obtenen els seus ID i noms.
A continuació, hi ha un determinat mapeador que converteix un objecte de la base en un objecte Java. I hi ha un tercer mètode a continuació que realment executa aquest codi. Tot això es pot substituir mitjançant JPA amb una línia, que s'escriu a continuació. Fa el mateix: cerca All ByIdIn. És a dir, en funció del nom del mètode, us genera una consulta SQL.
Una cosa molt xula. Jo mateix, quan no coneixia SQL, vaig utilitzar JPA. En general, presteu atenció. Si ets massa mandrós per aprendre SQL, és un desastre. I, en general, foc!
Primavera. Qui ha sentit parlar d'una cosa com el marc de primavera? Veus quants de vosaltres sou? No sense raó. Spring s'inclou als requisits de cada segona vacant de backend de Java. Sense ell, realment no hi ha enlloc en un gran desenvolupament. Què és la primavera? En primer lloc, es tracta d'un marc d'injecció de dependències. Sobre això també següent orador. Però, en resum, això és una cosa que us permet facilitar la importació de les dependències d'unes classes a unes altres. És a dir, es simplifica el coneixement de les dependències.
Spring Boot és una peça de Spring que us permet executar la vostra aplicació de servidor amb un sol botó. Aneu a THID, premeu un parell de botons i ara teniu la vostra aplicació de servidor en funcionament a localhost 8080. És a dir, encara no heu escrit ni una línia de codi, però ja funciona. Una cosa molt xula. Si escrius alguna cosa teva, foc!
La primavera és un marc molt gran. No només recull la vostra aplicació de servidor i resol la injecció de dependències. Us permet fer un munt de coses, inclosa la creació de mètodes d'API REST. És a dir, heu escrit algun mètode i hi heu adjuntat l'anotació Get mapping. I ara ja teniu algun mètode a localhost que us escriu Hello world. Dues línies de codi i funciona. Coses guais.
La primavera també facilita la redacció de proves. No hi ha manera sense proves en grans desenvolupaments. Cal provar el codi. Amb aquest propòsit, Java té una biblioteca fantàstica JUnit 5. I JUnit en general, però l'última versió és la cinquena. Hi ha de tot per provar, tota mena d'afirmacions i altres coses.
I hi ha un marc Mockito fantàstic. Imagineu que teniu alguna funcionalitat que voleu provar. La funcionalitat fa moltes coses, inclòs, en algun lloc del mig, inicia sessió a VKontakte amb el vostre identificador, per exemple, i rep el nom i els cognoms de l'usuari de VKontakte de l'ID. Probablement no incloureu VKontakte a les proves, això és estrany. Però heu de provar la funcionalitat, així que heu fet aquesta classe, utilitzant Mockito, mok it, imita-la.
Diràs que quan arriba una sol·licitud a aquesta classe amb un identificador tal i tal, retorna algun cognom, per exemple, Vasya Pupkin. I funcionarà. És a dir, provaràs tota la funcionalitat de mok one class. Una cosa molt xula.
Patrons de disseny. Què és això? Aquestes són plantilles per resoldre problemes típics que sorgeixen en el desenvolupament. En el desenvolupament, sovint sorgeixen problemes idèntics o similars que seria fantàstic resoldre d'alguna manera bé. Per tant, la gent va proposar bones pràctiques, determinades plantilles, sobre com resoldre aquests problemes.
Hi ha un lloc web amb els patrons més populars: refactoring.guru, podeu llegir-lo, esbrinar quins patrons hi ha, llegir un munt de teoria. El problema és que pràcticament és inútil. De fet, els patrons sense pràctica no són especialment útils.
Escoltaràs alguns patrons com Singletone o Builder. Qui va sentir aquestes paraules? Molta gent. Hi ha patrons tan senzills que podeu implementar vosaltres mateixos. Però la majoria dels patrons: estratègia, fàbrica, façana - no està clar on aplicar-los.
I fins que no vegeu a la pràctica en el codi d'una altra persona un lloc al qual s'aplica aquest patró, no podreu aplicar-lo vosaltres mateixos. Per tant, la pràctica és molt important amb els patrons. I només llegir sobre ells a refactoring.guru no és molt útil, però definitivament val la pena fer-ho.
Per què es necessiten patrons? Suposem que teniu una classe d'usuari determinada. Té un identificador i un nom. Cada usuari ha de tenir un identificador i un nom. A dalt a l'esquerra hi ha l'aula.
Quines són les maneres d'iniciar l'usuari? Hi ha dues opcions: un constructor o un configurador. Quins són els inconvenients dels dos enfocaments?
Constructor. Usuari nou (7, "Bond"), d'acord. Ara diguem que no tenim una classe d'usuari, sinó una altra, amb set camps numèrics. Tindreu un constructor que conté set nombres consecutius. No està clar quins són aquests números i quin d'ells pertany a quina propietat. El dissenyador no és genial.
La segona opció és setter. Escriu clarament: setId(7), setName ("Bond"). Enteneu quina propietat pertany a quin camp. Però setter té un problema. En primer lloc, podeu oblidar-vos d'assignar alguna cosa i, en segon lloc, el vostre objecte resulta ser mutable. Això no és segur i redueix lleugerament la llegibilitat del codi. És per això que la gent va idear un patró genial: Builder.
De què va això? Intentem combinar els avantatges d'ambdós enfocaments (setter i constructor) en un. Fem un objecte determinat, Builder, que també tindrà els camps Id i Name, que es construirà en funció del setter, i que tindrà un mètode Build que et retornarà un nou Usuari amb tots els paràmetres. Obtenim un objecte immutable i un setter. Guai!
Quins són els problemes? Aquí tenim el clàssic Builder. El problema és que encara podem oblidar-nos de comprovar en algun camp. I si ens oblidem de visitar l'ID, en aquest cas a Builder s'inicialitza a zero, perquè el tipus int no es pot nul·lar. I si fem el Nom “Bond” i ens oblidem de visitar l'oficina de DNI, tindrem un nou Usuari amb id “0” i el nom “Bond”. No es guay.
Intentem lluitar contra això. Al Builder canviarem int per int perquè sigui nul·la. Ara tot és genial.
Si intentem crear un Usuari amb el nom "Bond", oblidant-nos de posar el seu ID, obtindrem una excepció de punter nul, perquè l'ID no és nul·la, i el Builder té una excepció de punter nul·la, concretament.
Però encara podem oblidar-nos de posar un nom, així que establim la reproducció d'objectes com a nul. Ara, quan construïm el nostre objecte des del Builder, comprova que el camp no es pot anul·lar. I això no és tot.
Vegem l'últim exemple. En aquest cas, si d'alguna manera posem null al temps d'execució de l'ID, seria fantàstic saber immediatament que ho heu fet i no és genial que ara us equivoqueu.
Heu de llançar un error no en el moment de la creació de l'usuari, sinó quan establiu null a l'ID. Per tant, a Builder canviarem el setter Integer per int, i immediatament jurarà que han llençat null.
En resum, quin és el sentit? Hi ha un patró de Builder senzill, però fins i tot la seva implementació té algunes subtileses, per la qual cosa és genial veure diferents implementacions de patrons. Cada patró té desenes d'implementacions. Tot això és molt interessant.
Com escrivim Builder al codi de producció? Aquí teniu el nostre Usuari. Hi adjuntem una rotació de Builder de la biblioteca de Lombok, i ell mateix ens genera un Builder. És a dir, no escrivim cap codi, però Java ja pensa que aquesta classe té un Builder, i podem anomenar-lo així.
Ja he dit que Java té biblioteques per a gairebé tot, inclosa la de Lombok, una biblioteca fantàstica que us permet evitar l'escriptura normal. Constructor, GET.
Els patrons poden ser arquitectònics, relacionats no només amb una classe, sinó amb el sistema en conjunt. Hi ha un principi genial en el disseny del sistema: el principi de responsabilitat única. De què parla? El fet que cada classe ha de ser responsable d'algunes de les seves pròpies funcionalitats. En aquest cas, tenim un controlador que es comunica amb els usuaris, objectes JSON. Hi ha Façade, que converteix objectes JSON en models amb els quals treballarà l'aplicació Java. Hi ha un Servei que té una lògica complexa que funciona amb aquests models. Hi ha un objecte d'accés a dades que posa aquests models a la base de dades i els recupera de la base de dades. I hi ha la pròpia base de dades. En altres paraules, no és tot en una classe, però estem fent cinc classes diferents, i aquest és un altre patró.
Un cop hàgiu après més o menys Java, és fantàstic escriure el vostre propi projecte que tindrà una base de dades, treballarà amb altres API i exposarà la vostra aplicació de servidor als clients de l'API REST. Això seria una gran cosa per afegir al vostre currículum, seria un final genial per a la vostra educació. Amb això pots anar a buscar feina.
Aquí teniu un exemple de la meva aplicació de servidor. Al segon any, vaig escriure un article de trimestre amb els nois. Estaven escrivint una aplicació mòbil per organitzar esdeveniments. Allà, els usuaris podien iniciar sessió mitjançant VKontakte, col·locar punts al mapa, crear esdeveniments, convidar-hi els seus amics, desar imatges d'esdeveniments, etc.
Què he fet en el projecte? Va escriure una aplicació de servidor a Spring Boot sense utilitzar SQL. No el coneixia, vaig fer servir JPA. Què podria fer? Inicieu la sessió a VK mitjançant OAuth-2. Agafeu el testimoni de l'usuari, aneu a VK amb ell, comproveu que és un usuari real. Rebre informació sobre els usuaris a través de VKontakte. Va poder desar informació en una base de dades, també mitjançant JPA. Deseu amb habilitat imatges i altres fitxers a la memòria de l'ordinador i deseu els enllaços a la base de dades. En aquell moment no sabia que hi havia objectes CLOB a la base de dades, així que ho vaig fer d'aquesta manera. Hi havia una API REST per als usuaris, aplicacions client. I hi havia proves unitàries per a la funcionalitat bàsica.
[…] Un petit exemple del meu èxit d'aprenentatge de Java. Durant el meu primer any a la universitat, em van ensenyar C# i em van donar una comprensió de la programació OOP: quines són les classes, les interfícies, l'abstracció i per què es necessiten. Em va ajudar molt. Sense això, aprendre Java és bastant difícil; no està clar per què calen classes.
En el meu segon any a la universitat, van tornar a ensenyar Java core, però no em vaig aturar aquí, vaig anar jo mateix a estudiar Spring i vaig escriure un article del curs, el meu projecte, que he esmentat més amunt. I amb tot això, vaig anar a fer pràctiques a Yandex, vaig passar una entrevista i vaig entrar a Yandex.Market. Allà vaig escriure el backend per a Beru, aquest és el nostre mercat, i per a Yandex.Market.
Després d'això, fa sis mesos, em vaig traslladar a un altre equip dins del mateix Mercat. Fem analítiques per a socis comercials. Estem a la plataforma analítica, som tres al backend, així que tinc una part molt gran d'influència en el projecte. És molt interessant, de fet. És a dir, en realitat proporcionem dades sobre el mercat: quines són les vendes, en quines categories, en quins models, per a socis comercials, grans empreses conegudes. I només som tres, escrivim aquest codi i és molt xulo.
Gràcies! Links útils:
- .
- .
- .
- .
- .
- .
- .
- .
Font: www.habr.com