개요

처음으로 페어 프로그래밍을 해보았다. 페어 프로그래밍은 처음에는 기능 구현을 중점으로 하여 성능, 가독성, 중복 여부 등을 고려하지 않고 구현하였고, 이 후 한 번 더 살펴보며 리팩토링 과정을 거쳤다. 기능 구현도 어려웠지만 리팩토링 부분에서 더 많이 시간을 소요한 것 같다. 위의 두 과정을 거치면서 기술적 측면과 설계적 측면에서 여러모로 배우고 느낀점들이 많아 일부를 정리해 보았다. 이 중 제일 기초적이고 핵심적인 부분은 요구사항 명세서를 꼼꼼하게 읽고 작성자의 의도를 제대로 파악하는 것이라 생각한다. 잘못된 방향으로 코드를 작성한다면 아무리 잘 짜봐야 지우고 다시 작성해야하니 이 부분이 첫 단추부터 제대로 끼울 수 있는 중요 포인트라 생각한다.

배운 점들

• getcomputedstyle은 리플로우를 발생시킨다
• pageYOffset, scrollTo, throttle
• new FormData, Object.fromEntries
• translate3d는 리페인팅을 발생시키지 않고 GPU에서 돌리기에 translate보다 좋다.
• 요구사항에 가변 값이라는 언급이 없으면 고정값으로 사용하면 된다.
• 중복없이 간결하게 작성하는게 좋으나 가독성을 헤칠경우 중복하여도 나누는게 좋다.
• 모듈로 나눠져있을 때에는 객체를 빼서 굳이 IIFE로 묶어 은닉화 시킬 필요 없고 그냥 export 할 객체만 만들면 된다.
• documentFragment는 DOM 트리의 일부가 아니기에 거기다 추가/삭제를 하여도 리플로우가 발생하지 않는다. 다만 최종적으로 트리에 추가할 때 한 번 발생한다.

느낀 점들

경험이 중요하다

그 이유는 일단 리팩토링시 적절한 변수명, 중복 코드 함수화, IIFE로 객체 반환 후 메소드 사용, 동일 기능 수행하는 로직끼리 뭉쳐 놓기 등의 어느정도 일반적이게 통용되는 객관적인 컨벤션들은 그냥 외우면 되긴 한다.

그러나 그 외의 부분들은 주관적인 부분이 많아 그때 그때 처리해야 될게 달라서 경험이 중요한 요소로 작용한다. 예를 들어 DOM을 변수로 언제 빼는게 나은지, 계속 쿼리하는 함수가 실행되어 성능에 영향을 주어 변수로 DOM을 추출하여 사용하는게 나은지, 아니면 한 두번 밖에 사용되지 않아 굳이 변수로 만들어 메모리를 차지하게 하지 말고 그냥 쓰는게 나은지 등에 대한 결정은 경험 없이는 함부로 내리기 쉽지가 않다.

그 외에 추가적으로 MVC 패턴으로 분리하는 버릇, 은닉화나 캡슐화가 필요할 경우 IIFE로 묶어 객체나 함수를 반환하는 형식으로 작성하기, 변수명과 함수명 등은 최대한 자세하고 HTML과 일관성 있게 작성하기, 최대한 중복을 지양할 수 있는 방식으로 작성하기, state를 기반으로 동적 렌더링하기 등의 방식은 습관을 들이는 것이 좋겠다고 느꼈다.