Не тільки «входити в ІТ», а й рухатись уперед: як розвиватись Ruby-спеціалісту
Привіт, мене звати Володя, і я вже багато років працюю Ruby-розробником, учасник кор-команди Ruby спільноти Pivorak і ментор з цієї технології.
Попит на Ruby-розробників за останні роки зріс, але на ринку їх чомусь не густо. Це результати хайпу ~2010-го, коли фреймворк Ruby on Rails став модний, та антихайпу ~2015-го, коли відбувся відплив інженерів у Node.js, React, Python, Elixir та інші суміжні вебтехнології. Та попри це проєкти на Rails нікуди не зникли. Ба більше, спостерігаємо ренесанс цієї технології для фулстек-розробки. За роки роботи вже сформовані найкращі практики, написано багато книг і безліч статей, що допоможуть початківцю впевненіше почуватися. Але сьогодні бракує не в початківців, а саме досвідчених інженерів. То де ж їх брати?
Написати статтю мене підштовхнула одна гіпотеза, що не дає мені спокою останні кілька років: рубістам після старту кар’єри важко перейти на наступний рівень без менторства з боку досвідчених інженерів, а ще ж є психологічний бар’єр перед новим і невідомим. Причиною цього може бути надто велика варіативність способів і підходів у роботі для вирішення одного й того ж завдання або невпевненість у власних рішеннях. Інформаційний простір перевантажений різноманітною літературою, статтями та безмежними онлайн курсами де часто можна зустріти протилежні думки на одне і те саме. Відчуття відставання від трендів і, як наслідок, втрата мотивації до самонавчання. Як у цьому всьому знайти свій шлях після старту та орієнтири — незрозуміло.
Розберімось.
Як стати рубістом з Pivorak
П’ять років тому ентузіасти спільноти Pivorak запустили курси для Ruby-розробників — Pivorak Ruby Summer Course. В їхню основу лягла ідея менторства та самонавчання. Курс триває всього два місяці. Місяць інтенсивної теорії та місяць практики з досвідченим ментором над справжнім проєктом. За 4 сезони нам вдалось випустити у світ добру сотню рубістів-початківців. Ключовим успіхом курсів є високий рівень працевлаштування після їх завершення завдяки підтримці партнерів. Багато з випускників виросли в досвідчених інженерів, та дехто так і не наважився на крок у професію і зійшов з дистанції. Та чимало тих, хто за 1–2 роки губиться у світі Ruby та надто уповільнюється у зростанні.
Чому, маючи уже декілька років професійного досвіду на проєктах в продакшені, спеціалісти все ще плавають в основах Ruby та не можуть сформувати власне бачення професійного розвитку? Як так стається, що одна людина після першого року знає та використовує SOLID і патерни, а інша за 10 років так і не подужала нічого складнішого за «сервАйс» об’єкти, вважає, що бізнес-логіка в моделі та колбеки — це норм, і нічого не чула про Faraday?
Досвід показує, що бракує курсів підвищення кваліфікації. Варто допомогти не тільки «входити в ІТ», а й рухатись уперед. Від джуна до мідла, від мідла до сеньйора. Не особливо люблю ці наліпки, але ринкові стандарти диктують цю термінологію, та й нехай.
Валідація гіпотези
Щоб перевірити цю гіпотезу, місяць тому у своєму телеграм-каналі я оголосив набір на безплатне менторство. Умова була проста — початковий рівень з робочим досвідом, таргани в голові та бажання вчитись. Дуже несподівано для себе отримав чималу кількість листів. Звісно, всіх взяти неможливо, але приділити кожному 30 хвилин на перше знайомство виявилось дуже корисним та цікавим досвідом. Зрештою обрав трьох претендентів, котрим, як мені здалось, наставник потрібен найбільше: немає тімліда, є сильне бажання розвиватись і можливість вкладати в це час. Усім іншим я подякував за приділений час і пообіцяв написати цю статтю. Пообіцяв — виконую ;)
Інформаційні джерела
З цим усе складно. Як правило, на запитання «Де читаєш про новинки в рубі» у відповідь мовчання або щось типу: «Гуглю за потреби». Гуглити — це корисна навичка, але не така уже й ефективна. У момент вирішення проблеми варто мати 2–3 варіанти, щоб вибрати оптимальний, а для цього найкраще підходять кейси з прочитаних книг і статей. Тому так, доведеться читати. Коли чую на інтерв’ю від початківців щось на зразок: «Книги це довго та нудно», хочеться пустити сльозу. Людство ще нічого кращого для навчання, ніж читання, не придумало. Ви ж чомусь зараз читаєте цей текст. Читання — це довгий і медитативний процес, під час якого не треба запам’ятовувати все слово в слово. Варто вибрати важливе та сформувати власну думку. Ось і все. Терпеливість і праця.
Мій вибір для читання:
Щотижневий дайджест RubyWeekly — найкращий спосіб завжди бути в курсі новинок, скандалів і всього найцікавішого зі світу Ruby.Правда життя в тому, що не у всіх fluent English, тому Олексій Васільєв веде чудовий RWPod-подкаст російською мовою. Цінним для новачків буде якісний аналіз новин світу Ruby та Web від Олексія. Не просто «що», але й «чому»Twitter — місце, де все швидше з’являється, ніж на RubyWeekly, але й обсяг значно більший. Знайдіть усе можливе щодо Ruby, Rails, Hanami та просто будьте в темі. З часом ви навчитесь бачити, що саме варте уваги.ruby.libhunt — мій компас щодо актуальності бібліотек. Завжди його використовую, коли постає питання «а що ж взяти, щоб самому то не кодити».
Основи Ruby
У своїй основі Ruby проста мова. Головних будівельних блоків не так уже й багато. Все є об’єктом, і на всіх об’єктах можна викликати метод object_id чи public_methods та побачити усе на власні очі. Об’єкти належать до класів, а вони між собою наслідуються. Модулі потрібні для неймспейсів або міксинів. Примітивні типи даних, такі як Numeric, String, Hash та Array дуже потужні, але варто також звернути уваги на Struct, OpenStruct, Set, Queue та інші. З коробки є надто багато всього. Не все варто використовувати, але знати корисно.
Часто виникають проблеми з method_lookup та розумінням, звідки що береться і як викликається. Для цього раджу прочитати BasicObject й далі рухатися по дереву стандартних класів.
Рекомендована література:
The Well-Grounded Rubyist, Third Edition (David A. Black, Joseph Leo III) — поки нічого кращого для початківців не бачив.Ruby programming language (David Flanagan, Yukihiro Matsumoto) — це була моя перша книга з Ruby. Вже старенька, але все ще добре передає ідею ruby-way.
ООП
Чи треба знати ООП для мови, де все є об’єктом, — питання риторичне. Об’єктноорієнтований дизайн нам потрібен для зрозумілого опису бізнес-процесів програми. Код ми пишемо для людей, а не для машин, тому і власні велосипеди вигадувати не варто. Індустрія вже придумала все за нас. Залишилось тільки ознайомитись та взяти на озброєння. Варто не просто знати SOLID, а й активно ним користуватись.
Ось вам чудова добірка патернів з прикладами на Ruby від мого колеги Богдана.
На інтерв’ю я часто прошу кандидата описати якийсь об’єкт з інтер’єру в контексті ООП — крісло, стіл чи гітару на стіні. Як правило, у початківців проблеми саме з дизайном, тому рекомендовані книжки:
Practical Object-Oriented Design, An Agile Primer Using Ruby (Sandi Metz) — цікаве ООП дизайну на прикладі компанії для прокатів велосипедів. Рубісти вважають це класикою.99 Bottles of OOP (Sandi Metz, Katrina Owen, & TJ Stankus) — на продовження теми філософії ООП дизайну.
Метапрограмування
Магії не існує. Це просто код, котрий написали не ви. Метапрограмування — це спосіб написання коду, котрий генерує інший код. Це темна сторона сили, і про неї варто знати, а от чи користуватись — це вже інше питання. Для побудови DSL я застосовую class_eval, instance_eval, define_method, send та public_send. Корисно розуміти, як воно працює. На цю тему можу порадити книжку Metaprogramming Ruby 2 (Paolo Perrotta).
З відеоматеріалів рекомендую лекцію мого колеги Володимира Биньо з першого сезону курсів Pivorak.
Тестування
Не так важливо, чи пишете ви тести перед кодом, як те, чи пишете ви їх взагалі. Погано написаний тест — це краще, ніж не написаний. Без тестів ніяк. Взагалі ніяк. Тут важливо це просто прийняти та почати їх писати. Не говоріть на інтерв’ю дурниці на кшталт «без тестів розробка йде швидше». Розробник, який подібне говорить, так підтверджує власну низьку кваліфікацію. Тести є невіддільною частиною розробки програмного забезпечення. «Замовник не платить за тести» — це просто відмовка, за якою приховується лінь. Коли ви сідаєте в авто, то не питаєте когось, чи треба пристібатися. Тести — це ваш пасок безпеки.
RSpec є стандартом у світі комерційної Ruby-розробки, тому варто розібратися, що тестувати і як:
Effective Testing with RSpec 3 (Myron Marston and Ian Dees);Everyday Rails Testing with RSpec (Aaron Sumner).
Ruby on Rails
Як я вже писав, магії не існує. Це просто код, котрий написали не ви, а конкретно ось ці люди. Насамперед варто знати складники Rails: ActionPack, ActiveRecord, ActiveModel, ActionView та інші. Сам фреймворк модульний, і завжди можна щось прибрати, а щось додати. В Rails багато можливостей, але не всім варто користуватись. Бізнес-логіка в контролерах і моделях — це одразу «ні», а все решта прийде з досвідом. Моєю першою книжкою була Agile Web Development with Rails (Sam Ruby and David Bryant Copeland), але ще версії 3.0, а от стисло та доступно викладено у Rails Crash Course: A No-Nonsense Guide to Rails Development (Anthony Lewis).
Звісно, Rails — це фреймворк для створення вебзастосунків, і тут без фішок не обійтись. Свого часу я передивився всі RailsCasts від легендарного Ryan Bates, а зі свіженького раджу GoRails від Chris Oliver.
Не можу не згадати Crafting Rails 4 Applications (José Valim), і нехай вас не лякає цифра «4» в назві. Те, що Жозе описав у тій книзі, свого часу змінило моє ставлення до розробки вебзастосунків з Rails. Книга досі залишається актуальною.
У продовження теми раджу ознайомитись з Modular Rails (Thibault Denizet). Ця книга відкриває зовсім інший світ архітектури Rails-аплікацій. Упевнений, гурмани оцінять.
Якщо проєкт, на який ви потрапили, вже «пахне», ознайомтесь з Fearless refactoring rails від колеги з Вроцлава Andrzej Krzywda.
Що далі
Практика. Багато практики. Програмування не в голові, а на пальцях рук. В голові варто тримати тільки думки про те, як ефективно розв’язати проблему.
Раджу створити власний сайд-проєкт, або пет-проєкт, і там, як у пісочниці, спробувати усе, що прочитали в книжках, статтях. В роботу ж варто переносити тільки готові та перевірені рішення. Не варто очікувати, що робочий проєкт зобов’язаний вас чогось навчити. Професійний розвиток — це тільки ваша відповідальність. Роботодавець має тільки зарплату вчасно платити, щоб ви змогли купити собі ще книжок чи відеокурсів.
Технічні аспекти веброзробки практично не мають меж. І важливо бути в курсі новинок. У світі Ruby існує багато цікавого, крім Rails: Hanami, Grape, Sinatra, DryRb, Trailblazer.
Я вірю, що неможливо бути хорошим рубістом, якщо знаєш тільки рубі. Є інші класні мови програмування та фреймворки, звідки можна багато чого почерпнути. Нові техніки та парадигми тільки розширюють потенціал для генерації ефективних рішень у Ruby. Тепер ви вже знаєте одну мову, тому вивчити наступну буде значно простіше. Свого часу для мене такими стали Elixir та Phoenix Framework. Практика з цими технологіями зробила мене кращим рубістом, а рубі дало змогу знизити поріг входження в Elixir. Тут можу порадити класну книгу Phoenix for Rails developers (Elvio Vicosa).
Підсумок
Програмування — це складно. Не вірю, що є простий шлях професійного зростання, окрім постійного навчання та практики. Не обманюйте себе ілюзіями, що можна всього навчитись на практиці без читання книг і статей. Збережіть собі час і сили та переймайте чужий досвід. Зрештою, наша професія — це про автоматизацію та удосконалення світу.
Запрошую усіх, хто поділяє або не поділяє мою думку, долучитись до розмови в коментарях. Залишайте посилання на навчальні матеріали, котрі допомогли вам.
Ну й підписуйтесь на мій телеграм-канал ;)
По материалам: http://feedproxy.google.com/~r/DevelopersOrgUa/~3/AFbOLspkt8g/