기술부채란 무엇인가요?

기술 부채는 최적의 코드 품질보다 신속한 납품을 앞세운 결과입니다. 기술 부채는 소프트웨어 개발팀이 장기적 솔루션보다 빠른 해결책을 선택할 때 발생합니다.

부채 은유는 적절합니다. 누군가가 부채를 떠안을 때는 종종 단기적으로 재정 자원이 필요하기 때문입니다. 그러나 이는 나중에 부채를 갚아야 할 때 추가 비용을 발생시킵니다.

기술적 부채도 비슷한 방식으로 작동합니다. 편의성을 희생하고 추후 추가 작업을 하는 것입니다.

나중에 코드를 다시 검토하여 수정하지 않으면 문제가 될 수 있으며, 대출금을 갚지 않으면 이자와 벌금이 누적될 수 있습니다.

기술 부채는 반드시 문제가 되지는 않습니다. 그러나 제품이 제대로 최적화되지 않았거나 코드가 제대로 작동하지 않으면 문제가 될 수 있습니다.

기술 부채의 예

기술적 부채의 전형적인 예로는 2000년(Y2K) 문제가 있습니다.

1960년대와 1970년대의 많은 소프트웨어 개발자들은 날짜를 두 자리로 저장하여 귀중한 메모리를 절약하기로 했습니다. 그래서 "73" 대신 "1973"을 사용했습니다.

메모리 가격이 하락하는 동안에도 그 관행은 수년간 계속되었습니다. 그 프로그램 중 다수가 운영 사업에 내장되어 예상보다 훨씬 오래 사용되었습니다.

2000년이 다가오면서 수천 개의 기업과 정부 기관은 날짜 계산이 대규모로 실패할 것이라는 사실을 깨달았습니다. 이로 인해 광적인 청소 작업이 시작되었으며, 비용 $ 100 억.

하지만 기술적 부채는 소프트웨어에만 국한되지 않습니다. 예를 들어, 사이버 보안의 모범 사례는 개인이 아닌 조직 내의 역할에 파일 권한을 부여하는 것입니다.

행정 보조원이 일반적으로 볼 수 없는 민감한 문서에 대한 임시 액세스에 대한 승인을 받았다고 가정해 보겠습니다. IT 조직이 예외를 허용하고 나중에 취소하지 않으면 민감한 문서에 대한 영구 액세스 권한을 부여한 것입니다. 계정은 결국 손상되어 취약성을 나타낼 수 있습니다.

기술 부채의 단점은 무엇입니까?

단기적 수정이 빠르게 리팩토링되고 개발자가 기술 부채를 처리하는 방법을 안다면 단점은 거의 없습니다. 기업이 기회나 문제에 신속하게 대응할 수 있으므로 이점이 있을 수도 있습니다.

부채가 여러 겹 쌓이면 위험도 커집니다.

빠른 수정은 제대로 문서화되지 않았거나 전혀 문서화되지 않았을 수 있습니다. 그리고 빠른 수정을 수행한 사람들이 떠나면 회사에는 코드가 어떻게 작동해야 하는지 아는 사람이 아무도 없을 수 있습니다. 심지어 빠른 수정이 존재한다는 사실조차 모르는 사람도 있을 수 있습니다.

향상이나 변경은 의도치 않은 충돌을 만들어 프로그램이 실패하거나 느리게 실행될 수 있습니다. 조직이 변경으로 인해 애플리케이션이 망가질까 봐 개선하지 못하면 혁신이 느려집니다.

기술 부채에는 어떤 유형이 있나요?

기술 부채의 두 가지 주요 범주는 다음과 같습니다. 계획적인 의도하지 않은.

개발자 교육 회사의 CEO인 Steve McConnell 컨스트럭트, 정의하다 의도적인 기술적 부채란 의식적으로, 전략적으로 부담하는 것을 말한다.

그는 정의한다 의도치 않은 기술적 부채는 "잘못된 일을 해서 생기는 비전략적 결과"입니다.

2014년에 학자 그룹이 분류 체계 13가지의 고유한 유형의 기술 부채로 구성됩니다.

• 건축 부채
• 부채를 쌓다
• 코드 부채
• 결함 부채
• 디자인 부채
• 문서 부채
• 인프라 부채
• 사람들의 부채
• 부채 처리
• 요구 부채
• 서비스 부채
• 테스트 자동화 부채
• 테스트 부채

이러한 분류는 단기적 사고가 장기적 문제를 야기할 수 있는 모든 영역을 포괄하기 때문에 유용합니다.

기술 부채는 어떻게 발생하나요?

기술 부채의 유형은 다음과 같이 몇 가지 방식으로 발생할 수 있습니다.

의도적인 기술 부채

의도적인 기술 부채는 의식적인 결정입니다. 문서화하고 리팩토링을 위해 예약해야 합니다.

예를 들어: 지역 영업 관리자가 플랫폼에서 만들 수 없는 보고서를 생성해야 하는 마감일이 있습니다. 관리자는 마감일을 맞추기 위해 오픈소스 보고서 작성기를 사용하기 시작합니다. 이것이 기술 부채입니다.

하지만 개발팀이 오픈소스 보고서 작성자를 제거하고 마스터 보고 시스템을 수정하는 데 리소스를 사용한다면, 그것은 고의적인 기술 부채가 됩니다.

의도하지 않은 기술 부채

의도치 않은 기술 부채는 코드 리팩토링 계획 없이 편의상 변경이 이루어지는 경우를 말합니다.

또한 지식 부족이나 개발 표준을 따르지 못해서 발생한 잘못된 설계 결정으로 인해 발생할 수도 있습니다. 테스트 영역에서 의도치 않은 기술 부채는 다음과 같은 경우에 발생합니다.

• 테스트 모음이 불완전합니다
• 테스트가 잘렸습니다
• 편의를 위해 테스트는 건너뜁니다.

문서 부채

문서 부채는 흔히 발생하며, 개발자가 코드를 철저히 문서화하기에는 너무 서두를 때 발생합니다.

사람이 회사를 떠나서 코드를 이해하기 위한 지침을 남기지 않으면 장기적으로 문제가 될 수 있습니다. 문서 부채는 Y2K 문제의 주요 원인이었습니다.

인프라 부채

인프라 부채는 애플리케이션이 데이터베이스 및 파일 시스템과 같은 특정 구성 요소에 의존하도록 빌드될 때 발생합니다. 이러한 종속성이 문서화되지 않고 회사가 새로운 인프라로 마이그레이션하는 경우 애플리케이션이 작동하지 않을 수 있습니다.

기술 부채의 경고 신호는 무엇인가?

기술 부채의 경고 신호는 다음과 같습니다.

• 개발자가 코드베이스에 대한 통찰력이 부족하여 프로젝트가 중단됨
• 복잡성이나 문서 부족으로 인해 수정하기 어려운 버그
• 새로운 버그를 생성하거나 성능이 꾸준히 저하되는 버그 수정

기술 부채를 관리하고 예방하는 방법

기술 부채를 처리하는 방법을 아는 것은 건전한 개발 관행에서 시작됩니다. DevOps 환경에서는 여기에는 Shift-Left 및 Shift-Right 테스트가 모두 포함됩니다.

• Shift-left 테스트 테스트 프로세스를 개발 주기 전반과 초기에 이동합니다. 이렇게 하면 문제가 프로덕션에 포함되기 전에 예상하고 해결할 수 있습니다.
• Shift-right 테스트 애플리케이션이 프로덕션으로 이동한 후 피드백을 구합니다. 이런 방식으로, 소프트웨어가 널리 사용되기 전에 버그를 일찍 감지하고 수정합니다.

이러한 조치는 문제가 지나치게 커지는 것을 막는 보호막을 마련합니다.

기술적 부채를 만드는 해결 방법은 피할 수 없고 종종 필요합니다. 그러나 개발자가 해킹이 적용된 이유와 이를 수정하기 위한 지침을 포함하여 이를 문서화하는 것이 중요합니다.

기존 코드에 대한 정기적인 감사를 통해 팀 구성원이 서로의 작업을 검토하고 문서 간극이나 불규칙성을 발견할 수도 있습니다.

모범 사례는 무엇입니까?

조직이 DevOps 기술을 도입함에 따라 기술 부채가 무엇인지 명확히 하고 이를 관리하기 위해 민첩한 전략을 적용해야 합니다. 여기에는 다음을 구현하는 것이 포함될 수 있습니다.

• Shift-right 및 Shift-left 테스트
• 문제가 심각해지기 전에 발견하기 위한 A/B 및 카나리아 테스트 기술

피어 코드 검토를 통해 새로운 시각으로 개발자의 작업을 검토할 수 있습니다. 개발자는 일관되고 제한된 도구와 언어 세트로 작업해야 하며 각 단계에서 완료해야 하는 작업 체크리스트가 있어야 합니다.

효과적인 DevOps 조직 개발자에게 창작물을 어떻게 만들 것인지 선택할 수 있는 자유를 제공합니다. 또한 통제 불능 상태가 되지 않도록 보호 장치도 제공합니다.

기술 부채를 방지할 수 있는 도구는 무엇입니까?

위에 설명된 관행은 좋은 시작입니다. 다음을 통해 추가 혜택을 실현할 수 있습니다.

• 사용 자동 테스트 모듈이 변경될 때마다 모든 코드 변경에 대해 여러 디버깅 주기를 실행합니다.
• 설립 사운드 코드 구조 해결 방법을 방지하기 위한 필수 문서화를 포함한 절차
• 사용 프로젝트 관리 도구 팀이 모든 사람의 작업 상태를 확인할 수 있도록 합니다.
• 데 프로그래머는 팀으로 일합니다 두 사람이 서로의 결정을 이해할 수 있도록 하기 위해

오늘날 대부분의 소프트웨어는 로우코드 및 노코드 도구로 작성됩니다. 이러한 도구는 자체 문서화되어 있으며, 플로우차트와 드래그 앤 드롭 기술을 통해 논리와 원하는 결과를 시각적으로 표현할 수 있습니다.

이러한 도구를 전문적인 소프트웨어 개발에 적용하면 셀프 문서화 기능의 이점을 얻을 수 있습니다. 개발 관리자는 팀이 로우코드/노코드를 우아한 창작물의 대체물이 아닌 생산성 향상으로 보도록 장려해야 합니다.