Доброго зимового ранку, шановні читачі нашого блогу. Сьогодні у нашій #meeting room ми говоримо з нашим Senior Software Engineer Володимиром. Чи дійсно написання коду – це основна робота програміста та що найголовніше у командній роботі? Приємного читання!
Яке твоє найбільше усвідомлення за роки у сфері розробки?
Всі ми вміємо гарно виконувати свою роботу, наприклад – писати код або тестувати функціонал. Але не менш важливим є створення комфортної обстановки у команді та у спілкуванні із замовником. Саме взаєморозуміння у команді дозволяє створювати чудові продукти та ділитися навичками у команді.
Як змінювався світ розробки протягом твоєї кар’єри?
З’явилося багато нових та цікавих технологій та інструментів, які ми використовували на своїх проєктах. Ми сприймали ці інструменти як щось захоплююче та інноваційне, тому що до цього працювали з чимось іншим. Частина технологій з часом зникали, наприклад, Adobe Flex. Ми використовували Adobe Flex для створення 3D у нашому додатку. Інші технології просто еволюціонували у щось нове, наприклад, на зміну jQuery прийшли AngularJS, Angular, React та Vue.js.
Як би ти описав цінність, яку ми несемо як компанія для замовника?
Ми створюємо програмний продукт, який вирішує проблеми замовника. Така автоматизація може зробити життя багатьох людей більш комфортним. Всі ми розуміємо зручність використання пральної машини. Ми у свою чергу створюємо помічників наступного покоління.
Який найцікавіший старт проєкту ти можеш пригадати?
Мене запросили на один проєкт для виправлення дефектів. Цей проєкт був пов’язаний з онлайн навчанням. Замовник планував отримати виправлення за тиждень. Але у проєкта були складнощі зі збіркою, тому що він використовував досить застарілі залежності. Тому тижня ледве вистачило лише на збірку цього проєкту. Далі ми уже успішно працювали над виправленням дефектів. А через деякий час замовник вирішив створити нову версію цього продукту. Мені вдалося попрацювати і над новою версією, яку ми успішно створили.
Які, на твою думку, обов’язкові складові чи бест практики налаштування та ведення проєкту?
Крім самого коду важливо звертати увагу на автоматизовані тести та документацію. Тести допомагають знайти помилки у функціоналі при написанні нових частин проєкту та зміни старих. Це значно ефективніше за ручні перевірки, тому що за кілька секунд або хвилин можна перевірити багато різних сценаріїв. Вручну не вдасться цього зробити так швидко. Хоча ручне тестування також важливе. Також важливо описувати основний функціонал на проєкті у документах, наприклад, Readme або Wiki. Це потрібно робити для себе, а не лише для замовника. Ми неодноразово використовували власні документи, щоб згадати як саме працює функціонал через кілька місяців або років. Також це чудовий спосіб поділитися знаннями з колегами. Це економило нам багато часу та зусиль.
Що включає в себе розробка програмного продукту та скільки часу розробник витрачає саме на написання коду?
В розробку продукту може входити багато різних етапів. Їх можна умовно розділити на дві категорії. Перша – аналіз того, що потрібно замовнику та як це краще реалізувати. Відповідно до наших спостережень, на складних проєктах ця частина може займати 70-80% часу та зусиль. Сама реалізація функціоналу та написання коду зазвичай займає 20-30%. Важливо розуміти, що якість продукту дуже сильно залежить від першої частини, тому що у випадку помилки доведеться переписувати багато коду.
Як команді зростати якісно? Які цілі їй ставити перед собою?
Для початку важливо зрозуміти поточні вміння у команді та скласти план того, що ми хочемо отримати найближчим часом. При цьому важливо слідкувати за потребами продукту та станом поточних технологій.
Які, на твою думку, існують умовні рівні розвитку команди?
Спочатку важливо писати код, який працює. Він повинен виконувати свою роботу за виділений час. Йому повинно бути достатньо ресурсів пристрою, на якому він працює, наприклад, сервер, телефон або планшет. Також важливо, щоб цей код був зрозумілим для інших розробників. Наступний рівень полягає у роботі з існуючим кодом, його зміною та розширенням функціоналу. Тут може бути складніше, тому що нам потрібно розуміти чужий код. У більшості випадків цього повинно вистачити для роботи на багатьох проєктах. Проте можуть знадобитися навички покращення існуючого функціоналу, щоб він працював швидше. Можемо сприймати це як третій рівень умінь.
Яка найцікавіша задача, з якою ти стикався?
Було цікаво вирішувати проблеми з продуктивністю, коли щось працювало дуже повільно або не працювало взагалі. Часто такі проблеми виникають при обробці великих об’ємів даних, наприклад, звіти за кілька місяців або років. У таких задачах не можна бути впевненим, що вийде швидко та ефективно вирішити проблему, над якою скоріш за все уже працювали інші розробники. Цікавим прикладом було покращення SQL запиту, який не завершувався навіть через 3 години, тому що спрацьовував тайм-аут. Після оптимізації запит почав відпрацьовувати за 1-2 хвилини. Інший приклад оптимізації уже у додатку. Один HTTP запит використовував приблизно 15 GB оперативної пам’яті та завершувався з помилкою, тому що не вистачало пам’яті. Після оптимізації цей запит відпрацьовував, використовуючи приблизно 1 GB оперативної пам’яті.
Чи складно бути фулл стек розробником? Твої поради “початківцям” у цьому напрямку?
Працюючи фулл стек розробником, можна повністю ефективно створювати функціонал вцілому, а не лише його частину. Наші замовники високо цінують цей навик. Можу рекомендувати не боятися чогось нового та пробувати свої сили у різних напрямках.
Як розробнику не засумувати на проєкті? Чи дійсно бувають проєкти, де “нічого нового”?
На кожному проєкті можна знайти щось цікаве. Достатньо задати питання – як саме ми можемо покращити цей продукт? Ці пропозиції можна обговорити з командою та запропонувати замовнику. У багатьох випадках такі рекомендації високо цінують. Також можна вивчати нові технології і підходи у розробці та ділитися ними з колегами.
Що б ти побажав нашим читачам? 🙂
Бажаю усім цікавих проєктів та дружньої команди!
You are not signed in. Sign in to post comments.