설계 vs 가독성, 개념

프로그래밍을 하다 보면 설계 상으로는 모듈이나 컴포넌트를 분리하고 상속하는 것이 바람직한데, 이것을 사람이 이해할 수 있는 한가지 개념, 단어로 치환하는 것이 어려울 때가 있다.

나는 그럴 때 분리했을 때의 효용(주로 재사용성)을 고려한다. 재사용되지 않고, 앞으로도 재사용할 지 알 수 없다면 일단 가독성 쪽의 손을 들어준다. 또 그렇게 하는 편이 오버 엔지니어링을 방지하는 데 좋기도 하다. 필요하면 그 때 리팩토링하면 되니까.

그러나 분리하고 상속했을 때 재사용하여 유지보수성에서 이득을 얻을 수 있다면 분리한다. 고심해서 이름을 짓기는 하는데 누군가 처음 보면 이상하다고 생각할 길고 해괴한 이름들은 보통 이렇게 만들어진다. 이를테면 오늘은 전에 작업한 것과 비슷한 요구사항에 대응하기 위해서 기존 컴포넌트를 리팩토링하여 "소수자리채우개" 컴포넌트를 분리하였다. 이름만 보면 저건 뭐하자고 만든 녀석인가 싶어서 어이가 없을 수도 있지만 수학식에서 소수를 정렬할 때 수학식의 종류와 해당 식에 적용된 스타일에 관계 없이 prop만 넣어주면 소수를 자릿수에 맞춰 정렬해 주는 유용한 녀석이다. 

공통된 것을 묶는 설계도 있지만, 개념이 다른 것을 떨어트려 놓는 설계도 있다. 상속이 그러하다. Typescript에서 optional prop을 갖는 대신 컴포넌트를 extend하는 것이 더 좋다는 글을 본 적이 있다. 그러나 필요에 의해 그렇게 extend하려고 보면 상속된 녀석의 이름을 짓는 것이 난감할 수도 있다. 예를 들면 그룹 간 정렬을 맞춘다는 특별한 요구를 충족시키는 "그룹정렬하는세로계산식" 이라는 컴포넌트를 만들게 될수도 있다는 소리다. 물론 아직 현재 요구사항이 저런 컴포넌트를 만들어야 할 정도는 아니라서 실제로 만들지는 않았다.