기술적 부채를 평가, 관리 및 회피하는 방법

기술 부채가 금융 핸드북에서 빼낸 것처럼 들린다면 금융과 관련된 용어이기 때문입니다. 그러나 실질적인 의미에서 기술 부채는 프로그래밍과 관련이 있습니다. 소프트웨어 프로젝트를 개발하는 동안 특정 필수 단계를 건너뛰거나 기한을 맞추기 위해 아예 포기한다는 생각입니다.

완벽한 앱이나 소프트웨어를 개발하기 위해 개발자는 종종 임의의 작업을 수행하는 임의의 사람과 마찬가지로 시간에 쫓기는 경우가 많습니다. 따라서 일반적으로 완벽한 코드로 완벽한 제품을 제공하는 것과 시간을 최대화하는 것 사이에 일종의 절충안이 필요합니다.

그렇다면 문제는 이러한 절충안에 한계가 있습니까? 이 절충안으로 인해 발생할 수 있는 고유한 피해가 있습니까? 마지막으로, 개발자는 장기적으로 정말 더 나은가? 기술 부채에 관한 이 글에서 나는 이 모든 질문에 답하려고 노력할 것입니다.

기술 부채란 무엇입니까?

기술 부채를 정의할 때 먼저 이 용어를 생성한 것으로 알려진 사람인 Ward Cunningham을 언급해야 합니다. Cunningham에 따르면 기술 부채는 짧은 기간 내에 코드를 프로그래밍함으로써 발생하는 적자를 메우기 위해 코드를 프로그래밍하는 데 필요한 추가 개발 작업을 말합니다.

더 생생하게 표현하기 위해 지저분한 방을 청소해야 하고 수업에 늦는다고 상상해 보십시오. 지시를 수행하고 수업에 제시간에 도착할 수 있도록 소파 아래에 있는 대부분의 잔해를 빠르게 청소합니다. 이것의 결과는 결국 혼란을 정리하는 데 시간을 들여야 한다는 것입니다. 소프트웨어 개발의 경우 필요한 단계를 건너뛰고 '별로 깨끗하지 않은' 코드로 더 쉬운 경로를 따를 때 나중에 코드를 정리하기가 더 어려워집니다. 소프트웨어 프로젝트 도미노에는 여러 단계가 있으며 기존 문제를 오래 무시할수록 해결하는 데 더 오래 걸립니다.

기술 부채의 유형

기술 부채는 다음과 같은 다양한 유형이 있습니다.

계획된 기술 부채

이는 조직이 의도적으로 기술 부채를 지기로 결정한 상황에서 발생합니다. 이것은 앞서 논의한 바와 같이 일반적으로 명시된 마감일을 초과하고 특정 목표에 도달하기 위한 것입니다. 계획된 기술 부채에 관여할 때 조직은 포기할 수 있는 것과 포기할 수 없는 것을 명확히 해야 합니다. 정확한 기록을 유지해야 하며, 결국에는 처음에 건너뛰었던 오류를 반환하고 수정해야 한다는 점을 염두에 두어야 합니다.

의도하지 않은 기술적 부채

이러한 유형의 기술 부채는 첫 번째 부채와 정반대입니다. 조직이 기술적 부채를 예측하거나 계획하지 않을 때 발생합니다. 그 이유는 일반적으로 조직의 다양한 부서 간 의사 소통의 단절 또는 부서 간의 형편없는 작업 관행 때문입니다.

피할 수 없는 기술적 부채

이것은 조직의 어떤 조치도 막을 수 없는 일종의 기술적 부채입니다. 예를 들어 기술의 급격한 변화로 인해 과거에 작성된 일부 코드가 현재 예상되는 표준에 미치지 못하는 것이 당연합니다.

또한 이러한 종류의 기술적 부채는 코드가 이미 작성 중일 때 변경이 요청될 때 발생할 수 있습니다. 소프트웨어를 설계하는 도중에 특정 변경 사항이 도입되면 역학이 엉망이 되어 이전 코드를 쓸모없게 만들거나 불필요하게 만들 수 있습니다.

기술 부채의 원인

위에서 기술 부채에 대한 몇 가지 이유를 논의했지만, 나는 그것들을 더 명확하게 하기 위해 그것들을 차례로 선택하겠습니다.

서두름

기술 부채의 가장 흔한 원인은 서두름입니다. 개발자에게는 종종 엄격한 기한이 있으며 그 중 일부에는 특정 소프트웨어 출시 기한이 포함됩니다. 이러한 상황에서 개발자가 기술적인 부채를 지게 되는 것은 종종 이해할 수 있고 예상되는 일입니다. 이러한 유형의 기술 부채는 종종 의도적이며 코드에 버그가 있거나 스파게티 코드가 발생하는 문제를 일으킬 수 있습니다.

간과/실수

때때로 프로그래머는 잘못된 코드를 작성하여 결국 기술적인 부채로 이어집니다. 코더의 실수로 인해 나쁜 코드가 존재하는지 여부에 관계없이 실수는 기술적인 부채를 초래하고 확장성이 없기 때문에 결국 수정해야 하는 것이 사실입니다.

효과에 대한 인식 부족

때때로 기술 부채는 코더가 장기적으로 기술 부채가 얼마나 해로운지를 깨닫거나 인정하지 못하기 때문에 발생합니다. 이것은 프로그래밍 중에 지름길을 선택하는 해로운 영향에 대한 정당한 무지에서 비롯되거나 그 결과를 고의적으로 무시하는 것일 수 있습니다.

의도

기술 부채는 코더 또는 조직의 고의적인 행동으로 인해 의도적으로 발생할 수 있습니다.

모듈화 부족

이것은 주로 하나의 코드가 동시에 다른 비즈니스 로직을 제공할 수 있기 때문에 발생합니다. 이러한 상황은 소프트웨어를 훨씬 더 어렵게 만듭니다. 개발자가 코드를 작성할 때마다 모듈화 문제를 경험할 가능성이 커집니다.

기술부채 평가

기술 부채는 매우 힘들기 때문에 수동으로 계산해서는 안 됩니다. 이는 현재 문제와 가능한 미래 문제를 확인하기 위해 코드를 수동으로 입력해야 함을 의미합니다. 수동 프로세스가 얼마나 시간을 낭비하는지와는 별개로, 수동 프로세스가 끝나면 코드의 형태가 변경되었을 가능성이 있습니다.

평가를 수행하는 한 가지 방법은 이를 지원하는 일부 도구를 사용하여 정적 분석을 수행하는 것입니다. 사용할 수 있는 도구로는 Coverity, SonarQube, Check Style, Closure Compiler 등이 있습니다.

일반적으로 기술 부채를 계산하는 두 가지 방법이 있습니다. 첫 번째 접근 방식에서는 코드 비율에 따라 기술 부채 비율을 계산하여 얻을 수 있습니다. 여기서 초기 추정치 또는 앱 개발에 필요한 전체 시간은 기술적 부채를 해결하는 데 필요한 시간을 결정하는 데 사용됩니다.

두 번째 접근 방식에서는 SonarQube와 같은 다양한 도구에서 제공하는 추정치를 직접 사용할 수 있습니다. 이것은 기술 부채 목록 및 참조 코드와 결합됩니다. 도구에서 문제를 해결하는 데 필요한 시간을 정확하게 추정할 수 있습니다.

기술 부채를 평가하면 기술 부채를 해결하는 데 며칠이 걸릴지 알 수 있습니다. 부채가 많을수록 해결하는 데 더 오래 걸립니다.

기술적 부채 해결

기술 부채가 발생하여 어떻게 해야 할지 난감하다면 어떻게 하시겠습니까? 기술적 부채를 관리하기 위해 취할 수 있는 특정 단계가 있습니다.

첫째, 기술적 부채가 있음을 인정하고 이를 팀에 전달해야 합니다. 의사소통에서 무슨 일이 일어났는지, 그리고 그것을 바로잡기 위해 무엇을 해야 하는지 분명히 해야 합니다. 가능한 한 빨리 기술 부채를 처리해야 할 필요성을 명확하게 전달해야 합니다.

팀에 기술적 부채를 알린 후 취할 수 있는 세 가지 접근 방식이 있습니다. 첫 번째 접근 방식에서는 시스템을 그대로 유지하기로 결정할 수 있습니다. 이 시나리오에서는 응용 프로그램을 있는 그대로 사용합니다.

또는 애플리케이션을 리팩토링하도록 결정할 수 있습니다. 리팩토링은 앱의 복잡성을 줄이고 앱의 구조를 정리하기 위해 수행됩니다. 리팩토링을 통해 소프트웨어의 동작은 변경되지 않습니다. 영향을 받는 유일한 부분은 내부 구조입니다.

마지막으로 위에서 설명한 두 가지 옵션이 작동하지 않으면 코드를 완전히 교체해야 합니다. 이것의 한 가지 문제는 새로운 기술적 부채로 이어질 수 있지만 장기적으로 더 나은 절충안이 될 수 있다는 것입니다.

미래의 기술적 부채 피하기

물론 기술적 부채가 발생했을 때 해결하려고 하는 것보다 기술 부채를 피하는 것이 훨씬 더 현명한 일입니다. 시간과 스트레스를 모두 절약할 수 있다는 사실 외에도 처음부터 기술적인 부채로 인한 잔여 결과가 없는지 확인합니다.

기술적 부채 자체는 나쁘지 않다고 주장할 수 있습니다. 그들은 갚아야 할 빚이고 인간은 지구상에서 가장 책임 있는 종이 아니기 때문에 일반적으로 문제가 됩니다. 지속적으로 약한 옵션을 선택하면 일반적으로 소프트웨어의 강도가 약해지고 나중에 기능을 개선하기가 더 어려워집니다. 결국, 기술적 부채를 피하는 것이 누구에게나 최선의 방법입니다.

그렇다면 기술 부채가 발생하는 것을 방지하는 방법은 다음과 같습니다.

프로젝트 백로그 생성

여기에서 아이디어는 모든 사람이 프로세스를 최신 상태로 유지하고 수행 중인 작업에 대한 요구 사항에 신속하게 대처하도록 하는 것입니다. 백로그를 생성하면 모든 사람이 완료되지 않은 작업과 이를 달성하기 위한 경로를 볼 수 있습니다.

속도보다 품질 우선

자신이 프로그래머라면 많은 작업보다 양질의 작업을 우선시하는 법을 배워야 합니다. 코드가 깨끗하고 앱 또는 기타 소프트웨어가 완벽하게 개발되었는지 확인하십시오. 지름길을 택하려는 유혹은 가치가 없다는 것을 이해하십시오. 왜냐하면 결국에는 포기한 작업을 계속 수행해야 하기 때문입니다.

팀을 이끌고 있다면 이와 같은 가치를 팀원들에게 전달해야 합니다. 회원들은 결과 지향적인 솔루션을 만들고 지름길을 피하도록 가르쳐야 합니다.

인지도 창출

일반적으로 기술 부채가 무엇인지와 이를 피하는 방법에 대한 심층적인 지식은 처음부터 기술 부채가 발생하지 않도록 하는 데 유용할 수 있습니다. 필요한 지식으로 개발자를 무장시키면 기술 부채가 낳는 함정을 더 잘 피할 수 있습니다.

좋은 코딩 방법 소개

일부 코딩 관행은 기술 부채에 빠질 가능성이 더 높습니다. 따라서 긴밀한 결합을 피하고 추상화 및 리팩토링을 사용하는 것이 좋습니다.

업데이트된 기술 소개

정기적인 기술 업데이트는 기술 부채를 예방하는 훌륭한 수단이 될 수 있습니다. 업데이트할 때 사용 중인 것이 최신 프레임워크, 데이터베이스 및 응용 프로그램 소프트웨어인지 확인해야 합니다.

결론

대부분의 경우 기술 부채는 계속해서 프로그램을 개발하고 코드를 작성하는 한 피할 수 없습니다. 그러나 위에 나열된 단계를 따르면 발생 가능성을 크게 줄일 수 있습니다. 또한 기술 부채가 발생할 경우 모든 희망을 잃지 않습니다. 침착하고 자신감을 갖고 그에 따라 행동하십시오.