Чого чекати у перший тиждень як розробник програмного забезпечення

Ви знаєте, що вам подобається кодувати, але як це робити, виконуючи роботу? Що ви можете очікувати у перший тиждень?

Я не міг уявити свій перший тиждень на новій роботі. Ви починаєте кодування відразу? Що робити, якщо вони використовують мову / фреймворк, якого ви не вивчили? Як ви прискорите роботу з кодовою базою і знаєте, які пріоритети? Чи легко вступити до команди? Ви просто ... відкриваєте свій редактор і починаєте кодування? Що робити, якщо ти щось жахливо помилився і все зламав?

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

У цьому дописі я буду використовувати приклади того, що я робив протягом перших кількох днів у своїй останній ролі, щоб спробувати дати вам уявлення про те, чого ви можете очікувати.

Передумови

Я працюю розробником повного стеку в невеликій компанії. В команді інженерів є чотири розробники (включаючи мене) та технічного директора. Ми також тісно співпрацюємо з Власником продукту, який є одним із засновників. Я пішов із парою років досвіду кодування.

Всі сервіси працюють на AWS, і ми використовуємо NodeJS та Ruby.

День 1: В основному налаштування

Я прибув до офісу о 9 ранку. На моєму столі мене чекав новий блискучий MacBook Pro в комплекті з адаптерами та двома екранами. Команда розробників вивела мене на сніданок у сусіднє кафе, і коли ми повернулися, я сів і почав налаштовувати свою машину.

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

Мені надали аркуш А4 із переліком вимог, номерами версій тощо, за якими я обов’язково уважно стежив. Я також отримав доступ до різних сайтів, таких як BitBucket, менеджер паролів, AWS та Gitlab, і налаштував свої ключі SSH на моєму новому комп'ютері.

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

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

Останні пару годин дня я сидів з одним із старших розробників, поки він реалізовував функцію. Ми використали це як можливість для нього провести мене через цю частину програми, пояснивши, чому все було зроблено конкретними способами, ті частини, які спричинили проблеми, та аспекти, які в підсумку можуть змінитися в майбутньому.

День 2: Тестування

Мені дали завдання протестувати пару функцій в одному з репозиторіїв програми. Проведення нових тестів для написання - це чудовий спосіб познайомити їх із кодовою базою та ознайомити з деякою логікою програми.

Я витратив неабиякий час, просто читаючи код, з'ясовуючи, як це все працює разом, і перевіряючи, чи зможу я прослідкувати потік логіки. Мене зацікавили конвенції, які вибрала команда, спосіб розподілу коду та стилістичний вибір. Написати тести було не складно, але я завжди дуже обережний, роблячи свій перший знак на кодовій базі, над якою я раніше не працював!

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

Одним з невеликих випробувань, які я мав, було звикання до робочого процесу Git, який використовувала команда. Кожна команда має свій власний спосіб робити: деякі команди зливаються, деякі команди перебазують, деякі команди сквошують коміти, а інші ні, деякі слідують за популярними робочими процесами, подібними до цього, а інші просто змушують "підштовхнути" майстра "волею-неволею". Плюс є домовленості повідомлення та опису коміту, щоб отримати право, процес перегляду тощо.

Загалом, є багато невідвертих речей "так ми робимо". Пройшовши пару разів, виправивши свої помилки та поставивши запитання, тепер це друга природа.

Весь час я писав нотатки в блокнот і зберігав фрагменти коду в додатку під назвою Ведмідь. Потрібно було взяти так багато - як робити речі, переважні процедури для команди, речі, які я раніше не робив, і нові мови та основи для вивчення.

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

День 3: Шипий AWS

В рамках випуску, який ми вже виконували, нам потрібно було вирішити, як розгорнути службу, яку ми будуємо. Ми використовували AWS, але був вибір між використанням екземпляра EC2, який був би найпростішим вибором, оскільки це просто сервер у хмарі, на якому запущений ваш додаток, або щось дещо вигадливіше, як Elastic Container Service. Перевага ECS полягає в тому, що він буде керувати масштабуванням декількох екземплярів EC2 і, отже, буде хорошим варіантом для майбутнього. Але це наразі було не зовсім важливо.

З огляду на це, я отримав (зголосився) завдання висвітлити, наскільки легко було б розгорнути нашу службу на ECS. Шип просто означає випробувати щось, щоб дослідити доцільність. Якщо це буде важко, це не варто, оскільки це була майбутня оптимізація, яка нам зараз не потрібна.

Це вимагало багато навчання для мене, оскільки я раніше не використовував ECS Amazon, плюс додаток був додатком Rails, і я був набагато менш знайомий з цілою екосистемою Ruby / Rails. Я провів, можливо, загалом 30 годин, вивчаючи Ruby до приходу в компанію, оскільки знав, що це частина їхнього стеку, але я ледве торкнувся Rails. Плюс, це завдання мало трохи роботи з Docker, що також було для мене новим.

Мій технічний керівник змусив мене почати з того, що в основному було 1-годинним вступом до Docker, що було надзвичайно корисним. Звідти я проводив більшу частину дня, створюючи нову програму Rails, переглядаючи різні статті, документи та приклади, щоб перевірити, чи зможу я запустити цю справу на ECS. Я майже потрапив туди, але забезпечення інтеграції бази даних спрацювало каменем спотикання. Було просто так багато нового.

Я впевнений, що хтось більш знайомий з ECS чи Rails не мав би стільки проблем. Я не міг відійти, сказавши, що процес був об’єктивно важким. Це було важко для мене , але це не означає , що це було важко для всіх.

Не надто продуктивний день з точки зору корисного коду чи виводу, але я відчував, що навчився багато чому і з цієї точки зору, і це було чудово.

День 4: Спарювання та наставництво

Я прибув до офісу о 8 ранку, і, поки я чекав, коли прийдуть інші, я пройшов частину курсу Docker, який я спостерігав на Pluralsight. Я все ще прагнув завершити цей стрибок із вчорашнього дня, але визнав, що мені потрібно більше обґрунтування хоча б однієї з нових технологій, з якими я працював.

Я провів на курсі близько години, перш ніж до офісу прибуло більше людей, і ми взялися за рішення, хто що робитиме. Ще один новий розробник, який розпочав роботу трохи раніше мене, щойно повернувся з відпустки. Ми вирішили, що будемо поєднувати одне завдання. Ми створювали нову функцію в додатку Rails. Це було досить просте завдання, але Rails було новим для нас обох, тому було чудово працювати разом. Коли нам потрібно було щось пояснити, ми просто запитували когось із інших розробників, або особисто, або на Slack. Ми провели кілька чудових дискусій таким чином, і я почав розуміти, як працює Rails.

У другій половині дня я провів сеанс наставництва з технічним керівництвом, який був щедрим, оскільки напередодні я вже отримав приватний клас Docker! Наставництво - це можливість поставити запитання, разом розв’язати проблеми, навчитися чомусь разом або просто вибрати комусь мозок. Передача знань є дуже корисною.

У мене було багато дивних запитань щодо матеріалів бази даних та Rails, але я шкодую, що не мав жодної мети для першої сесії. Здається, я просто не був впевнений, чого чекати. На наступних сесіях я просив свого наставника показати мені, як зробити щось конкретне, наприклад, налаштувати сервер NGINX або налаштувати екземпляр EC2 для доступу до бази даних - речі, які він уже знав би, але для того, щоб зрозуміти, мені знадобилося б набагато більше часу самостійно.

День 5: Зустрічі та злиття

Багато програмних команд використовуватимуть комбінації стоячих зборів (часто щодня), регулярних ретроспектив (про робочі практики чи технічні проблеми) та сесій планування, щоб організувати свій робочий процес на високому рівні, в поєднанні з якимсь інструментом відстеження, коли робота в можна продемонструвати прогрес і роботу, що залишилася зробити.

Наша команда нічим не відрізняється, і більшість наших запланованих зустрічей ми проводимо у п’ятницю. Як і багато команд, акцент під час наших зустрічей полягає в тому, щоб задуматися про те, як ми працювали і що ми досягли, колективно вирішувати будь-які проблеми або блоки, а також визначати та планувати майбутні роботи, щоб у нас завжди було щось попереду ми готові перейти до.

Ми також виходимо на сніданок, щоб зв’язатись, що чудово!

Загалом, більша частина ранку була витрачена на ці заходи. Мені мало що було внести, оскільки я все ще розбирався по всій термінології та структурі продукту, і я завжди був позаду речення позаду, намагаючись наздогнати щойно сказане. Я пам’ятаю, протягом першого тижня я просто відчував, що мій мозок тане, коли я намагався утримувати в пам’яті всі різні компоненти архітектури (це покращується з часом, тому не хвилюйтеся!)

У другій половині дня ми з моєю парою змогли закінчити те, над чим працювали, вимагати перегляду коду, внести поправки та відкрити запит на об’єднання нашої роботи в програму. Ми не розгортались, оскільки це було в п’ятницю вдень, але зробили наступного понеділка. ?

Дякую за прочитання, сподіваюся, ця стаття дала вам деяке уявлення про те, як може виглядати ваш перший тиждень як розробника.

Я хотів би почути ваші коментарі та враження!