«Лінь — моя суперсила»: 5 якостей ідеального Software Engineer

— Я — Software Engineer до нутра кісток, — представляється Віталій, — В професії вже майже 23 роки. Більшість часу працював інженером, а останні п'ять років — Delivery Manager і Product Owner. Зараз разом із колегами ми створюємо продукт у межах ініціативи EngX. Продовжую програмувати, пишу код.

Хто такий Software Engineer

— Хто такий Software Engineer сьогодні? Це той, хто займається інженерною діяльністю в нашій галузі, а саме створенням та підтримкою функціонування програмного забезпечення. Бізнес-аналітики, розробники, тестувальники, DevOps — усі, кого ви можете побачити на командному мітингу, всі Software Engineers з різною спеціалізацією, — розповідає Віталій, — У сучасного інженера має бути розвинене водночас інженерне мислення (Engineering Thinking) та agile-мислення (Agile Thinking). Ми працюємо з технологіями, що швидко змінюються, складними бізнес-процесами і різноманітними способами взаємодії, тому agile-мислення потрібне нам для того, щоб бути ефективними в роботі, а інженерне — щоб бути результативними.

Є два терміни, які, на мою думку, багато хто неправильно перекладає і сприймає. Це Agile та Full Stack Developer.

Agile

— Насправді Agile перекладається як «спритний», а не «гнучкий» (Flexible). Agile — це про адаптацію до зовнішніх і внутрішніх умов, що постійно змінюються. Я можу уявити ментальну помилку перекладача, який переклав Agile Methodology як Гнучка Методологія. Слово «гнучкий» асоціюється зі зміною форми та податливістю, тобто з адаптацією через зміну свого внутрішнього стану під впливом зовнішніх умов. У той час як слово «спритний» асоціюється зі швидкістю та напрямом руху, з адаптацією через реакцію на зовнішні умови, через зміну швидкості та напрямку свого руху. І слово «спритний» набагато більше відповідає поняттю Agile і тому, що від нього чекає бізнес. Нам, інженерам, не потрібно викручуватися і прогинатися лише з тією метою, щоб рухатися вперед, як було заплановано місяць чи роки тому. Наше завдання бути зібраними та готовими у будь-який момент змінити напрямок та швидкість руху, щоб відповідати новим вимогам ринку, де працює наше програмне забезпечення. А це означає, що у нас не повинно бути зайвого «жиру та хвостів», що заважали б нам бути спритними. Я маю на увазі технічний борг, погану якість коду, відсутність юніт-тестів тощо.

Full-Stack Developer

— А ось Full-Stack Developer'ом у нас прийнято вважати розробника, який може і Back-End, і Front-End. Замовники ж Full-Stack розуміють це як повний цикл розробки: від збору вимог до релізу. Тобто розробник повинен знати та вміти:

• Збирати та прояснювати вимоги, брати активну участь у цьому процесі, взаємодіяти з бізнес-аналітиком;
• Взаємодіяти з UX-дизайнером, щоб розуміти UX та реалізувати його відповідно до задуму;
• Розбиратися в архітектурі застосунка та дотримуватися код-стандартів, що було закладено архітектором;
• Писати та рев'юїти код, щоб він відповідав архітектурі та стандартам якості, прийнятим на проєкті, працювати в парах з іншими розробниками, щоб знизити кількість помилок, а відповідно і загальний час розробки програми;
• Тестувати свій код і те, як він інтегрується в додаток, створювати юніт та автотести, активно взаємодіяти з командою тестування;
• Створювати білд-скрипти та взаємодіяти з DevOps під час розгортання додатка.я

— Робота Software Engineer зроблена тоді, коли додаток потрапить у продакшн, буде працювати без помилок і принесе користь кінцевому споживачеві. Full-Stack Developer — це Software Engineer, який робить все від початку та до кінця — від вимог до постачання. Він бере участь у всіх етапах процесу створення програмного забезпечення, — підсумовує Віталій.

Так, наприклад, розробник, який створює свій pet-проєкт, зазвичай робить все сам: від збору вимог до розгортання/постачання продукту. Просто у великих компаніях та великих проєктах ці функції виконує не одна людина, а різні інженери з різними спеціалізаціями. Але розбиратися та брати участь у всіх сферах виробництва кінцевого продукту треба обов'язково.

Якими якостями має володіти Software Engineer

— Ми в ініціативі EngX (Engineering Excellence) довго думали, які якості має мати ідеальний Software Engineer і дійшли наступних висновків.

Інженери мають:

1. Бути допитливими.
   Це означає дивитися на світ навколо себе, не замикатися, не залишатися в якомусь обмеженому потоці, цікавитися, брати участь у різних активностях крім проєкту, ходити на різні хакатони, мітапи з нових технологій. Хакатони в цьому випадку краще, на них можна попрактикуватися в написанні коду.
2. Мати почуття міри.
   Допитлива людина може зациклитися на абстрактних речах і заглибитись у надмірне покращення. Інженеру дуже важливо не абстрагуватися від продукту та зовнішнього світу. Потрібно думати про користувачів, про те, який у результаті продукт виходить і коли вони його отримають. Не всі завдання можна зробити абстрактно, та й не потрібно. Професія розробника — це не просто писати код та давати тестувальникам роботу. Турбота про результат, усвідомлення свого внеску в світ — ось якими принципами має керуватися інженер. Інженер взаємодіє з рештою команди, щоб його зміни були інтегровані в загальну систему і працювали як слід, були вчасними.
   Щоб вони були вчасними — означає робити усе необхідне, аби задовольнити вимогу, і щоб решта учасників команди теж встигли виконати свою роботу. Але не забуваємо про якість коду, яка дуже сильно впливає на майбутню «вчасну» розробку. І раннє виявлення багів: що раніше ми виявимо проблему, то менше часу на її вирішення буде витрачено; уважно читаємо специфікацію та вказуємо на помилки в ній.
3. Вміти працювати у команді.
   Джуніори часто не можуть потрапити на роботу у великі компанії саме тому, що вони не мають досвіду роботи в команді. У таких компаніях ніхто не працює поодинці, все робиться командою. І найсумніше, що більшість онлайн-курсів та менторських програм не надають такого досвіду. Здебільшого вони спрямовані на індивідуальну роботу, індивідуальне вивчення матеріалу та індивідуальну практику в написанні коду. Знань про те, як зібрати вимоги, як зробити дизайн додатка, як його протестувати, як його встановити на сервер або якимось іншим чином створити дистрибутив — не дають. А цього не вистачає, і це треба десь брати. Звичайно, фахівців можна навчати, але навчання ускладнюється тим, що неминуче буде багато помилок, проєкт може затягнутися, а це ризики. Плюс потрібно знайти людину, яка розповідатиме і показуватиме, як правильно робити, а це ресурс. Добре, якщо така людина є. Тоді джуніори і навіть мідли досить швидко вливаються в роботу і починають справлятися. Але найчастіше це не так.
   У мене в EPAM був досвід створення project-лабораторії, в межах якої я зібрав студентів-джуніорів у дві команди, і ми робили два невеликі проєкти. Я виступав у ролі Product Owner та ментора, навчав їх як команду, де є повний цикл розробки. Я показав їм, що робота над проєктом не пов'язана просто з написанням коду, а пов'язана з багатьма речами: опрацюванням вимог, тестуванням, розгортанням. Після трьох місяців роботи над проєктами хлопці сказали, що здобули хороший досвід і у них залишилося розуміння, як їм працювати в команді.
4. Бути лінивим.
   Ви, напевно, чули вираз «Лінь — двигун прогресу». Це саме так. Я називаю її своєю суперсилою. Це, звичайно, не означає, що я нічого не роблю. Лінь має бути такою, щоб, докладаючи мінімуму зусиль, отримувати максимальний результат. Наприклад, є якась рутинна дія. Ок, я її зроблю один раз, але наступного разу я придумаю якийсь простий спосіб, щоб ця дія у мене забирала менше часу та сил. Якщо робити все щоразу в лоба — коли тобі дали завдання, ти одразу пішов його робити — це недобре. Потрібно подумати, «полінуватися» робити одразу, знайти просте гарне рішення, яке принесе більше користі та займе менше часу та зусиль. Загалом інженер має більше думати — менше робити.
5. І не «тупити».
   Ця характеристика трохи конфліктує із попередньою властивістю. На заході є такий вираз fast try — fast fail. Це означає, що краще швидше спробувати щось зробити, переконатися, що це не працює, і відмовитися від плану. Нам складно це прийняти. Нас вчили не помилятися. Але насправді помилятися нормально, на помилках люди вчаться. Якщо боятися помилятися, то ми довго думатимемо, вивірятимемо і все одно не уникнемо падіння.

— У хорошому інженері мають бути якості, які суперечать одна одній. Бути захопленим своєю справою і знати міру, бути лінивим і не «тупити». Але важливо знаходити баланс між ними та правильно їх використовувати. Не потрібно все відразу робити в лоб, найпряміший шлях не завжди найшвидший, можна вигоріти від непосильних зусиль. Але без помилок не набиратимешся досвіду, який так потрібен, — резюмує Віталій.

Звісно, не слід забувати і про soft skills. Вони потрібні всім людям на будь-яких посадах. Джуніорам — для успішної роботи в команді, зрілішим фахівцям їх потрібно розвивати, щоб далі рухатися кар'єрними сходами.

Що почитати

— І наостанок залишу список із чотирьох книг хорошого інженера:

• Роберт Мартін: Чистий код. Створення і рефакторинг («чистий код завжди має такий вигляд, ніби його написав той, кому не байдуже» Р. Мартін»);
• Стів Макконел: Досконалий код («складний код є ознакою того, що ви недостатньо добре розумієте свою програму, аби зробити її простою» С. Макконел);
• Роберт Мартін: Ідеальний програміст. Як стати професіоналом розробки ПО (моя особиста думка, не можна стати ідеальним, можна тільки бути спочатку ідеальним джуном, потім ідеальним інженером і т.д.);
• Еліягу Ґолдратт: Мета. Процес безперервного вдосконалення (щоби розуміти мотивацію менеджерів і допомагати їм заходити у вузькі місця в створенні програмного забезпечення);

Хочеш поговорити про інженерну культуру? Запрошуємо в Discord Anywhere Club.