기술 부채란 무엇이며 피할 수 있습니까?

소프트웨어 개발에 종사하고 있다면 어느 시점에서 기술적인 부채를 처리해야 합니다. 그래서 제목에 있는 질문에 답하자면… 아니, 피할 수 없습니다. 그러나 그 영향을 최소화하고 손에서 벗어나지 않도록 할 수 있는 단계가 있습니다. 적어도 너무 나쁘게.

기술 부채란 무엇입니까?

기술 부채라고도 하는 기술 부채는 본질적으로 불완전한 코드로 인해 시간이 지남에 따라 발생하는 비용입니다. 소스 코드의 변경 및 업데이트에는 개발 팀에 새 구성원을 추가하거나, 새 기능을 추가하거나, 버그를 수정하고 악용을 패치하는 것과 마찬가지로 비용이 듭니다.

프로젝트가 커지고 코드베이스가 확장되고 더 많은 사람들이 해당 코드에서 작업하기 때문에 그들의 목소리와 스타일이 여기저기서 충돌할 것입니다. 기한이 있고 이상적이지 않은 솔루션이 제 시간에 완료되도록 소스 코드에 패치될 수 있습니다. 기능을 직접 코딩하는 대신 처리하기 위해 완전히 이해하지 못하는 오픈 소스 구성 요소를 추가할 수도 있습니다. 또는 버전 간에 라이브러리를 전환할 수 있지만(예: Backbone에서 React로), 여전히 프로젝트에 레거시 코드베이스를 사용하는 사람들을 지원해야 합니다.

이러한 것들 중 절대적으로 나쁜 것은 없습니다 . 혼자가 아닙니다. 전혀 아닐 수도 있습니다. 그러나 그것들을 합치면 발생하는 기술적 부채는 미래의 어느 시점에서 갚아야 할 것입니다.

어느 시점에서 해당 오픈 소스 구성 요소를 교체(또는 분기)해야 할 수 있습니다. 시간과 비용이 듭니다. 먼 미래에는 프로젝트에서 모든 백본 코드를 제거하고 레거시 사용자 지원을 중단해야 합니다. 다시 말하지만, 시간과 돈. 기한을 맞추기 위해 한 패치? 글쎄, 그것은 결국 취소되고 더 영구적인 수정이 필요합니다. 시간과 돈. 그리고 이 모든 작업을 수행하기 위해 이전 코드를 다시 살펴보고 이전 개발자의 코드와 논리를 이해해야 하는 팀의 새 구성원이 있을 것입니다. 시간. 돈.

당신은 그것을 얻을.

기술 부채는 추상적인 용어이며 종종 은유적이지만 기술 부채의 비용은 매우 현실적입니다. 상환하는 것은 금전적 가치가 있으며 근무 시간 및 급여 명세서에서 지불하는 이자를 추적할 수 있습니다. 모든 소프트웨어 개발의 최종선에서 확인할 수 있습니다.

기술 부채를 피할 수 있습니까?

내가 전에 말했듯이 ...별로, 아니요. 릴리스 후 코드로 돌아가면 작성하는 모든 프로젝트에서 기술적 부채가 발생하게 됩니다. 그러나 기술 부채의 유형을 분류하면 프로젝트에서 이를 최소화하고 설명할 수도 있습니다. 부채를 미리 생각해보면 자동차 론이나 모기지를 받는 것과 다를 바 없다. 비용, 이자, 혜택을 보고 지불할 수 있는지 여부를 결정합니다.

위에서 논의한 몇 가지 예를 살펴보고 비용을 피하거나 최소화하거나 흡수할 수 있는 방법이 있는지 살펴보겠습니다.

의도적 기술 부채 고려

우리가 의도적인 기술 부채라고 말할 때 우리가 의미하는 것은 당신의 팀이 당신이 작업하는 프로젝트의 언어나 유형에 대한 소위 모범 사례에 속하지 않는다는 것을 알고 있는 결정을 내렸음을 의미합니다. 우리는 당신이 만나야 하는 기한이 있을 수 있다고 앞서 언급했습니다. 그리고 아마도 그 기한은 어렵고 빠를 것입니다. 변경되거나 이동될 가능성이 0%일 수도 있습니다.

대출을 받고 기술 부채에 들어가는 것을 고려해야 할 때입니다.

여기에는 세 가지 옵션이 있습니다.

• 미완성이고 버그가 있지만 코드 명확성과 논리에 대해서는 양보하지 않는 소프트웨어를 내놓습니다.
• 완벽하게 관리할 수 없는 기능을 가져오지만 가능한 한 잘 작성된 기능을 릴리스하십시오.
• 모든 것이 실행되도록 "충분히 좋은" 코드를 작성하지만 나중에 다시 해결해야 할 가능성이 있는 개발 결정을 내립니다.

여기서 세 번째 옵션은 종종 사람들이 선택하는 것입니다. 기술 부채가 되는 것입니다. 그리고 아무 문제가 없습니다. 하기로 결정했기 때문 입니다.

목적이 있는 부채 대출 상환

코드에서 이 경로를 선택하기 위한 결정을 문서화해야 합니다. 당신이 한 일과 이상적인 솔루션이 무엇인지에 대해 기록해 두십시오. 그리고 이 부채 탕감 솔루션이 구현된 위치를 나타내기 위해 소스 코드에 최소한 어떤 종류의 설명을 포함해야 합니다. 이 단계를 수행하지 않으면 새로운 기능이나 확장된 코드베이스는 말할 것도 없고 버그 수정 및 패치에서도 완전한 솔루션을 기대할 때 패치워크 솔루션을 찾음으로써 프로젝트에 추가하는 것이 끔찍하게 지연될 수 있습니다.

다시 말하지만, 해당 패치워크 솔루션은 완벽할 수 있으며 실제 문제를 일으키지 않을 수 있습니다. 그러나 기술 부채는 여전히 존재하며 이를 설명해야 합니다.

레거시 코드 기술 부채 고려

또 다른 일반적인 기술 부채는 WordPress가 현재 많이 축적하고 있는 부채입니다. WordPress는 PHP 5.x에서 실행할 수 있습니다. 그러나 최신 업데이트는 사용자에게 최소한 PHP 5.6 이상이어야 한다고 알려줍니다. 2019년 말까지 WP Core에는 PHP 7.x가 필요합니다. 그러나 요구 사항을 높임으로써 많은 오래된 코드를 업데이트해야 합니다. 플러그인, 테마 및 Core 자체에 여전히 PHP 5.x 코드가 있기 때문입니다.

새로운 블록 편집기는 말할 것도 없습니다. 자바스크립트로 작성되었습니다. 구체적으로 반응하십시오. 그것은 PHP에 가까운 것이 아닙니다. 사실 워드프레스 코어의 상당 부분이 조금씩 자바스크립트로 재작성되고 ​​있습니다. 그러나 그 모든 JS는 PHP와도 칭찬하고 잘 어울립니다. 새로운 기술을 도입하는 것은 훌륭하며 새로운 버전 관리 요구 사항을 채택해야 합니다. 그러나 그렇게 하면 해당 소프트웨어가 한동안 존재해 왔던 피할 수 없는 기술적 부채에 대해 이자를 지불하게 됩니다.

레거시 코드의 부채 상환

좋은 방법이 없기 때문에 이것은 일종의 힘든 일입니다. 핵 옵션을 선택하고 새 언어/프레임워크/버전에서 처음부터 완전히 다시 작성할 수 있습니다(Divi 2와 Divi 3.0 사이에서 Backbone.js에서 React로 이동한 작업 참조). 그러나 여전히 오래된 라이브러리를 사용하는 사람들이 있기 때문에 부채 문제가 완전히 해결되지는 않습니다. 언젠가는 레거시 코드베이스에 대한 지원을 중단해야 합니다. 대출금을 갚는 것과 같은 이치다. 다음 것을 꺼내야 할 때까지.

이것이 옵션(또는 가장 좋은 아이디어)이 아닌 경우 언어 또는 버전별 기능에 의존하지 않도록 할 수 있습니다. 일부 브라우저는 새로운 기능을 신속하게 지원하지만 다른 브라우저(Microsoft Edge/IE, 기침)는 채택하지 않을 수 있으므로 프론트 엔드 개발자는 항상 이 문제를 해결해야 합니다. 기본을 고수함으로써 프로젝트의 미래를 대비할 수 있습니다. 그러면 업그레이드 또는 리팩토링할 때 해결해야 하는 변경 사항의 수가 그렇지 않을 때보다 줄어듭니다.

시간이 지남에 따라 여러 개발자 고려

이것은 대규모 팀이 소규모 개발 팀보다 시간이 지남에 따라 더 악화되는 경향이 있는 일종의 기술 부채입니다. 작은 아이들도 걱정할 필요가 있지만. 소프트웨어 엔지니어마다 코드를 다르게 작성합니다. 아주 드물게 똑같은 코드로 동일한 문제를 해결하는 두 명의 개발자가 있을 것입니다. 그들은 동일한 기능을 수행할 수 있고 최종 결과는 동일할 수 있지만 코드는 작성자의 목소리로 작성됩니다(예: Jason, Nathan, Donjete 및 나는 모두 독특한 스타일을 가지고 있습니다). 코드도 다르지 않습니다.

이를 염두에두고 논리도 때때로 다른 목소리를 가질 수 있습니다. 한 개발자가 완벽하게 명확하다고 생각하는 것은 다른 개발자가 보고 코드가 수행하는 작업을 수행하는 이유를 모를 것입니다. 이 문제는 원저자가 더 이상 상담할 수 없을 때 정말 문제가 됩니다. 이로 인해 발생하는 기술 부채는 치명적일 수 있습니다. 그러나 그것을 처리하는 방법이 있습니다.

오래된 개발자의 기술 부채 상환

가장 쉬운 방법은 가능한 최고의 개발자를 고용하고 회사를 떠나지 않도록 하는 것입니다. 항상.

그런 일은 거의 100% 일어나지 않을 것이기 때문에 이 빚을 갚는 것은 생각보다 조금 더 쉽게 완화될 수 있습니다. 우선, 개발 팀이 코드에 주석을 달도록 교육해야 합니다. 그리고 그것을 잘 논평하십시오. 다른 사람이 멀리서라도 모호한 것으로 간주할 수 있는 결정을 내릴 때마다 왜 그렇게 했으며 기능이 어떻게 작동하는지 기록하게 하십시오.

또한 팀의 모든 개발자가 스타일 가이드 또는 표준 세트를 고수하는지 확인하십시오. WordPress Core에는 플러그인, 테마 및 Core 기여를 인라인으로 유지하는 일련의 코딩 표준이 있어 나중에 오는 다른 사람이 문제를 일으키지 않습니다. Airbnb에는 업계 전반의 비공식 표준으로 채택된 React용 스타일 가이드가 있습니다. 내부 스타일 가이드와 표준조차도 개발자가 스스로 너무 멀리 가는 것을 방지합니다. 왜냐하면 그런 종류의 커밋은 스너프에 도달하지 않는 한 병합되지 않기 때문입니다.

마무리

기술 부채는 매우 현실적인 문제입니다. 또한 관리 방법을 안다면 매우 실제적인 리소스이기도 합니다. 기술 부채를 지는 시기와 상환 방법을 결정할 수 있기 때문에 개발이 가능한 것보다 더 빠르고 원활하게 진행될 수 있습니다. 그리고 부담을 지는 것이 불가피한 시기에 우리는 당신이 그렇지 않을 때보다 덜 영향을 미치기 위해 구현할 수 있는 전략에 대한 몇 가지 아이디어를 제공하기를 바랍니다.

프로젝트 및 개발 팀 내에서 기술 부채를 어떻게 처리합니까?

Andrey Suslov의 기사 특집 이미지/Shutterstock.com