Comments 11
Привет автор.
По сути статья написана достаточно качественно понятно как для новичка. Я уверен что вопросы могут возникнуть у тех кто хоть одной ногой уже в теме.
Так же похвалю автора за статью, так как тпакие статьи полезны тем чтобы устроившись на работу не вылететь с неё косяча казалось бы по таким пустякам.
Жду с нетерпением следующую главу. В ней затронуты тоже важные вопросы разобрав которые получиться избежать много проблем. Особенно интересно узнать что сейчас актуально и нужно изучать чтобы быть востребованным на рынке труда и не потратить время на изучение лишнего.
1. Онбординг: не бояться спрашивать и просить помощи.
Да, но есть вещи, понимание которых предполагается по умолчанию. Как минимум, это всё то, что можно подчерпнуть из документации, как из публичной, так и внутреннего пространства проекта и компании.
2. Не стесняться дергать того, кто дал задачу.
Задача должна быть поставлена так, чтоб исполнитель, с учетом уровня вовлеченности и компетентности, мог решить ее самостоятельно. Конечно, это в зоне ответственности руководителя, но и доля ответственности исполнителя тут есть. Нужно или в моменте проанализировать задачу, и если показалось, что есть невнятные моменты, то взять время на более углубленное знакомство с последующей запланированной встречей, где исполнитель сможет провалидировать понимание. А "дергать" лишний раз не надо, про это тут уже много написано.
3. Код-ревью. Защищаться и получать выгоду.
А тут всё верно. "Не нравится" - это плохое замечание, нужна конкретика. Но бвает и так, что "не нравится" потому, что проще с нуля переписать, чем объективно критиковать PR, каждая строчка которого вызывает нервный тик и кровоточение глаз.
4. Сразу уделять большое внимание чистоте кода и архитектуры(уровень классов, сервисов и тд).
Чтоб принимать правильные архитектурные решения, нужно обладать достаточной компетентностью, иметь качественные требования и полную информацию о прочих разных аспектах окружения. Если чего-то из этого нет - лучше сделать максимально просто и покрыть тестами, скорее всего интеграционными, чтоб потом можно было отрефакторить, и обязательно заложить этот рефакторинг в план. Да, придется следить за техдолгом, придется продать рефакторинг менеджменту, но это все равно проще, чем прыгнуть выше своей компетентности и значительно проще, чем предсказать будущее.
Иными слрвами, код должен быть максимально прост, и он не должен опираться на неподтвержденную информацию.
5. Писать больше тестов сразу.
Тестов нужно писать столько, сколько нужно. ) Серьезно. Я видел ситуации, в которых одна и та же функциональность с разной реализацией имела количество тестов, отличающееся на порядок. Мидл наколбасил реализацию и более 100 тестов, сениор отрефакторил, задекомпозил, получил 4е класса вместо одного, для 3х написал простейшие юниты, для 4го, который зависел от предыдущих 3х, написал юнит на моках. Тестов стало около 15.
Тесты - тоже код, а кода чем меньше - тем лучше.
Спасибо большое за очень полезную и развернутую обратную связь. Я внес некоторые коррективы в статью. Вы действительно помогли сделать ее лучше для читателей. Немного соображений на тему:
Уточнил, что есть общие вещи которые предполагается что вы знаете заранее.
Добавил что необходимо сначала углубиться в задачу, используя ваш опыт, знания, умение искать информацию попытаться самостоятельно найти ответы на вопросы, и только после этого пойти к ответственному коллеге с хорошо продуманным набором вопросов
Согласен и разделяю вашу боль, иной раз хочется взять и написать все самому, но я бы все равно объяснил что «к сожалению каждую строчку этого кода (куска *) нужно переделать, так как а,б,ц,д». А если такое возникает регулярно, то нужно задуматься о целесообразности нахождения сотрудника в команде, или на данных задачах. Это исключительно мнение из опыта, ни на что больше не претендую.
Согласен, но либо мне и всем моим знакомым из индустрии так везло, либо довольно часто происходит так, что фраза «потом отрефакторим» перерастает в «никогда». А компетенции для изначально грамотного проектирования на низком уровне системного дизайна по моему мнению должны быть.
Про тесты немного исправил название и добавил про важность качества а не количества, и про существенный вред бесполезных тестов
Спасибо огромное за помощь в улучшении статьи
10 вещей, которые бы я хотел услышать в первый год работы.
В одну статью все 10 вещей не поместились?
Когда я еще был совсем юн, мне часто повторяли
- Думай, что делаешь
- Посмотри, что ты делаешь
- Что ты делаешь?
И это был не абьюз. Это было очень неумелое, но важное обучение. Всегда необходимо думать что ты делаешь и знать что ты делаешь. Тогда большинство проблем отсекается. Вам нельзя сказать : "Так не пишут". Так в принципе люди с высшим образованием не должны даже сметь сказать, но всякие бывают (это про пункт 3)
Если вы хотите знать, что делаете, то вы совершенно естественно спрашиваете и учитесь. Потому что вы знаете, что сейчас не знаете что делаете, но должны узнать (это пункты 1 и 2)
4 и 5 тоже логично вытекают.
Всегда знайте что вы делаете. В любой момент вы должны четко и ясно рассказать что вы делаете.
И после этого уже переходим к "зачем" :) Это тоже важно.
Это очень простая, но необходимая база вообще для любой деятельности. А для такой сложной, как программирование, особенно.
Всегда знайте что вы (или ваш ИИ) делаете.
Какие все нежные стали.
Когда я устроился после обучения в вузе на первую в своей жизни работу (в финансах), мне сказали: “Вот программа "работа с таким-то банком", её разработчик разбился в ДТП, больше никто не знает, как она работает, ты должен разобраться и продолжить разработку. А да, ещё она несовместима с тестовой базой, поэтому отлаживаться будешь на рабочей, смотри ничего там не сломай". Ну и пришлось разобраться. Отлаживался, создавая вымышленные платежи от филиала фирмы Алкатель в стране Австрия, так как он был первым из клиентов по алфавиту, потом эти платежи аннулировал. 90-е годы, простые были нравы. Убить человека стоило сто долларов, так что при программировании движения денежных средств приходилось быть аккуратным.
Не стесняться дергать того, кто дал задачу.
Я с вами согласен, но я бы добавил кое что. Не нужно без разбора бежать к другому разработчику или автору.
Есть 2 грани, вообще не ходить или ходить каждый раз, даже когда все уже описано.
Я встречал таких) вместо того, чтобы посидеть самому, разобраться, сразу идут за помощью
Я уже полчаса не могу найти причину
А в это время ты сидишь и решаешь баг 10 часов)
Так что я бы сказал всем, кто вначале - сначала пробуйте разобраться сами, всегда, как бы тяжело не было, это вырабатывает самостоятельность.
Если уже чат гпт или 10 страниц Гугла не помогли, попросите помощи, в этом ничего плохо нет, но всегда сначала разбирайтесь сами)
Спасибо большое за конструктивную обратную связь, полностью с вами согласен, в первом варианте статьи я забыл сказать про эти моменты и внес изменения в статью касаемо того, что перед тем как бегать с вопросами к старшим коллегам, необходимо применить весь свой опыт, знания, умения искать информацию и если не сработало, с качественно собранным списком всех вопросов (не бегать по 1 каждые 5 минут), пойти за помощью к старшему коллеге
10 вещей, которые бы я хотел услышать в первый год работы. Опыт Java разработчика. Часть 1: не только лишь код