Невелика розповідь про те, як виглядає IT очима junior-розробника. Друзі! Мене звуть Данило, мені 25 років, і я працюю програмістом уже протягом 4 місяців, не маючи вищої освіти. Я хотів би поділитися своїми думками, які можуть комусь здатися цікавими чи допомогти у нашому тяжкому життєвому шляху.
Якщо ви опинабося на роздоріжжі та IT індустрія вас приваблює, але в той же час ви відчуваєте, що вам важко орієнтуватися в бізнесі, хочу розповісти, як все це приблизно виглядає зсередини. Щоб отримувати гроші за розробку, необхідно продавати розроблений продукт кеп. З повальним розвитком інтернету, який заполонив всю земну кулю, попит на програмне забезпечення, наскільки я можу судити, лише зростатиме. Сильніше посилюються вимоги контролю обліку діяльності різних організаціях, тому зберігається необхідність впроваджувати корпоративний софт. Власнику підприємства "Х" терміново знадобилося впровадити корпоративний софт для обліку товарів/співробітників/що-вгодно. Він звертається до IT-організації, яка готова йому продати його (якщо необхідно – попередньо розробивши, є багато готових рішень). Далі відбувається процес різноманітних застережень та планування архітектури програми. Команда намагається визначити, яким чином вони розроблятимуть проект, з урахуванням усіх можливих наслідків та нюансів. Планується та створюється архітектура БД (іноді вибирається самим замовником, іноді вибирається не з адекватної точки зору), архітектура самого додатка, а так само продумуються можливі ситуації наперед. Вкрай важливо закласти грамотну архітектуру проекту, тому що через помилку або невірно прийняті рішення, проект одного разу може зайти в глухий кут. Далі складається ТЗ (технічне завдання), за яким починається робота. Більшість програмістів (за ідеєю) повинні працювати строго за ТЗ, тому що у разі конфліктних ситуацій посилатися будуть насамперед на нього. Влаштовуючись молодшим розробником, ви, швидше за все, почнете працювати над додатком, що вже діє, і вам необхідно буде впізнавати його. Для цього існує специфікація або "wiki" проекту, де описується його поведінка в цілому, яким чином здійснюється можливість додавати новий функціонал, які технології застосовують, загалом – внутрішні особливості. Розробник працює у зв'язці з кількома людьми. Це його керівник – ПМ, Project Manager, голова проекту. Менеджер займається управлінською роботою - розподіляє ресурси, людей, розставляє пріоритети,
сваритьсярозмовляє із представником замовника, визначає для команди подальший вектор руху. Керівник рангом менший, але не менш важливий - тимлід. Цей підвид комбінує управлінську та технічну частину роботи, керуючи командою з кількох осіб, працюючи над чимось конкретним і без відриву від процесу написання коду. ТЛ видаватиме розробнику завдання, допомагатиме (можливо) у важких ситуаціях. Далі слідує аналітик. Завдання аналітика - інтерпретувати завдання з ТЗ, або отримані від когось ще зрозумілою розробнику мову. Він створює технічну документацію/специфікацію, де визначає необхідні відомості для девелопера, і що саме від нього потрібно на даному етапі розробки. Зустрічається не скрізь. Я з аналітиками на своєму проекті не знайомий. І, звичайно, тестувальник. Розробник, створивши функціонал та, провівши його налагодження, передає його тестувальнику, щоб він міг дослідити поведінку програми під різними ситуаціями, щоб знайти можливі баги, згодом передаючи код назад. Зараз існує безліч фреймворків та інструментів роботи для тестування, тому серйозні знання програмування для цього не потрібні. Розподіл роботи здійснюється за допомогою спеціальних внутрішніх сервісів, наприклад JIRA. Це схоже на якусь "робочу соціальну мережу", де у кожного співробітника є обліковий запис, на який він виходить завдання, де описано - що від нього потрібно, в які терміни необхідно вкластися, що це за робота - критична помилка, баг чи якесь покращення. Є стрічка новин, можна спостерігати - що зараз відбувається на проекті. Ви отримали завдання в JIRA, вам надійшло повідомлення про це, ви його відкрабо - побачабо, що потрібно, зробабо необхідне, відправабо завдання на "review" або "done" з коментарем про виконану роботу. Всі. Для того, щоб велика кількість людей могла одночасно працювати над одним проектом та мати актуальну версію та можливість оперативно фіксувати свою роботу, існують системи контролю версій (ВКВ). Централізовані ВКВ зберігають поточну версію проекту, яку співробітник може завантажити собі (update, poll), зробити якісь зміни в коді, і відправити їх у ВКВ (commit, push), щоб інші розробники теж отримали створені зміни. Проект може розвиватися з різних напрямків - гілок (branch), щоб на даний момент мати кілька варіацій готового рішення. Зазвичай після того, як розробник завершив якесь завдання, з ним проводять так званий code-review - коли ПМ, тимлід або досвідченіший співробітник починає дивитися - що він там понаписав і чи не зламається все, якщо застосувати на робочому сервері цей коміт. Якщо проект діє і експлуатується на даний момент і немає необхідності вводити новий функціонал, замовник може продовжувати платити організації за підтримку продукту. У випадку, якщо користувач наткнувся на баг або програма веде себе в цілому не так, як повинна - представник замовника звертається з цим і проблема усувається. Приклад робочої ієрархії можна побачити тут: Якщо проект діє і експлуатується на даний момент і немає необхідності вводити новий функціонал, замовник може продовжувати платити організації за підтримку продукту. У випадку, якщо користувач наткнувся на баг або програма веде себе в цілому не так, як повинна - представник замовника звертається з цим і проблема усувається. Приклад робочої ієрархії можна побачити тут: Якщо проект діє і експлуатується на даний момент і немає необхідності вводити новий функціонал, замовник може продовжувати платити організації за підтримку продукту. У випадку, якщо користувач наткнувся на баг або програма веде себе в цілому не так, як повинна - представник замовника звертається з цим і проблема усувається. Приклад робочої ієрархії можна побачити тут:https://ua.wikipedia.org/wiki/Організаційні_форми_управління Підсумовивши, зазначу, що дана робота дозволяє людині бути затребуваною в будь-якій точці земної кулі. Послуги аутсорсу ("продаж" компанією послуг своїх працівників на певний час у договірній основі) та аутстаффа ("продаж" співробітників для роботи в іншому місці на певний час у договірній основі) дозволяє всім на вигідних умовах обмінюватися кадрами. Для кадрів - чудова можливість подорожувати та дізнаватися щось нове. Які висновки я можу з цього зробити:
Програмування – виключно практична наука. Теорія покликана дати лише загальні рекомендації, до більшості речей доводиться приходити своїм розумом, тому навичка вирішує все.
Можливість мати відносно комфортний графік роботи.
Слід більш трепетно ставиться до свого організму. Добре спати і правильно харчуватися – запорука здорового розуму.
Консультуйтесь у більш успішних знайомих/друзів! Цікавтеся бізнесом, розробкою, принципами роботи програміста з середини. Досліджуйте ринок на наявність вакансій у вашому регіоні заздалегідь. І не спілкуйтеся з людьми, які не вірять у ваш успіх.
Що корисно знати:
SQL. Обов'язково. Необхідно буде часто працювати із СУБД.
Онлайн-стажування на codegym – мастхев. Це дійсно важкий плюс у вашому портфоліо, в якому вивчаються речі, які ви зустрінете на своїй першій роботі. Зрозуміло, з купою підводного каміння. Я починаю її проходити вже працюючи.
Зараз є таке модне слово – full stack developer. Цілком можливо, що вам доведеться писати не лише серверний код, а й клієнтський. Тому знадобляться знання html, xml, css та іншої верстки.
Я влаштувався після третьої співбесіди. Шукав роботу на hh, компанії з недовірою ставляться до людей без освіти та досвіду, тому єдине, чим ми можемо виграти – це скіли. Що порадувало – скрізь була досить привітна обстановка та ввічливі люди, з якими приємно спілкуватися. Цитата в тему "я ніколи не бачив людину, яка б сходила на 20 інтерв'ю і її нікуди не взяли". Ну і ложка дьогтю, куди ж без неї? Доведеться присвячувати цьому дуже багато часу, і тут зіграє фактор - подобається вам це в цілому чи ні, тому що кодити без бажання - подібно до тортур. Бажано ще розвиватися якось крім роботи, щоб бути конкурентним. На додачу можу додати про очевидні наслідки сидячого способу життя. Все вищеописане має винятково суб'єктивний погляд. Невелика ремарочка:Хочу сказати велике спасибі людям, які пишуть історії успіху, це справді мотивує! Ще хочу сказати спасибі творцем codegym за сам ресурс та за таке розвинене коммньюніті, де люди готові один одному допомагати у досягненні загальних результатів.
ПЕРЕЙДІТЬ В ПОВНУ ВЕРСІЮ