Исправлены ошибки в библиотечном коде или их случайно?

Question

Предположим я есть функция в библиотеке кода с ошибкой в ​​этом я нашел ошибку в библиотеке кодов:

class Physics 
{ 
    public static Float CalculateDistance(float initialDistance, float initialSpeed, float acceleration, float time) 
    { 
     //d = d0 + v0t + 1/2*at^2 
     return initialDistance + (initialSpeed*time)+ (acceleration*Power(time, 2)); 
    } 
} 

Примечание: пример, и язык, являются гипотетический

Я не могу гарантировать, что этот код не сломает.

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

если я создать 2-ую функцию:

class Physics 
{ 
    public static Float CalculateDistance2(float initialDistance, float initialSpeed, float acceleration, float time) { ... } 

    //Deprecated - do not use. Use CalculateDistance2 
    public static Float CalculateDistance(float initialDistance, float initialSpeed, float acceleration, float time) { ... } 
} 

В языке без возможности формально обесценить код, я просто доверяю всем, чтобы перейти на CalculateDistance2?

Это также Sucky, потому что теперь идеально имени функции (CalculateDistance) навсегда потеряли в устаревшую функцию, которая не нуждается, наверное, никто и не хотите использовать.

Должен ли я исправить ошибки или оставить их?

Смотрите также

• How to work in untestable legacy code- in bug fixing
• Should we fix that bug?
• Should this bug be fixed?
• Working Effectively With Legacy Code

Answer 1

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

Я был немного ума ...

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

Answer 2

Как aready описано, это компромисс между удовлетворением два различных группами пользователей:

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

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

Я думаю, вы должны спросить себя

«функция делает ли какой-либо смысл с существующей в настоящее время ошибка?»

Если это так, то оставьте это в библиотеке. В противном случае я, вероятно, выброшу его.

Answer 3

Хороший вопрос. Я с нетерпением жду некоторых других ответов. Вот мои 2 цента по вопросу:

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

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

(Если ваш класс происходит с СОМ-компонент, общепринятая бы создать новый интерфейс ICalculateDistance2, что делает исходный интерфейс устаревшим, но сохраняет его для обратной совместимости.)

Answer 4

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

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

Answer 5

Просто ради аргумента предположим, что ваш гипотетический язык был C++ (хотя он выглядит намного больше, чем Java). В этом случае, я хотел бы использовать пространство имен, чтобы создать вилку, которая была (разумно) легко иметь дело с точки зрения как новых, так и унаследованного кода:

namespace legacy { 
class physics { 
    Float CalculateDistance(float initialDistance, float initialSpeed, float acceleration, float time) 
    { 
    // original code here 
    } 
} 
} 

namespace current { 
class physics { 
    Float CalculateDistance(float initialDistance, float initialSpeed, float acceleration, float time) 
    { 
    // corrected code here 
    } 
} 

Оттуда у вас есть несколько вариантов для выбора между два. Например, существующий код может добавить директиву using: using legacy::physics;, и они будут продолжать использовать существующий код без каких-либо дополнительных изменений. Новый код мог бы добавить using current::physics; вместо этого, чтобы получить текущий код. Когда вы это сделаете, вы (возможно) отрицаете класс legacy::physics и планируете его для удаления через определенный период времени, количество ревизий или что-то еще. Это дает вашим клиентам возможность проверить свой код и переключиться на новый код упорядоченным способом, сохраняя при этом пространство имен legacy слишком загрязненным старым нежелательным файлом.

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

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

Answer 6

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

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

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

Итак, я бы честно сказал, чтобы исправить это.