@VisibleForTesting을 활용에 대한 단상

간만에 개발에 대한 글을 써본다. 코드를 잠깐 봐볼까 싶다가 @VisibleForTesting이라는 Annotation을 봤다. 사실 처음보는 Annotation이라 뭐하는 놈인가 싶은 생각이 들어서 찾아봤다. Package com.google.common.annotations Annotation Type VisibleForTesting   @GwtCompatible public @interface VisibleForTesting Annotates a program element that exists, or is more widely visible than otherwise necessary, only for use in test code.Do not use this interface for public …

Continue reading ‘@VisibleForTesting을 활용에 대한 단상’ »

Tech vs. NonTech

조직에서 리더의 역할은 중요하다. 그리고 조직의 규모에 따라 리더의 중요성 역시 비례한다. 대기업의 경우 최상위 리더가 누구냐, 어떤 방향성을 가지느냐가 큰 영향력을 갖는다. 최상위 리더의 방향성을 중간 리더들이 어떻게 해석해서 실행하기 때문이다. 그러나 최상위 리더가 좋은 의도로 방향을 잡아도, 이를 실행하는 중간 리더들의 해석이 잘못되면 좋은 의도가 안좋은(개인적인 생각에 최악인) 결과가 만들어지기도 한다. 더러 이 …

Continue reading ‘Tech vs. NonTech’ »

단축키

코딩을 할려고 마음먹을 때마다 처음 하는 일이 있다. 내가 사용하게 될 IDE에서 제공하는 단축키(Shortcut) 외우기. 다시 코딩을 시작하자 마음먹었던 네이버 입사 첫시절에도 그랬고, 라이엇 입사 초기에도 마찬가지였다. 이쁘게 정리된 단축키 목록을 모니터 옆에 붙혀뒀다. 이렇게 보면 아재 감성 충만하다. 나중에 알게됐지만 “Cmd + ?” 키가 단축키 목록이었다는… 일주일 정도는 지하철 출퇴근 길에 진심으로 외웠다. 필요하면 …

Continue reading ‘단축키’ »

Q&A: Architecture and Architect

3월에 모 부트캠프 참가자들을 대상으로 “S/W 아키텍처(Architecture)“에 대한 특강을 진행했다. 강의 이후에 이런 저런 질문들이 있었다. 질문들이 과정에 참가한 분들만 궁금해하는 사항들이 아닐 것 같아서, 정리해서 기록으로 남겨볼려고 한다. 원하시는 인재상, 어떤 개발자를 원하시는지 궁금합니다. 이야기를 개발을 리드하는 입장에서, 특히 쏘카의 개발 방향 관점에서 이야기했기 때문에 자연스럽게 이 질문에 가장 관심이 많았던 것 같다. 사실 …

Continue reading ‘Q&A: Architecture and Architect’ »

Test is always right.

Coding을 하면서 많은 것들을 고민하지만, 테스트만큼 고민스러운 것도 없다. 논리적으로 도움되고, 유지보수를 위해서라도 반드시 필요하다. 하지만 빨리 만들어서, 고쳐서 내보내야 한다는 심리적인 압박감이 강해지다보니 넘어가자. 바쁜데… 라는 합리성을 부여해버린다. 그래놓고 장애나면 급 후회를 하긴 하지. 언제나 그렇지만, 코딩/개발 단계의 시간보다 장애 대응하면서 보내는 시간이 훨씬 길다. 개발자의 입장에서 테스트는 반드시 필요하니 꼭 작성해두길 바란다. 한번 쓰고 …

Continue reading ‘Test is always right.’ »

CRA(create-react-app)에서 IE 지원하기

한국에서 인터넷 서비스는 IE 지원이 없으면 말도 안되는 이야기다. 적어도 작년까지는 확실히 그랬던 것 같다. 그랬을거야… 새로운 Frontend Application을 개발할 일이 있어서, CRA 프로젝를 생성했다. 별 생각없이 열심히 개발했다. 얼추 개발을 마무리해서 QA분들께 검증을 부탁했더니 IE에서 아예 동작을 안한다는… 응 뭐지? 개발 모드에서는 당연히 IE가지고 개발하는 frontend 개발자는 없으니까 그럴 수 있다고 치자. 그래도 IE11 …

Continue reading ‘CRA(create-react-app)에서 IE 지원하기’ »

휴면 계정 처리 – 배치에서 온라인 시스템으로

배치(Batch)라는 작업은 주기적으로 실행되는 작업을 말한다. 다루는 데이터가 적은 경우는 별 걱정이 없다. 하지만 다룰 데이터가 많다면 과연 이 작업이 정해진 시간안에 끝날지 걱정하게 된다. 배치 작업은 대량의 데이터에 대한 문제도 있지만, 한 주기안에 그 일이 끝나야한다는 시간적인 제약도 존재하는 문제기도 하다. 서비스와 이를 뒷받침하는 시스템은 계속 진화한다. 그리고 데이터와 시간에 대한 최적화도 진화에 맞춰 …

Continue reading ‘휴면 계정 처리 – 배치에서 온라인 시스템으로’ »

좋은 코드에 대한 생각 – 3: 작업에 대한 기록

개발이라는 건 기록의 작업이다. 코드 한줄을 작성하더라도 이유없는 코드가 없다. 이런 이유로 코드를 작성할 때 그 근거를 기록으로 남길려고 하고 권장한다. 당신은 어떤 방식으로 기록하고 있나? Jira와 같은 티켓 관리 시스템을 이용할 수도 있겠고, 혹은 Confluence에 일지를 쓸수도 있겠다. 하지만 당신이 개발자라면 이 문제를 개발자스럽게 풀고 있을 것이라고 생각한다. 코멘트? 가장 흔하게 생각할 수 있는 …

Continue reading ‘좋은 코드에 대한 생각 – 3: 작업에 대한 기록’ »

변수명으로 Readability 높이기?

코드 리뷰를 하다보면 약간 복잡한 expression 혹은 statement의 결과를 변수로 치환한 다음에 아래에서는 그 변수를 사용하는 경우가 있다.  변수의 값 참조가 여러번 이뤄지면 문제가 아니지만 갸우뚱하게 되는 케이스는 한번만 사용하는 경우다.  대부분의 자동화 분석 도구는 이런 경우에 대해 고치라는 처방전을 준다.  하지만 나는 기계가 아니라 사람이고 사람이 보기에 복잡해보이는 걸 두는 것보다는 “변수가 의미를 설명해주는데 …

Continue reading ‘변수명으로 Readability 높이기?’ »

좋은 코드에 대한 개인적인 생각 – 2

개발자는 코드를 작성해야한다.  그리고 코드들이 엮이고 엮여 시스템이 만들어진다.  시스템은 필요를 요청한 사용자에게 기능을 제공한다.  물론 시스템을 구성하기 위해 필요한 노력을 개발자만 하는 건 아니다.  인프라 엔지니어는 장비와 네트워크를 준비하고, 데이터베이스 엔지니어는 데이터를 보관할 수 있는 저장소를 준비한다.  최근에는 Data Scientist가 데이터를 분석하고 빅데이터 도구를 통해 적절한 값들을 생성해낸다. 이외에도 다양한 노력들이 합쳐져 시스템이 만들어진다. …

Continue reading ‘좋은 코드에 대한 개인적인 생각 – 2’ »