개발책에 나오는 것 처럼 통제된 환경에서 핵심만 가지고 코드를 작성할 수 없지 실전에서는.

간단하게 소켓통신으로 예를 들면
이론으로는 그냥 소켓 커넥트해서 문자열 몇개 띠리릭 보내고 받는 쪽에서는 그거 그냥 받아서 화면에 뿌리면 돼.

근데 이게 실제 프로덕션 코드가 되면 중간에 커넥션이 끊겼을 경우에 대한 예외처리, 통신이 빈번하다면 커넥션 풀 사용도 고려를 해야되고, 성능을 위해서 멀티 플렉싱 혹은 멀티 스레딩을 고려해야 되고, 효율적으로 프로토콜을 짜되, 추후에 있을 변화에 대비해서 확장성에되 신경을 써야돼. 주고 받는 서버-클라이언트 환경이 다른 경우에 바이트 오더링도 신경을 써줘야되고, 한글을 주고받는 경우에는 인코딩도 맞춰야되지. 거기다가 중간에 프로토콜이 바뀌는 경우엔 하위호완을 얼마나 가져갈 것인지에 대한 고민도 해야하고. 멀티 스레딩으로 데이터를 받았으면 데이터를 쌓는 곳에서 데드락이 걸리지 않는 것도 신경을 써야되고, 중간 버퍼가 필요하다면 내부 큐 사용이나 혹은 메시징 큐 사용도 고려해야되고, 생각만큼 tps가 안나오면 성능 최적화도 들어가야되고, 세세하게 신경써야할 부분이 정말 많아.

특히 백엔드 쪽이면.

그래서 이 모든 사항들을 전부 커버해가면서 코드를 짜면 코드가 금방 누더기가 되버려. 코드가 누더기여도 돌아가기만 하면 장땡 아니냐고 하는 사람도 있을지 모르겠는데, 최소한 개발을 업으로 삼고있는 사람이면 자기 코드에 대한 부끄러움을 느낄 줄 알아야 한다고 생각해. 특히 혼자짜는 코드가 아니라 팀에서 협업을 해야하고, 잠깐 테스트코드 짜는게 아니라 롱런해야하는 코드를 작성하는 거라면 가독성있고 파악하기 쉬운 구조를 택해야겠지.

이렇게 누더기 코드에서 보다 나은 코드로 만드는 요령들은 사실 어느정도 경험이 있는 개발자라면 몸으로 체득을 하고 있어. if문에 얼마나 중첩되면 보기 거슬리믄지, 어느 단위에서 함수로 끊어야하는지, 중복코드를 최소화 한다던지. 이런 작업들이 전부 궁극적으로는 클린코드를 지향하는 작업듯이라고 생각해.

근데 그냥 자연스레 체득한 기술들만 가지고 있으면 안되고 더 배워야지.
디자인 패턴같은 것들을 별로 안좋아하는 개발자들도 잇긴한데,
디자인패턴이란게 개발자들이 공통적으로 코드 누더기들을 가지고 어떻게 깔끔하게 뽑아낼 수 있을까 고민하면서 많은 사람들에 의해서 정리된 패턴들이라, 배워두면 절대로 도움이 될 수 밖에 없어.

내 개인적인 경험담을 쓰자면,
회사 내 레거시 코드가 있었고 이 코드는 오라클 디비랑 커플링이 심했단말야. 그래서 가장 심각했던건 표준 sql이 아닌 오라클 디비 문법, 오라클 디비 함수들이 수도 없이 많이 사용된 코든데,
이 코드를 mysql 에서도 돌게 하라는 태스크가 떨어졌어.
환장할 노릇이지.
제일 쉬운 해결책은 모든 쿼리가 있는 코드들마다 찾아가서 if로 분기태우고 mysql용 쿼리를 붙어넣는건데 그렇게 하기엔 양도 너무 많았고 그걸 다 테스트 할 시간도 없었어.

사실 애초에 이 코드에 orm을 적용했다면 이런 불상사도 없이 바로 mysql로 붙일 수 있었을텐데 이 레거시는 내 선임자의 선임자부터 타고내려온 오래되고 덩치큰 코드고 그걸 통째로 뜯어고친다는건 불가능했어.

이 문제에 대해서 나는 런타임상에서 오라클 쿼리를 표준 sql 쿼리로 변환하려는 계획을 세우고 쿼리 파서를 붙였어. 근데 다들 알다시피 쿼리란게 무한히 많은 형태를 가질 수 잇잖아. 단순한 select 쿼리부터 조인 붙인 쿼리, union 붙인 쿼리, 거기다가 where 조건이 어떻게 붙을지도 모르니까.


디자인 패턴중에 visitor 패턴이라고 있어. 자세한 설명을 여기서 하기는 힘들고, 그 패턴을 적용한 덕분에 파싱된 쿼리의 부분 부분마나 visitor로 재귀함수 쓰듯이 방문해 들어가서 가장 작은 부분에 대해서 오라클 쿼리를 표준 sql 로 변환할 수 잇도록 코드를 짰어.

변환해야하는 케이스들을 수집하고 실제로 코드를 작성하고 테스트까지 마친게 일주일이 채 안돼. 이걸 쌩 노가다로 하나하나 다 바꿔줬으면 세달도 모자랐겠지.

디자인패턴은 어려운 문제를 쉽게 풀 수 있는 수학 공식같은거야. 디자인 패턴같은건 필요없다고 하는 사람은 어쩌면 그 디자인 패턴들을 다 통달한 사람일지도 모르고 혹은 공식을 적용해야 할 만큼 어려운 문제를 만나보지 못한 사람일수도 있어.

경험상 후자가 많아.

- dc official App