프로그래밍의 나쁜 카르마. 기술 부채란 무엇이며 해결 방법

기술 부채. 자신의 전문 분야에서 적극적으로 일하는 대부분의 프로그래머는 이 용어를 다루어야 합니다. 많은 사람들에게 그 언급은 두통을 유발할 수도 있고, 프로젝트를 진행하는 동안 기술적 부채를 다룰 때마다 나타나는 신체의 다른 부위에 불편함을 유발할 수도 있습니다. 따라서 오늘 우리는 기술 부채(TD)에 대해 이야기하겠습니다. 기술 부채가 무엇인지, 어떻게 나타나는지, 기술 부채 유형은 무엇인지, 효과적으로 관리하는 방법은 무엇입니까?

기술부채란 무엇인가요?

그러나 먼저 용어를 이해해 봅시다. 기술부채는 소프트웨어 개발에 있어서 품질을 소홀히 하여 향후 추가적인 인건비 발생을 초래함으로써 소프트웨어 코드나 아키텍처에 누적된 문제를 소프트웨어 공학적으로 비유한 것입니다. 위키피디아 에서 기술부채에 대해 정의한 내용입니다 . 간단히 말해서, 기술 부채는 개발에 단순화되고 단기적인 솔루션을 적용한 결과이며, 나중에 후속 개선을 위한 비용과 시간이 계속 증가합니다(물론 부채가 "상환"되지 않는 한). 코드를 다시 작성하거나 제품을 기존 형태로 유지합니다. 일반 프로그래머의 세계에서 기술 부채는 부정적인 카르마 유형 중 하나이며, 나쁜 코드, 목발 사용 및 “일시적인”(실제로는 그리 많지는 않음) 솔루션에 대한 보복으로 제공되는 의욕을 꺾고 슬픔의 원천이 됩니다. 단기적인 문제를 해결하고 "신용" 개발 속도를 높이는 데 도움이 됩니다. 즉, 미래에 점점 복잡해지는 문제를 희생하면서 말입니다. IT업계에서 기술부채는 상당히 심각한 문제다. 최근 한 연구에 따르면 전 세계 기업들은 불량 코드를 수정하는 데 연간 850억 달러 이상을 지출하고 있습니다. 오래된 시스템과 "불량" 소프트웨어 지원과 관련된 프로젝트에 연간 약 3,000억 달러가 지출됩니다. 이것은 중요한 숫자입니다. 연구원들은 기술 부채와 그 결과를 다루는 모든 개발자의 노력이 "올바른" 개발에 다시 초점을 맞춘다면 현재 10년 동안 전 세계 GDP에 약 3조 달러를 추가할 것이라고 추정합니다.

출현 이유

예를 들어, 사업 개발(또는 스타트업 창업 ) 을 위해 대출을 받는 경우 금융 부채가 발생하는 것이 긍정적일 수 있는 것처럼 기술 부채가 항상 나쁜 것은 아니라는 점을 이해해야 합니다 . TD의 경우 이는 성공을 평가하고 시장 요구 사항을 연구하거나 새로운 틈새 시장을 빠르게 포착하기 위해 새로운 제품이나 서비스를 신속하고 자주 출시해야 하는 빠르게 성장하는 회사에 적합합니다. 그러나 금융 부채와 마찬가지로 기술 부채도 주의 깊게 관리하고 관리 방법을 알아야 합니다. 그렇지 않으면 심각한 문제가 발생할 수 있습니다. 소프트웨어 제품 개발 과정에서 기술 부채가 쌓일수록 회사에 더 많은 영향을 미칠 수 있으며, 새로운 릴리스의 출시 속도가 느려지고 해당 부채의 "유지"를 담당하는 일반 코더의 사기가 낮아지고 비용이 증가할 수 있습니다. , 이는 궁극적으로 회사를 파괴할 수도 있습니다. 기술적 부채가 발생하는 이유는 가능한 한 빨리 제품을 완성하거나 새 릴리스로 사용자를 만족시키려는 숭고한 욕구 외에도 열악한 제품 관리, 비현실적인 마감일 또는 리소스 제한, 물론 코더의 게으름 때문인 경우가 많습니다. , 낮은 자격과 주요 개발 원칙에 대한 이해 부족이 결합되어 종종 부채 증가에 기여합니다. 개발자 자신이 기술 부채의 존재와 지속적인 증가를 잘 알고 있지만 이를 변경할 권한이 충분하지 않거나 그러한 문제의 존재와 해결의 중요성에 대한 정보를 경영진에 전달할 수 없는 경우가 종종 있습니다.

분류

위에서 언급한 바와 같이 기술부채는 다양한 형태로 나타나며, 정의 자체는 단지 비유일 뿐이므로 기술부채의 종류는 다양하게 분류될 수 있습니다. 특히, 기술부채에 대한 세계적인 전문가 중 한 명으로 꼽히는 Tapad의 공동 창업자이자 CTO인 Dag Liodden은 연례 CTO Summit 행사에서 연설에서 기술부채를 세 가지 주요 유형으로 나눌 것을 제안했습니다 .

1. 의도적인 기술 부채.

   개발자가 의도적으로 최상의 솔루션을 선택하지 않은 경우에 나타납니다. 구현이 더 쉽고 빠르며 결과적으로 신제품을 시장에 신속하게 출시하는 데 도움이 되기 때문입니다.

   “때때로 우리는 개발 시간을 단축하기 위해 의도적으로 기술 부채를 떠안기도 합니다. 이 경로를 선택하기로 결정했다면 개발 중에 절약할 시간뿐만 아니라 나중에 그러한 부채를 "갚기" 위해 소비해야 할 시간도 고려하십시오. 또한 이해관계자(회사의 최고 경영진)가 그러한 결정으로 인해 향후 다른 기능의 출시가 필연적으로 지연될 것이라는 점을 인식하도록 해야 합니다.”라고 Dag Ljodden은 말했습니다.

   이러한 유형의 기술 부채를 해결하기 위한 접근 방식

   전문가는 이러한 기술 부채가 손실되기 전에 문제를 해결하고 프로젝트 구조의 필수적인 부분이 되기 위해 이러한 사례를 주의 깊게 문서화할 것을 조언합니다.

2. 우발적이거나 오래된 프로젝트 아키텍처로 인해 발생하는 기술 부채입니다.

   또한, 프로젝트 아키텍처를 생성하는 단계의 오류와 단점으로 인해 시간이 지남에 따라 기술 부채가 발생하는 경우가 많습니다. 시스템이 발전하고 소프트웨어 요구 사항이 변경됨에 따라 설계 오류가 더욱 분명해지고 새로운 기능을 추가하려면 더 많은 시간과 노력이 필요합니다. 초기 프로젝트 아키텍처의 품질은 여기서 중요한 역할을 합니다. 단순하고 기능적이어야 하며, 그러면 변경 사항에 더 쉽게 적응할 수 있습니다.

   이러한 유형의 기술 부채를 해결하기 위한 접근 방식

   이러한 유형의 기술 부채가 누적되는 것을 방지하고 심각한 수준을 초과하지 않도록 Dag Llodden은 시스템이 안정적인 상태에 있는 기간 동안 약 2년에 한 번씩 정기적으로 리팩토링할 것을 권장합니다. 팀 리더와 제품 관리자는 아키텍처와 자주 변경되는 프로젝트 요구 사항으로 인해 발생하는 이러한 종류의 기술 부채를 "갚기" 위해 시간을 할당해야 합니다.

3. 시간이 지남에 따라 발생하는 기술 부채.

   전문가는 이러한 기술 부채를 '오래 썩어가는' 부채라고 부릅니다. 지속적으로 추가되는 많은 변경 사항으로 인해 구성 요소나 시스템이 점차 복잡해지면서 시간이 지남에 따라 누적됩니다. 이는 여러 사람이 서로 다른 단계에서 시스템 작업을 하고 원래 아키텍처를 완전히 이해하지 못하는 경우 더욱 악화되는 경우가 많습니다.

   이러한 유형의 기술 부채를 해결하기 위한 접근 방식

   전문가는 이것이 정기적인 리팩토링을 통해 지속적으로 피해야 하는 세 가지 유형의 기술 부채 중 유일한 것이라고 말합니다. 이상적으로는 개발팀은 자신이 작업 중인 시스템의 아키텍처를 철저하게 이해하는 데 시간을 투자해야 합니다. 비록 원래 다른 사람이 만든 시스템이라 할지라도 말이죠. 시스템을 이해하면 프로젝트를 "썩는" 단계로 끌어들이지 않고도 잘못된 코드를 점진적으로 개선하고 수정할 수 있습니다.

기술 부채 관리 솔루션

기술 부채를 효과적으로 관리하기 위한 다양한 옵션이 있지만 모든 전문가는 기술 부채가 거의 모든 개발에서 필수적인 부분이고 이를 무시하는 회사는 항상 이후 단계에서 문제에 직면하기 때문에 이것이 수행되어야 한다는 데 동의합니다. 개발팀의 기술 부채 관리를 위한 몇 가지 효과적인 솔루션과 접근 방식은 다음과 같습니다.

1. 기술 부채를 처리하는 데 작업 시간의 고정된 비율을 할당하십시오.

   기술적 부채에 관한 문제는 의도적으로 부채를 제거하지 않는 한 이를 제거하기 위해 노력할 시간이 없다는 것입니다(항상 우선순위가 더 높은 작업이 있기 때문입니다). 따라서 좋은 해결책은 이러한 목적을 위해 특정 고정 비율의 작업 시간(약 20-25%)을 할당하는 것입니다.

   이것은 다양한 방법으로 수행될 수 있습니다.

2. 일주일에 1일 기술 부채 작업

   Если выделять на работу над устранением ТД всей командой один день в неделю, это How раз будет около 20% от общего рабочего времени. Для некоторых команд такой подход работает просто отлично и, говорят, даже повышает мораль, ведь в этот конкретный день недели вся команда занимается решением проблем, которые достают их все остальное время разработки.

3. Посвящать работе над ТД каждую четвертую задачу

   Такая система подходит тем командам, которые склонны разделять работу над проектом на примерно равномерные по времени и усorям для их выполнения задачи. Если один из каждых четырех тасков посвящать “выплате” ТД, это будет занимать около четверти всего времени разработки. А введение такого подхода в качестве правила позволит убедиться, что codeеры не будут откладывать технический долг “на потом”.

4. Переходящая роль

   Еще одним подходом к проблеме устранения технического долга будет назначать на данную задачу разных членов команды поочередно, чтобы равномерно распределить эту порой далеко не самую приятную работу среди членов коллектива. Количество разработчиков, назначенных заниматься “разгребанием” ТД, может быть разным — для команды из 4-5 человек будет достаточно одного, тогда How коллективы побольше могут назначать двух-трех. Но суть остается прежней — на работу над ТД должно уходить около 20-25% всех ресурсов и человеко-часов.

5. Правило бойскаутов.

   Правило бойскаутов состоит в том, чтобы всегда оставлять туристический лагерь (стоянку для палаток) в лучшем состоянии, чем он был до их прихода, то есть убирать даже тот мусор, который был оставлен не ими. Этот принцип, How выяснor заокеанские codeеры, отлично подходит и для управления техническим долгом. Согласно данному правилу, все члены команды должны заниматься исправлением ТД каждый раз, когда сталкиваются с ним в том or ином виде. Конечно, это правило нужно применять разумно, чтобы время, которое уходит на исправление ТД, не превышало “разумные” 25-30% от общих временных ресурсов.

6. Приоритизация “дорогого” технического долга

   Также эксперты в массе своей рекомендуют не забывать о том, что технический долг может различаться в том числе и по важности. Далеко не каждый тип ТД требует немедленного устранения, поэтому важно работать над классификацией разных видов технического долга и приоритезацией работы с ними соответственно. Проще говоря, прежде всего закрывать надо те долги, которые оказывают прямое влияние на speed разработки продукта, будучи частью его базовой архитектуры. Такие долги являются самыми опасными, потому что ведут к появлению новых долгов, которые могут расти How снежный ком.

Заключение

마지막으로, 소프트웨어 개발은 ​​개발의 필수적인 부분이기 때문에 기술적 부채 없이는 불가능하다는 점을 다시 한 번 강조하고 싶습니다. 그러나 기술적 특성에도 불구하고 TD는 여전히 개발 과정에서 인적 요소로 인해 발생하는 문제입니다. 그리고 완전히 없이는 할 수 없더라도 "깨끗한" 코드를 작성하고 가능한 한 책임감 있고 전문적으로 개발 프로세스에 접근하면 기술 부채 금액을 최대한 줄일 수 있습니다. 이것이 우리 모두가 바라는 것입니다!