[TIL] 2022/07/28 기술부채, 앞으로에 대해 회고

지금까지 그리고 앞으로도 기초, 기본이 되는 관련 지식 공부, 써보지않은 프레임워크, 라이브러리를 사용 해나가겠지만 이거 외에 요새 실무적인 효율성, 협업, 유지보수, 현재 트랜드로 사용되는 이유와 필요성을 고려하고 생각하는 시간을 가지게 되었다. 그전에 어떤건지 대충은 알았지만 공부나 사용 우선순위가 아니라 미루었거나 해보고 싶었지만 체감상 그전에 혼자 경험할 수없고 찍먹하기에는 껍데기만 핥을거 같아 미루었던 부분에 대해서 생각하고 정리하여 리스트를 만들면 좋겠다고 생각했다. 어떠한 고충이 있었고 느꼈는지, 그래서 앞으로 어떤걸 배우고 접목시킬지 서술하려고 한다. 결국 '왜' 라는게 생기기 마련인것 같다. 

 

이러한 생각과 결정을 한 이유는 현재 자사의 서비스에서 jQuery, JSP 로 사용된 레거시 코드를 기존 서비스는 유지하되 리액트로 고도화 작업을 하면서 내가 짠 코드가아닌 여러사람의 손을 탄 코드를 전반적으로 이해하면서 나의방식, 리액트 방식으로 옮기는 과정에서 분명하지않은 함수, 변수, 다른 방식으로 보다 복잡하게 짜여진 비즈니스로직 등을 보면서 이러한 고충들을 내가 느낀다면 앞으로의 미래에 나의 코드가 새로운 팀원 혹은 기존 팀원에게 이해하는데 어려움을 주고 같이 프로젝트 진행시에 수정이 필요할시 많은 어려움이 발생할 확률이 있다고 판단했다.

 

혼자 개발하는 경우 개인적인 선호가 기술 부채로 발전하지 않지만(지속되고 프로젝트가 커진다면 당연히 생기겠지만) 여러 개발자에 의해 개발되고 함께 일하다보면 다른사람이 작성한 코드를 변경하거나 활용해야 하는 경우가 생기고, 해당 코드의 구조가 자신의 가치관과 다르거나 익숙하지 않은 방식인 경우, 생산성을 저해하는 부채로 받아 들일수 있다.

 

만약 이러한 현상이 지속된다면 프로젝트가 더 커지면 복잡하게 연결된 비즈니스로직 data 상태관리, 여러 주구난방 정렬되지않은 함수들의 위치, 컨벤션 되지않고 고심하여 만들지않은 파일, 변수, 컴포넌트 이름의 난해함이 생긴다면 유지보수와 수정이 필요시 개발 속도를 저해하는 현상이 발생할 것이라고 생각하고 이것이 기술부채가 될것이고, 기술부채는 빚이기 때문에 이를 갚기 위해선 많은 시간과 노력을 투자하여 코드를 리팩토링하고 컨벤션을 정립해야 한다.

 

또한 프로젝트 커졌을때 리팩토링하기 힘들고 꺼려질수있고 시간을 많이 할애할수도 있기 때문에 여러 리스크가 커지는 것을 방지하기위해서 사전에 테스트코드 작성하여 기능을 수행하는 코드가 실제로 잘 작동하는지 확인한다. 리팩토링을 한다거나 유지보수를 한다고 하는 것은 결국엔 비즈니스 로직을 이해하고 좀더 잘 짜여지게 만들고 추가적인 작업에도 꼬이지않게 한다는 것인데, 이러한 비즈니스 로직을 위해 테스트 코드가 잘 구축되어 있다면 리팩터링을 진행할 때 두려움이 없어질 것이다. 따라서 요새는 아예 처음부터 테스트 코드부터 작성하는 테스트 주도 개발 TDD, Test Driven Development 방법론을 쓴다고 한다.

 

이러한 TDD 뿐만아니라 type이나 라이브 코딩중의 에러 체크 가능성을 고려, 혼자뿐 아니라 여러 사람과의 협업에서 잘못된 type, 코드 이해의 명확성을 주기위해 Typescript가 요새 많이 사용된다.

 

기술부채가 생기는 이유는 위에 언급한것과 같은 이유도 될수있지만, 회사란 결국 결과물이 중요한 곳이기 때문에  프론트엔드는 보이는 것을 다루기 때문에 속도와 결과물에 초점을 두는 회사, 대표, 팀원이 있다. 틀렸다고도 볼수없고 무시할수 없는 부분이기에 이러한 이유로 개발자는 항상 두가지의 고민을 하게된다. 첫째는 약간 지저분하지만 빠르게 개발하는 것, 둘째는 시간은 더 걸리지만 깔끔하게 개발하는 것이다. 이러한 문제를 워드 커닝햄, Ward Cunningham은 부채(Debt) 라고 설명하였다.

 

이러한 여러가지 이유로 위에 언급한것 이외에도 생산성, 효율성, 유지보수, 협업을 고려하여 다음과 같은 리스트를 우선순위로 두고 공부하거나 실질적으로 적용 해보고자한다. 또한 정확하게 관련된지 모르고 더많은 것을 찾아보지 못했기때문에 아래의 리스트가 수정되거나 추가될수 있을거 같다.

1. ESLint, prettier, 컨벤션에 대한 규칙, 이론 찾아 공부(변수, 파일명, class 명 등)

2. jest

3.Typescript (이미 해본적이 있지만 좀더 깊고 유용하게 사용하기위해)

4. storybook -> 디자이너와의 디자인시스템, 핸드오프 관련 활용 협업이 포커싱

 

또한 리액트 재활용성 element에 대해서도 연구하고 찾아보려고 한다. 이전에 해본적이 있고 활용한적이 있지만 체감상 만들기만하고 제대로 활용은 못했다 이유는 해당 서비스를 갈아엎거나 부분 삭제 수정, 해당 ui ux 삭제등 실제로 지속적으로 바뀌지않고 한번의 결과물 이외에 version 2 , 3 로 이어지지 않았다. 하지만 앞으론 기존 서비스에서 없애야하는 부분도 생기고 다른대서 똑같이 사용하거나, 조금 바뀐 버튼, 컴포넌트 등이 생기기 때문에 이러한 면에서 재활용성을 어떻게 만들것인가 연구하고 생각하고 찾아보려고한다.