Как работать с процессом разработки, который не поддерживает чистый код?

Это ваш ответ прямо здесь.

Эта компания не проводит обзоры кода, модульное тестирование и качество кода не заботит руководителей.

Так что единственный человек, делающий что-либо структурированным образом, — это вы. Несмотря на то, что код (по вашему мнению) беспорядок, другие разработчики это знают и понимают. Когда вы все исправляете, вы разрушаете их представление о том, как все это держится вместе.

Итак, просто продолжайте работать так, как хотите, но не тратьте дополнительное время на рефакторинг чужого кода (вы уже видели, что им это не нравится).

Если кто-то испортит вашу часть кодовой базы, пока вы отсутствуете, запланируйте время, чтобы исправить ее обратно, когда вы вернетесь.

Если вы не можете так жить, вам, возможно, придется изучить другие варианты трудоустройства — вряд ли вы сможете изменить то, как работает эта команда, не будучи руководителем.

Эмоциональный подход к рабочим вопросам совсем не продуктивен, но весьма обычен. Вы упомянули в комментарии, что устойчивый к изменениям коллега — это не тот человек, который изначально написал код. Это означает, что он может занять оборонительную позицию, потому что сам не пытался исправить код, поэтому он воспринимает рекомендуемое вами изменение как вызов. Или, может быть, он просто ленив и не хочет рефакторить код.

Я уверен, что вы использовали такие аргументы, как: плохо написанный код может работать, но он подвержен ошибкам, непонятен новым сотрудникам, его сложно поддерживать, и все это приводит к потере драгоценного времени. Если это не сработало, вам следует попробовать использовать эмоциональность самостоятельно.

• Я знаю, что код работает, потому что вы хорошо поработали над реализацией/поддержкой, но мне и потенциально любому новому члену команды разработчиков очень сложно понять и работать над ним (это также может звонить в колокол, поскольку почему все ваши предшественники ушли).

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

Вы также можете организовать встречу с разработчиками, руководителем группы И руководителем/руководителем проекта, чтобы сделать краткую презентацию полезного характера чистого кода и тестирования.

• Приведите как можно больше примеров того, как это поможет вам в будущем.
• Сделайте оценку усилий.
• Самое главное , попросите их рекомендации о том, как можно оптимизировать код и как вы можете работать вместе для реализации изменений.
• Составьте план, когда это может произойти.

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

Удачи!

Если смотреть с точки зрения менеджмента, огромный рефакторинг кода

• Сжигает сотни часов рабочего времени персонала,
• Не добавляет новых функций в код,
• Риски добавления новых ошибок, которых раньше не было.

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

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

Эта компания не проводит обзоры кода, модульное тестирование и качество кода не заботит руководителей.

Если вы хотите изменить это, вы должны привести веские аргументы, почему это следует изменить, подкрепленные данными . Помните, что проверка кода и написание модульных тестов требуют времени программистов, а это затраты. Любой час, потраченный на просмотр чужого кода, — это час, в течение которого вы не пишете код, приносящий деньги. Любой написанный модульный тест, который никогда не дает сбоев (то есть никогда не обнаруживает потенциальную ошибку), является пустой тратой ресурсов, которая никогда не окупится.

Менеджмент будет знать, сколько стоит X часов проверки кода, Y часов написания тестов и дополнительные Z часов на «улучшение качества кода». Утверждение «но позже у нас будет меньше ошибок» или «это упрощает написание кода в будущем» расплывчато и не поддается количественной оценке; это не будет иметь большого значения для руководства. Можете ли вы подсчитать, сколько времени теряется из-за плохого качества кода, отсутствия проверок кода и отсутствия модульных тестов? Примите во внимание, как долго выживает код. В компании, в которой я работаю, во многих кодах отсутствуют модульные тесты, но большая часть кода также будет либо отброшена, либо переписана в течение 6–12 месяцев.

Модульные тесты и качество кода — это хорошо (обзоры кода OTOH, с которыми я не согласен), но так же хороши быстрые ноутбуки и собственная кофейня с бесплатным качественным кофе. Они повысят производительность, но за них придется заплатить. Только в том случае, если выигрыш от повышения производительности превышает затраты, руководству имеет смысл внедрить их.

Просто иди вперед, ты не дерево!

Как разработчик, вы знаете, что не можете работать в таком месте, и вы знаете, что вы ничего не можете изменить (изменить образ мышления вашего босса), так что просто двигайтесь дальше! Найдите другую работу в лучшем месте!