Проблемы на первой работе: как быстрее влиться в большой проект?
Всем привет. Хотелось бы спросить совета у более опытных программистов по поводу их первой работы.
В конце апреля меня взяли на стажировку в небольшую компанию на позицию Junior Front End Developer. За 2 месяца я подтянул теоретическую базу по JS, познал основы Ember.js и RoR. Практикуюсь в написании кода дома, разрабатываю небольшой проект, всегда читаю книги и полезные статьи, в общем, стараюсь развиваться.
Но вот проблема: вместе со своим наставником я поддерживаю один большой интернет-магазин и для меня очень трудно разобраться в его архитектуре. Из-за этого есть некоторые проблемы с написанием нового и поддержкой старого кода и нормально работать на очень большом проекте, который я не до конца понимаю, очень сложно, а наставник хоть и поддерживает и всячески помогает, но говорит, что объяснение всей архитектуры займет очень много времени и просит самому понемножку разбираться с ней. Если кто-то сталкивался с такой проблемой в начале своей карьеры, помогите советом, как быстрее влиться в большой проект.
Заранее благодарен за ответы.
41 коментар
Додати коментар Підписатись на коментаріВідписатись від коментарів7 strategies to quickly become productive in an unfamiliar codebase.
Коментар порушує правила спільноти і видалений модераторами.
Просить senior-а помочь, если он отмахивается — идти к менеджеру и вежливо просить содействия. Раз вас взяли на проект и приставили наставника, то он обязан вам помогать. Далее — брать все возможные разносторонние таски, чтобы видеть проект с разных сторон.
Last but not least — не зацикливайтесь. Если есть выбор — настроить сложный конфиг или пофиксить 50 erb-шек, выбирайте конфиг. Уровень растет только на сложных задачах, также как экспу дают за сильных мобов/боссов, а за трешак не дают. Если вы видите какую-то адскую самописную хрень, которую 100 пудов нигде больше не юзается — забейте на нее. Лучше посмотрите как Rails работает/деплоится, подтяните JS.
Хорошо, когда есть синьйоры, и плохо когда один на проекте
Тут мабуть допомагає психологія.
Задавши собі питання: «Що зробив би на моєму місці senior?»
— Скинув проект на фріланс. Найняв індуса за 3.37 долара в годину, а сам попивав коктель на пляжі у В"єтнамі.
А не забагато? За $1,5 знайдеться дуже багато бажаючих
Тут необхідно множити на коефіцієнт Совісті.
Найняти двох індусів...
Ну в нормальной конторе одного на большой-средний проект ниже миддла не поставят и в любом случае будут присматривать и это означает что в проекте тотальный сапорт — мелкие баги и подъем/переподъем инстансов, бекапы и деплой, никаких новых фич.
Если это какая-то конторка с ЧСВ over 9000, которая натягивает ворованные CSS-ки на похапе то воможно все, но оттуда надо быстро бежать.
У меня такая-же ситуация. Но вот одно могу сказать. Если брать мою ситуацию, то понятно одно. У меня к примеру ситуация такая, по факту явлюсь asp.net developer. Также сейчас есть много новых проектов, но понятно одно, в етих проектах не используеться безлимитное колличество технологий, их гдето 4 — 5, причем мест применения запутанных не так и много и они ограничены. Мне стало ясно, что нужно просто разобраться стем, что есть уже. Запомни, твой магазин большой, много технологий, но их не безконечность. Ты их со временем все узнаешь. Так что прсото бери и делай и не пытайся всю вселенную сразу охватить. А то нужно такое ощущение, что нужно тему переименовать, как стать программером за 24 часа. Чувак, 3 года минимум. Так, что бери и делай.
Просто бери и делай....
на самом деле все просто — нужно перейти от общих вопрос (а какая у нас архитектура), к конкретным вопросам, ответы на которые не занимает много времени. ну например:
— а сколько у нас серверов и какая топология
— сколько у нас хранилищ данных, каких и зачем
— какого вида коммуникация существуют между сервером и клиентами
— а вот у нас есть фича AAA, каким образом для нее реализовано BBB
— а вот я смотрел код и вот тут такое ...
— а как мы ошибки обрабатываем
— а что у нас синхронно, а что нет
ну и так далее, мне тяжело сформулировать более подробные вопросы для вашего проекта, ибо я ничего о нем не знаю.
если ваш коллега настроен на диалог, то я думаю сработает и будет более удобно и вам и ему.
Это не только в начале карьеры такие проблемы бывают. Это совершенно обычная ситуация в нашей работе.
P.S.:
«Если долго мучаться — что-нибудь получится».
Угу, аналогичная «„проблема“» в каждом новом сложном проекте.
Я бы это не «проблемой» назвал бы, а «работой» )
«Проблему» можно переименовать в «трудность».
А че, тестів на проекті нема?
Никаких секретов, бери и изучай :(
В такие моменты вспоминаешь, что знание проекта — тоже труд.
Запасись терпением и просто берись за разные таски, из разных кусков проекта.
Со временем знание и понимание — прийдет.
Спасибо всем большое за ответы.
lurkmore.to/Ноотропы
а зачем знать весь проект чтобы работать? не ну честно, оно вам 100% все надо?
Я бы начал смотреть требования. Т.е. разобраться что и почему магазин должен делать. Просто читать код и пытаться понять логику работы очень сложно, можно разобраться как работает какая-то функция, типа принимаем данные, обработали, выдали результат, но не понимая почему мы получили такие данные и почему нужна такая обработка, чтением только кода, будет сложно разобраться в работе системы. Если наставник не может кратко описать как все работает, поговорите с «гуманитариями», у вас наверняка есть какие-то продакт менеджеры.
никогда не думал что магазин может иметь сложную архитектуру. на чем написана магазин ?
это вы с магазинами на hybris не сталкивались....
и сколько времени занимает выкатить новую фичу в таком магазине ?
там и много других вопросов есть (типа «сколько магазин может жрать памяти? И нахрена ему СТОЛЬКО?» или «сколько магазин может насоздавать таблиц в базе? И зачем это все?» и тп). Но главный вопрос у этой системы «как ее умудряются впаривать магазинам?»
дык это ж — планета Java!
www.hybris.com/...ture-technology
у нас просто — не бывает :)
просто, написание под заказ это на пыхе, рельсах или джанге
а на джаве — ставите все, и годится оно для всего, а потом — «конфигурируете».
под заказ конечно тоже бывает, разработка. но это — дорого и долго.
не всякий бизнес себе может позволить — разработку на джаве под заказ
Немного видел.
Могу ошибаться, но впечатление такое, что:
*) Это некий «обобщённый фреймворк для всего» для e-commerce, адски тяжёловесный. Реально, проще и быстрее на голых сервлетах с JSP и JDBC писать, чем всё это освоить.
*) Наверное, хотели сделать что-то, чтобы «быстро и просто» создавать сложные магазины. А в итоге круг простоты и сложности замкнулся, и вместо мега-фреймворка стало проще вернуться к сервлетам, JSP и JDBC. Потому что гибкая кастомизация понадобится скорее всего всегда.
ага, тоже какое-то такое впечатление осталось
Написан на RoR и Ember.js. Так как я новичок и работаю только несколько месяцев для меня это достаточно сложная архитектура.
вы в MVC модели разобрались и как рейлс работает с ней ?
Конечно. Проблема не в рельсе или в ембере,принцип их работы я понимаю. Проблема в большом количестве кода. Трудно разобраться во всех классах, вызовах, замыканиях, методах и т.д.
так начните с малого- разберитесь с формой заказа, потом с категориями товара, потом с модулями типа похожие вещи, комменты, рекомендации.я не знаю как руби строит магазины, но те магазины которые я видел — там все очень просто было. берешь страницу заказа в хроме — и жмешь показать исходники, потом открываешь ПХП файл и смотришь откуда он взял хидеры, откуда верстку, откуда списки взялись и т.д.
я не шарю в руби, поэтому я описал как это делать в пхп.
дело даже не в руби.
а в рельсах которые обильно сдобрены метапрограммированием :)
такой обильности применения этого подхода нет нигде, в 10ке ЯП из Tiobe
большие проекты на пхп пишутся без фрейворков
потому что это — Ruby :)
он на вид только — простой.
и в рекламе учебников для начинающих рубистов.
а из троицы — PHP, Python, Ruby — самый сложный.
насчет проблемы разобраться: в коде нередко сложно разобраться, потому что непонятно что он вообще делает. для чего он. то есть разбираться нужно — в самой предметной области.
вот представьте что вы — обычный пользователь программы в которой разбираетесь.
какие знания вам нужны — чтобы вас взяли на работу этим пользователем?
а представьте что вы сам заказчик, менеджер, который ставит задачу программистам, не понимая ничего в программировании.
в коде, может быть много неочевидных, технических фич. например частая — для быстродействия выбрано более сложное инженерное решение, чем простое, «в лоб», как просили — «программа должна делать вот так и так» — так и написано.
если вы плохо понимаете что должна делать программа — то будет сложно отличить где код реализующий функционал, а где — инженерный выкрутас его решения.
попробуй диаграмму проекта нарисовать, или составить mindmap того, что уже знаешь и понемногу расширять его от самых абстрактных аспектов архитектуры и до конкретных функций/методов, это может помочь понять