JavaRush/Java блог/Random/Общие рассуждения
Danil Gordeev
35 уровень

Общие рассуждения

Статья из группы Random
участников
Небольшое повествование о том, как выглядит IT глазами junior-разработчика. Друзья! Меня зовут Даниил, мне 25 лет и я работаю программистом уже на протяжении 4 месяцев, не имея высшего образования. Я хотел бы поделиться своими мыслями, которые могут кому-то показаться интересными или помочь в нашем трудном жизненном пути.
Общие рассуждения - 1
Если вы оказались на распутье и IT индустрия вас привлекает, но в то же время, вы чувствуете, что вам трудно ориентироваться в бизнесе, хочу рассказать, как все это приблизительно выглядит изнутри. Чтобы получать деньги за разработку, необходимо продавать разработанный продукт кэп. С повальным развитием интернета, который заполонил весь земной шар, спрос на программное обеспечение, насколько я могу судить, будет только расти. Сильнее ужесточаются требования контроля учета деятельности в различных организациях, поэтому сохраняется необходимость внедрять корпоративный софт. Владельцу предприятия "Х" срочно понадобилось внедрить корпоративный софт для учета товаров/сотрудников/чего-угодно. Он обращается к IT-организации, которая готова ему продать его (если необходимо - предварительно разработав, есть много готовых решений). Далее происходит процесс всевозможных оговорок и планировка архитектуры приложения. Команда пытается определить, каким образом они будут разрабатывать проект, с учетом всех возможных последствий и нюансов. Планируется и создается архитектура БД (иногда выбирается самим заказчиком, иногда выбирается не с самой адекватной точки зрения), архитектура самого приложения, а так же продумываются возможные ситуации наперед. Крайне важно заложить грамотную архитектуру проекта, потому что из-за ошибки или неверно принятых решений, проект однажды может зайти в тупик. Далее составляется ТЗ (техническое задание), согласно которому начинается работа. Большинство программистов (по идее) должны работать строго по ТЗ, потому что в случае конфликтных ситуаций - ссылаться будут в первую очередь на него. Устраиваясь младшим разработчиком, вы, скорее всего, начнете работать над уже действующим приложением и вам необходимо будет узнавать его. Для этого существует спецификация или "wiki" проекта, где описывается его поведение в целом, каким образом осуществляется возможность добавлять новый функционал, какие технологии применяются, в общем - внутренние особенности. Разработчик работает в связке с несколькими людьми. Это его руководитель - ПМ, Project Manager, голова проекта. Менеджер занимается управленческой работой - распределяет ресурсы, людей, расставляет приоритеты, ругается разговаривает с представителем заказчика, определяет для команды дальнейший вектор движения. Руководитель рангом поменьше, но не менее важный - тимлид. Данный подвид комбинирует управленческую и техническую часть работы, управляя командой из нескольких человек, работая над чем-то конкретным и без отрыва от процесса написания кода. ТЛ будет выдавать разработчику задания, помогать (возможно) в трудных ситуациях. Далее следует аналитик. Задача аналитика - интерпретировать задания из ТЗ, либо полученные от кого-то еще на понятный разработчику язык. Он создает техническую документацию/спецификацию, где описывает необходимые сведения для девелопера, и что конкретно от него требуется на данном этапе разработки. Встречается не везде. Я с аналитиками на своем проекте не знаком. И, разумеется, тестировщик. Разработчик, создав функционал и, проведя его отладку, передает его тестировщику, чтобы он мог исследовать поведение программы под различными ситуациями, чтобы найти возможные баги, в последствии передавая код обратно. Сейчас существует огромное количество фреймворков и инструментов работы для тестировки, поэтому серьезные знания программирования для этого не требуются. Распределение работы осуществляется с помощью специальных внутренних сервисов, например - JIRA. Это похоже на некую "рабочую социальную сеть", где у каждого сотрудника есть аккаунт, на который он получается задания, где описано - что от него требуется, в какие сроки необходимо уложиться, что это за работа - критическая ошибка, баг или какое-то улучшение. Присутствует лента новостей, можно наблюдать - что сейчас происходит на проекте. Вы получили задания в JIRA, вам пришло уведомления об этом, вы его открыли - увидели, что требуется, сделали необходимое, отправили задачу на "review" или "done" с комментарием о проделанной работе. Все. Для того, чтобы большое количество людей могло одновременно работать над одним проектом и иметь актуальную версию и возможность оперативно фиксировать свою работу, существуют системы контроля версий (СКВ). Централизованные СКВ хранят текущую версию проекта, которую сотрудник может скачать себе (update, poll), сделать какие-то изменения в коде, и отправить их в СКВ (commit, push), чтобы другие разработчики тоже получили себе созданные изменения. Проект может развиваться по разным направлениям - веткам (branch), чтобы на данный момент иметь несколько вариаций готового решения. Обычно, после того, как разработчик завершил какое-то задание, с ним проводят так называемый code-review - когда ПМ, тимлид или более опытный сотрудник начинает смотреть - что он там понаписал и не сломается ли все, если применить на рабочем сервере этот коммит. Если проект действует и эксплуатируется на данный момент и нет необходимости вводить новый функционал, то заказчик может продолжать платить организации за поддержку продукта. В случае, если пользователь наткнулся на баг или программа ведет себя в целом не так, как должна - представитель заказчика обращается с этим и проблема оперативно(или нет) устраняется. Пример рабочей иерархии можно увидеть здесь: https://ru.wikipedia.org/wiki/Организационные_формы_управления Подытожив, отмечу, что данная работа позволяет человеку быть востребованным в любой точке земного шара. Услуги аутсорса ("продажа" компанией услуг своих работников на определенное время в договорной основе) и аутстаффа ("продажа" сотрудников для работы в другом месте на определенное время в договорной основе) позволяет всем на выгодных условиях обмениваться кадрами. Для кадров - прекрасная возможность путешествовать и узнавать что-то новое. Какие выводы я могу из этого сделать:
  1. Программирование - исключительно практическая наука. Теория призвана дать только общие рекомендации, к большинству вещей приходиться приходить своим умом, поэтому навык решает все.

  2. Возможность иметь относительно комфортный график работы.

  3. Следует более трепетно относится к своему организму. Хорошо спать и правильно питаться - залог здорового разума.

  4. Консультируйтесь у более успешных знакомых/друзьях! Интересуйтесь бизнесом, разработкой, принципами работы программиста изнутри. Исследуйте рынок на наличие вакансий в вашем регионе заранее. И не общайтесь с людьми, которые не верят в ваш успех.
Что полезно знать:
  1. SQL. Обязательно. Необходимо будет часто работать с СУБД.

  2. Онлайн-стажировка на javarush - мастхэв. Это действительно увесистый плюс в ваше портфолио, в котором изучаются вещи, которые вы встретите на своей первой работе. Разумеется, с кучей подводных камней. Я начинаю ее проходить, уже работая.

  3. Сейчас есть такое модное слово - full stack developer. Вполне возможно, что вам придется писать не только серверный код, но еще и клиентский. Поэтому пригодятся знания html, xml, css и прочей верстки.
Я устроился после третьего собеседования. Искал работу на hh, компании с недоверием относятся к людям без образования и опыта, поэтому единственное, чем мы можем выиграть - это скиллами. Что порадовало - везде была довольно приветливая обстановка и вежливые люди, с которыми приятно общаться. Цитата в тему "я никогда не видел человека, который сходил бы на 20 интервью и его никуда не взяли". Ну и ложка дегтя, куда же без нее? Придется посвящать этому очень много времени, и тут сыграет фактор - нравится вам это в целом или нет, потому что кодить без желания - подобно пытке. Желательно еще развиваться как-то помимо работы, чтобы быть конкуретноспособным. В довесок могу добавить про очевидные последствия сидячего образа жизни. Все вышеописанное имеет исключительно субъективный взгляд. Небольшая ремарочка: Хочу сказать большое спасибо людям, которые пишут истории успеха, это действительно мотивирует! Еще хочу сказать спасибо создателем javarush за сам ресурс и за такое развитое коммньюнити, где люди готовы друг другу помогать в достижении общих результатов.
Комментарии (14)
  • популярные
  • новые
  • старые
Для того, чтобы оставить комментарий Вы должны авторизоваться
Vitaly
Уровень 27
25 марта 2018, 23:19
Позитивно и достойно уважения, молодец! Подскажи - что ты писал в резюме? С учетом того, что непосредственно опыта в it не было - как обратил на себя внимание эйчара?
23 февраля 2018, 13:45
Да, полезная инфа!
Олег
Уровень 31
22 февраля 2018, 23:28
Дуже круто і корисно!Дякую!
Gagarin
Уровень 28
20 февраля 2018, 11:33
Спасибо, было интересно!
Danil Gordeev
Уровень 35
20 февраля 2018, 19:49
спасибо за отзыв)
Аслан Backend Developer в Mail.ru Group Expert
2 марта 2018, 20:12
А можно чуть больше конкретики? Какова локация? В каком городе Вы живете? Учились ли Вы на технической специальности?(каков бекГраунд? не IT, но что?) Ваша компания работает с уже готовым BPM или ведет свою разработку? Дайте рекомендации, как учить SQL. И на каком уровне его следует уметь применять, чтоб иметь серьезный шанс на трудоустройство?
Danil Gordeev
Уровень 35
6 марта 2018, 08:13
поехали: 1) Город Пенза, около 600к человек. 2) Учился в ВУЗе на информационной безопасности, но, проучившись 2 года, бросил, т.к. надоело и в целом не понравилось. ВО у меня нет. 3) У нашей компании собственная платформа (написанная на java), которая используется для разворачивания готовых корпоративных решений. corchestra.ru Много команд, много проектов. 4) Практика, естественно) sql-ex.ru. Я бы не сказал, что нужен прям серьезный уровень, необходимо скорее общее понимание - как с этим работать; чтобы у вас глаза не округлились, когда вас попросят написать SELECT запрос с объединением таблиц, например. А какие-то нюансы вы уже узнаете непосредственно в процессе работы.
20 февраля 2018, 10:22
"В довесок могу добавить про очевидные последствия сидячего образа жизни." Dот это больше всего и убивает.
Danil Gordeev
Уровень 35
20 февраля 2018, 19:50
ага) зато остается больше энергии для того, чтобы заниматься какой-нибудь физической активностью
Максим
Уровень 40
Expert
19 февраля 2018, 22:42
Спасибо. Было интересно почитать, как там все устроено. Надеюсь в скором времени узнаю это лично!)
Danil Gordeev
Уровень 35
20 февраля 2018, 19:50
вам тоже спасибо, удачи)
Костик Хвостик
Уровень 18
19 февраля 2018, 21:31
Я - аналитик :) причем с большим стажем работы (10 лет). На JR cижу для общего развития и получения наглядного понимания того, с чем сталкивается программист и какая информация и в каком виде ему (программисту) необходима.
Danil Gordeev
Уровень 35
20 февраля 2018, 19:51
будучи аналитиком, вы часто занимаетесь именно технической работой (написание кода и так далее)?
Костик Хвостик
Уровень 18
20 февраля 2018, 20:40
Нет, конечно. Аналитика нельзя подпускать к написанию кода - это дело разработчика и его область ответственности. Дело аналитика выяснить и донести до разработчика требования, отвечать на вопросы разработчика и гарантировать, что труд программиста не вылетит в трубу из-за того, что заказчик не может сформулировать свои требования. При этом, если аналитик разбирается в программировании - это большой плюс, это позволяет гораздо быстрее и легче находить общий язык с техническими специалистами. В разных организациях области ответственности могут быть разделены по-разному, но описанный выше подход ИМХО является наиболее правильным. Код я пишу, поздно вечером, когда дома все затихает :) ну, не код, а так - задачки решаю :)