오늘도 개발

리팩토링

비효율적이고 알아보기 힘든 코드를 바꿔야할 때가 왔다.
프로젝트 진행이 잠시 뎌딘 틈을 타서 초반에 빠르게 기능만 구현한 코드를 바꾸고자 했다.

너는.. 오늘... 지옥에... 간다...

너무 만만하게 봤다.
로직만 좀 더 바꾸면 될 것 같았는데, 로직을 바꾸기 위해서 서비스 로직 뿐만 아니라 DB모델링부터 바꿔야 했다.

Model을 바꿨을 때 몰려오는 서비스 수정의 쓰나미, 두통이 쓰나미 인마헫...

천천히 정리하면서 가자

갑자기 앞이 깜깜해져서 먼저 상황 정리부터 필요하다고 생각했다.
현재 상황, 문제점, 내가 생각한 해결방법, 그리고 인터넷 조사.

먼저 내가 생각한 해결방법이 가능한지부터 조사했다.
다행히도 가능했다. (물론 이것이 좋은 코드라고 장담할 순 없다.)
하지만, 지금의 코드보다 읽기 쉽고 좀 더 명확한 코드를 원했기 때문에 지금보다 좋은 코드로 판단하고 실행에 옮기기로 했다.

배운 점

1. 내가 짠 코드는 코드의 파급효과가 크다.

한마디로 코드가 각각 객체로 독립적이지 못했고, 하나의 변화에 파급력이 커진 것이다. 사놓고 안읽은 객체지향의 사실과 오해를 읽어볼 생각이 들었다.

2. 테스트코드의 필요성

테스트 코드가 익숙하지 않고, 빠르게 기능 구현을 해야 하기 때문에 테스트 코드를 작성하지 않고 지나갔다. 근데 이것이 기능이 조금씩 더 생기면서 문제가 되었다. 새로운 기능을 추가했을 때, 그리고 리팩토링 했을 때, 내 코드를 믿을 수가 없었다. 시간이 가능할 때마다 테스트 코드를 작성해야겠다.

3. 의외의 결과도 존재한다

할 일을 정리해놨는데, 리팩토링을 하다보니 다음에 해야할 일이 해결되었다?

ES 모듈에서 __dirname

commonJS 모듈을 사용할 때, __dirname을 문제 없이 사용할 수 있었는데, ES 모듈로 변경하고 나서 문제가 생겼다.

문제가 생겼어...

구글링 결과 const __dirname = path.resolve()로 선언해줘야 한다고 한다.

정리

DB 설계는 어느 단계에서 잘 해야할까?
기획 단계에서 필요를 다 파악하고 DB를 설계해야 할까?
아니면 진행하는 도중 필요에 따라 수정해도 되는걸까?