기술 부채란 무엇입니까?

기술 부채는 현재 구현하지 않기로 의식적으로 선택했을 수 있는 알려진 엔지니어링 구현 지점입니다. 기술 부채는 일반적으로 발생하지만 신중하게 생각해야 합니다. 평가 시기/방법에 대한 몇 가지 지침을 제시합니다.

이상적으로는 모든 코드가 처음 구현되는 동안 알려진 모든 사례를 처리해야 합니다. 그러나 차단기가 있을 수 있습니다.

1. 경우에 따라 제품 기능이나 엔지니어링 논리가 명확하지 않을 수 있는 흔하지 않은 경우도 있습니다. 또한 규모나 트래픽 요구 사항이 불분명하여 트래픽 및 규모에 대한 준비가 부족하거나 과도할 위험이 있습니다.
2. 일반적이지 않은 사용 사례에 대한 구현이 명확하더라도 구현이 복잡하거나 시간이 많이 걸릴 수 있습니다.

우리 모두는 이상적으로는 기술 부채를 최소화하기를 원하지만 받아들이는 것이 타당할 때가 있습니다.

앞으로 나아가야 할 필요성

모든 세부 사항이나 완전한 구현이 없는 것은 방해가 될 수 있지만 종종 다음과 같은 몇 가지 이유가 조합되어 진행해야 합니다.

1. 종종 사용 또는 고객의 부분적인 피드백을 활용하여 추가 질문에 답하기 위해 무언가를 구축하거나 구현해야 합니다. 디더링은 비용이 많이 드는 지연으로 이어질 수 있으며 전혀 구현하지 않는 것보다 완벽하지 않은 구현의 위험을 감수하는 것이 좋습니다.
2. 특정 명확성 부족은 구축할 기능의 더 넓은 체계에서 상대적으로 중요하지 않을 수 있으며 쉽게 추가하거나 수정할 수 있으며 기능을 구현하지 않으면 비용이 더 많이 들 수 있습니다.

자질

우리가 기술 부채를 받아들일 때, 우리는 아마도 더 정확한 구현을 부분 구현과 교환하기로 의식적으로 결정했습니다. 그래도 좋은 기술 부채:

1. 기술 부채가 해결되면 현재 선택한 구현의 코드에 대한 코드 변동이 줄어듭니다.
2. 기능의 일부 일반적이지 않은 부분에 정상적인 오류가 발생합니다. 반대로 수정되면 기능이 점진적으로 개선됩니다.

위의 자질을 충족하는 좋은 기술 부채만 가져가야 합니다. 다음 질문은 평가에 도움이 됩니다.

비용

기술 부채 또는 놓친 사례 비용을 평가할 때 물어볼 몇 가지 질문:

1. 누락된 기능은 어디에 있습니까? 예: 데이터 시각화/프리젠테이션 또는 데이터 생성? 보다 구체적으로, 누락된 기능으로 인해 영구적으로 잘못된 데이터가 발생합니까?
2. 사용자 경험의 단점은 무엇입니까? 사용자가 비틀거리고 불만스러워할 가능성이 있는 일반적인 사용 사례입니까, 아니면 우리의 핵심 가치 제안의 주변에 있는 흔하지 않은 사례입니까?
3. 누락되거나 건너뛴 기능 설계 및 구현에 대한 세부 정보를 확신합니까? 아니면 그것을 정의하기 위해 부분 구현에 대한 피드백을 받고 싶습니까?

우리는 특정 혜택을 위해 기술 부채를 받습니다.

1. 더 빠른 출시, 잠재적으로 매출 증가 또는 고객 만족으로 이어질 수 있습니다.
2. 채택 데이터 또는 피드백을 얻을 가능성이 있어 누락된 기능을 더 잘 설계할 수 있습니다. 일부 명확하지 않은 기능의 경우 필요할 수 있습니다.
3. 엔지니어링 노력의 기회 비용이 단기적으로 절약됩니다.

견고한 설계의 기본 기본 원칙을 따르면 기술 부채를 해결하는 재작업이 최소화됩니다.

모듈성

서비스 및 객체가 잘 정의된 인터페이스로 잘 고려되었는지 확인합니다. 모듈성을 통해 코드 재작업 공간을 최소화하지 않고도 변경 사항을 현지화할 수 있습니다.

예를 들어 즉각적인 것 이상으로 생각하십시오.

1. 현재 기능 구현이 하나지만 나중에 구현을 인터페이스의 하위 클래스로 둘 수 있습니다. 이렇게 하면 나중에 더 많은 구현을 쉽게 추가할 수 있습니다.
2. 엔터티에 현재 필드에 대해 하나의 가능한 값이 있지만 나중에 더 있을 수 있는 경우 해당 값을 열거형으로 만듭니다.

깨끗한 스키마

실제 사용 사례를 밀접하게 모델링하는 좋은 데이터베이스 스키마 및 ORM 모델은 일반적으로 추가 변경에 강력 합니다 .

좋은 코딩 습관

1. 코드에 깊숙이 들어가지 않고 건조하게 조정할 수 있는 값을 유지하십시오. 런타임 입력 구성 변수 또는 코드 상수일 수 있습니다. 이것은 의식적인 결정이어야 합니다.
2. 일부 기능은 신속하게 반복하거나 고객별로 맞춤화할 수 있는 기능이 필요합니다. 코드가 낮거나 코드가 없는 도구를 사용하면 엔지니어가 아닌 사람도 쉽게 반복할 수 있습니다. 그리고 코드가 적고 이탈이 적습니다.
3. 위에서 언급한 일반적인 코딩 및 디자인 관행이 적용됩니다. 예를 들어 코드를 건조하게 유지(한 곳에서 코드를 쉽게 변경할 수 있음) 단순하게 유지(그래서 변경이 이해하기 쉬움) 등이 있습니다.
4. 일부 변경 사항은 기존 단일 노드 mongo 데이터베이스 서버에 복제본 세트를 추가하거나 mongo 데이터베이스 서버에 샤딩하는 것과 같이 문자 그대로 현상 유지에 따라 추가될 것입니다. 구현하는 데 비용이 많이 드는 경우 이러한 개선 사항에 대한 필요성은 추가 노력 없이 필요할 때까지 일정을 더 늦출 수 있습니다.

모든 사례를 처리하지 않는 것은 코드를 체크인할 충분한 이유가 되지 않습니다. 대신 다음은 앞으로 나아갈 수 있는 한 가지 방법입니다.

1. 보류 중인 기능 또는 설명 항목에 대한 풍부한 TODO 주석을 사용하여 브랜치에서 코드를 계속 커밋하십시오.
2. 이상적으로는 풀 요청을 제기하기 전에 모든 TODO를 해결하십시오.
3. 해결되지 않은 문제는 기술 부채가 됩니다. 코드 검토자 및 관련 엔지니어링 관리자/리드가 태그 지정/정보, Jira가 생성한 기술 부채 및 댓글에 Jira ID가 언급되었는지 확인하세요. PR 검토를 통해 기술 부채를 받아들일 수 있음을 재확인할 수 있기를 바랍니다.
4. 코드가 처리되지 않은 경우도 정상적으로 처리하는지 확인합니다. 예를 들어 프런트 엔드는 백엔드 충돌보다 아직 처리되지 않은 API 입력의 오류를 표시하기 위해 적절한 API 응답을 받습니다.
5. 초기 검토를 위한 스프린트 계획 요청에 나타날 수 있도록 다음 스프린트에 유지함으로써 기술 부채 Jira에 대한 타임라인을 염두에 두십시오.