기술 부채 소개
기술 부채 완료하는 데 더 오래 걸리기 때문에 더 나은 사례를 사용하는 대신 오늘 쉬운 솔루션을 선택하여 발생하는 향후 비용을 설명하는 용어입니다.
용어 기술 부채는 금융 부채에 대한 비교를 위해 선택되었습니다. 금융 부채에 있는 사람들은 그 당시에 적절하거나 유일한 옵션으로 보이는 결정을 내리는 것이 일반적이지만, 그렇게 하면 이자도 증가합니다.
이자가 많이 누적될수록 그들은 미래에 더 어려움을 겪게 되고, 선택할 수 있는 옵션이 줄어들게 됩니다. 금융 부채로 곧 이자가 증가하여 눈덩이 효과를 줍니다. 마찬가지로, 기술 부채는 개발자가 가치를 추가하는 대신 계획되거나 계획되지 않은 문제를 정리하고 재작업하는 데 거의 모든 시간을 소비하는 시점까지 쌓일 수 있습니다.
그렇다면 어떻게 될까요?
가장 일반적인 변명은 촉박한 기한입니다. 개발자가 코드를 신속하게 만들어야 하는 경우 종종 바로 가기를 사용합니다. 예를 들어 새 기능을 포함하도록 메서드를 리팩터링하는 대신 복사하여 새 버전을 만들 수 있습니다. 그런 다음 새 코드만 테스트하면, 코드의 다른 부분에서 원래 메서드를 사용하기 때문에 원래 메서드를 변경하는 경우 필요한 테스트 수준을 피할 수 있습니다.
이제 나중에 수정해야 하는 동일한 코드의 복사본이 두 개 있고 논리가 분기될 위험이 있습니다. 많은 원인이 있습니다. 예를 들어 개발자들 사이에서 기술 기술과 완성도가 부족하거나 명확한 제품 소유권이나 방향이 없을 수 있습니다.
조직에 코딩 표준이 전혀 없을 수 있습니다. 따라서 개발자는 무엇을 생산해야 하는지 조차 알지 못했습니다. 개발자는 대상에 대한 정확한 요구 사항이 없을 수 있습니다. 글쎄, 그들은 막판 요구 사항 변경의 대상이 될 수 있습니다.
필요한 리팩터링 작업이 지연될 수 있습니다. 수동 또는 자동화된 코드 품질 테스트가 없을 수 있습니다. 결국, 합리적인 시간 프레임과 합리적인 비용으로 고객에게 가치를 제공하기가 더 어렵고 어려워집니다.
기술 부채는 프로젝트가 최종 기한을 충족하지 못하는 주된 이유 중 하나입니다.
시간이 지남에 따라 통화 부채와 거의 같은 방식으로 증가합니다. 기술 부채의 일반적인 원인은 다음과 같습니다.
- 코딩 스타일 및 표준이 부족합니다.
- 단위 테스트 사례의 설계가 부족하거나 부실합니다.
- 개체 지향 디자인 원칙을 무시하거나 이해하지 않습니다.
- 모놀리식 클래스 및 코드 라이브러리.
- 기술, 아키텍처 및 접근 방식의 사용을 제대로 상상하지 못했습니다. (유지 관리, 사용자 경험, 확장성 등 모든 시스템 속성을 고려해야 함을 잊지 말아야 합니다.)
- 오버 엔지니어링 코드(필수가 아닌 코드 추가 또는 만들기, 기존 라이브러리가 충분한 경우 사용자 지정 코드 추가 또는 필요하지 않은 계층 또는 구성 요소 만들기).
- 주석 및 설명서가 부족합니다.
- 자체 문서화 코드(설명이 있거나 의도를 나타내는 클래스, 메서드 및 변수 이름 포함)를 작성하지 않습니다.
- 기한을 맞추기 위해 지름길을 택합니다.
- 불필요한 코드를 그대로 둡니다.
메모
시간이 지남에 따라 기술 부채를 갚아야 합니다. 그렇지 않으면 문제를 해결하고 새로운 기능 및 향상된 기능을 구현하는 팀의 기능은 더 오래 걸리고 결국에는 비용이 많이 듭니다.
우리는 기술적인 부채가 개발 중에 일련의 문제를 추가하고 추가 고객 가치를 추가하는 것을 훨씬 더 어렵게 만드는 것을 보았습니다.
프로젝트에 기술적인 문제가 있으면 생산성이 저하되고, 개발 팀이 좌절하고, 코드를 이해하기 어렵고 취약하며, 변경하고 이러한 변경 내용의 유효성을 검사하는 시간이 늘어나게 됩니다. 계획되지 않은 작업은 종종 계획된 작업에 방해가 됩니다.
장기적으로, 그것은 또한 조직의 힘을 약화시킵니다. 기술적인 부채는 조직에서 커지는 경향이 있습니다. 그것은 작게 시작하고 시간이 지남에 따라 성장한다. 빠른 해킹이 이루어지거나 변경 사항을 서두르야하기 때문에 테스트가 우회 될 때마다 문제가 악화되고 악화됩니다. 지원 비용은 더 높아지고, 변함없이 심각한 문제가 발생합니다.
결국 조직은 적시에 비용 효율적인 방식으로 고객의 요구에 응답할 수 없습니다.
모니터링을 위한 자동화된 측정
기술 부채의 지속적인 취득을 최소화하는 한 가지 주요 방법은 자동화된 테스트 및 평가를 사용하는 것입니다.
다음 데모에서는 부채를 평가하는 데 사용되는 일반적인 도구 중 하나인 SonarCloud를 살펴보겠습니다. (원래 온-프레미스 버전은 SonarQube였습니다).
사용할 수 있는 다른 도구가 있으며, 그 중 몇 가지에 대해 설명하겠습니다.
나중에 실습 랩에서 SonarCloud를 사용하도록 Azure Pipelines를 구성하고, 분석 결과를 이해하고, 마지막으로 프로젝트를 분석할 때 SonarCloud에서 사용하는 규칙 집합을 제어하도록 품질 프로필을 구성하는 방법을 알아보세요.
자세한 내용은 SonarCloud참조하세요.
검토하기 위해:
Azure DevOps는 빌드 중에 코드 품질을 확인하는 데 사용되는 광범위한 기존 도구와 통합할 수 있습니다.
현재 사용 중인 코드 품질 도구(있는 경우)는 무엇입니까?
도구에 대해 무엇을 좋아하거나 좋아하지 않습니까?