팀마다 curl_exec으로 외부 서비스를 부르는 코드를 각자 만들어 쓰고 있었다. 비슷한 것이 여러 벌 있으니 하나로 합치자는 이야기가 나왔고 그 일을 맡았다.
Table of contents
Open Table of contents
상황 — 며칠이면 끝난 코드 합치기
코드를 모아서 공통 부분을 뽑는 일 자체는 며칠이면 됐다. 그 뒤가 훨씬 길었다.
각 팀의 코드를 모아 diff를 떠 보니 겉보기에는 비슷한데 세부가 전부 달랐다. CURLOPT_TIMEOUT도 다르고 재시도 횟수도 다르고 curl_errno가 0이 아닐 때 하는 일도 달랐다.
세부가 달랐던 이유
이 차이를 어떻게 다룰지가 이 일의 핵심이었다. 하나로 통일하면 깔끔하지만 어느 팀에는 안 맞는 값이 된다.
그래서 각 팀에 왜 그 값인지를 물어봤다. 대부분은 이유가 있었고 그 팀의 사정에서 나온 값이었다. 다른 데는 대개 이유가 있다는 것을 물어보고 나서야 알았다.
외부가 바뀌면 같이 바뀌는 것만 합친다
무엇을 합치고 무엇을 남길지의 기준이 필요했다. 외부 서비스의 규격이 바뀌면 함께 바뀌어야 하는 것은 합친다.
그것은 어느 팀에서 부르든 같아야 하는 것이기 때문이다. 반대로 CURLOPT_TIMEOUT을 얼마로 줄지나 실패했을 때 무엇을 할지는 부르는 쪽의 사정이라 남긴다. 이 기준으로 가르니 합칠 것과 남길 것이 대부분 자동으로 정해졌다.
기본값을 정하는 기준
남기는 것들도 매번 지정하게 하면 번거로우니 기본값을 두어야 했다. 처음에는 가장 안전한 값을 기본으로 하려고 했다.
그런데 안전한 값은 대개 아무도 안 쓰는 값이라 틀렸을 때 알아채기 어렵다. 그래서 가장 흔한 경우에 맞추는 쪽으로 바꿨다. 그러면 대부분은 안 지정해도 되고 다른 값이 필요한 쪽만 지정하게 된다.
새것을 더한 뒤 옛것을 없앤다
여러 팀이 쓰는 코드는 고치기가 훨씬 어렵다. 누가 쓰는지를 모르면 바꿀 수도 없다.
그래서 바꿀 때는 먼저 grep으로 부르는 자리를 전부 찾고 새 방식을 더한 뒤에 옛 방식을 없애는 순서로 했다. 한꺼번에 바꾸면 어느 팀이 언제 깨질지 모른다. 전부를 합치는 것이 목표가 아니라 고칠 곳이 하나가 되게 하는 것이 목표였다.
정리
- 비슷해 보이는 코드도
diff를 떠 보면 세부가 다르다 - 다른 데는 대개 이유가 있으므로 먼저 물어본다
- 외부가 바뀌면 같이 바뀌는 것은 합친다
CURLOPT_TIMEOUT처럼 부르는 쪽 사정에서 나온 것은 남긴다- 기본값은 가장 안전한 값이 아니라 가장 흔한 경우에 맞춘다
- 안전한 값은 아무도 안 써서 틀렸을 때 늦게 안다
grep으로 누가 쓰는지 먼저 찾고 새것을 더한 뒤 옛것을 없앤다- 전부 합치는 것이 아니라 고칠 곳이 하나가 되는 것이 목표다