기존의 나쁜 관행이나 오래된 코드와 잘 맞지 않는 좋은 관행을 사용하는 것이 더 낫습니까?

기존의 타사 소프트웨어에 대한 확장을 작성하려고했기 때문에이 문제를 생각했으며 데이터베이스가 비정규 화되었습니다. 기존 테이블을 사용하고 새로운 필드를 추가해야했습니다.

디자인 스타일로 새 테이블을 만들거나 (대부분의 큰 속성이 하나의 큰 테이블로 구성됨) 새 테이블 집합을 모두 만들고 트리거와 같은 추가 기능을 사용하여 새 테이블과 오래된 테이블.

나는 기존의 좋지 않은 디자인 스타일을 사용하는 첫 번째 옵션으로 끝났지만이 질문을 남겼습니다. 기존의 나쁜 관행을 사용하거나 기존 코드와 잘 어울리지 않는 좋은 관행을 구현하는 것이 더 낫습니까? 다른 것을 선택해야하는 상황이 있습니까?

참고 : 지금까지 많은 대답은 나쁜 코드를 천천히 리팩토링하는 것과 관련이 있지만 그렇게 할 수는 없습니다. 코드는 우리 코드가 아니며 공급 업체가 자주 업데이트합니다. 나는 단지 그것에 구축 할 수 있습니다.

다음과 같은 경우 더 나은 디자인을 선택해야합니다.

1. 미래의 코딩에서 많은 부분을 차지하게 될 것입니다

2. 더 나은 디자인은 장기적으로 고객에게 더 비싸지 않습니다. 예를 들어, 나는 연말까지 중단 된 프로젝트에 대해 여러 달의 "리팩토링"을 목격했습니다.

다음과 같은 경우 "같은 나쁜 스타일"을 선택해야합니다.

1. 당신은 단지 돕고 있습니다. 기존 그룹에 참여할 수 있다고 생각하는 것은 비현실적이며 프로젝트를 파트 타임으로 작성하는 경우 더 높은 설계 표준을 적용 할 것입니다. 더 나은 디자인은 주관적이며 거의 항상 학습 곡선이 있습니다. 새로운 팀이 다른 팀에 의해 새로운 디자인을 배우지 못하면 프로젝트는 스타일의 엉망으로 끝날 것입니다. 더 나은 디자인의 코드는 이해할 수 없기 때문에 아무도 변경하지 않는 것들로 끝날 수 있습니다. 그것. 위의 예에서 타사 소프트웨어에 대한 업데이트가 있으면 어떻게됩니까?

2. "더 나은"디자인을 희생하면 실질적인 비즈니스 이점을 얻을 수 있습니다. 기능 X를 잘못 추가하는 것처럼 큰 계약을 맺을 수 있지만 마감일을 놓치면 아무것도 끝나지 않습니다. 이것은 mgmt와 기술 팀 사이의 역사적인 갈등이 시작되는 곳입니다. 집을 리모델링하는 것처럼 누군가는 언제 지불해야하는지 결정해야합니다. 전기 나 배관없이 1 년 동안 살면서 처음에 빚을 갚을 수 있습니다. 또는 이러한 유틸리티를 사용하면 3 배나 많은 비용을 지불 할 수 있습니다.

장기적으로는 좋은 방법을 사용하는 것이 좋습니다. 변경 사항을 구현하는 데 시간이 덜 걸리므로 시간과 노력이 절약됩니다.

가능한 경우 모범 사례로 리팩토링하기 위해 약간의 단계를 수행하십시오 (예 : 일반화 테이블을 정규화 테이블로 변경하고 이전 테이블 이름을 가진 뷰를 사용하는 SQL의 경우).

장기적으로 말하면 "품질, 시간, 돈"삼각형이 여기에도 적용됩니다 (즉, 2 개 선택). 시간이 없다면 이전 관행을 따라야 할 수도 있지만 이는 문제를 추가하고 설계도 수정해야 함을 의미합니다.

계속해서 나쁜 디자인의 코드를 추가하고 추가하면 좋은 디자인을 사용하는 코드베이스로 끝나지 않을 것입니다. 가능한 한 좋은 디자인을 사용하고 좋은 디자인으로 리팩터링하십시오.

글쎄, 나는 그것이 각각의 경우에 달려 있다고 생각합니다. 성능과 디자인이 허용하는 경우 모범 사례를 사용하는 것이 좋습니다. 그러나 예를 들어 해당 테이블이 높은 액세스 테이블 인 경우 sincronization에 대한 트리거를 작성하면 성능에 부정적인 영향을 줄 수 있습니다.

이제 고객은 더 나은 디자인을 사용했다는 것을 알지 못하고 솔루션이 시스템을 느리게 만들었다는 것을 알게 될 것입니다. 이러한 유형의 결정은 사례별로 이루어져야하며, 경험과 기준을 사용하여 결정해야합니다.

아마 당신이 올바른 선택을했다고 생각합니다.

가능한 한 응용 프로그램 코드와 열악한 데이터 디자인을 분리해야합니다.

테이블을 업데이트하고 있습니까? 그렇지 않은 경우 SQL보기를 작성하여 애플리케이션에 편리한 방식으로 해당 테이블을 표시하십시오. SQL 뷰는 작성하기 쉽고 응용 프로그램 코드보다 테스트하기가 훨씬 쉽습니다.

레거시 테이블을 업데이트해야하는 경우 업데이트를 관리하기 위해 저장 프로 시저를 작성하는 것이 좋습니다. 쓰기가 조금 더 복잡하지만 즉시 테스트 할 수 있습니다.

트리거를 사용하여 데이터베이스를 정규화 할 때 이전 코드를 동기화 상태로 유지하려면 일시적인 경우 좋은 솔루션입니다. 목표는 이전 코드를 변경하는 것이지만 타사를 다룰 때는 효과가 없을 수 있습니다. 스키마 변경 사항을 최신 상태로 유지해야합니다.

잘못된 코드에서 점점 더 많은 기능을 사용하면 지속적인 문제가 발생합니다. 해결 방법이 표준이되었습니다. 변경 사항이 너무 오래 걸리고 다른 버그 나 제한 사항이 생길 수 있으므로 사용자는 실망 할 것입니다. 우리가 그렇게하지 말아야하는 대신에 그렇게 할 수 없다고 말하는 프로그래머가되고 싶은 사람은 누구입니까?

일부 코드는 단독으로 남겨 둘 수 있습니다. 우리는 항상 그런 사치가 없습니다.

당신은 여기서 기술 부채를 다루고 있습니다. 요컨대 기술 부채는이자를 의미하며 시간이 지남에 따라 지불해야하며 어느 시점에서는 환불해야합니다.

Develloper의 시간은 비용이 들기 때문에 기술 부채는 실제 부채처럼 보이며 실제 비용도들 수 있습니다.

기본적으로 두 가지 주요 솔루션과 그 사이에 많은 솔루션이 있습니다. 당신은 지금 그 부채를 환불하지 않기로 결정하고 계속이자를 지불 할 수 있습니다. 분명히 이것은 장기적으로 더 많은 비용이 들지만 지금 당장 결과를 얻을 수 있습니다. 해당 부채를 환불하도록 선택할 수도 있으므로, 환불하지 않는 한 더 이상 이월하지는 않지만 결국에는이자가 없습니다.

일반적으로 배송 기한이 있으며 마감 기한을 놓치면 고객에 대한 불신이 발생하여 결국 고객을 잃게됩니다. 이것은 기술 부채를 파기해야 할 정당한 이유 일 수 있습니다. 고객에게 기술 부채를 추가로 지불 할 가치가 있다고 생각합니다.

결국, 새로운 방법론을 채택해야하며, 그렇지 않으면 점점 더 많은 부채를 얻게되고 결국 파산하게됩니다 (지금은 사람들이 처음부터 다시 시작하기로 결정하거나 프로젝트가 잘못 실패 할 때).

기존 코드베이스를 변경하고 시간이 지남에 따라 새로운 관행으로 전환하는 방법을 계획하고 매일 변경 사항을 비트 단위로 배포해야합니다. 어떤 시점에서 리팩토링이 다른 손실로 이어질 때 어떤 손실이 더 나쁜지 고려하고 가장 좋은 손실을 고려하십시오.

리팩토링하지 않는 비용은 시간이 지남에 따라 증가합니다 (이것은 기술 부채의 이익입니다). 따라서 이것은 결국 가장 비용이 많이 드는 선택이 될 것입니다.

상사가 기술 부채의 개념을 이해하도록하십시오. 예방 조치를 취하더라도 기술 부채가 발생합니다. 어떤 시점에서, 그것을 환불하는 데 사용되는 돈. 고의로 기술 부채를 만들 때는 그에 대한 정당한 이유가 있어야하며 부채를 실제 부채처럼 투자로 간주해야합니다. 다른 경우에는 의도적으로 기술 부채를 수행하지 마십시오.

DB를 진화시키고 그 진화를 전개하는 방법론에 관심이있을 수 있습니다 : http://richarddingwall.name/2011/02/09/the-road-to-automated-database-deployment

그건 그렇고, 그것은 어려운 작업이므로 행운을 빕니다. 그럴 가치가있다 !

이것은 "나중에 내 작업의 이점을 활용해야합니까?"라는 전형적인 문제입니다. 그리고 그 대답에 대한 일반적인 해결책이 있다고 생각하지 않습니다. 그러한 결정에 관련된 모든 요소 (기술적 및 인간적) 만 알 수 있습니다.

그러나 문제가 흥미로운 질문을 제기합니다.

자동 코드 리팩토링이 코드의 균일 성을 높이기 위해 충분히 발전하고 있습니까?

궁극적으로 잘못된 디자인은 변경되거나 죽어야합니다. 그렇지 않으면 나쁜 디자인이 아닙니다. 여기서 중요한 질문은 리팩토링 비용에 관한 것입니다. 귀하 (또는 귀하의 고용주)가 현재 가격을 기꺼이 지불하지 않으며 현재 기술 상태에서 원치 않을 것임을 귀하의 질문에서 분명히 보입니다.

그러나 코드 리팩토링 자동화는 약간의 발전을 이루었습니다. 오늘날 컴파일러가 바이너리를 최적화 할 수 있다면 누가 내일 코드를 최적화하지 않겠는가? 언젠가는 개발자와 디자이너가 새로운 요구 사항에 적응하기 위해 코드를 매우 쉽게 리팩터링 할 수있는 일부 도구가 등장 할 것입니다. 결국, 레거시 코드를 다루는 것은 오늘날 가장 큰 과제 중 하나입니다.

그러한 도구가 존재한다면 (이미 놀랍지 않을 것입니다), 그러한 결정을 할 때 그것을 고려하는 것이 좋습니다.

좋은 습관은 항상 가난한 것보다 우선합니다. 코드베이스에 잘못된 방식으로 코드가 흩어져 있다면 같은 방식으로 자신의 물건을화물 컬트하지 말고 코드를 올바르게 작성하고 다른 모든 사람들에게 올바른 방법으로 교육하도록 노력하십시오.