코드 작성 시에 주석은 무척 중요하다. 다른 사람 기준은 어떤지 모르겠지만 내가 상각하는 코드 주석은 크게 봐서 2가지로 나눌 수 있다. 메소드, 클래스, 파일 등 코드의 집합에 대한 설명 코드 집합 내부에서 코드 중간에 나타나는 주석 메소드, 클래스 등의 주석은 예를 들어 JavaDoc 형태로 이 메소드와 클래스를 사용하는 다른 개발자들의 이해를 돕기 위해 당연히 적어야 한다. 논란이 되는건 두 번째 주석이다. 개인적으로는 그냥 참고할 만한 책 정도인 클린 코드에서도 주석에 대해 언급한 구절이 있다....
얼마전에 MDN 번역 레포에 기여한 PR이 대충 200개가 되었다. 정확한 수치는 모르지만 느낌상 기존에 번역 안됐던 문서는 대충 200개 이상, 그 만한 숫자의 문서를 최신화했을 것이다. 2021년 5월 12일에 올린 첫 PR은 사소했다. JavaScript 함수의 기본 매개변수에 대한 설명이었는데, 띄어쓰기와 사소한 태그 변경 정도였다. 원래 내 블로그 혹은 사이트에다가 별도의 JavaScript 레퍼런스를 만드려고 했었는데, 어찌되었건 첫 MDN 기여를 계기로 방향을 바꿨다. 내 사이트에 나만의 정보를 적기보다는 모두가 유지보수해나가는 MDN에 기여하는게 사회적으로 가치있는 일이라 생각했고, 그 생각은 지금도 유효하다....
오늘 팀원 한 명이 면담을 신청해서 이런저런 얘기를 나눴는데, 어쩌다보니 이직으로 주제가 옮겨갔다. 팀원이 지금보다 더 좋은 곳으로 간다면 축하의 박수와 함께 보낼 수 있을 정도로 이직 자체를 나쁘게 생각하지 않는데, 문제는 그 시기였다. 그 팀원은 한 회사에서 3년은 너무 길다고 생각하고 있었다. 면담 자리에서 생각나지 않아서 말은 못했지만, 나중에 그 의견을 곱씹어보니 과거에 읽었던 글이 생각난다. Full Cycle Developers at Netflix이라는 글이다. (번역본은 여기) 넷플릭스 기술 블로그에서는 2018년에 공개한 글이지만, 이 글은 2021년에 접했다....
CTO 3년차. 급하게 쓴 2022년 회고. 작은 기업의 CTO는 Chief of Technology Officer가 아니라 Chief of Troubleshooting Officer라는 우스개소리가 있다. 하지만 적어도 올 한해 나로서는 우스개소리가 아니었다. 올 한해는 CTO가 된 이후 업무적으로나 업무 외적으로나 가장 힘든 한 해였다. 풀필먼트 업무가 본궤도에 오르면서 반드시 처리해야할 일은 많아지는 한편 심각한 개발 리소스 부족에 직면하게 되었다. 직접 API개발, 코드리뷰 등 직접 개발의 최전선에 있긴 하지만 이 때는 개발 리소스가 너무 없어서 군단장(장군)이 직접 참호에 들어가서 밀려드는 이슈에 대고 총을 쏘아야 했다....
회사가 점점 커지고 개발팀이 점점 커지면서 미뤄두었던 숙제를 하나씩 꺼내어 처리하고 있는데 그 중 하나는 바로 이메일 전송방식 개선이다. 지금은 파트너 혹은 고객에게 이메일을 보낼 일이 있다면 API에서 직접 노드 메일러로 메일을 보내고 있었는데 사실 이렇게 하면 API의 처리량이 떨어지기 때문에 하면 안되는 안티패턴이다. 여태까지는 그렇게 요청이 많지 않았고 별 무리가 없어서 일단 나중에 해야겠다고 미뤄뒀었는데, 드디어 꺼내어 처리할 수 있게 되었다. 이메일 전송은 사실 별도의 Queue에 던져놓고 Worker가 Queue에서 빼서 보내는 방식으로 처리하는게 제일 좋은 방법이다....