Небольшое повествование о том, как выглядит IT глазами junior-разработчика.
Друзья! Меня зовут Даниил, мне 25 лет и я работаю программистом уже на протяжении 4 месяцев, не имея высшего образования. Я хотел бы поделиться своими мыслями, которые могут кому-то показаться интересными или помочь в нашем трудном жизненном пути.
Если вы оказались на распутье и IT индустрия вас привлекает, но в то же время, вы чувствуете, что вам трудно ориентироваться в бизнесе, хочу рассказать, как все это приблизительно выглядит изнутри.
Чтобы получать деньги за разработку, необходимо продавать разработанный продукт кэп. С повальным развитием интернета, который заполонил весь земной шар, спрос на программное обеспечение, насколько я могу судить, будет только расти. Сильнее ужесточаются требования контроля учета деятельности в различных организациях, поэтому сохраняется необходимость внедрять корпоративный софт.
Владельцу предприятия "Х" срочно понадобилось внедрить корпоративный софт для учета товаров/сотрудников/чего-угодно. Он обращается к IT-организации, которая готова ему продать его (если необходимо - предварительно разработав, есть много готовых решений). Далее происходит процесс всевозможных оговорок и планировка архитектуры приложения. Команда пытается определить, каким образом они будут разрабатывать проект, с учетом всех возможных последствий и нюансов. Планируется и создается архитектура БД (иногда выбирается самим заказчиком, иногда выбирается не с самой адекватной точки зрения), архитектура самого приложения, а так же продумываются возможные ситуации наперед. Крайне важно заложить грамотную архитектуру проекта, потому что из-за ошибки или неверно принятых решений, проект однажды может зайти в тупик.
Далее составляется ТЗ (техническое задание), согласно которому начинается работа. Большинство программистов (по идее) должны работать строго по ТЗ, потому что в случае конфликтных ситуаций - ссылаться будут в первую очередь на него.
Устраиваясь младшим разработчиком, вы, скорее всего, начнете работать над уже действующим приложением и вам необходимо будет узнавать его. Для этого существует спецификация или "wiki" проекта, где описывается его поведение в целом, каким образом осуществляется возможность добавлять новый функционал, какие технологии применяются, в общем - внутренние особенности.
Разработчик работает в связке с несколькими людьми. Это его руководитель - ПМ, Project Manager, голова проекта. Менеджер занимается управленческой работой - распределяет ресурсы, людей, расставляет приоритеты,
ругается разговаривает с представителем заказчика, определяет для команды дальнейший вектор движения.
Руководитель рангом поменьше, но не менее важный - тимлид. Данный подвид комбинирует управленческую и техническую часть работы, управляя командой из нескольких человек, работая над чем-то конкретным и без отрыва от процесса написания кода. ТЛ будет выдавать разработчику задания, помогать (возможно) в трудных ситуациях.
Далее следует аналитик. Задача аналитика - интерпретировать задания из ТЗ, либо полученные от кого-то еще на понятный разработчику язык. Он создает техническую документацию/спецификацию, где описывает необходимые сведения для девелопера, и что конкретно от него требуется на данном этапе разработки. Встречается не везде. Я с аналитиками на своем проекте не знаком.
И, разумеется, тестировщик. Разработчик, создав функционал и, проведя его отладку, передает его тестировщику, чтобы он мог исследовать поведение программы под различными ситуациями, чтобы найти возможные баги, в последствии передавая код обратно. Сейчас существует огромное количество фреймворков и инструментов работы для тестировки, поэтому серьезные знания программирования для этого не требуются.
Распределение работы осуществляется с помощью специальных внутренних сервисов, например - JIRA. Это похоже на некую "рабочую социальную сеть", где у каждого сотрудника есть аккаунт, на который он получается задания, где описано - что от него требуется, в какие сроки необходимо уложиться, что это за работа - критическая ошибка, баг или какое-то улучшение. Присутствует лента новостей, можно наблюдать - что сейчас происходит на проекте. Вы получили задания в JIRA, вам пришло уведомления об этом, вы его открыли - увидели, что требуется, сделали необходимое, отправили задачу на "review" или "done" с комментарием о проделанной работе. Все.
Для того, чтобы большое количество людей могло одновременно работать над одним проектом и иметь актуальную версию и возможность оперативно фиксировать свою работу, существуют системы контроля версий (СКВ). Централизованные СКВ хранят текущую версию проекта, которую сотрудник может скачать себе (update, poll), сделать какие-то изменения в коде, и отправить их в СКВ (commit, push), чтобы другие разработчики тоже получили себе созданные изменения. Проект может развиваться по разным направлениям - веткам (branch), чтобы на данный момент иметь несколько вариаций готового решения.
Обычно, после того, как разработчик завершил какое-то задание, с ним проводят так называемый code-review - когда ПМ, тимлид или более опытный сотрудник начинает смотреть - что он там понаписал и не сломается ли все, если применить на рабочем сервере этот коммит.
Если проект действует и эксплуатируется на данный момент и нет необходимости вводить новый функционал, то заказчик может продолжать платить организации за поддержку продукта. В случае, если пользователь наткнулся на баг или программа ведет себя в целом не так, как должна - представитель заказчика обращается с этим и проблема оперативно(или нет) устраняется.
Пример рабочей иерархии можно увидеть здесь: https://ru.wikipedia.org/wiki/Организационные_формы_управления
Подытожив, отмечу, что данная работа позволяет человеку быть востребованным в любой точке земного шара. Услуги аутсорса ("продажа" компанией услуг своих работников на определенное время в договорной основе) и аутстаффа ("продажа" сотрудников для работы в другом месте на определенное время в договорной основе) позволяет всем на выгодных условиях обмениваться кадрами. Для кадров - прекрасная возможность путешествовать и узнавать что-то новое.
Какие выводы я могу из этого сделать:
Программирование - исключительно практическая наука. Теория призвана дать только общие рекомендации, к большинству вещей приходиться приходить своим умом, поэтому навык решает все.
Возможность иметь относительно комфортный график работы.
Следует более трепетно относится к своему организму. Хорошо спать и правильно питаться - залог здорового разума.
Консультируйтесь у более успешных знакомых/друзьях! Интересуйтесь бизнесом, разработкой, принципами работы программиста изнутри. Исследуйте рынок на наличие вакансий в вашем регионе заранее. И не общайтесь с людьми, которые не верят в ваш успех.
Что полезно знать:
SQL. Обязательно. Необходимо будет часто работать с СУБД.
Онлайн-стажировка на javarush - мастхэв. Это действительно увесистый плюс в ваше портфолио, в котором изучаются вещи, которые вы встретите на своей первой работе. Разумеется, с кучей подводных камней. Я начинаю ее проходить, уже работая.
Сейчас есть такое модное слово - full stack developer. Вполне возможно, что вам придется писать не только серверный код, но еще и клиентский. Поэтому пригодятся знания html, xml, css и прочей верстки.
Я устроился после третьего собеседования. Искал работу на hh, компании с недоверием относятся к людям без образования и опыта, поэтому единственное, чем мы можем выиграть - это скиллами. Что порадовало - везде была довольно приветливая обстановка и вежливые люди, с которыми приятно общаться. Цитата в тему "я никогда не видел человека, который сходил бы на 20 интервью и его никуда не взяли".
Ну и ложка дегтя, куда же без нее? Придется посвящать этому очень много времени, и тут сыграет фактор - нравится вам это в целом или нет, потому что кодить без желания - подобно пытке. Желательно еще развиваться как-то помимо работы, чтобы быть конкуретноспособным. В довесок могу добавить про очевидные последствия сидячего образа жизни.
Все вышеописанное имеет исключительно субъективный взгляд.
Небольшая ремарочка:Хочу сказать большое спасибо людям, которые пишут истории успеха, это действительно мотивирует! Еще хочу сказать спасибо создателем javarush за сам ресурс и за такое развитое коммньюнити, где люди готовы друг другу помогать в достижении общих результатов.
Позитивно и достойно уважения, молодец!
Подскажи - что ты писал в резюме? С учетом того, что непосредственно опыта в it не было - как обратил на себя внимание эйчара?
Я - аналитик :) причем с большим стажем работы (10 лет).
На JR cижу для общего развития и получения наглядного понимания того, с чем сталкивается программист и какая информация и в каком виде ему (программисту) необходима.
ПЕРЕЙДИТЕ В ПОЛНУЮ ВЕРСИЮ