개발자

Part 1. 용어 정리 OSS OpenSource Software, 오픈소스 소프트웨어의 약자 본 글에서 오픈소스 프로젝트 같은 의미로 사용할 예정이다. Apache Pulsar Kafka 와 같은 클라우드 네이티브 메시징 시스템 및 플랫폼 Yahoo에서 처음 시작되었고 이후 Apache 재단에 인큐베이팅, 그리고 메인으로 졸업 Jackson ObjectMapper 로 많이 알려져있는 프로젝트 ObjectMapper 는 Jackson 팀이 관리하는 jackson-databind 라는 프로젝트의 API 정확한 명칭은 FasterXML 이라는 팀이 있고 이 팀의 멤버들이 jackson-databind, jackson-module-kotlin 등의 라이브러리들을 관리한다. Part 2. 서론 최근 내가 메인..

1. 시작하며 21년 11월부터 22년 4월까지 6개월 간 F-Lab의 멘토링을 수료했다. 그동안 여러 궁금증도 해소하고, 내 문제점들도 파악하고, 많은 개발자 분들과 교류도 하고, 크고 작은 서비스 회사에 면접을 보는 기회도 얻고, 운이 좋게도 그 중 몇몇에는 합격하기도 햇다. 정말로 치열한 백엔드 개발자 시장에서 합격한 대로 입사하는 마냥 쫓아가기만 하는 상황에서 선택이라는 사치를 아주 조금이나마 부릴 수 있는 정도는 된거 같고 어떻게 하면 경쟁력을 유지할 수 있는지도 (hopefully) 익힌 것 같다. 약 반년 전 까지만해도 방황하던 나를 더 나은 상황에 있게 만들어준 F-Lab의 백엔드 개발자 멘토링에서 경험한 것들을 공유해본다. F-Lab의 멘토링을 고민하고 있을 또 다른 개발자분들께 조금이나..

읽어보기 https://programmers.co.kr/pages/2022-dev-survey 2022 프로그래머스 개발자 설문조사 5362명이 참여한 온라인 설문 조사 결과를 통해 우리나라 개발자들의 솔직한 의견을 확인하세요. programmers.co.kr

나중에 읽어보기 https://survey.stackoverflow.co/2022 Stack Overflow Developer Survey 2022 In May 2022 over 70,000 developers told us how they learn and level up, which tools they’re using, and what they want. survey.stackoverflow.co

Contents # 시작하며 # G o o d : 용어의 선 # B a d : 용어의 악 # DTO-VO-Entity-Dao 1. Good : DTO-VO-Entity 들은 "왜" 필요할까? 2. Bad : DTO-VO-Entity 와 같은 정의들은 "꼭" 필요한가? # 결론은 # 시작하며.... 최근 멘토링을 진행하며 DTO, VO, Entity , Domain 등의 단어를 정말 많이 사용한 것 같다. 멘토님이 몇번 들으시더니 위 용어들의 정의를 찾아보고 공유해달라고 하셨다. 예리했다. 내가 생각하는 의도가 맞다면 프로젝트 과정에서 꼭 필요한 작업이라고 생각한다. 나는 가족과 회의나 토론을 정~말 많이한다. 그렇게 살다보니 커뮤니케이션 과정에서 공통된 정의를 가지고 있지 않은 용어들과 암묵적인 전제는 ..

이번 포스팅은 혹시나 다른 방법을 찾으신 분은 댓글로 공유 부탁드립니다! Contents 0. "중계 서비스" 관점에서 API 문서화가 필요한 이유 1. Swagger 채택 이유 1-a. 적용을 위한 비용이 상대적으로 낮습니다. 1-b. Swagger에서 Spring Rest docs로 전환하는 케이스가 많습니다. 1-c. 저렴한 전환 비용 2. Swagger : 단점과 보완 전략 2-a. 검증이 되지 않은API의 노출 2-b. 서비스를 위한 코드와 문서화 코드의 결합 3. 서비스 코드와 문서화 코드의 분리 방법 3-a. Swagger의 동작 원리 3-b. 적용 순서 3. 마치며... 0. "중계 서비스" 관점에서 API 문서화가 필요한 이유 최근 프로젝트에 문서화 툴을 적용하자는 제안을 받았습니다. 물..

Contents 시작하며 Level 1. 이벤트 순서대로 나열하기 갑자기 Bonus? 중개와 중계 차이점 Level 2. 역할 관점으로 분리하기 Level 3. 결과 반환시점을 기준으로 기준으로 분리 Level 4. 커뮤니케이션 역할에 따른 서비스 분리 Level 5. 동기-비동기로 분리 Level 6. 초기세부구현 : 시작점 Level 7. 추후 고민이 필요한 부분들 1. 주문상태확인 기능 2. 중개 기능 (요청 전달) 3. 라이더의 위치정보 오늘은 여기까지 시작하며 지난번 블로그에서 프로젝트 주제선정 과정과 기초 유저 플로우(위 사진)를 소개해드렸습니다. 이후 저는 상세 구현 목록과 서비스 아키텍처를 도출하기 위해 로버트 마틴 "클린 아키텍처"를 옆에 펼쳐놓고 서비스를 디테일하게 분석하기 시작했습니다..

Contents 0. 시작하기 앞서 1. 주제 범위 좁히기 2. 주제는 "배달의민족 중계 서비스"로 정했습니다. 3. 유저 플로우를 정의했습니다. 4. 마치며.... 5. 참고 자료들 0. 시작하기 앞서 팀프로젝트 주제 선정은 왜 중요하고, 왜 어려울까요? 우선 주제는 명확할수록 개발 과정에서 협의가 순조롭게 진행될 수 있기 때문입니다. 또한 주제는 프로젝트 이름에 반영되고 프로젝트 이름은 git repo와 소스 코드에 조금이라도 반영되기 때문입니다. 저는 과거 여러 프로젝트들을 거치면서 나름의 주제 선정 전략을 다듬어왔고 이번 프로젝트 주제를 기대 이상으로 순조롭게 정할 수 있었습니다. 주제도 팀 전체가 만족하는 것으로 보입니다. (please!) 그래서 오늘은 이번에 적용해본 주제 선정 과정을 여러 ..