단점 고치기

이직 한지 대략 한달쯤 됐군요.

입사하고 나서 느낀 가장 아이러니 한 것은, 오픈이 얼마 남지 않은 프로젝트인데도, 검증이나 테스트가 의외로 안되어 있더라는 점이죠.

유닛 테스트 자체는 적지 않지만 그 커버리지가 높다고 하기 어려운 상황이고요.

전반적인 자동화를 통한 커버리지를 올리는 작업을 주로 하고 있습니다. 계측/측정에 대한 업무 위주랄까요.

트러블 슈터로써 문제가 발생할 여지를 검토하고, 또 테스트를 통해 검증하는 작업을 맡게 됐다고 보시면 될거 같네요. (물론 조만간 컨텐츠 작업도 하게 되지 않을까…싶네요. 자동화를 통한 커버리지를 올리는 목표를 달성하고 나면 말이죠)

하다보면…이 일도 나름 재밌습니다. 안정적인 서비스를 해냈다는게 서버 개발자로써 뿌듯하게 생각해야 될 목표지점 중 하나니까요. (디아3 반성하라!!)

원래 성격 자체가 덜렁대는 데다가, 성격도 급하다보니 사고뭉치였던 저로썬 제가 트러블 슈터적인 성향의 개발자가 될꺼라곤 사실 상상하기 어려웠습니다.

저 역시도 다른 많은 분들처럼 열혈 게이머였으며, 아마추어 게임 개발자 출신으로써 그저 재미난 게임을 만들고 싶었던 사람일뿐이었습니다.

뭐 아마추어 게임 개발자이긴 했다보니 비정규직 개발 작업 (툴 외주 및 소규모 게임) 에 여럿 참여하다보니 아예 경험이 없는 개발자는 아니였죠.

뭐…어찌어찌 하다보니 휴학 없이 졸업을 하게 됐고, 군대 가기전 돈좀 모아놓고 가려고 1년정도 일할 곳을 찾던중 감사하게도 병역특례를 주신다는 회사에 입사하게 됐습니다.

그 조건은 서버로 전직…!!! 전직후 버라이어티한 사고들을 잔뜩 치고나니…. 아 내가 이런 실력으론 회사에도 민폐, 내 자신에게도 부끄럽고, 유저분들에게도 민폐겠구나 싶었습니다.

그래서 어떻게하면 사고를 많이 안치는 개발자가 될 수 있을까에 대한 고민이 많아졌고, 만약 실수를 하게 되도 빨리 해결하려는 노력이 생활화됐죠.

제가 가장 집중한 부분은, “나처럼 덜렁대는 사람이라도 사고치지 않기 위한 방법이 무엇이 있을까?” 였습니다.

그 과정에서 얻은 결론에 대한 즉흥적인 정리입니다.

  1. 커버리지를 높이는 것만이 살길이다.

당연히 자동화! 유닛 테스트는 커버리지의 일부일뿐.

유닛 테스트를 이용하면 그 기능의 개별 동작에 대한 검증은 이뤄지는데. 하지만 그 기능들이 맞물려 돌아가며 상호작용에 대한 부분을 검증하는 것은 어렵죠. 유닛 테스트는 당연히 필요하지만, 런타임 테스트도 반드시 필요합니다!

보통 서버의 경우는 이를 위한 테스트 클라이언트 구현이 이루어지는 경우가 많고, 테스트 클라이언트를 통해 자동화된 스트레스 테스트, 기능 테스트를 하면 됩니다.

  1. 적어도 알고 있는 부분에서 실수한건 잘 핸들링하자 꽤나 많은 실수…이 로직에서 실패하면 밑에 로직들은 엉망이 될걸 알면서 왜 핸들링 안하나요?? 리턴 값 없는 함수라면 throw를 통해서라도 1차 감염에서 바로 코드 흐름을 멈춰야합니다… 만약 아직도 예외처리 안하고 있다면 그거부터 하고!

예외처리가 잘되어있다면 throw랑 RaiseException의 적절한 활용은 코드 흐름을 catch한 상위 지점까지 코드 흐름을 옮길 수 있습니다. 

proactor등으로 비동기 작업을 던져놓은 경우에도, 적정위치를 try-catch로 감싸두면 코드 흐름 제어에 장점이 많아요.

  1. 자신을 믿지마라 도대체 얼마나 잘하길래 자기 코드에 테스트도 한줄 없고, 검사 로직도 한줄 없을까? 자신이 실력이 좋다해도 다른 사람이 쉽게 망가뜨리기 쉬운 코드 짜지말아야 합니다. 코드만으로 의도를 전달하는 건 굉장히 뛰어난 실력입니다.

const랑 접근 지정자만 잘써도 의도 파악이 쉬워집니다.

주석 달려있는 코드 고칠때는 주석도 고치고! (은근히 많은 코드가 변경시 코드만 고쳐져있고,주석이 수정안되서 두 내용이 다르면 크게 혼동이 오고, 코드를 훨씬 오래봐야되요. 주석 고치기 귀찮으면 지우기라도 합시다)

  1. 많이 짜봐라 누가 그러더군요… 3년차 넘어가면 코드 짜는거보다 설계가 많아진다고. 

하지만 제 생각엔 많이 짜고, 많이 지워버리는게 더 많이 늘고 더 좋은 결과물이 나온다고 생각합니다. 

생각한 대로 많이 돌려보고 마음에 들지 않으면 버리면 되는거에요. (은근히 한번 작성한 코드 아까워하는 사람 많은데 그러지 맙시다. 프로토타이핑은 어디까지나 프로토타이핑!).

run and fix를 통해 배우는게 많습니다. 코드를 읽기만할때랑 작성해보면 그 격차가 꽤나 큽니다.

TDD도 run and fix에 기반한거고 봐도 되요. 코드를 작성하는 과정에 수정이 함께 하니까요.

많이 짜고 지우고 유닛 테스트와 함께 코드의 커버리지를 높인다면 충분히 검증된 코드를 많이 짜고, 버려야 될 코드를 깨닳을 수 있습니다. (유닛테스트로 각이 안나오는 코드가 작성되는 경우가 종종있는데 이런 코드는 미련없이 버립시다)

  1. 책임감 갖고 일하자… 전 항상 예전에 제가 작성했던 코드와, 그 습관… 아마추어 시절과 클라이언트 프로그래머 시절의 마인드를 한심하다 생각합니다.

제가 짠 코드가 정상적인 상황에만 잘돌아가는 나약한 코드였던게 말이죠.

헌데 예전의 저처럼, 많은 개발자들이 자기 코드를 다방면으로 보지 못하더군요.

그런 방어적인 코딩 하는 사람들에겐 아무리 말해도 못알아듣겠지만… 남의 코드를 보는것 만큼, 자기 코드를 자주 들여다 보는 것도 꽤나 좋습니다.

어제 짠 코드 오늘보면 허접하다면, 오늘 다시 맘에 들게 고치면 됩니다.

refactoring 능력도 하는 만큼 늘더군요.

책임감 갖고 작성한 코드만큼 자기 실력을 늘려주는게 없다고 생각합니다.

당장 서비스에 들어갈 코드 아니라고 대충 짜지 맙시다.

특히 굳이 사용하지 않는 코드 언젠가 쓸꺼라 예상하고 만들어놓고, 유닛테스트도 안붙이고 그러지 맙시다. 

기능이 작성되어있으면 잘 동작할거라 믿고 쓰게 되는게 일반적이라구요.

이정도로 하겠습니다. 

저도 아직 갈길이 먼 개발자지만… 라이브 경험이 부족한 분들의 코드에선 느껴지는게 많습니다. 

뭐랄까… 유지보수하기 쉬운 코드란걸 원한다고 말은 하면서, 막상 다른 사람 코드나 자신이 짰던 코드를 들여다보며 느낀 불편함이 개선되지 않고, 습관대로 작성하시는 느낌?

팀작업이잖아요. 안좋은 습관은 함께 고쳐나갑시다.

새 회사를 한달쯤 다녔지만 아직 사람들도 낯설고 어색해서…아직 뭐 딱히 재밌게 다니고 있진 않습니다.

워낙에 바쁜시기인 것도 있을테고, 전에 다녔던 회사들에서 동료들과 친밀한 사이였던게 그리워서… ㅠ_ㅠ 

재입사 하는 사람들 마음이 이해가 간다는…

그래도 조금씩 친해져서 나름 재밌게 다니려 노력중이에요~

솔직히 이 곳을 얼마나 오래 다니게 될지 확신은 못하겠습니다만… 좋은회사인건 확실하다고 생각해요.

최소한 목표한바가 명확하고 그에 대한 의지는 있으십니다. (안되어 있는 것들은 여러가지 여건 등으로 인해 못해오셨던거란 느낌?)

저도 그에 힘을 보태고 싶고, 좋은 결과 이루고 싶네요.

Comments

comments powered by Disqus