개발일지
-
어쩌다 DDD 공부를 시작했다개발일지 2019. 3. 25. 00:24
주말 동안 를 공부하고, Apache Kafka와 AWS Kinesis에 대해서 조금 기술조사를 했다.아직 어렵기만 하지만 곧 판단의 기준이 설 거라고 생각하고! 열심히 공부하고 있다. 오늘은 DDD를 공부하게 된 계기에 대해서 생각이 나 적어보려고 한다. 어쩌다 만난 DDD팀 내 테크 리더님의 추천으로 DDD를 조금씩 공부하고 있다.DDD를 공부하게 된 계기는 따로 있었는데... 현재 우리가 만드는 서비스는 각 도메인별로 모듈화한 상태로 개발되고 있다.즉 계정, 인증, 통계 등의 문제 영역 별로 별도의 모듈 안에서 개발되고, 별도의 DB를 사용한다.배포도 모듈 단위로, 서로 분리된 EC2 Auto Scaling Group를 통해 이루어진다. -- 여기서부터 설명 어설픔 주의 -- 이렇게 하면 문제 영역..
-
회사에 와서 보이는 지식이 있다개발일지 2019. 1. 24. 02:04
얼마 전에 기술 배우는 타이밍이 있다는 내용의 글을 쓴 적이 있는데, 그 내용의 연장선상에서 이 글을 쓰게 될 것 같다. 기술 배우는 타이밍에는 외부 환경이 큰 영향을 미친다.이 때문에 학생 때 중요하게 느껴지는 지식과 회사에 와서 중요하게 느껴지는 지식이 많이 달라지는 것 같다. 특히나 회사에서 일하지 않았다면 그 가치를 체감하기 어려운 지식들이 있다.오늘은 이런 지식들에 대해서 생각나는 대로 언급해 보려고 한다. 밖에서 안 보이는 것들이 있다지금 다니는 회사에서는 운영 경험이 없는 상황에서 새로운 서비스를 만드는 (천재일우의) 기회를 얻었지만,반대로 기존 서비스에 대한 운영 경험이 없다보니 자꾸 놓치는 부분이 생기곤 한다. 가령 로그 분석은 지금도 프로세스가 머릿속에 명확하게 서지 않는 부분 중 하나..
-
미안해하지 않을 방법개발일지 2019. 1. 18. 23:02
오늘 클라이언트 개발자분이 나에게 미안하다고 말씀하시는 일이 있었다."아녜요 전혀, 괜찮습니다"라고 말했지만, 이후에도 여러가지 생각을 하게 되는 말이었다. 어쩌면 일하는 사람에게는 "아녜요 괜찮습니다"라는 대답이 불충분한 것은 아닐까? 괜찮아 보였지만 아니었다클라이언트 개발자분들이 본격적으로 작업을 시작하면서 매일매일 API 스펙에 대한 수정 요청을 받고 있다. 개별 API에 대해서 이를 전적으로 사용하는 클라이언트 개발자분에게 피드백을 받다 보니점차 불명확한 부분이 명확해지고 있고, 적어도 필드 구성은 정착된 느낌이 있는 것 같다.서버 개발자들도 (아직 이견은 있지만) 논의 과정에 대해서는 어느 정도 공유를 하고 있는 상황인 듯하다. 그런데 오늘은 클라이언트 개발자분의 뜻에 따라 예전에 주셨던 피드백..
-
일에서 배우고 기록한다개발일지 2019. 1. 18. 00:53
업무를 마치고 나서 매일매일 글을 쓰는 것은 쉽지 않다.그제는 1시 반, 어제는 2시에 글을 올리고 잤었다. 수면 부채가 쌓이고 있다... 정기적으로 글을 쓰는 것도 처음인데, 매일 글을 쓰겠다고 다짐하고 나니 무언가 희생해야 하는 것들이 있다는 걸 알게 됐다.가장 먼저 희생되는 것은 글의 퀄리티고(!) 최근에는 잔업이 많아지면서 여유 시간이나 공부 시간도 희생되기 시작했다. 그래서 엊그제는 이런 생각을 하기도 했다. 글 쓸 시간에 차라리 개발서 한 챕터를 더 읽으면, 내일 API 설계를 더 잘할 수 있지 않을까? 업무에서 배우는 것들이 있다분명 지금은 하나의 글을 쓰기 위해서 하루에 1~2시간을 투자하고 있고,이는 웬만한 개발서 한 챕터를 읽거나, 페이스북 RSS 등에서 좋은 글 4~5개를 훑어볼 수 ..
-
작명이 코드가 된다개발일지 2019. 1. 17. 01:52
사내 스터디의 일환으로 작년 10월부터 를 읽고 정리하고 느낀 점을 써 왔었다.그리고 어제 드디어 13장 동시성을 정리했다. 14장부터는 코드를 직접 살펴보기 때문에, 직접 정리할 수 있는 부분은 여기까지일 것 같다.오늘은 한바탕 책을 읽은 기념으로 에 관한 내용을 조금 언급하려고 한다. 에서 가장 재밌는 부분 중 하나는 책의 순서다.이 책은 가장 중요한 내용을 처음에 언급하는 경향이 있기 때문이다. 1장의 제목은 '깨끗한 코드' 그 자체다. 나쁜 코드가 발생시키는 비용을 언급하고,코드를 대하는 전문 개발자의 자세는 어떠해야 하는지 짚고 넘어가는 장이다. 그러면 2장의 제목은 뭘까? 작명이 코드가 된다바로 '의미 있는 이름'이다. '클래스'도 '시스템'도 '단위 테스트'도 아니다. (이것들은 9장에 이르..
-
기술 배우는 타이밍개발일지 2019. 1. 16. 01:46
잔업이랑 공부하면서 자정이 넘어갔다.매일 글 쓰는 게 쉬운 일은 아니라고 생각했지만... 😓 최근에는 API 개발 전 Mock 데이터를 만들면서 일을 어떻게 하면 편하게 할 수 있을지 생각하고 있다.오늘보다 내일 더 효율적으로 일하기 위해 하는 공부들.셸 스크립트나 json schema나 git 같은 것들을 예로 들 수 있겠다.기술마다 배우는 계기가 다르다생각해 보면 답답해서 공부하게 되는 기술들이 있다.vi 명령어는 잘 모르지만 dd(한 줄 삭제), o(커서 바로 아랫줄에 삽입)는 안 쓰면 하도 불편해서 외웠다든지.Mock 데이터에 필요한 파일 메타데이터를 손으로 만들다가 답답해서 셸 스크립트를 배웠다든지.JSON 데이터를 일일이 손으로 고치다가 답답해서 JSON Schema를 사용하게 됐다든지... ..
-
요약으로 시작하면 어떨까개발일지 2019. 1. 14. 23:07
실 서비스의 코드는 복잡하다. 노장의 얼굴에 복잡한 주름이 지는 것처럼, 실 서비스의 코드는 다양한 장애와 문제 상황을 겪고 요구 사항을 추가하면서미묘한 오류까지 해결하고 기워둔 상태로 남아 있을 것이다. 그래서 어떤 개념을 소개할 때 인용하기에는 적절하지 않을 수 있다. 실 서비스의 코드는 복잡하다입사하고 며칠 후, 스프링의 ㅍ도 잘 모르는 상태에서 실제로 작동하는 서비스의 코드를 보고 이해해야 하는 일이 있었다. 코드는 매우 복잡해 보였고, 클래스 하나에 인터페이스가 하나씩 달려 있는 등...코드의 복잡성과 양에서 모두 버겁다는 느낌이 들었다. 어떤 클래스의 정의를 찾아 들어가려고 하면 다시 모르는 게 나오고, 또 모르는 게 나오고... 마치 집을 나오다가 지갑을 잊어버려서 들어가고, 지갑을 찾다가 ..