10 вещей, которые бы я хотел услышать в первый год работы. Опыт Java разработчика. Часть 1: не только лишь код

[Android1983]

Привет автор.

По сути статья написана достаточно качественно понятно как для новичка. Я уверен что вопросы могут возникнуть у тех кто хоть одной ногой уже в теме.

Так же похвалю автора за статью, так как тпакие статьи полезны тем чтобы устроившись на работу не вылететь с неё косяча казалось бы по таким пустякам.

Жду с нетерпением следующую главу. В ней затронуты тоже важные вопросы разобрав которые получиться избежать много проблем. Особенно интересно узнать что сейчас актуально и нужно изучать чтобы быть востребованным на рынке труда и не потратить время на изучение лишнего.

[Alex_software_dev]

Здравствуйте, спасибо большое за теплые слова. Постараюсь хорошо сделать вторую часть. Тема изучения будет частично затронута во второй части.

[moonster]

1. Онбординг: не бояться спрашивать и просить помощи.

Да, но есть вещи, понимание которых предполагается по умолчанию. Как минимум, это всё то, что можно подчерпнуть из документации, как из публичной, так и внутреннего пространства проекта и компании.

2. Не стесняться дергать того, кто дал задачу.

Задача должна быть поставлена так, чтоб исполнитель, с учетом уровня вовлеченности и компетентности, мог решить ее самостоятельно. Конечно, это в зоне ответственности руководителя, но и доля ответственности исполнителя тут есть. Нужно или в моменте проанализировать задачу, и если показалось, что есть невнятные моменты, то взять время на более углубленное знакомство с последующей запланированной встречей, где исполнитель сможет провалидировать понимание. А "дергать" лишний раз не надо, про это тут уже много написано.

3. Код-ревью. Защищаться и получать выгоду.

А тут всё верно. "Не нравится" - это плохое замечание, нужна конкретика. Но бвает и так, что "не нравится" потому, что проще с нуля переписать, чем объективно критиковать PR, каждая строчка которого вызывает нервный тик и кровоточение глаз.

4. Сразу уделять большое внимание чистоте кода и архитектуры(уровень классов, сервисов и тд).

Чтоб принимать правильные архитектурные решения, нужно обладать достаточной компетентностью, иметь качественные требования и полную информацию о прочих разных аспектах окружения. Если чего-то из этого нет - лучше сделать максимально просто и покрыть тестами, скорее всего интеграционными, чтоб потом можно было отрефакторить, и обязательно заложить этот рефакторинг в план. Да, придется следить за техдолгом, придется продать рефакторинг менеджменту, но это все равно проще, чем прыгнуть выше своей компетентности и значительно проще, чем предсказать будущее.

Иными слрвами, код должен быть максимально прост, и он не должен опираться на неподтвержденную информацию.

5. Писать больше тестов сразу.

Тестов нужно писать столько, сколько нужно. ) Серьезно. Я видел ситуации, в которых одна и та же функциональность с разной реализацией имела количество тестов, отличающееся на порядок. Мидл наколбасил реализацию и более 100 тестов, сениор отрефакторил, задекомпозил, получил 4е класса вместо одного, для 3х написал простейшие юниты, для 4го, который зависел от предыдущих 3х, написал юнит на моках. Тестов стало около 15.

Тесты - тоже код, а кода чем меньше - тем лучше.

[Alex_software_dev]

Спасибо большое за очень полезную и развернутую обратную связь. Я внес некоторые коррективы в статью. Вы действительно помогли сделать ее лучше для читателей. Немного соображений на тему:

1. Уточнил, что есть общие вещи которые предполагается что вы знаете заранее.

2. Добавил что необходимо сначала углубиться в задачу, используя ваш опыт, знания, умение искать информацию попытаться самостоятельно найти ответы на вопросы, и только после этого пойти к ответственному коллеге с хорошо продуманным набором вопросов

3. Согласен и разделяю вашу боль, иной раз хочется взять и написать все самому, но я бы все равно объяснил что «к сожалению каждую строчку этого кода (куска *) нужно переделать, так как а,б,ц,д». А если такое возникает регулярно, то нужно задуматься о целесообразности нахождения сотрудника в команде, или на данных задачах. Это исключительно мнение из опыта, ни на что больше не претендую.

4. Согласен, но либо мне и всем моим знакомым из индустрии так везло, либо довольно часто происходит так, что фраза «потом отрефакторим» перерастает в «никогда». А компетенции для изначально грамотного проектирования на низком уровне системного дизайна по моему мнению должны быть.

5. Про тесты немного исправил название и добавил про важность качества а не количества, и про существенный вред бесполезных тестов

   Спасибо огромное за помощь в улучшении статьи

[LeshaRB]

10 вещей, которые бы я хотел услышать в первый год работы.

В одну статью все 10 вещей не поместились?

[Alex_software_dev]

Была бы слишком длинной на мой взгляд

[gybson_63]

Когда я еще был совсем юн, мне часто повторяли
- Думай, что делаешь
- Посмотри, что ты делаешь
- Что ты делаешь?

И это был не абьюз. Это было очень неумелое, но важное обучение. Всегда необходимо думать что ты делаешь и знать что ты делаешь. Тогда большинство проблем отсекается. Вам нельзя сказать : "Так не пишут". Так в принципе люди с высшим образованием не должны даже сметь сказать, но всякие бывают (это про пункт 3)

Если вы хотите знать, что делаете, то вы совершенно естественно спрашиваете и учитесь. Потому что вы знаете, что сейчас не знаете что делаете, но должны узнать (это пункты 1 и 2)

4 и 5 тоже логично вытекают.

Всегда знайте что вы делаете. В любой момент вы должны четко и ясно рассказать что вы делаете.

И после этого уже переходим к "зачем" :) Это тоже важно.

Это очень простая, но необходимая база вообще для любой деятельности. А для такой сложной, как программирование, особенно.

Всегда знайте что вы (или ваш ИИ) делаете.

[Alex_software_dev]

Спасибо вам большое. Очень точно сказано - всегда необходимо думать что ты делаешь и знать что именно. Это действительно момент, без которого всё остальное не работает