2019-04-10 18:41:44 (2019-04-20 04:55:38)

통신부 함수를 만들 때마다 늘 하는 고민이 있다. 오늘 시작한 건 아니고 이미 결론도 내고 적용까지 끝낸 내용이지만 코드를 보다가 순간 왜 이렇게 만들었나 싶었다가 이유가 떠올라서 정리 차원에서 적는다.

 

나는 빈도수에 따라 함수를 만든다. 단발성으로 사용하면 어느 정도 길어도 그 자리에 쓰고 주석처리하고 끝내는 대신 두 번 이상 사용한다면 무조건 함수를 만드는 식이다. 이런 함수들이 유사한 경우 나는 가능하면 함수를 통합하는 편이다. 대개 파라미터 두세개로 구분할 수 있는 정도라면 합쳐놓고 있다.

 

늘 생각하지만 이런 기준에 따르면 통신부 함수는 너무나도 비슷한 요소가 많다. 동일한 서버에 동일한 정보로 페이지 주소나 파라미터만 조금 다른 통신을 보내면 데이터만 다른 동일한 형태의 응답을 받는 통신이니까 말이다. 요즘은 워낙 오픈소스가 잘 되어있어서 잡다하게 보완할 일이 잘 없지만 에러 처리를 하거나 다수 통신 공통 파라미터가 있거나 암복호화라도 한다면 아무리 해당 로직이 따로 있어도 각 통신마다 똑같은 처리를 하느니 하나로 합쳐놓는게 훨씬 낫다는 생각이 든다. 특히 대부분의 통신은 하나의 기능과 매칭되는 경우가 많기 때문에 통합해두지 않으면 굳이 함수로 분리할 필요가 있나 싶은 생각마저 든다.

 

지금까지 일하면서 봐 왔던 코드는 대부분 통신마다 별도의 함수를 가지고 있기는 했지만, 대부분은 응답 형식이 통일되어 있지 않기 때문이었다. 대개의 회사는 작은 회사에서 시작해서, 큰 회사는 또 큰 회사라 외부 업체를 쓰니까, 이런저런 이유로 체계 없이 여러 사람의 손을 타면 가장 먼저 중구난방이 되는 건 응답 형식이다. 시간이 지나고 누군가 손을 대서 서버를 정리한다 해도 이미 중구난방인 응답에 맞게 짜여진 코드를 갖고 있는 클라 개발자는 대부분 똑같은 코드를 복사해서 보수하고 끝난다. 이런 경우였다.

 

또는 서버가 여러개인 경우도 있다. 오픈 api를 직접 가져다 쓰거나 회사 서버가 예전 서버니 현재 서버니 복잡한 경우에 그런데 사실 아무리 많이 가져다 써도 하나의 클라에서 네다섯개 이상의 서버를 붙는 경우는 거의 보지 못했다. 또 그렇다해도 서버별로 공통 함수를 만들어주면 되니까 이건 상관없다고 본다. 사실 이 경우 함수가 분리되는 건 암복호화 방식이 다르거나 키가 달라서가 많아서 이쯤 되면 분리하는게 맞다 싶기도 하다. 어느 서버는 파라미터를 전체를 암호화하고 어느 서버는 일부 파라미터만 암호화하고 어느 서버는 GET으로 어느 서버는 POST로 어느 서버는 섞어서 이걸 함수 하나에서 맞추는 건 배보다 배꼽이 크다.

 

또 다른 이유가 있을 수도 있겠지만, 대부분 급하게 적당히 만들다보니 형식이 틀어지거나 또는 틀어질 것을 감안해서 분리하는 경우가 많았다. 서버 개발 역시 동시에 진행해야 하는 나와는 상관없는 이야기였다. 실제로 서버 개발을 처음 맡았을 때는 이런 이유로 통신 함수를 하나로 합치기도 했었다. 통신 구분자를 별도로 선언해주거나 주소 또는 파라미터 맵을 만드는 식으로 어디엔가 커스텀을 해주어야 했지만 똑같은 코드 그대로 복사해서 코드 라인을 늘리는 것보다는 낫다고 생각했다.

 

그런 내가 서버도 클라도 내가 다 만들어야 하는 이번 프로젝트는 분리하기로 했다. 이유는 간단하다. 분리해두는 편이 나중에 다시 보기 쉽기 때문이다. 이번 iOS 개발을 하면서 느낀 건, 아무리 간단한 코드라도 통합을 한다면 무조건 복잡도가 증가한다는 거다. 내가 이 언어를 잘 안다면 아무리 복잡해도 적당히 눌러보고 엄청 꼬아놨네 만드느라 힘들었겠다ㅎㅎ 하면 그만이지만 이번처럼 OS도 툴도 언어도 전부 어색한 상황에서는 약간의 복잡도 증가가 상상 이상으로 긴 시간의 개발 시간으로 이어지더라. 뭐, 나 혼자 계속 할 코드라면 복잡하고 말고 주석 달고 알아서 하겠거니 하고 치울텐데 장기적으로는 남에게 이관해 줄 코드라 가능하면 더 간단하게 짜려는 마음도 있었다.

 

사실 내가 긴 코드, 중복된 코드를 좋아하지 않아서 함수는 합쳐놓고 구분자 만들고 클래스는 상속하고 그래서 그렇지 개별 함수를 만들면 함수 이름부터 해당 기능에 대해서 명확하게 쓸 수 있고 조건문 분기 없이 각 기능에 꼭 필요한 처리만 추가할 수 있어서 편하기도 하다. 요즘 하드웨어 성능이 워낙 올라가서 크게 상관은 없겠지만 아주 미세하나마 실행 속도도 나아질 거다. 이러니 저러니 말해도 서버 통신부는 서버 매뉴얼이 없으면 이해하기 힘든데 서버를 정리하기에는 너무 긴 시간이 걸릴 것 같아서 기왕 인수인계해야하는 클라이언트, 가능하면 서버 매뉴얼 없이 같이 적당히 넘기려는 마음이 크다. 내가 만든 서버가 아니라서 잘 모르겠어서 정리하는 차원이기도 하고, 뭐 그렇다.

 

왜 이렇게 길어졌지.


번호 분류 제목 글쓴이 날짜
575 일반 친구란 좋은 거야 19/07/26 01:27
574 일반 격조했다 19/07/24 23:59
573 일반 윈도우 업데이트가 세상 거창하네 19/05/01 06:57
572 개발 갑자기 델리게이트 패턴을 이해하게 됐다 19/04/26 08:51
571 개발 이걸 어디에 적어놔야 기억을 할까 19/04/24 03:47
570 일반 사람은 바깥 바람도 쐬고 살아야 해 19/04/24 02:18
569 개발 드디어 코드 블럭을 제대로 쓸 수 있게 됐다 19/04/22 10:25
568 개발 아 진짜 재밌네 19/04/20 05:49
567 개발 점 표기법과 대괄호 표기법 19/04/19 02:52
566 개발 하 수학 공부를 좀 더 열심히 했어야 했어 19/04/15 16:07
개발 이번에는 통신부 함수를 분리하기로 했다 19/04/10 18:41
564 개발 알게 된 거 조금씩 적어야지 19/04/09 18:35
563 개발 진짜 별 걸 다 알게된다 19/04/09 17:32
562 개발 이게 최선인 걸까 싶다 19/04/08 16:35
561 개발 가끔은 재부팅도 필요하다고 한다 19/04/05 14:06
560 일반 사람은 바쁘게 지내야 하나 봐 19/03/26 15:09
559 일반 영웅 넘버는 언제 들어도 참 좋다 19/03/24 01:53
558 기록 나는 어떤 사람이 되어야 할까 19/03/23 02:37
557 기록 우울하다 말하기 전에 몸이 아픈 건 아닌가 생각해보자 19/03/21 02:17
556 일반 눈이 오고 있어요 여러분 19/03/15 19:17