結婚できない男

프로젝트 규모가 커지면서 가장 고민스런 부분이

package 관리였다.

전통적인 계층형, 기능으로 구성하기 등

어느 하나 맘에 드는게 없었다.

이 책에서는 육각형(hexagonal) 아키텍처로 이 고민에 대한 대안을 제시한다.

좋은 내용인데....

매 기능마다 adapter, domain, application 을 가져 간다는게.....

패키지명이 너무 중복 같은데, 이 부분에 대한 고민은 별로 없는거 같다.

이런 중복 보다는 구조에서 오는 이점이 더 크서겠지....

case by case 라지만...... 여전히 패키지 구조를 어떻게 가져 가야 할지 모르겠다.

그동안 별 생각없이 넘겼던

package private 에 대해 자세히 알게 된거 같다.

좋은 책이다. 읽어 보길 권장한다.

프로페셔널 제품 책임자 스크럼을 활용한 경쟁력 있는 제품 개발

지라 프로젝트를 스크럼 방식으로 관리해 보려고

[ 쉽게 배우는 Jira Project ] 라는 책을 샀지만, 내용이 너무 빈약해서

스크럼을 공부하기 위해 산책.

최근 구직 활동을 위해 이력서를 내면 대부분의 회사들이 애자일을 필수 조건으로

요구하고 있다.

몇권의 애자일 책을 읽은적은 있지만, 한번도 경험해 보지도 못했고, 애자일이 뭔지도 모른다.

이 책 역시 내 갈증을 하나도 풀어 주지는 못한거 같다.

제품 책임자가 뭔지는 알게 된게 소득 같다.

책 : 프로페셔널 제품 책임자 스크럼을 활용한 경쟁력 있는 제품 개발

하나의 제품을 만드는 여러 팀에게 유용한 완료 정의 템플릿

1 제품 레벨

 1) 모든 테스트 통과

 - 인수

 - 회귀

 - 성능

 - 통합

 2) 코드 완성

 - 스타일 가이드 준수

 - API 문서화

 - 개발 브렌치에 체크인

 - 단위 테스트

 - 알려진 결함 없음

 3) 문서화

 - 릴리스 노트

 - 사용자 가이드

 - 지원 가이드

 - 컴플라이언스

 4) 통합

 - 다른 팀과 메인으로 머지

 5) 승인

 - 제품 책임자

2 팀레벨

 1) 단위 테스트 > 80%

 2) 경고 없음

 3) 테스트 우선

 4) 함수 길이 < 12줄 ---> 권고 사항이지 필수는 아닌거 같음

 5) 줄 길이 < 80자    ---> 모니터가 커졌는데, 이건 아닌거 같음. 120줄 ~ 150줄 사이 팀이 논의

 6) 도구/보드 업데이트

 7) 팀 리뷰