Clean Agile - Chapter 4

클린 애자일

위의 책 내용을 참고하여 정리한 글입니다.

자세한 내용은 책에서 확인하세요.

메타포 ( = 유비쿼터스 언어 )

팀에서 정한 어휘나 용어를 메타포라 하고,

이를 잘 활용하면 효율적으로 의사소통을 할 수 있다.

 

가장 흔한 예로 Cookie 가 대표적이고,

Cookie 값을 추가할 때 "쿠키를 구웠다"라고 말하는 것도 마찬가지로 메타포이다.

( 헨젤과 그레텔에 바닥에 쿠키를 길을 찾기 위해 남겼다 => 정보를 남긴다. => 쿠키 가 어원이라는데 맞는진 모르겠다. )

지속 가능한 속도

가장 말도 안되는 실수를 하는 때는 늦은 밤 정신없이 일하는 도중이라는 것을 깨달았다.

개발은 장기적으로 진행되는 작업이다.

단기간에 마무리 되지 않기 때문에 지속 가능해야 한다.

 

야근은 헌신이 아니고 한다고 더 빨리 가지도 않는다.

개발 평균 속도는 더 느려진다.

의문

제품 내부에는 '메일' 전달 시스템이 있었는데, 다른 프로세스와 정보를 주고받을 때 사용하는 것이었다.
..
모든 신경이 최고조에 달하던 새벽 2시, 우리는 깨달았다. 프로세스의 낮은 부분에서 메일로 자신에게 데이터를 보내면,
높은 부분에서 메일을 읽을 수 있을 것이다.!
..
왜 이 결정이 잘못되었는지 끔찍하고 구체적인 세부 사항을 지루하게 설명하지는 않겠다.

위에 내용은 책에서 드는 저자 ( 로버트 c. 마틴 )가 야근하면서 한 실수인데,

같은 부분을 몇 번을 읽어도 뭐가 잘못됐는지 모르겠다...

 

생각 1. 프로세스끼리 자칭 '메일'이라는 걸로 통신하면 안 되나??

=> 통신을 아예 안 할 수는 없는데. 안드로이드에서 EventBus 도 잘만 쓰잖아?

 

생각 2. 낮은 프로세서에서 뭘 보내면 안 되나??

=> 낮은 프로세스? 커널? 커널끼리도 통신해야지..

 

생각 3. 아 '메일' 이름이 문제구나.

=> '메일' 이란 이름으론 프로세스 간의 통신을 위해 만들었다는 걸 전혀 이해할 수 없다.

=> 프로젝트 전반에 사용할 메타포로는 실패한 어휘이다.

메일을 보내는 기능을 너무 깊게 뿌리를 내려서 되돌릴 수 없게 되어 버렸다.

결론은 모르겠다.

로버트 c. 마틴이란 존재가 이름이 잘못된 걸 가지고 돌이킬 수 없었다고 표현했을까?..

공동 소유

애자일에서 코드는 전체 팀이 소유이고,

구성원 전부가 모든 모듈을 공부하고 개선하기 위해 노력해야 한다.

그리고 이를 통해 팀의 지식이 넓게 퍼진다.

( 요즘은 깃을 쓰니 개인 소유하기도 힘들고, PR을 잘한다면, 자연스럽게 모든 코드를 보게 된다. )

지속적 통합 / 지속적 빌드

지속적 통합 ( CI ) 은 일정 시간마다 커밋하고, 메인 브랜치에 머지한다는 뜻이다.

커밋 전에는 모든 테스트는 통과된 상태여야 하고,

배포 전에는 모든 feature 브랜치는 머지하고 비활성화시켜야 한다.

 

팀에 사람이 많을수록 지속적 통합을 통해서 거대한 conflict 이 발생하는 것을 막아야 한다.

 

지속적 빌드는 공유된 코드 ( 깃에 올라간 )가 빌드 중에 절대 깨지면 안 된다는 뜻이다.

테스트 역시 절대 실패해서는 안된다.