코딩을 하면서 “왜 코드 조각을 나누는게 이로울까?” 라는 생각의 답을 찾은 것 같다. 예전에 한 파일에 컴포넌트를 여러개 적는 짓을 저지른 적이 있다. (참고: 똑같은 변수 적어도 되네?(Module System))
그땐 “컴포넌트 안의 컴포넌트 안의 컴포넌트 안의 컴포넌트 안의 …” 이렇게 들어가는 것을 별로 좋지 않게 생각했다. 왜냐면 작업할 컴포넌트를 찾고 작업하는데 시간이 너무 많이 소요되었기 때문이다. 그 때 문득 한 파일에만 중복되지 않으면 된다는 생각에 여러 컴포넌트를 넣었다. 비즈니스 적으로 2번 이상 사용되지 않으니까 파일로 따로 만드는 것이 좋지 않겠다는 판단에 몰아 넣었다. 내가 쓸 땐, 위에서 아래로 내려다 보면서 거부감이 없다고 생각했지만 하나의 파일이 생각보다 파일이 너무 거대했다. 하지만 남이 쓴 코드에서는 거부감이 들었다.
내가 작성할 땐, 분명 파일의 depth를 줄일 수 있다고 판단했는데, 왜 거부감이 드는걸까? 그 이유는 가독성이 떨어지기 때문이다. 개발자는 현대에 들어오면서 남이 유지보수하기에 편안한 코드를 짜는 것이 중요한 시대가 왔다. 더 이상 남이 보기에 어려운 코드가 아닌 쉬운 코드를 짜는 개발자가 고급 프로그래머의 기준이 되었다.
내가 짠 코드의 문제는 line 수도 문제였지만 애초부터 컴포넌트를 분리해야 할 때와 분리하지 말아야 할 때를 제대로 분리하지 못하였기 때문이 아닐까 생각한다. 한 지인 개발자가 내 코드를 보고 말했다. “map으로 돌리는거 다른 개발자분들은 다 따로 파일로 빼던데 같이 있네요?” 이 때, 나는 이상한 느낌을 직감했고, 그리고 ‘개발자가 해당 내용을 유지보수하러 왔을 때, 어디까지 알아야 하는걸까?’라는 기준의 생각을 매번 했지만 파일 수를 신경 쓴다고 선언적으로 프로그래밍을 하지 않았다는 것을 느꼈다. 그래서 나의 철학과 기준을 다시 정리할 필요가 있어서 다양안 ‘원칙’들을 정리하고 싶어졌다.
Principle of least astonishment(POLA; 최소 놀라움의 원칙)
: 시스템의 구성 요소가 대부분 기대하는 대로 작동해야 하는데 갑자기 이상하게 동작해서 놀라게 해서는 안된다는 원칙이다.
문득 이걸 보니 side-effect가 떠올랐고 React의
useEffect가 떠올랐다.