- Що ж повинен знати java розробник
- Core Java і ООП
- JDBC (Java Database Connectivity)
- Servers
- Unix-like
- Servlets + JSP
- Spring
- ORM
- Web-framework
- Web-services (SOAP, REST)
- SQL, HTML, JavaScript
- специфічні вимоги
- Як вибрати спеціалізацію
- У якому порядку все це вивчати
Я виступав з аналогічною темою на IT fest, і, судячи з реакції залу, людям було цікаво. Формат доповіді стислий, багато довелося промовляти вже потім, окремо від виступу. Та й якість записи вийшло не дуже, не все чутно. Тому вирішив написати статтю.
Спочатку про себе коханого. У мене досить великий досвід роботи java-розробником (з 2001 року, навіть вважати страшно), а програмістом і того більше - з 96-го. Більшу частину з цих років я працював тімліда в різних аутсорсингових компаніях Києва. Крім того, більше 10 років я викладаю в навчальних центрах Luxoft, NetCracker і ось IntroPro. І навіть рік вів у школі інформатику. Загалом, навчати вмію. Ну і з іншого боку, у багатьох компаніях я виступав як технічний фахівець, який проводить співбесіду. Так що я ще й та сама людина, яка знає, про що вас будуть питати на майбутній роботі. В цьому році я взяв участь у створенні навчальної програми по java в GoIT і викладав в одній з груп. Більшість моїх студентів вже працюють.
Я це все розповів не заради хвастощів, а для того, щоб пояснити, на чому я грунтуюся, кажучи про список технологій і порядку навчання.
Отже, почнемо, і раптово з кінця - я зберу висновки, які зробив з навчання молодих фахівців.
Перший висновок найсумніший - програмістами можуть стати не всі. І нема чого сміятися! Спочатку я розраховував, що навчитися програмувати може будь-хто. А чого там, програмування - відверто не rocket science. Бери більше, кидай далі. Але все виявилося не так. Все вперлося в мотивацію. Зараз поясню.
Не буває людей взагалі без здібностей до програмування. Але все одно - всі люди різні. Так ось, навчаючись (в тому числі і програмування), ви витрачаєте мотивацію. Досягаючи чогось в процесі навчання - ви мотивацію заповнюєте. І чим менше у вас здібностей, тим важче вам просуватися до чергового досягнення. Якщо у вас було не так вже й багато мотивації, ви ризикуєте просто до наступного здобутки не довчитися. А інша людина, можливо з меншою мотивацією, ніж у вас, але з великими здібностями просто буде клацати завдання як горіхи і довчиться. Се ля ві.
Другий висновок. Вчитися java-розробнику без ментора, що працює в цій сфері - неможливо. Наша індустрія сповнена величезною кількістю невиразних і навіть контр-інтуїтивних знань про те, як треба чинити і як не треба. Самі ви в цьому не розберетеся. Гарантовано.
Після конференції мене питали - так що ж робити, якщо наставника немає? Відповідаю: знайдіть собі ментора. Розумієте, програмістам теж треба рости, з мідл ставати сеньйорами, з сеньйорів - тімліда і так далі. І для всього цього треба отримати досвід керівництва, спілкування з підлеглими. І де його взяти? Тут проблема та ж сама, що і у Джун - потрібен досвід, щоб отримати певну роботу. А отримати його можна тільки на цій роботі. Так що допоможіть один одному.
Де знайти такого ментора? Потусити на форумах програмістів (на тому ж DOU) - постукає до людей в личку з питанням: «Вибачте, а можна я буду вам час від часу питання задавати?» Більшість погодиться. Полазьте на лінкедін, в кінці кінців.
Третє. Найважливіше, що робить java-розробника java-розробником - звичка і здатність швидко знаходити знання і вбирання їх з необхідною швидкістю. Саме на це повинен бути націлений процес навчання джавістов. Вчити їх за класичною університетської схемою (лекції, семінари) - безглуздо. Тільки по жорстокої схемою: розгойдали і кинули у вир. Хто зможе - випливе. Ну а якщо людина не може нічого вдіяти з тим, що крім нього ніхто задачу не вирішить ( «є ти і є завдання, все інше залежить від тебе»), то йому програмістом не стати. Інша розмова, що завдання повинні бути підібрані з правильною складністю - щоб їх можна було вирішити, але для цього потрібно напружити всі можливості.
Поки це тільки основні начерки (завдання вже є і непогано себе зарекомендували, але критерії оцінки результату поки чиста смаківщина менторів), а хочеться мати точний план навчання з усіма крапками реперів. Я над цим працюю, як буде готове, відразу повідомлю. Попередні начерки - в кінці статті, можете відразу переходити туди.
Що ж повинен знати java розробник
Тут я просто приведу список, а потім розкрию всі пункти окремо:
- Core Java;
- ООП;
- JDBC;
- Servers + Servlets + JSP;
- Spring;
- ORM;
- Web-frameworks;
- Web-services (SOAP, REST);
- SQL, HTML, JavaScript;
- Специфічні вимоги.
Core Java і ООП
Мене постійно запитують, що я маю на увазі під знанням ООП. Розповідаю. Перш за все, це означає вільно орієнтуватися в трьох принципах ООП. Розуміти, як працює успадкування і поліморфізм. Тобто якщо один клас успадковується від іншого, кого і до чого треба приводити, а що автоматично є екземпляром чого. Якщо у базового класу і у дочірнього є метод з однаковою сигнатурою, то які саме обмеження накладаються на типи прийнятих і значень, а також кидаються винятків. Що буде в compilation time, а що в run time. Ну і так далі. Людина, яка цього не розуміє, нормальний код не напише - це вже перевірено. Особисто ми таких просто не беремо, навіть якщо у людини хороші знання фреймворків. Собі дорожче буде потім його код підтримувати.
З Core java потрібно знати методи об'єкта Object і Collection Framework. Enterprise java - це на 90% колупання в різних колекціях. Від них нікуди не втечеш.
Так само часто запитують про concurrency. Відповім дещо суперечливе, але з мого досвіду так. Є проекти, які жорстоко зав'язані на многопоточность. Для найму в ці проекти вас буду жорстоко ганяти по concurrency. В інших проектах многопоточности особливо немає, і вас там про неї нічого не запитають. Думаю, загальне уявлення мати необхідне всім, вчити чи глибше - самі вирішуйте. Інша розмова, що є безліч собеседователей, які страшно люблять цю тему і будуть вас по ній питати, навіть якщо для проекту це все нафіг не треба. Чому саме многопоточность користується у них такою великою любов'ю - тут я тільки руками розводжу.
JDBC (Java Database Connectivity)
Навіщо вчити те, що ніхто вже в чистому вигляді не користується? З двох причин.
По-перше, новачків люблять наймати на проекти підтримки (support). А це в більшості своїй досить древній софт, написаний кимось лівої задньої. І ймовірність того, що там використовується plain JDBC - не нульовий.
По-друге, під капотом у всіх ORM-ів все одно лежить той же самий старий добрий JDBC. І рано чи пізно (скоріше рано, ніж пізно), коли у вас щось зламається, ви побачите як раз помилки JDBC. І з цим треба буде щось робити
Servers
Тут все просто. Будь-java розробник повинен знати Tomcat. Він найпростіший, найлегший і мабуть, що має найбільшу knowledge base. Запитувати на співбесіді про нього вас ніхто не буде - передбачається, що ви його і так знаєте. Чи не знати томкет - це сором і ганьба. Майте на увазі.
Далі варто вивчати вже JBoss / WildFly - все-таки багато J2EE технології на томкете не працюють (ті ж EJB або кластерне рішення, хоча, може, я відстав від життя). А ось JBoss / WildFly - якраз оптимальний. Він безкоштовний і цілком функціональний. Ніхто не очікує від новачка, що він взяв і скачав десь WebLogic і фігачіт код під нього. А ось знання JBoss / WildFly - саме воно. Більш того, він частенько використовується навіть у серйозних замовників
Unix-like
Про знання Юнікса вас можуть максимум запитати - чи володієте і на якому рівні. Відразу відповідаю - достатньо володіти на рівні користувача. Запустити, зупинити, скористатися SSH і SCP. Ну в общем-то і все.
Servlets + JSP
Цей пункт аналогічний пункту про JDBC. І зустрічаються вони все-таки іноді, і знання того, що під капотом більш сучасних web фреймворків - дуже корисно. Як мінімум, скорочує час знаходження помилки в рази. Зайвим не буде. Та й запитати на співбесіді про це цілком можуть.
Spring
Знання спрінга - ультимативно. Як мінімум, тому що спринг - галузевий стандарт. І не важливо, подобається вам спринг чи ні. Головне, щоб ви його знали. З ймовірністю 80% ви будете з ним працювати вже на одному перших трьох проектів. Та й взагалі, ентерпрайз розробник не повинен перебирати - це хочу, це не хочу. Взялися і працюємо. Ось це якраз той випадок.
Є ще CDI, стандарт від Оракл. Я провів опитування серед своїх друзів, питаючи, хто ним користується. 80% відповіли: «А що це таке ?. Решта 20% сказали: «Ні, не користуємося». Так що можете сміливо на нього забити.
ORM
Промисловим стандартом є Hibernate. Знову ж таки, подобається він вам чи ні, знати ви його зобов'язані. Використовувати повинні через JPA.
Обсяг знань: вміти замепіть відносини один-до-одного, один-ко-многим і багато-до-багатьох. Написати HQL запит і налаштувати Лейзі завантаження.
Web-framework
У цьому пункті все-таки смаківщина, але знання будь-якого веб-фреймоврка необхідно. JSF, так JSF. SpringMVC, так SpringMVC. Все буде добре. Головне, щоб ви могли хоч якимось чином отрисовать UI. Всі веб-фреймворки подібні в принципах роботи, так що вчіть те, що здасться найбільш затребуваним.
Web-services (SOAP, REST)
Ну, з REST взагалі все просто. Від Джавера там потрібно тільки анотацію повісити. І в принципі представляти, як воно працює.
З SOAP складніше - треба знати кілька ключових слів, описати, для чого служить WSDL, ну і представляти загальні основи протоколу.
SQL, HTML, JavaScript
Знання SQL - ультимативно. Ви повинні його знати на рівні Джава. Зараз навіть на проекти, що використовують NoSQL бази, не беруть без доброго знання SQL. Що вже говорити про інших. Чому він так потрібен - пояснювати не буду, але якщо коротко - на SQL ви будете писати часто і багато. Звичайно, не збережені процедури (хоча це теж не виключено, але це все-таки екзотика), але запити на вставку і перевірку тестових даних - дуже часто.
Я не беру людей на посаду в двох випадках. Якщо вони завалюються на першому пункті (Core Java і ООП) і на цьому. Робіть висновки.
Щодо знання HTML я навіть говорити не буду. Чого там знати? Прочитав статтю - ти вже його знаешь.Естественно, всі хитрощі і заморочки сучасних CSS - це хліб Front End. Ось нехай вони там і пасуться. Ми ж повинні добре знати HTML і трохи JavaScript. Причому, знання JavaScript - відмінний бонус для новачка. Знаєте чому? Тому що новачків люблять брати на саппортовий проект, в якому давно вже не працюють дизайнери. Java-скриптик підправити іноді треба, а Джавера його не люблять. І якщо ви, на відміну від решти команди, готові їм займатися - все будуть вас любити. І ви з більшими шансами потрапите на роботу, ніж чистоплюї, які не хочуть длубатися в цьому вашому фронт-енді. Так що любите JavaScript, і буде вам щастя.
За обсягами знань. Треба знати сам JavaScript. Добре також вміти читати JQuery. А ще краще - вміти його писати. Якщо ви володієте відповідним досвідом - не соромтеся вказати їх в резюме. Це суміжні з нами знання. Це вам не PHP який-небудь, про який Джавера кажуть: «У тебе досі є в резюме PHP, тобі не соромно?»
Знання скриптових мов (sh, bash, perl & etc) - штука корисна. Як мінімум, ви збільшуєте свої можливості по затикання дірок - а це і є основна суть роботи на саппортовом проект. Інша розмова, запитувати вас про це на співбесіді не будуть, а вивчити основи такої мови - справа кількох днів. Так що я б не радив в це упиратися.
специфічні вимоги
Ви повинні бути готові, що при прийомі на роботу вас насамперед запитають: «А чи знаєте ви фреймворк бла-бла-бла 4.2?» Нормальний відповідь - ні, не знаю. У будь-якому проекті є якісь дивні речі, які тільки там і використовуються. Все знати ви не можете і не повинні навіть намагатися.
Як вибрати спеціалізацію
Дуже раджу всім початківцям програмістам вибрати собі спеціалізацію. Зараз поясню, що я маю на увазі. Ми всі - java-розробники. Ок, все знають Джава, все знають більш менш повний стек наших фреймворків. Але, в будь-якому проекті буде цінуватися людина, яка реально добре знає один з потрібних фреймворків. Наприклад - гуру по Hibernate. Або гуру по якомусь PrimeFaces. Або - потужний знавець Oracle DB.
Ви зрозуміли, до чого я. Так, знати потрібно все, але щось одне - вивчити досконально. І вразити своїми глибокими знаннями про будову вашого улюбленого фреймворка собеседователя. Так, природно не в кожній команді потрібен фахівець саме по вашому коханому фреймворку. Там ви просто будете звичайним Джавера. Але в якійсь команді ваша поява буде зустрінуте оплесками - «О! саме ти і був нам потрібен, тебе нам послало небо! »Коротше, ви зрозуміли. Будьте як всі, але трошки краще :)
У якому порядку все це вивчати
Значить так, спочатку ставимо мети. Ми повинні домогтися того, щоб новачок не боявся жахливого масиву знань і звик до того, що все він не буде знати ніколи. І навчився працювати в ситуації неповного знання.
Поки методика виглядає такою:
1. Поринути в складні алгоритмічні завдання. Головне, щоб ці завдання ще не були реалізованими в готових бібліотеках, і людина розуміла, що завдання щодо реальна. Наприклад - вивести щось отформатироване. Сенс: викликати у людини розуміння, що будь-яке завдання вирішується. Просто потрібно кілька днів подумати, покриття завдання, і ось тоді все вийде.
2. Намалювати до цих завдань Unit tests. Юніт тести легко покажуть всі помилки вашого проектування і змусять переписати код в набагато більш пристойному форматі. Як бонус - студент звикає не боятися правити код знову і знову. Це вміння абсолютно необхідно для професійного програміста
3. Навчитися декомпозиції. Вибрати кілька предметних областей і помалювати по ним UML діаграми. Це необхідно, щоб просто зрозуміти - це і буде найскладнішим в нашій роботі. Єдине зауваження - діаграми повинні перевірятися досвідченим і розумним ментором. На цьому етапі ментор просто необхідний. Налаштувати свій мозок на вирізання Скоуп проекту, на декомпозицію об'єктів і їх взаємозв'язків - це те, що саме не прийде, скільки НЕ програмуй.
4. Зробити код на основі результатів однієї з декомпозицій. Цей код буде згодом нашим шаром бізнес-логіки.
5. Починати роботу з базою. Освоїти JDBC і всі його частини. Це буде значно простіше після попереднього пункту. Код також необхідно показати менторові. Як показує моя практика, багатопоточність (яка в будь-якому випадку передбачається для цього коду) - штука не відразу лізе в голову. Треба, щоб вас направили.
6. Вивчити основи інтернету і томкет. Треба зробити до вашої бізнес-логікою і DAO layer останню частину, що залишилася - UI. Поки на сервлетах і JSP. Потрібно зробити так, щоб JSP зверталися до бізнес-логікою за її даними. Та запитувала дані з бази і повертала їх на View (JSP). При натисканні на кнопки в JSP управління передавалося в сервлети, які відправляли команди бізнес-логікою на зміну стану. А та, в свою чергу, змінювала дані в базі за допомогою DAO layer. І потім сервлети відправляли управління назад на JSP (наприклад - перенаправленням), і потім все повторювалося. Тут треба уважно стежити, щоб ніякі запити від JSP не лізли в DAO layer.
7. Вивчити можливості томкета. Створюємо Data Source і працюємо вже не з фізичним коннектом, а з логічним, отримуючи його через JNDI.
8. Освоїти Spring. Все, що потрібно зробити - проінжектіть DataSource в потрібні класи DAO Layer. Спочатку - через XML конфігурацію, а потім - через анотації. Цих знань буде достатньо
9. Тепер можна вводити Hibernate через JPA анотації. Сенсу вивчати меппінг-файли я не бачу. Вони вже майже ніде не використовуються. Замінюємо весь код в DAO на HQL або Criteria. Що краще піде.
10. Ну і нарешті, найвеселіше - вибираємо фреймворк для морди. Я б порекомендував якийсь JSF або SpringMVC.
Далі, коли ключові речі освоїли, вивчати можна вже що завгодно. Я б рекомендував зануритися в SQL, WebServices і JavaScript
Звертаю увагу: перескакувати етапи вкрай не раджу.
Якщо у вас вийде слідувати цьому плану, і ваш ментор виявиться достатньо кваліфікований, все буде відмінно. І скоро на одного Java розробника побільшає. Удачі вам!
Після конференції мене питали - так що ж робити, якщо наставника немає?І де його взяти?
Де знайти такого ментора?
Потусити на форумах програмістів (на тому ж DOU) - постукає до людей в личку з питанням: «Вибачте, а можна я буду вам час від часу питання задавати?
Відповіли: «А що це таке ?
Чого там знати?
Знаєте чому?
Це вам не PHP який-небудь, про який Джавера кажуть: «У тебе досі є в резюме PHP, тобі не соромно?