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

28

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

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

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

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

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

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

Keiki
источник
2
такое обсуждение о снижении порогов инструмента? ... или я неправильно понял. Это написано в замешательстве.
dagnelies
4
Вопрос имеет несколько очень неясных частей. «уменьшить эти нарушения» - хотите ли вы уменьшить фактическое количество нарушений (переписав старый код), количество правил, проверенных Sonar, к устаревшей кодовой базе или количество правил вашего стандарта кодирования, которому вы хотите следовать при изменении чего-либо в устаревшем коде?
Док Браун
4
Также у нас есть устаревший продукт ужасного качества кода. Поскольку он будет заменен новым продуктом, очистка старого кода практически не имеет смысла. Это означает: мы принимаем более низкий стандарт в устаревшей кодовой базе.
Бернхард Хиллер
4
@keiki: все еще неясно: достаточно ли новой кодовой базы, чтобы иметь разные правила проверки для старого и нового кода? Как насчет частей, которые вы изменяете в устаревшей кодовой базе? Является ли ваша проблема в том, что приведение измененных частей к более высокому стандарту требует слишком больших усилий, или вы не можете разделить эти части при проверке Sonar, чтобы можно было полностью проверить только эти измененные детали?
Док Браун

Ответы:

73

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

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

Brendan
источник
15
Я полагаю, что в этой дискуссии есть еще одно измерение - профессионализм, во многих профессиях, если ваш начальник попросит вас срезать углы, вы можете отказаться делать это на основании моральных соображений (иногда даже закон поддерживает вас), я не понять, почему разработчики программного обеспечения должны вести себя по-другому.
Алессандро
21
@AlessandroTeruzzi Вы можете отказаться делать что-либо по (личным) моральным причинам в любом месте, независимо от профессионализма. Не гарантирует, что вы будете продолжать работать в этом месте, хотя.
Кромстер говорит, что поддерживает Монику
Кроме того, поскольку кодовые базы часто бывают чрезвычайно сложными, трудно доказать что-либо из упомянутого, даже если опытный разработчик может на собственном опыте знать, что в конечном итоге срезание углов будет дорогостоящим.
mkataja
17
В этом ответе нет ничего плохого, но, тем не менее, это, ИМХО, не полезно для большинства реальных ситуаций. Повышение качества кодовой базы часто приводит к снижению затрат на обслуживание, особенно в долгосрочной перспективе, но эти эффекты редко поддаются количественной оценке. Поэтому это часто стратегическое решение.
Док Браун
2
@DocBrown Я предварительно согласен, но я думаю, что разработка, основанная на количестве вложенных элементов, а не OP, не является эффективным подходом к улучшению устаревшей кодовой базы.
brian_o
44

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

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

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

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

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

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

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

Джон Форкош
источник
2
Это отвечает на вопрос «Должно ли наследие быть переписано». Но OP не спрашивает, как исправить предупреждения или произойдет ли перезапись. Вопрос был о стандарте качества - в основном требование для каждого изменения не увеличивать количество предупреждений проверки.
Базилевс
9
Это напрямую касается вопроса, который не о переписывании. ОП хочет отстаивать «отношение к обслуживанию устаревшего кода так же, как если бы вы занимались новыми разработками». Этот ответ гласит: "Вах! Ты не должен этого делать!" Может быть, не ответ ОП или вы хотели бы услышать, но полностью ответить на вопрос.
Джонатан Юнис
1
@Basilevs (и @ JonathanEunice). Что сказал Джонатан И обратите внимание, что я начал с того, что прямо сказал: «забудь инструмент, он неприменим к ситуации», что напрямую решает вопрос, хотя и отрицательно. Но, как говорится, если вы собираетесь критиковать, предложите конструктивную критику. Поэтому я не мог просто сказать: «Не делай этого». Я также должен был предложить, что делать вместо этого (и это стало немного более скучным, чем я ожидал, когда начал писать).
Джон Форкош
1
При работе с устаревшими проектами кода мне иногда нравится создавать интерфейсный слой, который находится между старым и новым кодом. Это обеспечивает четкое разделение между старой и новой частями и облегчает поиск и устранение неисправностей новых частей, чем если бы они были забиты кучей кода, который я не понимаю.
суперкат
@supercat Если это можно сделать, это, безусловно, хороший подход. Но, вспоминая различные мои проекты по исправлению ситуации в 2000 году, вам просто нужно было «погрузиться» в середину существующего кода и возиться с ним. Невозможный (пере) факторинг на старый / новый возможен (без >> массивного << переписывания). Например, вместо того, чтобы добавлять два байта к полям даты для четырехбайтового года в формате ccyy, требующего оптовых обновлений для массивных баз данных, просто интерпретируйте yy> 50 как 19yy, а yy <= 50 как 20yy. Но единственная разумная реализация для этого включает в себя множество небольших изменений в каждом месте, где используется yy.
Джон Форкош
13

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

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

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

gnasher729
источник
2
Однажды я пришел к проекту, который был сделан быстро (игнорируются предупреждения компилятора и т. Д.). В проекте был бардак, была ошибка. Номер был переполнен. Команда искала 2 недели. Я установил среду компилятора со всеми включенными флагами предупреждений (счетчик увеличился с 500 до нескольких тысяч предупреждений). Я прошел все предупреждения. Через 3 часа я получил 0 предупреждений. По какой-то причине код работал. Но мы не знали почему. Я фиксировал код при каждом изменении в моей ветке. После небольшого поиска я нашел это. Неявно объявленная функция, которая заставляет C искажать возвращаемое значение.
CodeMonkey
7

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

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

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

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

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

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

nigel222
источник
2
Вы имеете в виду Western Digital ? Это был этот отзыв ? Можете ли вы предоставить источники, подтверждающие вашу историю?
Легкость гонок с Моникой
3
Уверен, он имеет в виду Digital Equipment Corp, слабый проблеск которого, возможно, все еще живет глубоко в черном сердце Hewlett Packard.
Джон Хэсколл
1
Да - Digital также известен как DEC.
nigel222
5

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

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

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

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

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

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

Стоимость….

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

Выгода

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

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

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

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

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

Личный опыт…

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

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

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

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

dagnelies
источник
0

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

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

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

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

MrSmith42
источник