실용주의 프론트엔드 개발을 읽고 느낀점을 써봤습니다.

서문

리팩토링을 하는 목적에 대해서 다시 생각해봤다. “코드 품질 향상과 성능 개선” 이 두가지 목적을 이루기 위해 하는 것이라 생각했었는데, 잘못 생각한 것 같다. 마지막 문구인 “성능 향상을 위해 불가피하게 복잡하게 쓰는 코드”의 케이스도 생각해 볼 수 있다. 다시 정리하자면 “동작은 그대로, 코드 품질 향상”이 더 맞는 것 같다.

기능 추가와 리팩토링을 동시에 진행하는 것은 불가능 하다고 생각한다. 기능 추가는 “없던 것을 새로 만드는 작업” 이고, 리팩토링은 “있던 코드를 수정하는 것” 이기 때문이다. 코드가 없으면 수정도 없다고 생각한다.

1. 리팩토링을 하면 뭐가 좋을까

• 설계를 처음부터 잘 하는 사람은 천재가 아니고서는 없다고 생각한다. 한줄 한줄 쓰고 수정해 나가면서 점점 더 좋은 설계가 되어가는 것이라 생각한다.
• 가장 최악은 “작성자도 이해못하는 코드”라 생각 한다.
• 프로그래밍 속도에 대해서는 아직까지는 의문이다. 아직까지 경험이 부족해서 그런가, 디버깅 속도가 더 빨라진 다는 것을 체감하지 못했다.

2. 구조 리팩토링은 그림으로 시작한다. (참고 : 레거시 코드에서 이해하기 쉬운 코드로 리팩토링)

• Angular를 이용한 프로젝트였지만, 사실 어떤것을 쓰든 똑같다고 생각함.
• 외부 라이브러리를 한번 감싸서 사용한다면, 라이브러리가 바뀌더라도 쉽게 수정할 수 있을 것 같다.

const axios = axios.create({})

const postData = (url: string, params: any) {
  return axios.post(url, params)
}

postData()를 이용해서 Axios를 쓰다가 다른 이유 등으로 axios를 안쓰게 된다면, 저 postData()만 수정하면 된다.

• 보이스카웃 원칙: 소프트웨어 장인책에서도 나오는 이 용어를 좋아한다. 다만 일정 등으로 인해 여력이 안되는 아쉬운 상황이 많이 나오기 때문에, 일정을 잡을 때 리팩토링 까지 고려해야겠다.
• 기술적 부채를 평가하기: 10가지의 평가기준이 있는데, 개발을 하면서 고려해야 할 것이라 본다. 특히 복잡한 Boolean 로직과 이해하기 어려울 수 있는 함수 및 메서드가 가장 고려되어야 한다고 생각한다.

3. 코드 리팩토링의 방법은 모두가 알고 있다

• 모두가 알고 있다. 다만 실천하지 않을뿐. 또는 실천할 여건이 안되거나..