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

Мне сложно работать в моей текущей работе.

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

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

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

Есть ли у вас мысли о том, как с этим бороться? Я немного устал от необходимости каждый раз взламывать "грязную кодовую базу"!

Ответ 1

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

Удостоверьтесь, что вы можете вывести то, что вы жалуетесь, в конкретный недостаток. Если не по какой-либо другой причине, так что вы можете мотивировать среднего руководства на улучшения. Вещи, которые трудно вывести в измеримые факты, как правило, происходят из-за разницы в вкусе/стиле, а не в качестве (есть места, чтобы читать об этом предмете). Ответ, отправленный smacl, имеет хороший и конкретный совет!

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

Принятие подобной ситуации аналогично тому, как "плохие качественные линейки продуктов и дорогостоящее и разочаровывающее обслуживание - это то, с чем моя компания может жить" . Это, конечно, редко бывает. Однако менеджеры (т.е. Те, у кого есть проблемы/нет, идут на то, какие проекты имеют приоритеты) очень часто не знают о проблемах или почему разработка стоит дорого. Они не должны быть в этом отношении.

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

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

Удачи.

Ответ 2

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

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

Например:

Не держаться от него:

"Другие разработчики используют эти неясные, вводящие в заблуждение идентификаторы, а затем I вынуждены тратить часы на выполнение кода, пытаясь понять, что они имели в виду. Он занимает много my time.

Сохраняя себя:

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

Я надеюсь, что это поможет.

Ответ 3

1) Сделать проблему более заметной и получить управление бай-ином

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

2) Подумайте об экономичном способе продвижения вперед

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

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

3) Согласитесь с более долгосрочными улучшениями с вашими сотрудниками

Сядьте и согласитесь с разумными стандартами кодирования для будущего кода с другими программистами.

Ответ 4

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

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

Ответ 5

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

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

С другой стороны, жалоба приведет к тому, что вы будете рассматриваться как жалобщик. Подумайте, какой результат вы хотите, и какие действия, скорее всего, приведут к такому результату. Вы всегда будете слышать ответ "Нет", когда вы спрашиваете: "Могу ли я выполнять X-дни работы без каких-либо примечательных результатов?"

Ответ 6

Вы можете бросить курить и надеяться найти что-то лучшее.

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

Ответ 7

Считаете ли вы возможным добавить fxcop в автоматизированные сборки для обеспечения стиля кодирования? Помимо этого, вы можете попытаться предложить TDD, который даст возможность тем, кто пишет тест, чтобы понять, что интерфейсы для каждого класса структурированы определенным образом.

Сверху моей головы, что все, что я могу придумать.

Ответ 8

Для начала:

Обеспечьте использование инструментов статического анализа кода. На каждом языке есть несколько хорошо известных инструментов.
Покажите некоторые примеры до и после реорганизованного кода и объясните, почему вы считаете это лучше. Старайтесь не помещать ни одного человека на место.
Кодовые обзоры опытных разработчиков.
помните, что некоторые разработчики не могут помочь, независимо от того, насколько вы пытаетесь...
Если кто-то критикует ваш код как вежливый и открытый, вы можете чему-то научиться.
Цикломатическая сложность/количество изменений/ошибок. Сложный код с большей вероятностью ломается, вызывают больше ошибок, которые вызывают больше изменений, которые стоят дороже!

Ответ 9

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

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

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

Ответ 10

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

Ответ 11

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

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

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

Ответ 12

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

Ответ 13

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

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

Ответ 14

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

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

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

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

Ответ 15

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

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

Если они помнят, что они написали это, они могут уловить..

Ответ 16

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

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

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

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