https://www.yes24.com/Product/Goods/122535338
기술서적에서는 기술 선택의 과정이나 트러블 슈팅의 날 것의 느낌이 잘 안드는데
블로그에서 회고하며 쓴 글들이 많아서 어떤 고민과 선택을 했는지는 좋았다.
처음에는 재미있었지만, 블로그 모음글이라 책이 이어지는 느낌이 없었다.
현재 시점에서 책이 어색하지 않지만, 기술내용은 몇 년뒤에는
바뀔 수도 있는 내용들이라 잘 모르겠다. 2, 3 시리즈로 나올 수 있을 것 같지만 굳이라는 생각도..? 🧐
회사에서 기술 블로그를 잘 작성할 수 있게 도와주고, 그러한 문화가 있었기에
책으로도 나왔을 것이라 생각한다.
- 재미있던 부분 메모
pg.8. 기술력을 외부로 알리는 일만큼 내부 개발자들이 소통하고 성장할 수 있는 문화를 만드는 일도 중요하다.
=> '곳간에 인심난다' 괜히 있는 말이 아니다.
pg.23 파일럿 프로젝트 안내. 요구사항 분석 -> 설계 -> 문서화 -> 임무 분담 -> 개발 -> 배포 -> 회고
=> 팀의의 중요한 가치를 파일럿에 담는다.
pg.25 자유 주제 워크숍
=> 평소에 공유하는 문화가 있음을 자랑. 발표 순서를 정하는 것은 경험상 쉽지 않다.
평소에 구성원들이 학습을 하는 분위기여야 잘 굴러갈 듯.
pg.29 코드 리뷰
=> 팀원들이 적극적으로 리뷰를 달아주는 경험을 입사때 받는다면(아마 좋은 분위기로..?) 앞으로 회사 생활도
기대되겠다.
pg.38 PR
=> 테스트 없는 것은 허용하지 않는다. 룰이다.
pg.41 시니어개발자
=> 시니어의 삶. 우리 회사 시니어도 오세요. 어떤 좋은 점을 어필할까 위주로 읽음.
선순환 구조. 좋은 주니어가 옴 => 좋은 시니어가 도와줌 => 좋은 시니어로 진화함.
- 61 pg 리뷰크기는 300줄 미만유지
- 62 pg 리뷰반영후 피드백에 변경한내용 알려주기
- 68pg 질문이 계속 나오면, 질문을 덜 받으려면 어떻게할까 고민
- 71pg 쓰레드 시작은 대화의 목적을 밝히기
- pg.119 내가 어디까지 입력했는지 알수 있는 ui
- pg.127 페이징, 날짜조회를 잘못사용하는 사례. 제약이없으면 엄청난 호출을 할수있다
- pg.130 호출하는 데이터가 본인데이터인지 확인하자
- pg.136 로컬에서 접근은 mq, api 다막기
- pg.137 배치 실행여부도 검증
- pg.157 기술선택 전개. Spring cloud+mq vs spring cloud schedule
: 우리팀에 맞는 적절 기술 찾는게 인상적.
- pg.184 현재 가장 어려운 어려운 문제 먼저 고민하기. 나에게 일주일의 시간이 있다면 무엇을 해볼까?
- pg.231 조건 between(start<= status <= end) 대신 start <= status < end+1로
- pg.232 controller, service 의 데이터 전달. service에서 요구하는 사항의 DTO로.
- pg.233 최대한 예외케이스 부터 테스트 작성.
=> 맞는 말이지만 저자도 리뷰 후에 알게 된 것. 개발자는 본인이 아는 케이스만 작성하기 쉬움.
개발자, 한 달에 책 한 권 읽기 2023년 11월~2024년 1월 모임 | Festa!
Festa에서 당신이 찾는 이벤트를 만나보세요.
festa.io
책 모임에서 나눴던 이야기(2023-11-30)
회사에서 말고 대용량을 경험할 사례가 있을까?
- 코로나 보드, 서버시간 홈페이지
MR 어떻게 쓰지?
- 코드가 예상되어야함. 왜 이것을 했는지. 실행방법.
- 스샷, 도움이 되는지
협업을 할 수록 git rebase 중요한 것같다.
기술도입 어떻게 하는지. 혹은 나의 판단이 적절한지 어떻게 판단하는지
- 내가 신뢰하는 사람과 대화를 나눈다.
온보딩 경험 나누기
- 레거시 고쳐보기. 회사에서 좋았던 소스 공유하고, 레거시 코드 개선해보기
- 테스트 코드 작성하기
- 강남언니 온보딩 경험이 좋았다. 싱크 얼라인으로 제품 이해. 다른 동료와 런치, 커피타임을 가졌다.
