유튜브 리뷰 - 코딩의 실 아샬(03/16)

기술 부채가 뭐지? 왜 문제야?

• 한번에 코드 변화량이 많아지는 경우가 있다. (파일 개수차이, 코드라인 개수 등)
• 그런 경우 코드리뷰가 쉽지않다.
  • 작업을 나누려는 단위가 너무 크다.
    • 서로 연관된것들이 많고 분류하기가 어려워서
  • 한번에 여러 작업을 수행하려고 한다.
• 기술부채가 뭘까
  • 오래된 언어, 오래된 기술 등을 쓰는것이 기술부채가 될 수도 있지만
  • 비용이 많이 들거나 == 생산성을 저하시키는 기술이 기술부채다
    • 변화에 대한 비용 –> 작은 것을 고치려고 할때도 많은 비용이 들 수 있다.
  • 변화에 대한 비용이 계속 증가하게 되는 상황
    • 10분 걸리던 문제가 하루가 걸리게 되고… 하루가 걸리던 문제가 일주일.. 이런식으로 계속 증가
• 기술 부채에 대한 개념을 잘 모르지만 영상을 보고 내가 생각한것은 리팩토링이다.
• 예를 들어서 생각해보면, 주소록을 출력하는 기능을 개발했다. 지금은 주소록을 출력하는 기능 밖에 없기 때문에 기술부채가 발생하지 않을것이다. 그런데 여기서 주소록을 수정하는 기능, 주소록을 다른사람에게 전송해주는 기능 등을 추가한다고 생각해보면.. 그 기능에 대한 변수, 메소드, 라이브러리 등 추가될것이다. 이렇게 계속 기능이 추가되다보면, 그리고 서로 연관이 있기때문에 조그마한 수정에도 여러 메소드와 변수를 수정해야하는 결과가 생길것이다. 그렇기 때문에 비용(빚)이 조금 쌓였을때 계속 리팩토링 하는것이 중요하다는 생각을 했다.
• 옛날에 아는선배에게 코드리뷰하는것을 본적이 있는데, 엄청 조그마한 수정에도 수많은 PR과 코멘트들이 달렸었다. 그걸 보고 처음에는 아니 그냥 단순한 수정하나만 해주면되는데 저렇게까지 리뷰를 할 필요있나? 생각을 했었는데 지금 생각해보면 그렇게 하는게 장기적으로 보면 더 맞는 방법인거같다. 물론 내가 현업에서 일을 해보지 않았기 때문에 장,단점에 대해 크게 와닿아서 하는 얘기는 아니다.