새로운 언어 구조를 사용하도록 이전 코드를 업데이트해야합니까, 아니면 오래된 구조를 고수해야합니까?

프로그래밍 언어로 기능이 향상되기 전에 오래 전에 작성된 일부 기능적 코드를 개선하고 싶습니다. 이론적으로 전체 프로젝트는 최신 버전의 언어를 사용합니다. 그러나이 특정 모듈 (및 실제로 다른 많은 모듈)은 여전히 ​​오래된 방언으로 작성되었습니다.

내가해야합니까:

• 코드의 일부를 건드릴 필요는 없지만 패치를 작성하기는 쉽지만 모듈의 다른 곳에서는 유사한 상황에서 사용되지 않는 새로운 언어 기능을 사용하여 패치를 작성합니까? (이것은 내가 직관적으로 선택한 솔루션입니다.)
• 몇 년이 지났다는 사실을 무시하고 패치를 작성하는 동안 나머지 코드에서 사용되는 스타일을 반영하여 마치 몇 년 전에 동일한 작업을 수행하는 것처럼 효과적으로 동작합니까? (이 솔루션은 직관적으로 바보처럼 생각하지만“좋은 코드”에 대해 말하는 모든 사람들이 모든 비용으로 일관성을 유지하는 데 따르는 혼란을 겪을 경우 아마도 이것이 내가해야 할 일입니다.)
• 새로운 언어 구조와 규칙을 사용하도록 전체 모듈을 업데이트 하시겠습니까? (이것은 아마도 최상의 솔루션이지만 다른 작업에 더 잘 쓸 수있는 많은 시간과 에너지가 필요할 수 있습니다.)

상황에 따라 너무 많이 의존하기 때문에이 질문에 대한 명확한 대답을하는 것은 불가능합니다.

코드베이스 스타일의 일관성은 코드를 이해하기 쉽게 만드는 데 도움이되므로 유지 관리의 가장 중요한 측면 중 하나입니다.
다른 스타일을 혼합하여 코드를 이해하기 어렵게 만드는 저주를받은 최초의 프로그래머는 아닙니다. 몇 년 안에 저주를하는 것은 당신 자신 일 수도 있습니다.

반면에 코드를 처음 작성할 때 존재하지 않았던 새로운 언어 구문을 사용한다고해서 유지 관리 성이 떨어지거나 코드 스타일이 깨지는 것은 아닙니다. 모든 것은 사용하려는 특정 언어 기능과 팀이 이전 스타일의 코드와 새로운 기능에 얼마나 친숙한 지에 달려 있습니다.

예를 들어, OO 스타일의 코드베이스에 map / reduce와 같은 기능적 프로그래밍 개념을 도입하는 것은 일반적으로 바람직하지 않지만 람다 함수를 사용하지 않는 프로그램에 여기 저기 람다 함수를 추가하는 것이 좋습니다 전에 그런 것.

코드와 코드의 모양은 크게 관련 이 없습니다 . 코드 가 하는 일은 중요합니다.

코드를 변경 / 다시 작성해도 코드의 기능이 변경되지 않는다고 보장 할 수 있다면 마음의 내용에 맞게 코드를 리팩토링 할 수 있습니다. 이 "보증인"은 변경 전후에 실행할 수있는 철저한 단위 테스트 세트로, 눈에 띄는 차이가 없습니다.

안정성을 보장 할 수없는 경우 (테스트를받지 않은 경우) 그대로 두십시오.

"더 나은"소프트웨어를 만들려고하더라도 비즈니스 크리티컬 소프트웨어를 "깨뜨려"준 사람은 아무도 없습니다. "작업"은 매번 "더 나은"것보다 우선합니다.

물론 그러한 운동을 위해 준비된 테스트 세트를 만드는 것을 막을 수는 없습니다 ...

비용과 이점 측면에서 거의 모든 것을 분석 할 수 있으며, 이것이 여기에 적용된다고 생각합니다.

첫 번째 옵션의 명백한 이점은 단기적으로 작업을 최소화하고 작업 코드를 다시 작성하여 무언가를 깨뜨릴 가능성을 최소화한다는 것입니다. 명백한 비용은 코드베이스에 불일치가 발생한다는 것입니다. 작업 X를 수행 할 때 코드의 일부에서 한 가지 방법으로 수행되고 코드의 다른 부분에서 다른 방식으로 수행됩니다.

두 번째 접근 방식에서는 일관성이라는 명백한 이점을 이미 언급했습니다. 명백한 비용은 몇 년 전에 포기했을 수도있는 방식으로 일하기 위해 마음을 구부려 야하며 코드를 읽을 수없는 상태로 유지하는 것입니다.

세 번째 접근 방식의 경우 명백한 비용은 단순히 더 많은 작업을 수행해야합니다. 덜 명백한 비용은 당신이 일하고 있던 것들을 깨뜨릴 수 있다는 것입니다. 오래된 코드가 제대로 작동하는지 확인하기 위해 테스트가 부적절한 경우가 종종 있습니다. 명백한 이점은 (성공적으로 가정 할 때) 멋지고 반짝이는 새 코드가 있다는 것입니다. 새로운 언어 구조를 사용할 때 코드베이스를 리팩토링 할 수있는 기회가 있습니다. 코드 기반을 리팩토링 할 수 있습니다. 언어를 작성할 때의 언어를 그대로 사용하더라도 언어 자체를 개선 할 수 있습니다. 일이 쉬워졌고, 큰 승리일지도 모른다.

다른 주요 요점 : 현재이 모듈은 프로젝트 전체를 유지 관리하고 있더라도 오랫동안 유지 보수가 최소한 인 것으로 보입니다. 그것은 꽤 잘 작성되어 있고 비교적 버그가 없다는 것을 나타내는 경향이 있습니다. 그렇지 않으면 중간에 더 많은 유지 관리를 받았을 것입니다.

그것은 또 다른 질문으로 이어집니다 : 지금 당신이 만들고있는 변화의 근원은 무엇입니까? 전반적으로 여전히 요구 사항을 충족하는 작은 버그를 모듈에서 수정하는 경우 전체 모듈을 리팩토링하는 데 시간과 노력이 크게 낭비 될 가능성이 있음을 나타냅니다. 다시 말하지만, "현대적인"기대를 충족시키지 않는 코드를 유지하면서 현재와 거의 같은 위치에있을 수 있습니다.

그러나 요구 사항이 변경되었을 수도 있으며 이러한 새로운 요구 사항을 충족시키기 위해 코드를 작성하고 있습니다. 이 경우 첫 번째 시도가 실제로 현재 요구 사항을 충족하지 못할 가능성이 높습니다. 또한 요구 사항이 다시 안정화되기 전에 몇 차례 수정 될 가능성이 상당히 높습니다. 즉, (상대적으로) 단기적으로이 모듈에서 중요한 작업을 수행 할 가능성이 훨씬 높으며, 알고있는 한 영역 만이 아니라 나머지 모듈 전체에서 변경을 수행 할 가능성이 훨씬 높습니다. 지금. 이 경우 전체 모듈을 리팩토링하면 추가 작업을 정당화 할 수있는 실질적인 단기적 이점이있을 가능성이 훨씬 높습니다.

요구 사항이 변경된 경우 어떤 종류의 변경이 포함되어 있는지, 그리고 그 변경을 유발 한 사항도 살펴 봐야합니다. 예를 들어, SHA-1을 SHA-256으로 대체하기 위해 Git을 수정했다고 가정 해 봅시다. 이는 요구 사항의 변경이지만 범위가 명확하게 정의되어 있고 매우 좁습니다. SHA-256을 올바르게 저장하고 사용하면 나머지 코드베이스에 영향을 미치는 다른 변경이 발생하지 않을 것입니다.

다른 한편으로, 작고 별개로 시작하더라도 사용자 인터페이스 변경은 풍선 화되는 경향이 있으므로 "이 화면에 하나의 새 확인란 추가"로 시작한 항목은 "고정 UI 변경 "사용자 정의 템플릿, 사용자 정의 필드, 사용자 정의 색 구성표 등을 지원합니다."

전자의 경우 변경을 최소화하고 일관성 측면에서 오류를 범하는 것이 가장 합리적입니다. 후자의 경우 완전한 리팩토링이 훨씬 유리합니다.

나는 당신에게 첫 번째 옵션을 갈 것입니다. 코드를 작성하면 규칙을 따라 더 나은 상태를 유지합니다.

따라서 새로운 코드는 모범 사례를 따르지만 현재 진행중인 문제와 관련이없는 코드는 다루지 않습니다. 이 작업을 잘 수행하면 새 코드가 이전 코드보다 더 읽기 쉽고 유지 관리 가능해야합니다. 이를 유지하면 작업을 위해 터치해야하는 코드가 점점 더 "더 나은"코드이기 때문에 총 유지 보수성이 향상되는 것으로 나타났습니다. 더 빠른 문제 해결로 이어집니다.

답은 다른 많은 것들과 마찬가지로 의존적이라는 것 입니다. 예를 들어 콜백 지옥을 피하는 등 장기 유지 관리 기능을 크게 개선하는 등 오래된 구성 요소를 업데이트하는 데 큰 이점이있는 경우. 큰 이점이 없다면 일관성은 친구 일 것입니다.

또한 두 개의 별도 함수 내에서 피하려는 것보다 동일한 함수에 두 개의 스타일을 포함하지 않는 것이 좋습니다.

요약 : 최종 결정은 특정 사례의 '비용'/ '혜택'분석을 기반으로해야합니다.