임시 해결 방법으로 메소드 이름에 버그 번호를 포함시키는 것이 좋지 않은 것으로 간주됩니까?

수석 사람 인 동료가 코드 검토에서 나를 차단하고 있습니다. 왜냐하면 그는 일부 결함 ###에 대한 해결 방법이기 때문에 'PerformSqlClient216147Workaround'메서드의 이름을 지정하기를 원하기 때문입니다. 이제 메서드 이름 제안은 메서드가 실제로 수행하는 작업을 설명하는 PerformRightExpressionCast와 같은 것입니다. 그의 주장은 "이 방법은이 경우에 대한 해결 방법으로 만 사용되며 다른 곳에서는 사용되지 않습니다."

임시 해결 방법으로 메소드 이름에 버그 번호를 포함시키는 것이 나쁜 습관으로 간주됩니까?

동료가 제안한대로 방법의 이름을 지정하지는 않습니다. 메소드 이름은 메소드의 기능을 표시해야합니다. 같은 이름은 PerformSqlClient216147Workaround그것이 무엇을 나타내지 않습니다. 문제가 있으면 방법을 설명하는 설명을 사용하여 해당 방법이 해결 방법이라고 언급하십시오. 이것은 다음과 같습니다.

/**
 * Cast given right-hand SQL expression.
 *
 * Note: This is a workaround for an SQL client defect (#216147).
 */
public void CastRightExpression(SqlExpression rightExpression)
{
    ...
}

나는 MainMa 에 버그 / 결함 번호가 소스 코드 자체에는 표시되지 않아야하고 메타 데이터이기 때문에 소스 제어 주석에 표시되어야하지만 소스 코드 주석에 나타나는 경우에는 끔찍하지 않다는 데 동의합니다 . 메소드 이름에 버그 / 결함 번호를 사용해서는 안됩니다.

작동하는 임시 수정보다 더 영구적 인 것은 없습니다.

그의 제안은 10 년 후에 잘 보입니까? 이전에는 수정 된 결함으로 각 변경 사항을 설명하는 것이 일반적이었습니다. 보다 최근에는 (지난 30 년간)이 스타일 주석은 코드 유지 관리 성을 감소시키는 것으로 널리 받아 들여지고 있습니다. 이는 메서드 이름이 아닌 주석에 불과합니다.

그가 제안한 것은 QC 및 QA 시스템이 상당히 부족하다는 강력한 증거입니다. 결함 및 결함 수정 추적은 소스 코드가 아닌 결함 추적 시스템에 속합니다. 소스 코드 변경 사항 추적은 소스 제어 시스템에 속합니다. 이러한 시스템 간의 상호 참조는 결함을 소스 코드로 추적 할 수있게합니다 .....

소스 코드는 어제가 아니라 내일이 아닌 오늘을 위해 존재합니다 (내년에 무엇을 할 계획인지 소스에 입력하지 않음) ...

임시 해결책입니까? 그런 다음 검토자가 제안한 이름을 사용하지만 메서드를 사용하지 않는 것으로 표시하면 코드를 컴파일 할 때마다 경고 메시지가 생성됩니다.

그렇지 않은 경우 216147코드가 버그 추적 시스템 (소스 제어에 연결된 버그 추적 시스템)에 연결되어 있지 않으므로 항상 코드에서 의미가 없다고 말할 수 있습니다 . 소스 코드는 버그 티켓과 버전을 참조하기에 좋은 장소가 아니며, 실제로 참조를 넣어야하는 경우 주석에 작성하십시오.

의견에서도 버그 번호만으로는 가치가 없습니다. 다음과 같은 의견을 상상해보십시오.

public IEnumerable<Report> FindReportsByDateOnly(DateTime date)
{
    // The following method replaces FindReportByDate, because of the bug 8247 in the
    // reporting system.
    var dateOnly = new DateTime(date.Year, date.Month, date.Day);
    return this.FindReportByDate(dateOnly);
}

private IEnumerable<Report> FindReportsByDate(DateTime date)
{
    Contract.Requires(date.Hour == 0);
    Contract.Requires(date.Minute == 0);
    Contract.Requires(date.Second == 0);

    // TODO: Do the actual work.
}

코드가 10 년 전에 작성되었고 방금 프로젝트에 참여했으며 버그 8247에 대한 정보를 어디서 찾을 수 있는지 물었을 때 동료들은 웹 사이트에 버그 목록이 있다고 말했다고 상상해보십시오. 보고 시스템 소프트웨어이지만 웹 사이트는 5 년 전에 다시 작성되었으며 새로운 버그 목록은 서로 다릅니다.

결론 :이 버그가 무엇인지 전혀 모릅니다.

동일한 코드가 약간 다른 방식으로 작성되었을 수 있습니다.

public IEnumerable<Report> FindReportsByDateOnly(DateTime date)
{
    // The reporting system we actually use is buggy when it comes to searching for a report
    // when the DateTime contains not only a date, but also a time.
    // For example, if looking for reports from `new DateTime(2011, 6, 9)` (June 9th, 2011)
    // gives three reports, searching for reports from `new DateTime(2011, 6, 9, 8, 32, 0)`
    // (June 9th, 2011, 8:32 AM) would always return an empty set (instead of isolating the
    // date part, or at least be kind and throw an exception).
    // See also: http://example.com/support/reporting-software/bug/8247
    var dateOnly = new DateTime(date.Year, date.Month, date.Day);
    return this.FindReportsByDate(dateOnly);
}

private IEnumerable<Report> FindReportsByDate(DateTime date)
{
    Contract.Requires(date.Hour == 0);
    Contract.Requires(date.Minute == 0);
    Contract.Requires(date.Second == 0);

    // TODO: Do the actual work.
}

이제 문제를 명확하게 볼 수 있습니다. 주석이 끝날 때 하이퍼 텍스트 링크가 5 년 전에 죽었다고하더라도, FindReportsByDate왜로 대체 되었는지 이해할 수 있기 때문에 중요하지 않습니다 FindReportsByDateOnly.

나는 PerformSqlClient216147Workaround더 많은 정보를 찾습니다 PerformRightExpressionCast. 기능 이름, 기능, 기능 또는 추가 정보를 얻는 방법에 대해서는 의심 할 여지가 없습니다. 소스 코드에서 쉽게 검색 할 수있는 명시적인 함수입니다.

문제를 고유하게 식별하는 버그 추적 시스템을 사용하면 시스템에서 해당 버그를 풀 때 필요한 모든 세부 정보를 제공합니다. 이것은 소스 코드에서 수행하는 매우 현명한 일이며 변경이 발생한 이유를 이해하려고 할 때 향후 개발자 시간을 절약 할 수 있습니다.

소스 코드에 이러한 함수 이름이 많이 있으면 문제는 명명 규칙이 아닙니다. 문제는 버그가있는 소프트웨어입니다.

동료의 제안에는 가치가 있습니다. 티켓 번호 아래 버그 데이터베이스에 기록 된 이유와 코드 변경 사항을 변경 한 이유를 연관시켜 추적 성을 제공합니다.

그러나 함수가 존재하는 유일한 이유는 버그를 해결하는 것입니다. 문제가 문제가 아니라면 소프트웨어가 그 일을하지 않기를 바랍니다. 아마도 당신 은 소프트웨어가 그 일을하기를 원할 것입니다. 그래서 함수의 이름은 그것이 무엇을하는지 그리고 문제 도메인 이 그것을 요구하는 이유를 설명해야합니다 ; 버그 데이터베이스에 왜 필요한지 솔루션은 반창고가 아닌 응용 프로그램의 일부처럼 보여야합니다.

나는 당신과 그가이 모든 것을 비례 적으로 얻었을 것이라고 생각합니다.

귀하의 기술적 주장에 동의하지만 하루가 끝날 때 특히 며칠 / 몇 주 / 몇 달 안에 코드베이스에서 제거 할 수있는 임시 수정 인 경우 큰 차이는 없습니다.

자존심을 상자에 다시 넣고 자기 길을 가지라고 생각합니다. (그도 듣고 있다면, 당신은 타협해야한다고 말하고 싶습니다. 두 자아는 모두 상자에 들어갔습니다.)

어느 쪽이든, 당신과 그는 더 나은 일을해야합니다.

임시 해결 방법으로 메소드 이름에 버그 번호를 포함시키는 것이 나쁜 습관으로 간주됩니까?

예.

이상적으로, 클래스는 응용 프로그램 흐름 / 상태의 개념에 가장 적합하게 매핑 / 구현되어야합니다. 이 클래스의 API 이름은 클래스의 상태에 대한 작업을 반영하여 클라이언트 코드가 해당 클래스를 쉽게 사용할 수 있도록해야합니다 (즉, 특별히 읽지 않으면 문자 그대로 아무 의미도없는 이름을 지정하지 마십시오).

해당 클래스의 공개 API의 일부가 기본적으로 "문서 / 위치 X에 설명 된 작업 Y 수행"이라고 말하면 API를 이해하는 다른 사람들의 능력은 다음에 달려 있습니다.

1. 외부 문서에서 무엇을 찾아야하는지

2. 외부 문서를 어디에서 찾아야하는지

3. 그들은 시간과 노력을 들여 실제로보고 있습니다.

그런 다음, 메소드 이름은 "결함 X"가이 결함에 대한 위치를 언급하지도 않습니다.

코드에 액세스 할 수 있고 결함 추적 시스템에 액세스 할 수 있으며 안정적인 코드가있는 한 추적 시스템이 계속 유지된다고 가정합니다 (현실적인 이유는 없습니다).

최소한 동일한 위치에서 결함에 항상 액세스 할 수 있고 지난 15 년 동안 동일한 URL에 있었던 Microsoft 결함 번호와 같이 변경되지 않는 경우에는 해당 링크를 제공해야합니다. API 문서에 문제가 있습니다.

그럼에도 불구하고 한 클래스의 API 이상에 영향을 미치는 다른 결함에 대한 해결 방법이있을 수 있습니다. 그러면 어떻게 하시겠습니까?

여러 클래스에서 결함 번호가 동일한 API를 사용하면 data = controller.get227726FormattedData(); view.set227726FormattedData(data);실제로 많은 것을 알려주지 않고 코드를 더 모호하게 만듭니다.

data = controller.getEscapedAndFormattedData(); view.setEscapedAndFormattedData(data);216147 결함 ( "최소한 놀람"의 설계 원칙을 위반하는 경우)을 제외하고 또는 다른 방식으로하려는 경우를 제외하고 는 조작을 설명하는 이름 ( ) 을 사용하여 다른 모든 결함을 해결하기로 결정할 수 있습니다. 코드의 "WTF / LOC"측정을 증가시킵니다).

TL; DR : 나쁜 연습! 당신의 방으로 가십시오!

프로그래머의 주요 목표는 작업 코드와 표현의 명확성이어야합니다.

해결 방법 이름 지정 (.... 해결 방법). 이 목표를 달성하는 것 같습니다. 일부 단계에서는 근본적인 문제가 해결되고 해결 방법이 제거되기를 바랍니다.

나에게 버그 후 메소드의 이름을 지정하면 버그가 해결되지 않았거나 근본 원인이 식별되지 않았 음을 나타냅니다. 다시 말해, 아직 알려지지 않은 상태임을 암시합니다. 타사 시스템에서 버그를 해결하는 경우 원인을 알고 있기 때문에 해결 방법이 해결책입니다. 문제를 해결할 수 없거나 해결할 수 없습니다.

SqlClient와 상호 작용할 때 올바른 식 캐스트를 수행해야하는 경우 코드에서 "performRightExpressionCast ()"를 읽어야합니다. 이유를 설명하기 위해 항상 코드에 주석을 달 수 있습니다.

지난 4 년 반 동안 소프트웨어를 유지 관리했습니다. 뛰어들 때 코드를 이해하기 어렵게 만드는 것 중 하나는 히스토리로만 작성된 코드입니다. 다시 말해, 그것이 오늘날 쓰여졌다면 그것이 작동하지 않을 것입니다. 나는 품질을 말하는 것이 아니라 관점을 말하는 것입니다.

내 동료가 한 번은 "결함을 고칠 때 코드를 예전처럼 만들었습니다."라고 말했습니다. 내가 해석하는 방법은 "이 버그가 존재하지 않는 경우 코드를 모양으로 변경하는 것"입니다.

결과 :

1. 일반적으로 결과적으로 코드가 줄어 듭니다.
2. 간단한 코드
3. 소스 코드의 버그에 대한 참조가 적음
4. 향후 회귀 위험 감소 (코드 변경이 완전히 확인되면)
5. 개발자가 더 이상 관련이없는 학습 기록에 부담을주지 않아도되므로 분석하기가 더 쉽습니다.

소스 코드는 현재 상태에 어떻게 도달했는지 알려줄 필요가 없습니다. 버전 관리를 통해 이력을 알 수 있습니다. 단순히 작동하는 데 필요한 상태에 있도록 소스 코드가 필요합니다. 즉, 가끔 "// bug 12345"라는 의견은 나쁜 생각은 아니지만 악용 될 수 있습니다.

따라서 메서드 이름을 'PerformSqlClient216147Workaround'로 지정할지 여부를 결정할 때 다음과 같은 질문을 해보십시오.

1. 코드를 작성하기 전에 버그 216147에 대해 알고 있었다면 어떻게 처리했을까요?
2. 해결 방법은 무엇입니까? 이 코드를 본 적이없는 사람이 그것을 본다면, 그것을 따라갈 수 있을까요? 이 코드의 작동 방식을 알기 위해 버그 추적 시스템을 점검해야합니까?
3. 이 코드는 얼마나 일시적입니까? 내 경험에 따르면 @mattnz가 나타내는 것처럼 임시 솔루션은 일반적으로 영구적입니다.