Notice
Recent Posts
Recent Comments
Link
일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
1 | 2 | |||||
3 | 4 | 5 | 6 | 7 | 8 | 9 |
10 | 11 | 12 | 13 | 14 | 15 | 16 |
17 | 18 | 19 | 20 | 21 | 22 | 23 |
24 | 25 | 26 | 27 | 28 | 29 | 30 |
Tags
- Typesript
- Elastic Load Balancing
- Jenkins
- NoSQL
- kubernetes
- 코드프레소
- springboot
- ci/cd
- ELB
- TypeScript
- Auto Scaling Group
- docker
- codepresso
- Redis
- k8s
- 아키텍처
- REPLICATION
- AWS
- ASG
Archives
- Today
- Total
Study Note
Technical Debt 본문
Technical Debt은 개발 단계에서 제대로 개발을 하지 않으면, 나중에 이자가 붙어 더 많은 일을 해야 한다는 뜻이다.
여러 원인중 다음과 같은 주요 원인을 통해 Technical Debt가 발생한다.
- 비스니스 조직으로부터으 무리한 압박
- 부정확한 요구 사항이나 잦은 변경
- 잘못된 의사 결정 프로세스
- 부족한 협업
- 부족한 테스트
- 부족한 문서화
- 리팩토링 지연
- 낮은 수준의 아키텍처 설계
Technical Debt가 꼭 나쁜 것은 아니다. 회사에서 부채를 유지하면서 다른 곳에 투자할때 이익이 생길수 있다. 이처럼 Technical Debt이 발생 시키면서 개발 인력을 다른 곳에 투자함으로써 더 좋은 효과를 낼수 있다. 중요한건 Technical Debt의 비율이다.
Technical Debt, 아키텍처, 기능, 버그 관계의 그림이다.
- 기능 : 긍정적인 가치가 구체화 된것
- 버그 : 부정적인 가치가 구체화 된것
- 아키텍처 : 긍저적인 가치에서 비롯되었지만 시각화, 수치화가 힘듬
- Technical Debt : 부정적인 가치에서 비롯되었지만 시각화, 수치화가 힘듬
'아키텍처 > 소프트웨어 개발과 테스트' 카테고리의 다른 글
태스크 관리 도구 (0) | 2020.02.18 |
---|---|
태스크와 요구사항 (0) | 2020.02.18 |
태스크 (0) | 2020.02.18 |