결함/버그는 기술 부채의 일부분인가? 여러가지 의견이 존재하지만 결함은 기술 부채에 포함되지 않는다 보는 것이 훨씬 효과적인 듯 싶다. 이 쪽 입장에서는 결함/버그와 기술 부채를 구분하는 기준으로 '가시성'을 언급하는데, 즉 결함은 사용자 눈에 보이지만 기술 부채는 대체로 보이지 않는다는 관점이다. 대개의 경우 결함은 집중적인 관심/관리를 받게된다. 반면 기술 부채를 이끄는 문제는 대부분 보이지 않기 때문에 관심을 받지 못하고 무시되거나 뒤로 미뤄지곤 하게 된다. 결국 실용적인 관점에서 결함과 분리해서 기술 부채로 관심/관리을 쏟을 부분을 따로 정립해두어야 '기술 부채'가 갖는 함의를 제대로 현실에서 살려낼 수 있을 것이다. 그리고 이 관점에서야 기술 부채를 해결하는 주요 수단으로서 '리팩토링'의 가치가 실질적으로 의미를 가지게 될 수도 있고 ...
어젯밤 자기 전 잠깐 읽은 리팩토링 책에 나온 내용 중 공감 가는 부분을 나름 기억에서 꺼내 정리해 본 겁니다. 기술 부채를 꾸준히 제 때 갚지 않으면 왜 '복리'로 불어나는지에 대해서 나중에 한 번 따로 이야기 해보도록 하겠습니다. 이 부분이 공감되면 왜 조직에서 '리팩토링'이 주요 활동이 되어야 하는지도 논할 수 있 ...
'Slack 채널 정리' 카테고리의 다른 글
stretch goal (0) | 2019.12.06 |
---|---|
js - if 문 줄여 쓰는 꽁수 (0) | 2019.12.06 |
js 리팩토링 중 실수 (0) | 2019.12.06 |
js 버전 메모 (0) | 2019.12.06 |
js - 객체 배열 중 특정 property 값에서 max/min 값 찾는 방법, 그리고 여담 (0) | 2019.12.06 |