En que se diferencia Java doutras linguaxes populares? Por que debería ser Java o primeiro idioma en aprender? Imos crear un plan que che axude a aprender Java desde cero e aplicando habilidades de programación noutros idiomas. Imos enumerar as diferenzas entre crear código de produción en Java e desenvolver noutros idiomas. Mikhail Zatepyakin leu este informe nunha reunión para futuros participantes Yandex e outros desenvolvedores principiantes: reunión de Java Junior.
- Ola a todos, chámome Misha. Son un programador de Yandex.Market, e hoxe vouche dicir por que aprender Java e como facelo de forma eficaz. Podes facer unha pregunta razoable: por que vou contar esta historia e non un programador forte con moitos anos de experiencia? O caso é que eu mesmo estudei Xava hai pouco, hai un ano e medio, polo que aínda lembro como era e que trampas hai.
Hai un ano fixen prácticas en Yandex.Market. Desenvolvín o backend para Beru, para o propio Market, probablemente o usaches. Agora sigo traballando alí, nun equipo diferente. Creamos unha plataforma analítica para Yandex.Market para socios comerciais.
Imos comezar. Por que aprender Java desde un punto de vista práctico? O caso é que Java é unha linguaxe de programación moi famosa. Ten unha comunidade moi grande.
Por exemplo, existe un índice TIOBE deste tipo, un índice popular da popularidade das linguaxes de programación, e Java ocupa o primeiro lugar alí. Ademais, nos sitios de traballo, probablemente notarás que a maioría das vacantes son sobre Java, é dicir, desenvolvendo en Java, sempre podes atopar un traballo.
Dado que a comunidade é moi grande, calquera pregunta que teñas atopará unha resposta nalgúns Stack Overflow ou noutros sitios. Ademais, ao desenvolver en Java, realmente estás escribindo código na JVM, polo que podes cambiar facilmente a Kotlin, Scala e outras linguaxes que usan a JVM.
Que ten de bo Java desde o punto de vista ideolóxico? Hai diferentes linguaxes de programación. Resolven diferentes problemas, xa o sabes. Por exemplo, Python é excelente para escribir scripts dunha liña para resolver problemas rápidos.
No lado positivo, pode controlar totalmente o código executable. Por exemplo, temos coches, coches sen condutor Yandex, o seu código está escrito en plus. Por que? Java ten tal cousa - Garbage Collector. Borra a memoria RAM de obxectos innecesarios. Esta cousa comeza espontaneamente e fai stop-the-world, é dicir, para o resto do programa e vai a contar obxectos, memoria clara de obxectos. Se tal cousa funciona nun dron, non é xenial. O teu dron conducirá en liña recta, neste momento borrará a súa memoria e non mirará para nada a estrada. Polo tanto, o dron está escrito sobre os profesionais.
Que problemas resolve Java? É principalmente unha linguaxe para desenvolver grandes programas que son escritos ao longo de anos, por decenas ou centos de persoas. En particular, gran parte do backend en Yandex.Market está escrito en Java. Temos un equipo distribuído en varias cidades, dez persoas en cada unha. E o código é fácil de manter, foi compatible durante dez anos ou máis e, ao mesmo tempo, entran novas persoas e comprenden este código.
Que características debe ter unha linguaxe para que o código que nela sexa facilmente soportado e para que poida desenvolverse facilmente en grandes equipos. En primeiro lugar, debe ser código lexible e debe ser fácil de implementar solucións arquitectónicas complexas. É dicir, debería ser doado escribir abstraccións de alto nivel, etc. Todo isto é o que nos proporciona Java. Esta é unha linguaxe orientada a obxectos. É moi sinxelo implementar abstraccións de alto nivel e arquitecturas complexas.
Tamén hai moitos frameworks e bibliotecas para Java, porque a linguaxe ten máis de 15 anos. Durante este tempo, todo o que se podía escribir estaba escrito nel, polo que hai toneladas de bibliotecas para todo o que poidas necesitar.
Que habilidades básicas, na miña opinión, debería ter un xogador principiante de JA? En primeiro lugar, este é o coñecemento da linguaxe principal de Java. O seguinte é algún tipo de marco de inxección de dependencias. O seguinte orador, Kirill, falará sobre isto máis a fondo. Non vou profundar demasiado. O seguinte é a arquitectura e os patróns de deseño. Necesitamos ser capaces de escribir código arquitectónicamente bonito para poder escribir aplicacións grandes. E este é algún tipo de SQL ou ORM para tarefas de traballo coa base de datos. E isto aplícase máis ao backend.
Vaia! Núcleo Java. Realmente non descubrirei América aquí, necesitas coñecer o idioma en si. Ao que debes prestar atención. En primeiro lugar, Java lanzou moitas versións nos últimos anos, é dicir, en 2014-2015 lanzouse a sétima, despois a oitava, a novena, a décima, moitas versións novas e introducíronse nelas moitas cousas interesantes. , por exemplo, a API de Java Stream , lambda, etc. Cousas moi chulas, frescas, chulas que se usan no código de produción, que preguntan nas entrevistas e que precisas saber. Polo tanto, non debes coller un libro do estante da biblioteca Java-4 e ir aprendelo. Este é o noso plan: aprendemos Java-8 ou superior.
Prestamos moita atención a innovacións como Stream API, var, etc. Pregúntanse durante as entrevistas e úsanse constantemente na produción. É dicir, a API de Stream é moito máis xenial que os loops, en xeral, unha cousa moi interesante. Asegúrese de prestar atención.
E hai todo tipo de cousas como iteradores, excepcións, etc. Cousas que che parecen pouco importantes, sempre que escribas un pequeno código ti mesmo. Non precisas destas excepcións, quen as necesita de todos os xeitos? Pero definitivamente preguntaránselles nas entrevistas, definitivamente che serán útiles na produción. En xeral, debes prestar atención ás excepcións, iteradores e outras cousas.
Estruturas de datos. Non podes quedar sen estruturas, pero será xenial se non só sabes que hai conxuntos, dicionarios e follas. E tamén diferentes implementacións de estruturas. Por exemplo, o mesmo dicionario en Java ten moitas implementacións, incluíndo HashMap e TreeMap. Teñen diferentes asintóticas, están estruturadas de forma diferente por dentro. Debes saber en que se diferencian e cando usar cal.
Tamén será moi xenial se sabes como funcionan internamente estas estruturas de datos. É dicir, non é fácil coñecer as súas asintóticas: canto funciona a aposta, canto tempo funciona o pase, pero como funciona a estrutura no interior, por exemplo, que é un balde en HashMap.
Tamén paga a pena prestar atención ás árbores e aos gráficos. Son cousas que non son moi comúns no código de produción, pero son populares nas entrevistas. En consecuencia, ten que ser capaz de atravesar árbores, gráficos en ancho e profundidade. Todos estes son algoritmos sinxelos.
Tan pronto como comeces a escribir calquera código grande, complexo, usando bibliotecas, código multiclase, entenderás que é difícil para ti sen construír sistemas e resolver dependencias. Estes son principalmente Maven e Gradle. Permítenche importar bibliotecas ao teu proxecto nunha soa liña. É dicir, escribe un xml dunha liña e importa bibliotecas ao proxecto. Grandes sistemas. Son aproximadamente iguais, usa un: Maven ou Gradle.
A continuación - algún tipo de sistema de control de versións. Recomendo Git porque é popular e hai toneladas de tutoriais. Case todo o mundo usa Git, é unha cousa xenial, non podes vivir sen el.
E algún tipo de ambiente de desenvolvemento. Recomendo IntelliJ Idea. Acelera moito o proceso de desenvolvemento, axúdache moito, escribe todo o código estándar para ti, en xeral, é xenial.
Ligazóns da diapositiva: ,
SQL. Un pouco sobre backenders. En realidade houbo un caso divertido aquí. Dous días antes da miña segunda entrevista de prácticas, unha rapaza de recursos humanos chamoume e díxome que en dous días me preguntarían sobre SQL e HTTP, necesitaba aprendelo. E non sabía case nada sobre SQL ou HTTP. E atopei este sitio xenial - . Aprendín SQL en 12 horas, quero dicir, sintaxe SQL, como escribir consultas SELECT, JOIN, etc. Sitio moi chulo, recoméndoo encarecidamente. De feito, en 12 horas aprendín o 90% do que sei agora.
E tamén é xenial coñecer a arquitectura de bases de datos. Estes son todo tipo de claves, índices, normalización. Hai unha serie de publicacións sobre isto en Habré.
En Java, ademais de SQL, hai todo tipo de sistemas de mapeo relacional con obxectos como JPA. Hai algún código. No primeiro método hai algún código SQL - SELECT ID name FROM info.users WHERE id IN userIds. Da base de datos de usuarios, da táboa, obtéñense os seus ID e nomes.
A continuación, hai un certo mapeador que converte un obxecto da base nun obxecto Java. E hai un terceiro método a continuación que realmente executa este código. Todo isto pódese substituír usando JPA cunha liña, que se escribe a continuación. Fai o mesmo: busca Todo ByIdIn. É dicir, baseándose no nome do método, xera unha consulta SQL para ti.
Cousa moi chula. Eu mesmo, cando non sabía SQL, usaba JPA. En xeral, preste atención. Se es demasiado preguiceiro para aprender SQL, é un desastre. E, en xeral, lume!
Primavera. Quen escoitou falar do marco da primavera? Xa vedes cantos sodes? Non sen razón. Spring inclúese nos requisitos de cada segunda vacante de backend de Java. Sen el, realmente non hai ningún lugar nun gran desenvolvemento. Que é a primavera? En primeiro lugar, este é un marco de inxección de dependencias. Sobre isto tamén seguinte orador. Pero en resumo, isto é algo que che permite facilitar a importación das dependencias dunhas clases a outras. É dicir, simplifícase o coñecemento das dependencias.
Spring Boot é unha peza de Spring que che permite executar a túa aplicación de servidor cun só botón. Vai a THID, preme un par de botóns e agora tes a túa aplicación de servidor en funcionamento no localhost 8080. É dicir, aínda non escribiu unha soa liña de código, pero xa está a funcionar. Cousa moi chula. Se escribes algo propio, lume!
A primavera é un marco moi grande. Non só recolle a súa aplicación de servidor e resolve a inxección de dependencias. Permítelle facer un montón de cousas, incluíndo a creación de métodos da API REST. É dicir, escribiu algún método e anegoulle a anotación Get mapping. E agora xa tes algún método en localhost que che escribe Ola mundo. Dúas liñas de código e funciona. Cousas chulas.
A primavera tamén facilita a escritura de probas. Non hai forma de probar en gran desenvolvemento. O código debe ser probado. Para este fin, Java ten unha biblioteca xenial JUnit 5. E JUnit en xeral, pero a última versión é a quinta. Hai de todo para probar, todo tipo de afirmacións e outras cousas.
E hai un marco Mockito incrible. Imaxina que tes algunha funcionalidade que queres probar. A funcionalidade fai moitas cousas, incluíndo, nalgún lugar do medio, inicia sesión en VKontakte co teu ID, por exemplo, e recibe o nome e apelidos do usuario de VKontakte desde o ID. Probablemente non inclúas VKontakte nas probas, é estraño. Pero cómpre probar a funcionalidade, así que fixeches esta clase, usando Mockito, mok it, imitalo.
Dirás que cando unha solicitude chega a esta clase cun ID tal ou tal, devolve algún apelido, por exemplo, Vasya Pupkin. E funcionará. É dicir, probarás toda a funcionalidade de mok one class. Cousa moi chula.
Patróns de deseño. Que é? Estes son modelos para resolver problemas típicos que xorden no desenvolvemento. No desenvolvemento, moitas veces xorden problemas idénticos ou similares que sería xenial resolver dalgún xeito ben. Polo tanto, a xente presentou as mellores prácticas, certos modelos, sobre como resolver estes problemas.
Hai un sitio web cos patróns máis populares: refactoring.guru, podes lelo, descubrir que patróns hai, ler unha morea de teorías. O problema é que é practicamente inútil. De feito, os patróns sen práctica non son especialmente útiles.
Oirá falar dalgúns patróns como Singletone ou Builder. Quen escoitou estas palabras? Moita xente. Hai patróns tan sinxelos que podes implementar ti mesmo. Pero a maioría dos patróns: estratexia, fábrica, fachada - non está claro onde aplicalos.
E ata que vexas na práctica no código doutra persoa un lugar ao que se aplica este patrón, non poderás aplicalo ti mesmo. Polo tanto, a práctica é moi importante con patróns. E só ler sobre eles en refactoring.guru non é moi útil, pero definitivamente paga a pena facelo.
Por que son necesarios patróns? Digamos que tes unha determinada clase de usuario. Ten un Id e un Nome. Cada Usuario debe ter un Id e un Nome. Arriba á esquerda está a aula.
Cales son as formas de inicializar o usuario? Hai dúas opcións: un construtor ou un setter. Cales son as desvantaxes de ambos enfoques?
Construtor. novo usuario (7, "Bond"), está ben. Agora digamos que non temos unha clase de Usuario, senón outra, con sete campos numéricos. Terá un constructor que contén sete números consecutivos. Non está claro cales son estes números e cal deles pertence a que propiedade. O deseñador non é xenial.
A segunda opción é setter. Escribes claramente: setId(7), setName(“Bond”). Entendes que propiedade pertence a que campo. Pero o setter ten un problema. En primeiro lugar, pode esquecerse de asignar algo e, en segundo lugar, o seu obxecto resulta ser mutable. Isto non é seguro para fíos e reduce lixeiramente a lexibilidade do código. É por iso que a xente se lle ocorreu un patrón xenial: Builder.
De que se trata isto? Tentemos combinar as vantaxes de ambos os enfoques (setter e constructor) nun só. Facemos un determinado obxecto, Builder, que tamén terá campos Id e Nome, que se construirá en función do setter, e que terá un método Build que che devolve un novo Usuario con todos os parámetros. Obtemos un obxecto inmutable e un setter. Genial!
Cales son os problemas? Aquí temos o clásico Builder. O problema é que aínda podemos esquecernos de comprobar nalgún campo. E se nos esquecemos de visitar o ID, neste caso en Builder inicialízase a cero, porque o tipo int non é nulo. E se facemos o Nome "Bond" e esquecemos de visitar a oficina de DNI, teremos un novo Usuario con id "0" e o nome "Bond". Non mola.
Imos tentar loitar contra isto. En Builder cambiaremos int a int para que sexa anulable. Agora todo está xenial.
Se tentamos crear un Usuario co nome "Bond", esquecendo poñer o seu ID, obteremos unha excepción de punteiro nulo, porque o ID non é nulo, e o Builder ten unha excepción de punteiro nula, concretamente.
Pero aínda podemos esquecer poñer un nome, polo que establecemos a reprodución de obxectos como nula. Agora, cando construímos o noso obxecto desde Builder, comproba que o campo non é anulable. E iso non é todo.
Vexamos o último exemplo. Neste caso, se dalgunha maneira poñemos nulo no tempo de execución de ID, sería xenial saber inmediatamente que o fixeches e non é xenial que esteas a cometer un erro agora.
Debes lanzar un erro non no momento da creación do usuario, senón cando estableces nulo no ID. Polo tanto, en Builder cambiaremos o setter Integer a int, e inmediatamente xurará que botaron a nulo.
En resumo, cal é o punto? Hai un patrón de Builder sinxelo, pero incluso a súa implementación ten algunhas sutilezas, polo que é moi xenial mirar diferentes implementacións de patróns. Cada patrón ten decenas de implementacións. Todo isto é moi interesante.
Como escribimos Builder no código de produción? Aquí está o noso Usuario. Achegámoslle unha rotación de Builder desde a biblioteca de Lombok, e el mesmo xera un Builder para nós. É dicir, non escribimos ningún código, pero Java xa pensa que esta clase ten un Builder, e podemos chamalo así.
Xa dixen que Java ten bibliotecas para case todo, incluída a Lombok, unha biblioteca xenial que che permite evitar a escritura estándar. Construtor, GET.
Os patróns poden ser arquitectónicos - relacionados non só cunha clase, senón co sistema no seu conxunto. Hai un principio tan xenial no deseño do sistema: o Principio de Responsabilidade Única. De que está a falar? O feito de que cada clase debe ser responsable dalgunha das súas propias funcionalidades. Neste caso, temos un controlador que se comunica cos usuarios, obxectos JSON. Hai Facade, que converte obxectos JSON en modelos cos que despois traballará a aplicación Java. Hai un Servizo que ten unha lóxica complexa que funciona con estes modelos. Hai un obxecto de acceso a datos que coloca estes modelos na base de datos e os recupera da base de datos. E está a propia base de datos. Noutras palabras, non está todo nunha clase, pero estamos facendo cinco clases diferentes, e ese é outro patrón.
Unha vez que aprendes máis ou menos Java, é xenial escribir o teu propio proxecto que teña unha base de datos, traballar con outras API e expor a túa aplicación de servidor aos clientes da API REST. Esta sería unha gran cousa para engadir ao teu currículo, sería un final xenial para a túa educación. Con isto podes ir buscar traballo.
Aquí tes un exemplo da miña aplicación de servidor. No meu segundo ano, escribín un traballo de trimestre cos rapaces. Estaban escribindo unha aplicación móbil para organizar eventos. Alí, os usuarios podían iniciar sesión a través de VKontakte, colocar puntos no mapa, crear eventos, invitar aos seus amigos a eles, gardar imaxes de eventos, etc.
Que fixen no proxecto? Escribiu unha aplicación de servidor en Spring Boot sen usar SQL. Eu non o coñecía, usei JPA. Que podería facer? Inicie sesión en VK mediante OAuth-2. Colle o token do usuario, vai a VK con el, comproba que é un usuario real. Reciba información sobre os usuarios a través de VKontakte. Puido gardar información nunha base de datos, tamén a través de JPA. Garda con habilidade imaxes e outros ficheiros na memoria do ordenador e garda ligazóns a eles na base de datos. Nese momento non sabía que había obxectos CLOB na base de datos, así que o fixen deste xeito. Había unha API REST para usuarios, aplicacións cliente. E houbo probas unitarias para a funcionalidade básica.
[…] Un pequeno exemplo da miña aprendizaxe exitosa de Java. No meu primeiro ano na universidade, ensináronme C# e entendín a programación POO: que son as clases, interfaces, abstracción e por que son necesarias. Axudoume moito. Sen isto, aprender Java é bastante difícil; non está claro por que se necesitan clases.
No meu segundo ano na universidade, volveron a ensinar Java core, pero non me quedei aí, fun eu mesmo estudar Spring e escribín un traballo do curso, o meu proxecto, que mencionei anteriormente. E con todo isto, fun a realizar prácticas en Yandex, pasei unha entrevista e entrei en Yandex.Market. Alí escribín o backend para Beru, este é o noso mercado e para o propio Yandex.Market.
Despois diso, hai seis meses, paseime a outro equipo dentro do mesmo Mercado. Facemos analíticas para socios comerciais. Estamos na plataforma analítica, somos tres no backend, polo que teño unha cota moi grande de influencia no proxecto. É moi interesante, de feito. É dicir, en realidade proporcionamos datos sobre o mercado: cales son as vendas, en que categorías, en que modelos, para socios comerciais, grandes empresas coñecidas. E só somos tres, escribimos este código, e é moi chulo.
Grazas! Ligazóns útiles:
- .
- .
- .
- .
- .
- .
- .
- .
Fonte: www.habr.com