[What is Refactoring] Technical Debt

이 페이지는 GURU 사이트 [what-is-refactoring] Technical Debt의 번역을 담고 있습니다.

Technical debt

Technical Debt

모든 사람들은 처음부터 훌륭한 코드를 쓰기위해 최선을 다합니다. 아마 프로젝트를 망치기 위해 의도적으로 더러운 코드를 짜는 프로그래머는 없을 것 입니다.

그렇다면 어떤 시점에서 코드가 더러워지는 걸까요?

더러운 코드에 대한 기술 부채는 워드 커닝험에 의해 제안되었습니다.

은행에서 융자를 받으면 더 빠르게 물건을 구입할 수 있습니다. 구매 과정을 빠르게 하기 위해 추가 비용을 지불하죠.

당신은 원금을 갚을 뿐만 아니라, 추가 비용에 대한 이자도 지불합니다. 더 말할 필요도 없이, 이는 이자의 양이 수입을 초과하여 완전히 상환하는 것을 불가능하게 만들 수도 있습니다.

기술 부채의 원인

1. 업무적 압박

• 때때로 업무의 순환은 완전히 기능을 끝내기 전에 일을 끝마칠 것을 강요합니다. 이런 경우 패치와 클러치가 코드에 나타나 프로젝트의 완료되지 않은 부분을 숨깁니다.

2. 기술 부채 결과에 대한 이해의 부족

• 때때로 고용주는 기술 부채가 축적됨에 따라 발전 속도를 늦추는 "이자"가 있다는 것을 이해하지 못할 수 있습니다.
• 이는 경영진이 리팩토링의 가치를 이해하지 못했기 때문에, 팀의 시간을 리팩토링에 할애하기 어렵게 만들 수 있습니다.

3. 구성 요소의 엄격한 일관성에 대처하지 못함

• 각 모듈의 산물이라기보다 모놀리스와 닮은 프로젝트이다. 이 경우엔, 프로젝트의 한 변경사항이 다른 부분에 영향을 끼칩니다.
• 각 개인의 업무 분리가 어려워져 팀의 발전이 더 어려워집니다.

4. 테스트의 부재

• 즉각적인 피드백이 부족하면, 신속하고 위험한 해결 방법이나 난관이 발생할 수 있습니다.
• 최악의 경우, 이런 변경 사항이 구현되자마자 테스트없이 프로덕션으로 배포됩니다. 이 결과는 매우 치명적일 수 있습니다.
• 예를 들어, 결점이 없는 핫픽스는 수천의 고객에게 이상한 테스트 전자메일을 보내거나 전체 데이터베이스를 플러시하는 손상을 시킬 수 있습니다.

5. 문서의 부재

• 이는 만약 주요한 사람이 프로젝트를 그만두게 되었을 때, 새로운 사람이 프로젝트에 들어오는 것을 늦추고 개발을 주저하게 만들 수 있습니다.

6. 팀원들간의 상호 교류의 부재

• 만약 지식이 회사 전체에 배포되지 않는다면, 사람들은 그 프로젝트에 대한 프로세스와 정보가 뒤떨어진 상태로 일을 해야 합니다.
• 이런 상황은 후배 개발자들이 그들의 멘토들에 의해 잘못 훈련될 때, 악화될 수 있습니다.

7. 몇개의 브랜치들의 장기간 지속되는 개발

• 이는 기술 부채가 누적될 수 있으며, 이후 변경 사항이 병합될 때 부채가 더 증가하게 됩니다.
• 고립된 상황에서 변화가 많을 수록 기술 부채는 더 커지게 됩니다.

8. 리팩토링의 지연

• 프로젝트의 요구사항은 끊임없이 변화하고 있으며, 어떤 시점에서는 코드의 일부가 쓸모없고 번거로워지며 새 요구사항을 충족하기 위해 재설계되어야 함이 명백해집니다.
• 반면, 이 프로젝트의 프로그래머들은 쓸모없는 부품들과 함께 작동되는 새로운 코드들을 매일 쓰고 있습니다.
• 따라서, 리팩토링이 지연될 수록 향후 더 많은 종속 코드를 재작업해야합니다.

9. Compliance 모니터링의 부재

• 프로젝트를 작업하는 모든 사용자가 적합한 코드(이전에 작성한 방식과 동일한 코드)를 작성할 때 발생합니다.

10. 무능함

• 개발자가 적절한 코드를 구현할 줄 모를 때 발생합니다.