기능 구현보다는 운용성과 유지보수성

비교적 최근의 이야기이다.

나는 여러 항목들과 그것들 간의 상호작용을 데이터베이스화하는 안건을 맡았다.

처음에는 그저 항목들 사이에 관계를 설명해주는 트랜잭션 테이블을 두면 되지 않을까? 완전 쉽쟈네카 어이~w 하는 안이한 스탠스로 영향조사를 실시했다.

허나 그것은 나의 생각을 아득히 뛰어넘는 강적이었다.

 

그것은 유구한 역사의 흐름을 자신의 몸으로 꿋꿋이 버텨왔다는 것을 자랑하듯이 항목 하나하나가 몇천 줄에 육박하는 JSP코드로 하드코딩 되어 있었다.

뿐만 아니라 동일한 항목이어도 대분류에 따라 열몇개로 나누어져 각기 다른 상호작용을 가지고 있었다는 것 또한 문제였다.

 

이 정도는 다이죠부다! 대분류에 대한 컬럼을 추가하면 되니까!

하지만 나의 행복회로가 완전히 식어버리기 까지는 그리 오랜 시간이 걸리지 않았다.

조건ー『 A and (B or C) 』。

그렇게 나의 몸은 산산이 부서졌다.

 

안건에 들어가기에 앞서 방향성을 잡는 데에 많은 시간을 낭비했기 때문에 빠른 해답을 이끌어내기 위해 금단의 마검 「 포도당 캔디ーTHE ラムネ 」의 힘을 빌렸고 이내 하나의 아이디어를 도출해 낼 수 있었다.

의존관계의 기준치를 정하고 조작이 이루어질 때 수치가 더해지거나 빼지는 식으로 대응하면 어떨까?

 

1. A OR B일 경우

• displayRef = 1
• optionA = 1, optionB = 1
• A와 B 중 어느 하나가 선택되면 플래그가 1 이상이 되어 표시
• 둘 다 해제되면 플래그가 0으로 되어 비표시

2. A AND B일 경우

• displayRef = 2
• optionA = 1, optionB = 1
• A와 B 중 어느 하나만 선택되면 플래그가 1이 되어 비표시인 채로 유지
• 둘 다 선택되면 플래그가 2가 되어 표시

3. A AND ( B OR C )와 같은 복잡한 연산의 경우

• displayRef = 101
• optionA = 100, optionB = 1, optionC = 1
• B와 C가 함께 선택되어도 플래그가 2가 되기 때문에 비표시인 채로 유지
• A를 선택하여 플래그를 100이상으로 올려주어야 한다.

당시에는 꽤 획기적인 아이디어라고 생각했었다.
나는 팀장님께 곧바로 달려가 기세등등하게 브리핑을 하였지만 적막만이 맴돌았다.

어째서...? 코노 와타쿠시의 아이디어에 흠이라도 있다는 것인가 크윽...

그렇게 어색한 침묵을 깨고 피드백이 날아왔고 끝내 납득할 수밖에 없었다.

모든 기능을 커버하는 설계도 물론 중요하다.
하지만 설계에 있어서 무엇보다도 중요한 것은
네가 이 세상을 떠나더라도 다른 사람들이 간단하게 활용할 수 있도록 하는 운용성과 유지보수성이다.

 

아아ー、그런 것인가。나의 완패로구나…

금단의 마검을 사용한 대가로 상호작용에 대한 건은 프론트엔드 쪽으로 이관되고 말았다.