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

Question

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

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

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

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

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

Answer 1

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

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

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

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

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

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

Удачи

Answer 2

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

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

Например:

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

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

Не подпускать себя к этому:

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

Надеюсь, это поможет.

Answer 3

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

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

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

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

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

3) Согласуйте улучшения условий с вашими коллегами

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

Answer 4

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

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

Answer 5

Для начала:

1. Обеспечить использование инструментов статического анализа кода. У каждого языка есть несколько хорошо известных инструментов.

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

3. Кодовые обзоры опытных разработчиков.

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

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

6. Цикломатическая сложность / количество наборов изменений / ошибок. Сложный код с большей вероятностью ломается, вызывает больше ошибок, которые вызывают больше изменений, которые стоят больше денег!

Answer 6

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

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

Answer 7

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

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

Answer 8

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

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

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

Answer 9

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

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

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

Answer 10

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

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

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

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