Чим Java відрізняється від інших популярних мов? Чому саме Java може бути першою мовою для вивчення? Давайте складемо план, який допоможе вивчити Java як з нуля, так і із застосуванням навичок програмування іншими мовами. Перерахуємо відмінності між створенням продакшен-коду Java та розробкою іншими мовами. Михайло Затепякін прочитав цю доповідь на зустрічі для майбутніх учасників Яндекса та інших розробників-початківців — Java Junior meetup.
- Всім привіт, мене звуть Мишко. Я розробник з Яндекс.маркету, і сьогодні я розповім вам, навіщо вчити Java і як робити це ефективно. Ви можете поставити резонне питання: чому це розповідатиму я, а не якийсь сильний розробник з купою років стажу? Справа в тому, що я сам вивчав Java нещодавно, півтора року тому, тому ще пам'ятаю, як це приблизно було і які є підводні камені.
Рік тому я потрапив на стажування до Яндекс.Маркету. Розробляв бекенд для "Беру", для самого Маркета, ви напевно ним користувалися. Зараз продовжую працювати там, в іншій команді. Ми робимо аналітичну платформу Яндекс.Маркету для бізнес-партнерів.
Давайте приступимо. Навіщо вивчати Java з практичної точки зору? Справа в тому, що Java - це дуже відома мова програмування. Має дуже велике ком'юніті.
Наприклад, є такий TIOBE-індекс, популярний індекс популярності мов програмування і Java там займає перше місце. Також на сайтах з вакансіями ви, напевно, помітите, що більшість вакансій — саме про Java, тобто розробляючи на Java, ви завжди зможете знайти собі роботу.
Оскільки комьюніті дуже велике, на будь-яке ваше питання знайдеться відповідь на якомусь Stack Overflow або інших сайтах. А ще, розробляючи на Java, ви, насправді, пишете код JVM, тому зможете легко пересісти на Kotlin, Scala та інші мови, що використовують JVM.
Чим хороша Java з ідеологічної точки зору? Існують різні мови програмування. Вони вирішують різні завдання, ви знаєте. Наприклад, на Python дуже добре писати однорядкові скрипти для вирішення швидких завдань.
На плюсах можна повністю контролювати код, що виконується. Наприклад, у нас їздять машинки, безпілотні автомобілі Яндекса, їхній код написаний на плюсах. Чому? Java має таку штуку — Garbage Collector. Вона очищує оперативну пам'ять від непотрібних об'єктів. Ця штука запускається спонтанно і робить stop-the-world, тобто зупиняє решту програми і йде рахувати об'єкти, очищати пам'ять від об'єктів. Якщо така штука працюватиме у безпілотнику, це не круто. Ваш безпілотник їхатиме прямо, в цей момент очищатиме пам'ять і ніяк не дивитися на дорогу. Тож безпілотник написаний на плюсах.
Які завдання розв'язує Java? Це насамперед мову для розробки великих програм, які пишуться роками, десятками чи сотнями людей. Зокрема, багато бекенда в Яндекс.Маркеті написано на Java. У нас розподілена команда у кількох містах, по десять осіб у кожному. І код легко підтримувати, він підтримується вже десять і більше років, і при цьому приходять нові люди, які розуміються на цьому коді.
Якими характеристиками повинен мати мову, щоб код на ньому був легко підтримуваний і щоб його було легко розробляти у великих командах. Це в першу чергу повинен бути код, що читається, і на ньому має бути легко реалізовувати складні архітектурні рішення. Тобто на ньому має бути легко писати високорівневі абстракції і т. д. Все це таки надає нам Java. Це об'єктно-орієнтована мова. На ньому справді просто реалізовувати високорівневі абстракції та складні архітектури.
Також існує дуже багато фреймворків та бібліотек для Java, тому що мові вже понад 15 років. За цей час на ньому було написано все, що могло бути написано, тому є купа бібліотек для всього, що може стати вам у пригоді.
Якими основними скілами, на мій погляд, повинен мати джавіст-початківець? Насамперед, це знання мови Java core. Далі це якийсь Dependency Injection фреймворк. Про це повніше розповідатиме наступний доповідач Кирило. Я особливо заглиблюватись не буду. Далі це архітектура та патерни проектування. Нам потрібно вміти писати архітектурно красивий код, щоб писати великі програми. І це якийсь SQL або ORM для завдань роботи з базою. І це більше стосується бекенда.
Поїхали! Java core. Тут я особливо Америку не відкрию – треба знати саму мову. На що варто звернути увагу. По-перше, Java вийшло дуже багато версій за останні роки, тобто в 2014-2015 вийшла сьома, потім восьма, дев'ята, десята, дуже багато нових версій, і в них вводили дуже багато нових крутих штук, наприклад, Java Stream API , лямбда і т. д. Дуже кльові свіжі круті штуки, які використовуються в production-коді, про що запитують на співбесідах і які потрібно знати. Тому не варто брати книгу з полиці у бібліотеці Java-4 та йти її вчити. Такий собі план: учимо Java-8 чи вище.
Уважно звертаємо увагу на нововведення, такі як Stream API, var, і т. д. Їх запитують на співбесідах, які постійно використовують у production. Тобто в Stream API сильно крутіше циклів, взагалі, дуже крута штука. Зверніть увагу обов'язково.
І є ще всякі штуки на зразок ітераторів, Exceptions і таке інше. Те, що здається вам поганим, поки ви пишете якийсь маленький код самі. Вам не потрібні ці Exceptions, кому вони взагалі потрібні? Але їх точно будуть питати на співбесідах, вони точно знадобляться вам у продакшені. Загалом варто звернути увагу на Exceptions, ітератори та інші штуки.
Структура даних. Без структур нікуди, при цьому буде здорово, якщо ви не просто знатимете, що бувають set, dictionary, листи. А ще — різні реалізації структур. Наприклад, у тієї ж dictionary в Java багато реалізацій, зокрема HashMap і TreeMap. Вони різні асимптотики, вони по-різному влаштовані всередині. Потрібно знати, чим вони відрізняються, коли якусь використовувати.
Також дуже здорово буде, якщо ви знатимете, як працюють ці структури даних усередині. Тобто не просто знати їх асимптотики – за скільки працює ставка, за скільки працює прохід, а як працює структура всередині – наприклад, що таке бакет у HashMap.
Також варто звернути увагу на дерева та графи. Це такі штуки, яких не дуже багато в продакшен-коді, але люблять їх на співбесідах. Відповідно, потрібно вміти обминати дерева, графи завширшки, глибину. Це все прості алгоритми.
Як тільки ви почнете писати скільки-небудь великий код, складний, з використанням бібліотек, багатокласовий код, ви зрозумієте, що вам важко без систем збирання та resolve-залежності. Це, в першу чергу, Maven і Gradle. Вони дозволяють вам імпортувати бібліотеки у ваш проект реально в один рядок. Тобто ви пишете однорядковий xml та імпортуєте до проекту бібліотеки. Відмінні системи. Вони приблизно однакові, використовуйте будь-яку – Maven чи Gradle.
Далі – якась система контролю версій. Я рекомендую Git, тому що він популярний, є купа туторіалів. Багато користуються Git, кльова штука, без неї нікуди.
І — якесь середовище розробки. Я рекомендую IntelliJ Idea. Вона дуже прискорює процес розробки, сильно вам допомагає, пише за вас всякий boilerplate-код, загалом, клювання.
Посилання зі слайду: ,
SQL. Трохи про бекендерів. Тут насправді був забавний кейс. Мені за два дні до моєї другої співбесіди на стажування зателефонувала дівчина-HR і сказала, що через два дні мене будуть запитувати SQL і HTTP, потрібно вивчити. А я не знав про SQL, ні про HTTP приблизно нічого. І я знайшов такий кльовий сайт. . На ньому я вивчив SQL годин за 12, в сенсі синтаксис SQL, як писати SELECT-запити, JOIN і т. д. Дуже кльовий сайт, дуже рекомендую. Реально за 12 годин вивчив 90% того, що я зараз знаю.
І ще добре знати архітектуру баз даних. Це усілякі ключі, індекси, нормалізація. Про це є серія постів на Хабрі.
У Java, крім SQL, є всякі Object-relational mapping-системи типу JPA. Є певний код. У першому методі якийсь SQL-код – SELECT id name FROM info.users WHERE id IN userIds. З бази даних users, з таблиці, отримують їх айдішники, імена.
Далі є якийсь маппер, який перетворює об'єкт із бази на джавовий об'єкт. І є нижче за третій метод, який, власне, виконує цей код. Все це за допомогою JPA можна замінити на один рядок, який написано нижче. Вона робить все те саме, — find All ByIdIn. Тобто, за назвою методу він генерує вам SQL-запит.
Дуже кльова штука. Я сам, коли не знав SQL, використав JPA. Загалом зверніть увагу. Якщо ліньки вчити SQL, - вогонь. І взагалі вогонь!
Spring. Хто чув про таку штуку, як фреймворк Spring? Бачите, як багато вас? Недарма. Spring є у вимогах кожної другої вакансії з бекенду на Java. Без нього реально нікуди у великій розробці. Що таке Spring? Насамперед це Dependency Injection-фреймворк. Про це теж наступний доповідач. Але якщо стисло, це штука, яка дозволяє вам полегшити імпортування залежностей одних класів на інші. Тобто спрощується знання залежностей.
Spring Boot - такий шматок Spring, який дозволяє вам піднімати свій серверний додаток однією кнопкою. Ви заходите на THID, натискаєте пару кнопок, і ось у вас на localhost 8080 вже піднято вашу серверну програму. Тобто ви ще жодного рядка коду не написали, а воно вже працює. Дуже кльова штука. Якщо пишете щось своє, вогонь!
Spring – дуже великий фреймворк. Він не тільки піднімає вам серверну програму та резолвіт Dependency Injection. Він дозволяє робити купу всього, зокрема створювати REST API-методи. Тобто ви написали якийсь метод, повісили на нього інструкцію Get mapping. І ось у вас на localhost вже є якийсь спосіб, який пише вам Hello world. Два рядки коду, і працює. Крута штука.
Також Spring спрощує написання тестів. Без тестування у великій розробці ніяк. Код слід тестувати. Для цього Java має кльову бібліотеку JUnit 5. І взагалі JUnit, але остання версія п'ята. Там є все для тестування, всякі assertions та інші штуки.
І є офігенний фреймворк Mockito. Уявіть, що у вас є функціональність, яку ви хочете протестувати. Функціональність робить багато чого, зокрема, десь у середині вона входить у «ВКонтакте» з вашим, наприклад, айдішником, і отримує по айдишнику ім'я та прізвище користувача «ВКонтакте». Напевно, ви не будете в тестах входити "ВКонтакте", це дивно. Але функціональність протестувати вам потрібно, тому ви цей клас за допомогою Mockito зробили його mok, його імітацію.
Ви скажете, що коли в цей клас приходить запит із айдішником таким, повертає якесь прізвище, наприклад, Вася Пупкін. І це працюватиме. Тобто ви тестуватимете всю функціональність за mok один якийсь клас. Дуже кльова штука.
Патерни проектування. Що це таке? Це шаблони для вирішення типових проблем, що виникають у розробці. У розробці часто виникають однакові, або схожі на якісь завдання, які було б добре якось добре вирішувати. Тому люди вигадали best practices, якісь шаблони, як вирішувати ці проблеми.
Є веб-сайт з більшістю популярних патернів - refactoring.guru, можна почитати, дізнатися, які бувають патерни, прочитати купу теорії. Проблема в тому, що це практично марно. Фактично патерни без практики особливої користі не несуть.
Ви почуєте про якісь патерни типу Singletone чи Builder. Хто чув ці слова? Дуже багато людей. Є такі прості патерни, які ви можете продати самі. Але більшість патернів: стратегія, фабрика, фасад – не зрозуміло, де їх застосовувати.
І поки ви не побачите на практиці в якомусь чужому коді місце, до якого застосовано цей патерн, застосовувати його самим не вдасться. Тому з патернами дуже важливою є практика. І просто прочитати про них на refactoring.guru не дуже корисно, але це обов'язково потрібно зробити.
Навіщо потрібні патерни? Нехай у вас є клас User. У нього є Id та Name. У кожного User обов'язково має бути і Id, і Name. Зліва зверху – клас.
Які є способи ініціалізувати User? Два варіанти - або конструктор, або setter. Які є мінуси обох підходів?
Конструктор. New User (7, «Bond»), окей. Тепер припустимо, що у нас не клас User, а якийсь інший, із сімома числовими полями. У вас буде конструктор, в якому сім чисел, що поспіль йдуть. Незрозуміло, що це за числа, яке з них до якого належить. Конструктор – це не здорово.
Другий варіант – setter. Ви чітко пишете: setId(7), setName(«Bond»). Ви розумієте, яка property до якого поля належить. Але у setter є проблема. По-перше, ви можете забути забути щось, а по-друге, ваш об'єкт виходить змінним. Це не потокобезпечно і трохи знижує читання коду. Тому люди вигадали кльовий патерн — Builder.
Що це? Намагатимемося зібрати плюси обох підходів — і setter, і конструктора — в одному. Робимо якийсь об'єкт, Builder, у якого теж будуть поля Id і Name, який сам будуватиметься на основі setter, і який матиме метод Build, який повертає вам нового User з усіма параметрами. У нас виходить незмінний об'єкт та setter. Кльово!
Які проблеми? Ось ми маємо класичний Builder. Проблема — ми все ще можемо забути забути якесь поле. І якщо ми забули засетити айдішнік, в даному випадку в Builder він проініціалізується нулем, тому що тип int не nullable. І якщо ми зробимо Name «Bond» та забудемо відвідати айдішник, у нас буде новий User з id «0» та ім'ям «Bond». Чи не кльово.
Спробуймо з цим поборотися. У Builder поміняємо int на int, щоб він був nullable. Тепер все чудово.
Якщо ми намагаємося зробити User з ім'ям «Bond», забувши проставити йому айдішник, у нас впаде null pointer exception, тому що айдішнік не nullable, а у Builder - null, конкретно pointer exception.
Але ми все ще можемо забути встановити ім'я, тому ми навішуємо object replay на null. Тепер, коли ми будуємо з Builder наш об'єкт, він перевіряє, що поле не nullable. І це ще не все.
Погляньмо на останній приклад. У разі якщо ми в айдишном рантаймі якимось чином поклали null, і було б чудово відразу дізнатися, що ти це зробив і це не кльово, що ти зараз робиш помилку.
Потрібно кинути помилку не в момент створення User, а коли ти відвідуєш айдишник null. Тому ми в Builder поміняємо в setter Integer на int, і він відразу тут свариться, що викинули null.
Коротше, у чому суть? Є найпростіший патерн Builder, але навіть у його реалізації є якісь тонкощі, тому дуже кльово подивитися на різні реалізації патернів. Кожен патерн має десятки реалізацій. Це дуже цікаво.
Як ми пишемо Builder у продакшен-коді? Ось наш User. На нього вішаємо ротацію Builder із бібліотеки Lombok, і вона сама генерує нам Builder. Тобто ми не пишемо коду, але Java вже вважає, що цей клас має Builder, і ми його можемо ось так викликати.
Я вже говорив, що в Java є бібліотеки практично для всього, у тому числі Lombok, кльова бібліотека, яка дозволяє вам не писати boilerplate. Builder, GET.
Паттерни бувають архітектурні - що стосуються не тільки одного класу, а до системи в цілому. Є такий клювання принцип у проектуванні систем: Single Responsibility Principle. Про що він говорить? Про те, що кожен клас повинен відповідати за свою функціональність. В даному випадку ми маємо Controller, який спілкується з користувачами, JSON-об'єктами. Є Facade, який перетворює JSON-об'єкти в моделі, з якими далі працюватиме Java додаток. Існує Service, в якому є складна логіка, що працює з цими моделями. Є Data Access Object, яка ці моделі кладе до бази і дістає з бази. І є сама база даних. Іншими словами, не все це знаходиться в одному класі, а ми робимо п'ять різних класів, і це ще один патерн.
Коли ви більш-менш вивчили Java, добре написати якийсь власний проект, в якому буде база даних, робота з іншими API, і який надаватиме REST API-клієнтам вашу серверну програму. Таку штуку буде чудово вставити в резюме, це кльове закінчення вашого навчання. З цим можна йти та влаштовуватися на роботу.
Ось приклад моєї серверної програми. На другому курсі я з хлопцями писав курсову роботу. Вони писали мобільний додаток для організації заходів. Там користувачі могли заходити через ВКонтакте, ставити на карті точки, створювати заходи, кликати на них своїх друзів, зберігати зображення заходів і т.д.
Що зробив у проекті я? Написав серверну програму на Spring Boot, не використовуючи SQL. Я його не знав, використав JPA. Що воно вміло робити? Авторизуватись у VK через OAuth-2. Брати токен користувача, йти з ним до VK, перевіряти, що це справжній користувач. Отримувати інформацію про користувачів через ВКонтакте. Воно вміло зберігати інформацію у базі даних, також через JPA. Вміло зберігати картинки та інші файли в пам'яті комп'ютера та зберігати посилання на них у базі. Я тоді ще не знав, що є CLOB-об'єкти у базі, тому робив так. Там був REST API для користувачів клієнтських додатків. І були юніт-тести на основні функціональності.
[…] Невеликий приклад мого успішного вивчення Java. На першому курсі в університеті мені викладали C# і дали розуміння про ООП-програмування — що таке класи, інтерфейси, абстракція, для чого вони потрібні. Мені це дуже допомогло. Без цього вивчати Java досить складно, незрозуміло, навіщо потрібні класи.
На другому курсі в університеті знову ж таки давали Java core, але я на цьому не зупинився, пішов вивчати Spring сам і написав курсову роботу, свій проект, про який я говорив вище. І з цим усім я пішов на стажування до Яндексу, пройшов співбесіду, потрапив до Яндекс.Маркету. Там я писав бекенд для Беру, це наш маркетплейс, і для самого Яндекс. Маркету.
Після цього, півроку тому, я перевівся в іншу команду всередині Маркета. Ми робимо аналітику для бізнес-партнерів. Ми в аналітичній платформі, нас на бекенді троє, тому в мене дуже велика частка впливу на проект. Це дуже цікаво насправді. Тобто, ми реально надаємо дані щодо ринку — які продажі, в яких категоріях, в яких моделях, для бізнес-партнерів, великих відомих компаній. І нас лише троє, ми пишемо цей код, і це дуже прикольно.
Дякую! Корисні посилання:
- .
- .
- .
- .
- .
- .
- .
- .
Джерело: habr.com