레거시 코드베이스의 품질 표준을 낮추는 방법에 대해 논쟁하는 방법은 무엇입니까? [닫은]

28

우리는 상상할 수없는 나쁜 코드가있는 큰 레거시 코드베이스를 가지고 있습니다.

우리는 이제 몇 가지 품질 표준을 정의했으며 완전히 새로운 코드베이스에서 또는 기존 코드를 만지는 경우 그 표준을 충족 시키려고합니다.

그리고 우리는 이미 수천 건의 위반 사항이있는 Sonar (코드 분석 도구)를 가진 사람들을 시행합니다.

이제 토론은 레거시에 대한 위반을 낮추기 위해 제기되었습니다. 레거시이기 때문입니다.

토론은 가독성 규칙에 관한 것입니다. 얼마나 많은 중첩 된 if / for ..처럼 가질 수 있습니다.

이제 레거시 코드에서 코딩 품질을 낮추는 것에 대해 어떻게 논쟁 할 수 있습니까?

code-quality static-analysis legacy-code

— 게이 키
소스

2

도구의 임계 값을 낮추는 것에 대한 토론입니까? ... 또는 내가 잘못 이해 했습니까? 혼란스러운 방식으로 작성되었습니다.

— dagnelies 2012 년

13

$ {something}에서 $ {someone}까지 어떻게 설명합니까?

— gnat

4

이 질문에는 분명하지 않은 부분이 있습니다. "위반 위반"-실제 위반 횟수 (이전 코드를 다시 작성하여), Sonar에서 레거시 코드 기반으로 테스트 한 규칙 수 또는 따르고 싶은 코딩 표준 규칙 수를 줄이려고합니까? 레거시 코드에서 무언가를 변경할 때?

— Doc Brown

4

또한 우리는 끔찍한 코드 품질의 기존 제품을 보유하고 있습니다. 새로운 제품으로 대체되기 때문에 오래된 코드를 정리할 가치가 거의 없습니다. 즉, 기존 코드 기반에서 더 낮은 표준을 수용합니다.

— Bernhard Hiller

4

@ keiki : 여전히 불분명합니다 : 새로운 코드베이스가 이전 코드와 새로운 코드에 대해 다른 유효성 검사 규칙을 가질만큼 충분히 분리되어 있습니까? 레거시 코드베이스에서 변경하는 부분은 어떻습니까? 변경된 부품을 더 높은 표준으로 올리는 문제가 너무 많은 노력을 기울이거나 Sonar의 검증에서 해당 부품을 분리 할 수 없어 변경된 부품 만 전체적으로 검증 할 수 있습니까?

— Doc Brown

73

코드는 끝의 수단 일뿐입니다. 그 목적은 다양 할 수 있지만 일반적으로 이익입니다.

이익이라면; 판매 증가, 유지 보수 비용 절감, 개발 비용 절감, 임금 감소, 재교육 비용 감소 등 이익을 향상시킬 수 있다는 것을 보여주고 자합니다. 이익 향상; 화장실에서 돈을 씻는 재미있는 방법이 될 것입니다.

— 브렌던
소스

15

나는이 토론에서 전문성이라는 또 다른 차원이 있다고 생각합니다. 많은 직업에서, 상사가 모서리를 자르라고 요청하면 도덕적 근거에 따라 거부 할 수 있습니다 (때로는 법을 뒷받침합니다). 소프트웨어 개발자가 다르게 행동해야하는 이유를 이해합니다.

— Alessandro Teruzzi

21

@AlessandroTeruzzi 당신은 전문성에 관계없이 어느 곳에서나 (개인적인) 도덕적 근거에 대해 아무것도 거부 할 수 있습니다. 그래도 그 장소에서 계속 일할 것이라고 보장하지는 않습니다.

— Kromster는 Monica

또한 코드베이스는 종종 매우 복잡하기 때문에 노련한 개발자가 경험을 통해 코너를 자르면 장기적으로 비용이 많이 든다는 사실을 알고 있지만 언급 한 사항을 입증하기가 어렵습니다.

— mkataja

17

이 답변에는 잘못된 것이 없지만 그럼에도 불구하고 대부분의 실제 상황에는 유용하지 않습니다. 코드베이스의 품질을 향상 시키면 특히 장기적으로 유지 관리 비용이 절감되는 경우가 많지만 이러한 효과는 거의 정량화 할 수 없습니다. 따라서 종종 전략적인 결정입니다.

— Doc Brown

2

@DocBrown 나는 잠정적으로 동의하지만, 다수의 nested if-ifs-driven 개발, la OP는 레거시 코드베이스를 개선하는 효과적인 접근 방법이 아니라고 생각합니다.

— brian_o

44

저 자신과 저는 레거시 코드의 프로듀서이자 관리자였습니다. 도구가 "수천 건의 위반"(또는 그 문제에 대해 수백 건)을 생성하는 경우 도구를 잊어 버리면 상황에 해당되지 않습니다.

원래 개발자가 오랫동안 사라져서 토론 할 수 없다고 생각합니다. 따라서 디자인과 코딩 스타일의 이유와 위치를 이해하는 사람은 아무도 없습니다. 수백 또는 수천 건의 위반을 수정한다고해서 몇 줄의 코드를 여기저기서 다시 작성해야하는 것은 아닙니다. 대신, 리팩토링 / 재 기능 분해가 의심의 여지가 없습니다. 현재 디자인을 완전히 이해하지 않고 기존의 모든 큰 코드베이스에이를 시도하고 완전히 새로운 버그 / 문제 등을 도입해야합니다. 새로운 웜 캔은 현재 가지고있는 것보다 더 나빠질 수 있습니다 (또는 툴 >> thinks << 지금 가지고있는 것보다 나쁩니다).

"수천 개의 위반"을 해결하기위한 유일한 합리적인 접근 방식은 처음부터 다시 작성하는 것입니다. 길고 비용이 많이 들며 경영진에게 판매하는 것은 거의 불가능합니다. 이 경우에는 아마도 맞을 것입니다 ...

레거시 코드는 일반적으로 조정이 필요합니다. y2k 또는 주식이 256에서 10으로 갔을 때와 같습니다. 나는 그 cr * p 모두를했다. 그리고 다른 많은 유사한 것들. 일반적으로 때로는 나쁜 스타일, 잘못된 기능적 분해, 나쁜 등을 "읽고"수정해야하는 장소 모음을 찾을 수 있다는 점에서 꽤 "정확한"것입니다. 그리고, "그 장소들 사이에서"일어나는, 즉 더 높은 수준의 흐름은 당신에게 미스터리로 남아있을 수 있습니다. 변경하려는 현지화 된 기능을 이해 한 다음 부작용을 테스트, 테스트, 테스트하기 만하면 현지화 된 지식으로는 예측할 수 없습니다.

그런 코드를 통해 길을 찾을 수 없다면 레거시 코드를 유지하는 가장 좋은 사람이 아닐 수도 있습니다. 어떤 사람들은 빈 화면으로 시작하여 아름다운 프로그램을 작성할 수 있지만 다른 사람들의 코드로 구성된 큰 코드베이스로 시작하여 유지할 수는 없습니다. 다른 사람들은 코드를 유지할 수 있지만 처음부터 시작할 수는 없습니다. 일부는 둘 다 할 수 있습니다. 적합한 사람들이 레거시 코드를 유지하고 있는지 확인하십시오.

레거시 코드베이스를 처음부터 다시 디자인하고 다시 작성해야 할 때가 종종 비즈니스 (또는 기타) 요구 사항이 바지 자리 "비틀기"로 인해 변경된 요구 사항을 더 이상 수용 할 수없는 정도로 변경되는 경우입니다. . 그 시점에서 새로운 기능 요구 사항 문서를 먼저 작성하여 모든 이해 당사자가 참여할 수 있도록하는 것부터 시작할 수 있습니다. 기본적으로 완전히 새로운 볼 게임입니다.

유일무이 한 >> wrong <<해야 할 일은 레거시 코드 유지 보수를 새로운 개발과 같은 방식으로 처리하는 것입니다. 그리고 그 한 가지 잘못된 것은 당신이 가고 싶은 길인 것 같습니다 :) 당신이하고 싶은 것이 아닌 내 말을 들어보십시오.

— 존 포코 쉬
소스

2

"레거시를 다시 작성해야합니까?"라는 질문에 대답합니다. 그러나 OP는 경고를 수정하는 방법 또는 재 작성이 필요한지 묻지 않습니다. 문제는 품질 표준에 관한 것이 었습니다. 기본적으로 유효성 검사 경고 수를 늘리지 않기 위해 모든 변경에 대한 요구 사항입니다.

— 바실 레프

9

이것은 다시 작성 하는 것이 아니라 질문을 직접 해결합니다 . OP는 '새로운 개발과 동일한 방식으로 레거시 코드 유지 관리'를 주장하고 싶습니다. 이 답변은 "WOAH! 당신은 그렇게하지 말아야합니다!"라고 말합니다. OP가 답을 원하거나 듣고 싶지는 않지만 질문에 완전히 응답 할 수 있습니다.

— Jonathan Eunice

1

@Basilevs (및 @ JonathanEunice). 요나단의 말. 그리고 나는 "도구를 잊어 버려, 상황에 적용 할 수 없다"고 직접 말함으로써 시작했다. 그러나 비판을 받으려면 건설적인 비판을 제공하십시오. 그래서 나는 "그것을하지 마십시오"라고 말할 수 없었습니다. 나는 또한 대신 무엇을해야하는지 제안해야했다 (그리고 내가 글을 시작할 때 예상했던 것보다 조금 더 긴 시간이 걸렸다).

— John Forkosh

1

레거시 코드 프로젝트로 작업 할 때 때때로 이전 코드와 새 코드 사이에있는 인터페이스 레이어를 디자인하고 싶습니다. 이를 통해 기존 부품과 새 부품을 깔끔하게 구분할 수 있으며 이해하지 못하는 코드로 인해 새 부품이 어두워 진 경우보다 쉽게 문제를 해결할 수 있습니다.

— supercat

@supercat 만약 이것이 가능하다면, 그것은 좋은 접근 방법입니다. 그러나 다양한 y2k 개선 프로젝트를 회상하면 기존 코드의 중간에 들어가서 코드를 어지럽히기만하면됩니다. 이전 / 새로 가능 (>> 대량 << 재 작성없이)으로 팩토링 할 수 없습니다. 예를 들어, 4 바이트 ccyy 형식 연도의 날짜 필드에 2 바이트를 추가하지 않고 대규모 데이터베이스에 대한 도매 업데이트가 필요한 경우 yy> 50을 19yy로, yy <= 50을 20yy로 해석하면됩니다. 그러나 yy가 사용되는 모든 장소에서 작은 변화가 많이 발생합니다.

— John Forkosh

13

문제는 그 코드가 얼마나 좋은지 나쁜지가 아닙니다. 문제는 얼마나 많은 투자를 통해 얻을 수있는 혜택입니다.

따라서 마음에 들지 않는 수천 가지를 찾는 도구가 있습니다. 도구의 결과를 무시하거나 수천 가지 변경 작업에 투자 할 수 있습니다. 많은 것들입니다. 사람들은 변경 사항을 검토하는 동안이 아니라 검토하는 동안 집중되지 않으며, 모든 변경 사항을 테스트하는 방법 (또는 시험해 보는 방법)을 파악하는 데 오랜 시간이 걸리므로 제대로 테스트되지 않으므로 버그가 있습니다. 따라서 버그를 찾아서 고칠 때까지 전반적인 부정적인 결과로 많은 시간과 돈을 투자했습니다.

반면에 도구는 "좋아하지 않는"것이 아니라 버그 또는 잠재적 인 버그를 찾을 수 있습니다. 레거시 코드가 여전히 널리 사용되고 있다면 올바른 도구가 실제로 버그를 찾을 수 있습니다. 따라서 컴파일러 경고를 하나씩 켜고 유용한 지 (모두 유용한 것은 아닌지) 확인하고 해당 경고를 수정하는 것이 좋습니다.

— gnasher729
소스

2

나는 한 번 빨리 프로젝트를 시작했습니다 (컴파일러 경고 등 무시). 프로젝트는 엉망이었고 버그가있었습니다. 숫자가 넘쳤습니다. 팀은 2 주 동안 검색했습니다. 모든 경고 플래그가 설정된 컴파일러 환경을 설정했습니다 (카운트 수는 500에서 수천 경고로 증가했습니다). 나는 모든 경고를 겪었다. 3 시간 만에 경고가 0 개있었습니다. 어떤 이유로 코드가 작동했습니다. 그러나 우리는 이유를 몰랐습니다. 지점이 변경 될 때마다 코드를 커밋했습니다. 약간의 검색 후 나는 그것을 발견했다. 암시 적으로 선언 된 함수로 C가 반환 값을 깨뜨 렸습니다.

— CodeMonkey 2012 년

7

고장 나지 않았다면 고치지 마십시오

실제로 모든 소프트웨어 개발자와 관리자에게 문신을해야 잊어 버리지 않아야합니다.

예, 모든 최신 코딩 규칙을 위반합니다. 예, FORTRAN-77로 C로 래퍼를 사용하여 작성되었으므로 Python에서 호출 할 수 있습니다. 예, 이들은 구조화되지 않은 GOTO입니다. 그렇습니다. 3 천 라인 길이의 서브 루틴이 하나 있습니다. 예, 변수 이름은 Croat에만 의미가 있습니다. 등

그러나 10 년 이상 분노 테스트를 거쳤으며 통과 한 경우에는 그대로 두십시오! 필요한 수정이 작은 경우 가능한 작고 로컬로 유지하십시오. 다른 것이 있으면 고칠 필요가없는 것을 깨뜨릴 위험이 더 커집니다.

물론, 때로는 유지 관리가 불가능한 크루 지이며 "작은"수정을 수용하는 유일한 방법은 처음부터 다시 작성하는 것입니다. 어떤 경우에는 변경을 요청하는 사람에게 돌아가서 그 비용이 얼마인지 (재 작성을위한 달러 또는 인시, 피할 수없는 새로운 벌레에 대한 피의 땀과 눈물) 비용을 알려 주어야합니다.

오래 전에 Digital의 디스크 드라이브 중 하나에 오류가 발생했습니다. 그들은 결국 귀환하고 결국 대가를 치르면 어떤 비용이 드는지 알고 있습니다. 분명히 HDA 내부에 필터를 붙인 접착제 덩어리가있었습니다. 공학적 표현은 접착제에 대해 "비모수 적으로 지정되었으며, 수용 할 수 없음"이라고 말했다. 콩 카운터는 다른 접착제를 소싱하여 디스크 드라이브 당 1 센트 미만으로 "저장"되었습니다. HDA 내부에 증기가 방출되어 2 년 동안 서비스를받은 후 드라이브를 죽였습니다. 그가 고칠 때까지 파산되지 않았습니다. 의심 할 여지없이 "작은 변화 일뿐입니다 ..."

— nigel222
소스

2

Western Digital 을 의미 합니까? 이 되었습니까 리콜 ? 스토리를 백업 할 소스를 제공 할 수 있습니까?

— Monica와의 가벼운 경주

3

그는 확실히 Hewlett Packard의 흑심 속에 깊은 곳에서 살 수있는 희미한 희미한 디지털 장비 공사를 의미합니다.

— 존 하 스콜

1

예-디지털은 DEC라고도합니다.

— nigel222

5

레거시 코드의 품질 수준을 낮출 필요는 없습니다. 또한 경고를 즉시 수정할 필요가 없습니다. 프로젝트의 모든 구성 요소에서 모든 "새"변경 사항이 고품질 표준을 준수하는지 확인하십시오. 즉, 커밋은 경고 횟수를 늘려서는 안됩니다.

균일하고 죽은 간단한 접근 방식입니다.

기존 레거시 코드가 그대로 작동합니다 (필요하지 않은 수정이 없기 때문에). 새로운 코드의 고품질을 보장합니다. 추가 비용이 들지 않습니다.

— 바실 레프
소스

나는 단어로 이의를 제기 할 수 이제까지 당신의 첫 번째 단락의 끝에서. 예를 들어, 스타일이 경고를 발생시키는 수백 줄 함수의 중간에 수십 줄의 변경이 필요한 경우에도 기존 스타일에 결함이없는 한 기존 스타일을 계속 사용하려고합니다. 읽을 수없는 정도. 나는 함께 와서 물건을 뒤섞어 야하는 다음 가난한 사람을 위해 가능한 한 쉽게 삶을 만들고 싶습니다. 어떤 도구의 표준을 만족시키는 것 외에 다른 이유로 스타일을 혼합하는 것은 그 자체로 나쁜 스타일입니다. 대신, 가능한 한 원래의 표준 / 스타일을 따르십시오.

— John Forkosh

나는 선이나 기능이 아닌 커밋을 말했다. 아마도 문제가있는 장소에 대한 예산을 확보하기 위해 편집 할 때 엉망인 부분을 정리해야합니다.

— Basilevs

3

위험 관리….

대규모 레거시 코드베이스의 코드는 최소한 소프트웨어의 실제 사용에 의해 테스트되었습니다.
대규모 레거시 코드베이스의 코드에 자동화 된 단위 테스트가 적용되는 것은 매우 모호합니다.
따라서 큰 레거시 코드베이스에서 추위에 대한 변경은 위험이 높습니다.

비용….

코드를 작성하는 동안 코드가 코드 검사기를 통과하게 만드는 것이 저렴합니다
나중의 상태에서 그렇게하는 것은 훨씬 더 비싸다

이익

코딩 표준을 유지하면 더 나은 코드 디자인이 이루어질 수 있기를 바랍니다.
그러나 코딩 표준 검사 도구에서 경고를 제거하기 위해 코드를 변경하는 데 많은 시간을 소비하는 사람이 코드 디자인을 개선 할 가능성은 거의 없습니다.
복잡한 코드를 이해하지 못하는 사람이 간단한 방법으로 나누지 않는 한 간단한 코드는 더 명확하고 이해하기 쉬운 경향이 있습니다 .

추천….

코드 섹션에 많은 버그가있는 것으로 보이거나 추가 기능을 추가하기 위해 많은 변경이 필요한 경우 코드의 기능을 100 % 이해합니다.
또한 코드의 필요성이 입증되었으므로 해당 코드 섹션에 적절한 단위 테스트를 추가하는 데 시간을 보내십시오.
그런 다음 코드 리팩토링 (이제 이해)을 고려하여 새 코드 검사도 통과했습니다.

개인적인 경험….

프로그래머로 일한 다른 20 년 동안, 나는 새로운 코딩 표준 검사기에서 모든 출력을 제거하기 위해 맹목적으로 오래된 것을 변경하여 지시받은 계약자의 수입을 늘리는 것 외에는 어떤 이점도 얻지 못한 사례를 본 적이 없습니다.
마찬가지로 이전 코드를 새 코드 표준처럼 보이기 위해 이전 코드를 작성해야하는 코드 검토 (TickIt / ISO 9001이 잘못됨)를 통과해야하는 경우도 마찬가지입니다.
새 코드에서 코딩 표준 검사 도구를 사용하면 지속적인 비용을 줄임으로써 큰 이점을 얻는 경우가 많습니다.
회사가 많은 고객이있는 제품에 사용되는 오래된 코드를 유지 관리하는 비용에 실패한 것을 본 적이 없습니다.
나는 시장에 너무 느려서 고객으로부터 수입을 얻지 못해 회사가 실패하는 것을 보았습니다….

— 이안
소스

0

도구의 임계 값을 낮추는 것에 대한 논의입니까? ... 또는 내가 잘못 이해 했습니까? 혼란스러운 방식으로 작성되었습니다. 그렇지 않은 경우 내 답변을 삭제하십시오.

IMHO 도구의 감수성을 줄이는 것이 좋습니다. 왜? 가장 털이 많은 코드를 강조하기 때문입니다. 대안은 수천 건의 위반으로 보고서를 작성하는 것입니다.

... 그 외에는 관련 사람들과 그것에 대해 이야기하고 그 이유도 들으십시오.

— 자그마한
소스

0

레거시 코드를 새로운 깨끗한 코드와 분리하려고합니다. 예를 들어 Eclipse에서는 서로를 사용하는 다른 프로젝트에 배치 하여이 작업을 수행 할 수 있습니다. 'clean'-project 및 'legacy'-project .

이 방법으로 서로 다른 품질 표준을 가진 소나의 두 프로젝트를 분석 할 수 있습니다. 표준은 규칙의 중요성 만 달라야합니다. 규칙 자체는 동일해야합니다. 당신은에서 볼 수있는이 방법은 'legacy' 프로젝트 수정해야 무슨 일이'의 기준에 부합하는 clean' 프로젝트 '를 .

레거시 코드를 더 높은 표준으로 끌어 올릴 때마다 '깨끗한'프로젝트로 옮길 수 있습니다.

매일 작업 시간이 오래 걸리기 때문에 '깨끗한'프로젝트 표준에 도달하는 모든 수업을 들어 올리는 것은 불가능합니다. 그러나 레거시 코드를 만질 때마다 조금씩 개선하여 작은 단계를 거쳐야합니다.

— MrSmith42
소스