Я, девелопер

[Про автора: Павло Веллер — CTO, Digital Engagement Practice в EPAM Systems. Практично 20 років досвіду в розробці та продуктів з використанням Java, С#, Ruby, JavaScript та ін. (з них близько 14 років в EPAM). Веде власний блог www.pveller.com ]

У жовтні 2017 року в Будапешті відбулася конференція EPAM SEC 2017: Engineering Next, присвячена майбутньому технологій і новому поколінню інженерних рішень. На ній я поділився своїм баченням того, що значить бути Full Stack девелопером в наші дні і чому практичний досвід — це ключ до того, щоб стати справжнім експертом в області мультитехнологий. Відео виступу можна знайти за посиланням . І спеціально для читачів DOU матеріал за мотивами мого виступу.

Хто такий Full Stack девелопер

Одного разу на конференції в Денвері я почув правильний питання: «Ви позиціонуєте себе як Full Stack девелопер. А коли ви в останній раз писали device driver?». Сенс полягає в тому, що, оскільки стек «глибокий», ми делегуємо безліч завдань, а той стек, з яким більшість з нас працює щодня, — лише верхівка айсберга. Як більшість з нас зобразить архітектуру проекту? Швидше за все, ми отримаємо приблизно таку картину: Presentation tier — Business logic tier — Database tier. Інша версія: React JS/Native/VR, — REST API's в микросервисах — Polyglot persistence. Так модно, ніж класична трирівнева архітектура, але це все одно лише вершина айсберга.

Отже, бути Full Stack девелопером не означає бути експертом у всьому цьому. Готовий посперечатися і аргументовано довести, що ні у вас, ні у мене це не вийде. Візьмемо HTML. Здавалося б, що може бути простіше? Наприклад, на epam.com я нарахував не більше 15 тегів (сучасний HTML — це одні <div>). Бути експертом в такій кількості — не складно. Але як щодо HTML5? Service workers, Web workers, WebSockets, WebRTC, скоро — WebUSB — ось неповний перелік того, що потрібно знати, щоб називатися експертом у новій версії мови. Чи багато хто може похвалитися ідеальними знаннями всього перерахованого? Особисто я не можу.

Інший приклад — CSS. 15 років тому його навіть не зараховували до мов програмування, а роботи і зарплати) у фронтенд-розробників, швидше за все, було менше, ніж у Java-девелоперів. Як ідуть справи зараз, коли до CSS додалася цифра 3 (а фактично 4)? Ми вже не пишемо вручну, ми компілюємо. Специфікація розбита на ряд модулів, що проходять власні етапи сертифікації. Модулі для переходів, трансформації, анімації, два grid layout, окремий модуль для голосового браузера. Якщо хто-небудь хоче називатися експертом в CSS, він повинен бути експертом у всіх цих складових. Третій приклад — JavaScript, який повністю змінився протягом лише останніх двох-трьох років.

Так реально бути експертом в JavaScript і CSS, і в HTML? І до речі, ми говоримо тільки про «вершині верхівки айсберга. Як щодо фреймворків — Angular 1/2/3/4, React, Vue, Ember, Aurelia? І добре, якщо ваш сервер на Java, а якщо ні? Це може бути .NET, .NET Core, C#, F#, Erlang, Elixir, Ruby, Golang і так далі — варіантів безліч. Чи Можете ви бути експертами у всьому? А потім ще бази даних, реляційні та не дуже.

Тому я визначаю Full Stack девелопера як фахівця, який має власні переваги і працює з мовою програмування і стеком технологій, який він віддає перевагу в даний конкретний момент. І крім того, у нього (чи в неї) є перелік технологій, з якими він стикався на практиці і в яких розбирається на досить високому рівні.

Шлях експерта — це постійні навчання, практика та помилки

Є 2 ключові критерії, за якими можна визначити, чи може фахівець називатися «в достатній мірі експертом» (зауважте, це поняття не тотожне «експерта вищої категорії») у якомусь конкретному стеку технологій. Ці критерії — reason (уміння мислити на різних рівнях абстракції) і troubleshoot (вміння визначати, що і чому не працює).

Наведу приклад. Припустимо, в додатку — а жодне з них не «одношарове» — виникає проблема. Ваших знань і компетенції повинно бути достатньо, щоб за симптомами припустити, з-за чого виникла проблема і як її вирішити. Ви можете помилятися, причому неодноразово, але у вас має бути розуміння, з чого почати, як продовжити, що робити, якщо ви помилилися, і що робити далі. Це troubleshoot. Інший варіант — «чистий аркуш», коли ще нічого не збудовано, розуміння проблеми та інструментів допоможе визначити архітектуру, продумати різні варіанти і з кількох правильних відповідей вибрати правильну. Це reason.

Як же досягти такого рівня? Відправна точка — це ви самі, ваше щире бажання пройти через всі труднощі і виклики реального досвіду в роботі з вибраними технологіями. Теоретичної підготовки недостатньо. Я кажу про реальну роботу в умовах жорстких дедлайнів і пресингу, досвіду рішення проблем на практиці. Щоб досягти досконалості ви повинні робити це систематично, повторюючись режимі. Рекурсивно.

Важливо навчитися вчитися

Поділюся своєю власною історією. Моя професійна кар'єра девелопера почалася 17 років тому з розробки software для компаній клієнтів. Я працював на Delphi (сподіваюся, не всі ще забули, що це таке), PHP, Perl, мовою асемблера, яким з тих пір більше жодного разу не користувався. Парадоксально, але моїм головним козирем на початковому етапі стало вільне володіння німецькою мовою, оскільки на ньому була написана надана клієнтом специфікація. Я виявився «досить вмілим девелопером», щоб прочитати її і правильно зрозуміти завдання.

Два місяці тому я взявся за XSLT. Мені сподобався цей функціональний мову і процес його вивчення, хоча дуже небагато поділяють мою думку. Більше того, я люблю його досі. Потім було трохи практики з Lotus Notes, але дуже скоро я перейшов на Java для написання Lotus Notes Agents. Потім — великий проект щодо створення серверних сторінок на старій добрій Javа-версії 2000 року. Ще через рік мені знадобилися знання Oracle PL/SQL.

В ті часи я був джуниором, зі мною працювали супервайзери. Мені допомагали розібратися в тонкощах і нюансах, але всі описані технології доводилося застосовувати в умовах цієї проектної роботи для вирішення реальних завдань. І до речі, досвід з PL/SQL, придбаний в ті 6 місяців, я використовую досі, оскільки SQL не змінився. Потім був великий Java-проект з PostgreSQL. Для внутрішньої системи ми вибрали браузер IE5 з XMLHttpRequest. Ми працювали з AJAX, коли цей термін ще не був придуманий. Таким чином, я освоїв багато з фронтенда.

Не завжди все виходило: проект по створенню програми на VB6 з базою даних MySQL, в якому я виконував функції delivery-менеджера, «провалився», але це окрема історія. Резюме: за три роки роботи в реальних проектах, як того, кого сьогодні називають Full Stack, задіявши безліч технологій в кожному з них, я виробив практичні навички. І в 2003 я прийшов в EPAM. До речі, саме слово EPAM ми використовуємо як дієслово: «Він або вона ще не навчилися «епамить». І мова йде не про технології, а про skills. Найважливіше навчитися постійно навчатися. Це, напевно, найважливіше з того, що я засвоїв за перші три роки кар'єри.

Потрібно навчитися вчитися. Лише перехресного навчання мало. Фронтенд-розробнику недостатньо пройти курс Java і повернутися до фронтенду або навпаки. Ми повинні створювати середовище, в якому зможемо отримувати перехресний досвід. Новий тип професійного зростання інженерів повинен включати в себе звичку змінювати технології кожні 3-5 років, а для деяких спеціалізацій і частіше, наприклад, кожні 6 місяців. Для таких професій, як solution architect, це повинно стати обов'язковою вимогою перш, ніж проходити тестування на SA 1-го рівня.

На даний момент ми вимагаємо від фахівців знання технологій, але не популяризуємо шляху до їх освоєння. Наприклад, якщо ви працювали Java-девелопером 2 роки, досягли рівня senior і переключаєтеся на щось інше, спочатку вам буде дуже складно. Але через 2 місяці ви звикнете, і надалі з кожним разом буде все легше і легше. Важко лише зробити перший крок, перше «перемикання». І гарантую, після освоєння нової технології підвищиться також ваш рівень в Java, тому що ви не тільки вивчите нові інструменти і методи, але і розвинете інший тип мислення, побачите звичні речі під новим кутом. Зміна технологій повинна періодично повторюватися на вашому кар'єрному шляху — і це надзвичайно важливо!

Синдром самозванця як потужний мотиватор

Що мене надихає? Перш за все, потрібно освоїти методи боротьби з так званим «синдромом самозванця» (imposter syndrome) або ж недостатньою впевненістю у власних силах, значущості. Комусь може здаватися, що він вартий тих грошей, які йому платять. Періодично цей синдром переживає кожен спеціаліст IT-сфери, особливо у нинішній час, коли технології розвиваються з фантастичною швидкістю.

Коли це трапляється зі мною, я роблю паузу, беруся за проект, реалізуючи який доводжу оточуючим і, в першу чергу, самому собі власну цінність як професіонала. «Синдром самозванця» відступає, щоб через деякий час повернутися знову. І все повторюється.

Другий важливий компонент — programming language tourism. Перефразую анекдот, який закликає не плутати туризм з еміграцією. Ви не повинні любити все, що пробуєте сили, але ви зобов'язані спробувати для того, щоб мати про це уявлення. Мій кращий «тур» відбувся 5 років тому: я знайшов проблему в рекламному оголошенні Spotify і, не витрачаючи час на рішення за допомогою алгоритмів, прописав її, але на 3 мовах — Java, Ruby і Prolog. На вивчення останнього я витратив 2 тижні, викроюючи час між поточною роботою і зустрічами. І це один з тих прикладів, коли, озираючись назад, я задоволений результатами своєї роботи. Цей написаний 5 років тому код мені подобається до сих пір (він, до речі, є на моєму GitHub , якщо комусь цікаво).

Ніколи раніше я не вивчав Prolog, навряд чи скористаюся нею в майбутньому, але зате я переконався, що можу його вивчити, і, при необхідності, написати на ньому що-небудь. До речі, сам код був хороший. Він складався всього з 18 рядків проти 45 на Ruby і 300 на Java, повністю аналогічним функціоналом.

Існує спеціалізована платформа — , на якій ви можете практикуватися в 30 мовами, отримати допомогу інших фахівців, пробувати, вивчати. І потім, звичайно ж, переходити до реальної практики.

Що нам потрібно для того, щоб рухатися вперед? Перше — створити спільноту людей, яких я називаю людьми «типу А». Вони здатні діяти, запускати невеликі проекти, створювати прототипи. Вони — практики. Друге — нам потрібні люди, здатні генерувати ідеї і передавати людям типу А. Я, наприклад, практик, людина, яка реалізує ідеї, але не генерує їх.

І, повторюся, все починається з вас самих. Отримуйте реальний досвід, вивчайте те, про існування чого навіть не здогадувалися. Це принесе новий досвід, який допоможе стати краще в основний обраної спеціалізації. Потрібно постійно, знову і знову кидати виклики самим собі.

Опубліковано: 05/06/18 @ 11:56
Розділ Блоги

SEO Блог