Как спорить с понижением стандартов качества для устаревшей кодовой базы? [закрыто]

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

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

И мы применяем те с помощью Sonar (инструмент анализа кода), который уже имеет несколько тысяч нарушений.

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

Обсуждение о правилах читабельности. Например, сколько вложенных ifs / for .. может иметься.

Теперь, как я могу поспорить против снижения качества нашего кода на унаследованном коде?

Код - это всего лишь средство для достижения цели. Какой это может быть конец, но обычно это прибыль.

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

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

Я предполагаю, что первоначальные разработчики давно ушли и недоступны для обсуждения. Так что нет никого, кто бы понимал, почему и почему стиль дизайна и кодирования. Исправление сотен или тысяч нарушений не будет проблемой переписывания нескольких строк кода здесь и там. Вместо этого, несомненно, требуется рефакторинг / повторное функциональное разложение. Вы пытаетесь сделать это с любой большой существующей кодовой базой, не зная глубоко ее текущий дизайн, и вы обязаны представить целый новый набор ошибок / проблем / и т.д. Просто новая банка с червями, даже хуже, чем та, что у вас сейчас есть (или хуже, чем ваш инструмент >> думает << у вас сейчас).

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

Устаревший код обычно требует только настроек. Как для 2000 года, или когда акции выросли с 256-х до десятичных. Я сделал кучу и того и другого. И много других подобных вещей. Обычно это довольно «точно», потому что вы можете «прочитать» иногда плохой стиль, плохую функциональную декомпозицию, плохой и т. Д. И найти коллекцию мест, которые нужно изменить. И тогда, что происходит «между этими местами», то есть, что является потоком более высокого уровня, может остаться для вас загадкой. Просто убедитесь, что вы понимаете локализуемую функциональность, которую вы меняете, и затем тестируйте, тестируйте, тестируйте на любые побочные эффекты и т. Д., Ваши локализованные знания не смогут предвидеть.

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

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

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

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

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

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

Если это не сломано, не исправляйте это

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

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

Но если это было проверено в гневе больше десяти лет или больше и прошло, оставьте это в покое! Если нужная модификация мала, то держите ее как можно меньше и как можно более локально. Все остальное подвергается большему риску поломки чего-либо, что не нуждается в ремонте.

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

Давным-давно произошло множество сбоев одного из дисков Digital. Они закончили тем, что вспомнили и заменили их всех, и Горд знает, сколько стоит. Видимо, внутри HDA был кусок клея, удерживающий фильтр. В инженерном манифесте сказано, что клей "Непараметрически указан, НЕТ ЗАМЕНЯЕМЫХ ДОСТУПНО". Счетчик бобов "экономится" под цент на диск, используя другой клей. Он испустил пар внутри HDA, который убил диск после нескольких лет эксплуатации. Это не сломалось, пока он не исправил это. Несомненно, "это было только крошечное изменение ..."

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

Это единый и очень простой подход.

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

Контроль риска…

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

Стоимость….

• Заставить код проходить проверку кода, пока вы пишете код, дешево
• Делать это в более позднем состоянии намного дороже

Выгода

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

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

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

Рекомендация….

• Если показано, что в разделе кода содержится много ошибок или требуется много изменений для добавления дополнительных функций, потратьте 100% времени на понимание того, что он делает.
• Также потратьте время на добавление хороших модульных тестов в этот раздел кода, так как они вам нужны.
• Затем вы можете рассмотреть возможность рефакторинга кода (теперь вы понимаете), чтобы он также прошел проверку нового кода.

Личный опыт…

• За другие 20 лет работы программистом я никогда не видел случая, чтобы слепое изменение старого для удаления всех выходных данных из новой программы проверки стандартов кодирования имело какие-либо преимущества, кроме увеличения дохода подрядчиков, которым было поручено это сделать.
• Точно так же, когда старый код должен быть сделан для прохождения проверки кода (TickIt / ISO 9001 сделан неправильно), который требовал, чтобы старый код выглядел как новый стандарт кодирования.
• Я видел много случаев, когда использование стандартных инструментов проверки кода для нового кода имело большие преимущества за счет сокращения текущих затрат.
• Я никогда не видел, чтобы компания отказывалась от затрат на поддержку старого кода, который используется в продукте с большим количеством клиентов.
• Я видел, как компания терпела неудачу из-за того, что не получала доход от клиентов из-за того, что слишком медленно выходила на рынок….

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

ИМХО, было бы неплохо уменьшить чувствительность инструмента. Зачем? Потому что это выделит самые сложные части кода. Альтернативой является создание отчетов с тысячами нарушений, которые становятся бесполезными из-за огромного размера.

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

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

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

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

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