리팩터링 2판을 읽으며 정리한 내용을 담고자 일종의 일기를 쓴다. 책을 갖고 있지 않은 사람이나 정보를 얻고자 하는 사람에게는 해당 내용들이 무슨말인가 할 수 있다. 일종의 필기라고 생각하고 책과 함께 읽으면 좋을 것 같다. 나 또한 다시 읽을때 함께 꺼내 보고자 정리하였다.
프로그램이 새로운 기능을 추가하기 편한 구조가 아니라면, 기능 추가가 쉬운 형태로 리팩터링을 하자
1. 중복 코드의 여지가 있는 것들을 분리하자
로직 변경이 없지 않는 이상, 오래 사용할 코드에서 중복코드는 골치거리가 된다.
2. 확장성이 있는 (변동이 있는) 코드들은 분리하자
저자의 경험상 어떤 방식으로 정하든 반드시 6개월안에 변경하게 된다 -> 깊은 공감
즉 변경이라는 것이 리팩토링의 중요성을 깨닫게 해준다.
리팩토링의 과정에서 가장 중요한 첫 단계는 테스트코드이다.
-> 프론트엔드에서의 테스트코드는 각론의박이 정말 많다. 특히 컴포넌트의 E2E 테스트 혹은 유닛테스트에 대해서...
-> 테스트 코드를 작성하는 노력이 실제 작업의 1.5배가 들고, 해당 컴포넌트가 단순한 view (정적인 view or 심플한 사용자 인터렉션)일 경우가 많다.
-> 수십, 수백, 수만개의 데이터에 대해 일정한 결과값을 보여야 한다면 적절해 보인다라고 생각한다.
-> 프론트엔드에서 다루는 함수도 다양하다. 이에 대한 테스트와 결과값을 준비하는 것은 다른 영역, 이러한 함수에 대해서는 필수로 필요해 보임. ex) 일정 string 변환기, intl 등등
다음으로는 함수 쪼개기를 진행한다.
함수를 따로 빼낼때는 유효범위를 벗어나는 변수가 있는지 확인한다. 정적으로 매개변수로 활용 될 변수도 있지만, 내부에서 값이 바뀔 수 있는 변수들은 조심히 다루어준다.
컴파일 후 테스트하여 실수가 없는지 확인한다. 사람은 실수를 하기에 이러한 과정이 반복되는 것이 중요.
-> 커밋 쪼개기, 함수나누기 등등 모두 최소 단위로 하는 것의 중요성. 사람은 실수한다. 과정들을 잘 나누어 작업하는 것이 나를 믿고 하는 것 보다 더욱 효율적이다. 피드백 주기를 짧게 가져가자
네이밍의 중요성도 기억하자.
-> 솔직히 영어의 실력이 어느정도 도움이 된다.
-> 접두어에 타입 이름을 사용하고 명확하지 않을때는 부정관사(a/an)을 붙히는 방법.
-> 명확성을 의심하지 말자. 디버깅과 버그픽스가 굉장히 빈번했던 나에겐 정말 와닿는 말이다. Spelling마져 틀리고 커밋하는 개발자들은 정말 많다.
임의 변수를 질의 함수로 바꾸기 - 변수 인라인하기
-> [2/28] 해당 부분에서의 궁금증이 있다... 함수를 반복적인 호출로 하게 되는데 (물론 간단하지만) 이는 성능적으로 좋지 않은 선택이 아닐까? 인라인된 변수는 함수로 이루어져 있고, 이는 결국 반복적인 함수 호출을 의미한다. 단순하게 메모리에서 주소값을 가져오는 행동과 함수를 호출하는 행동에서의 손해는 없을까? (물론 미시적인 관점에서)
-> 바로 다음 페이지에 이에 대한 의문을 표기해주었다. 리팩터링과 성능의 관계를 자세히 설명하는 뒷 부분을 참고하고 다시 복기하자
-> 느려지더라도 리팩터링 된 코드는 그렇지 않은 코드보다 성능 개선하기 쉽다.
-> 지역변수를 제거하면 추출 작업이 훨씬 쉽다.
변수 제거하기
-> 임시 변수에 함수가 대입 된 경우 별도의 함수로 관리할 수 있다.
-> 반복문 내에 별도로 존재하는 로직은 두개의 반복문으로 관리할 수 있다.
-> 위와 같이 분리 된 로직을 함수로 추출하여 리팩터링 할 수 있다.
저자의 철학 -> 리팩토링으로 느껴지는 성능의 저하는 리팩토링을 한 후에 다시 고민하는 것이 더욱 수월하다. 즉 리팩토링은 must 이다.
커밋을 자주하자
코드가 복잡할수록 단계를 작게 나누면 작업 속도가 빨라진다. 실수가 있을때 가장 최근 커밋으로 돌아가서 실패한 원인에 대한 분석이 용이하다.
중첩 함수를 분리하는 과정에서 데이터는 중간데이터를 활용하여 정리 할 수 있다.
이러한 과정 속에서 코드의 량은 늘 수 있다. 하지만 프로그래밍에서 명료함만큼 중요한 것은 없다. 모듈화를 통해 다양한 함수들의 역할을 구분 할 수 있고, 수정할 수 있다.
[2/28] 클래스를 이용한 다형성 버전에 대한 생각은 몇번 더 책일 읽어 본 후 이야기 하는 것이 좋아보인다.
'Software Engineering' 카테고리의 다른 글
[OAuth 2.0] Microsoft ID 플랫폼과 함께 OAuth 2.0 복기하기 (0) | 2023.05.27 |
---|---|
[Web App] Frontend Developer로 Web App 개발하기 (0) | 2023.01.14 |
[Design Pattern] 의존성 (Dependency) (0) | 2022.10.09 |
[Javascript] Class vs Factory Function (2) | 2022.09.24 |
Git 브랜치 전략, Git-flow (0) | 2022.09.03 |