Skip to content
isdnetworks
Go back

여러 팀이 같이 쓰는 모듈

팀마다 curl_exec으로 외부 서비스를 부르는 코드를 각자 만들어 쓰고 있었다. 비슷한 것이 여러 벌 있으니 하나로 합치자는 이야기가 나왔고 그 일을 맡았다.

Table of contents

Open Table of contents

상황 — 며칠이면 끝난 코드 합치기

코드를 모아서 공통 부분을 뽑는 일 자체는 며칠이면 됐다. 그 뒤가 훨씬 길었다.

각 팀의 코드를 모아 diff를 떠 보니 겉보기에는 비슷한데 세부가 전부 달랐다. CURLOPT_TIMEOUT도 다르고 재시도 횟수도 다르고 curl_errno가 0이 아닐 때 하는 일도 달랐다.

세부가 달랐던 이유

이 차이를 어떻게 다룰지가 이 일의 핵심이었다. 하나로 통일하면 깔끔하지만 어느 팀에는 안 맞는 값이 된다.

그래서 각 팀에 왜 그 값인지를 물어봤다. 대부분은 이유가 있었고 그 팀의 사정에서 나온 값이었다. 다른 데는 대개 이유가 있다는 것을 물어보고 나서야 알았다.

외부가 바뀌면 같이 바뀌는 것만 합친다

무엇을 합치고 무엇을 남길지의 기준이 필요했다. 외부 서비스의 규격이 바뀌면 함께 바뀌어야 하는 것은 합친다.

그것은 어느 팀에서 부르든 같아야 하는 것이기 때문이다. 반대로 CURLOPT_TIMEOUT을 얼마로 줄지나 실패했을 때 무엇을 할지는 부르는 쪽의 사정이라 남긴다. 이 기준으로 가르니 합칠 것과 남길 것이 대부분 자동으로 정해졌다.

기본값을 정하는 기준

남기는 것들도 매번 지정하게 하면 번거로우니 기본값을 두어야 했다. 처음에는 가장 안전한 값을 기본으로 하려고 했다.

그런데 안전한 값은 대개 아무도 안 쓰는 값이라 틀렸을 때 알아채기 어렵다. 그래서 가장 흔한 경우에 맞추는 쪽으로 바꿨다. 그러면 대부분은 안 지정해도 되고 다른 값이 필요한 쪽만 지정하게 된다.

새것을 더한 뒤 옛것을 없앤다

여러 팀이 쓰는 코드는 고치기가 훨씬 어렵다. 누가 쓰는지를 모르면 바꿀 수도 없다.

그래서 바꿀 때는 먼저 grep으로 부르는 자리를 전부 찾고 새 방식을 더한 뒤에 옛 방식을 없애는 순서로 했다. 한꺼번에 바꾸면 어느 팀이 언제 깨질지 모른다. 전부를 합치는 것이 목표가 아니라 고칠 곳이 하나가 되게 하는 것이 목표였다.

정리


Share this post on:

Previous Post
케이스마다 붙어 있던 오프라인 짝
Next Post
만드는 쪽과 처리하는 쪽이 달랐다