Как объяснить своим коллегам, что они создают дерьмовый код?

Question

Мне трудно продолжать работать на моей нынешней работе.

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

Мой начальник уже знает о моих мыслях - я выразил, что чувствует, что работает так Он попросил меня привести примеры того, что было не так. Когда я указал на два или три небольших вопроса, он сказал: «Да, хорошо», но этот рефакторинг стоит ему больших денег, и что мы должны выпустить продукт (не первый раз, когда я слышу это).

Я должен признать, что примеры были не самыми убедительными, но проблему на самом деле сложно объяснить. Он состоит из множества крошечных «плохих решений» в кодовой базе. (Мы также видим, что этот вопрос абсолютно субъективен). Например, неправильное именование, работа с нулями, стандартный шаблон, невозможность повторного использования кода (или наоборот) и так далее. Может быть утомительно переосмысливать чужой код снова, чтобы оправдать то, что я сделал бы это по-другому.

У вас есть мысли о том, как с этим бороться? Я немного устал от необходимости взламывать каждый раз код quick 'n dirty !

Answer 1

Одна вещь, которую я пытаюсь сделать, и она может вам помочь. Если часть кода плохая, и идея, которую вы предлагаете исправить, согласована как лучшая, но не дается оправдание «нет времени», почему бы вам не переписать ее? говорите в свободное время? Если вы решите остаться на этой работе какое-то время, это только поможет вам. И только вы будете учиться и стать лучшим программистом.

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

Answer 2

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

Answer 3

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

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

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

Answer 4

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

Answer 5

99% времени вы никогда не сможете выбрать людей, с которыми работаете. Не все отношения работают, будь они работают или нет.

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

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

Answer 6

В жизни все не идеально, и если вы начнете придираться, перья будут взъерошены, а отношения испортились.

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

Это подходит для вашей ситуации ...

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