2장. 애자일 시작하기
땜질은 늪을 만든다 (p.40)
"그 코드 부분은 이해할 필요가 없어. 그대로도 잘 동작하는 것 같잖아. 그래, 하긴 조금 고칠 필요가 있겠네.
그냥 그 결과에 한 줄 더 붙여 봐, 그럼 동작하잖아. 계속해서 그렇게 끼워 넣어. 아마 괜찮을 거야"
=> 악마의 꼬득임을 읽고 문제점을 생각해 봅시다.
<내용파악>
버그가 있고, 시간압박을 받는 상황. 땜질을 해도 잘 돌아갈 것 같다. 당장은 괜찮다.
땜질하듯 수정하는 일이 반복되면 코드는 엉망이 되고 프로젝트의 생명을 위협하는 일이 된다.
<조언>
지뢰를 조심하라 : 어설픈 수정이 문제다. 즉, 압박을 받으면 진짜 문제가 무엇인지 모르고,
side effect고려 없이 고치는 땜질식 수정은 문제다. 명료함이 사라지고, 아무도 이해못할 코드가 된다.
(TODO : 경험담)
따로 코딩하지 말라 : 코드리뷰가 필요하다. (TODO : 경험담)
단위 테스트를 사용하라 : (TODO : 경험담)
<얘기꺼리>
- if..else..가 난무하는 코드
- 스파게티 코드 경험담
- 리팩토링의 효과 (땜질한 코드를 이렇게 고쳤더니 다음에 뭐가 좋았어요~ 등등)
- 공통모듈 코드리뷰 회의
- 코드리뷰는 꼼꼼하게 하나?
- 코드리뷰 회의는 시간이 많이 걸려 부담스럽다.
- 코드리뷰 회의로 얻은 것 : 오류 줄어듬, 코드 신뢰성 높아짐, 명료한 코드 탄생
- 단위테스트의 장점
- 단위테스트가 없을 때의 불안감
3장. 애자일 기르기
이해할 때까지 질문하라 (p.71)
<악마의 꼬득임>
"네가 들은 설명을 받아 들여. 문제가 있다고 얘기 들은 곳만 찾아보면 돼. 뜬구름 잡느라 시간 낭비하지 마."
=> 악마의 꼬득임을 읽고 문제점을 생각해 봅시다.
<내용파악>
문제를 해결하려면 큰 그림을 잘 이해해야 한다.
다른 사람이 어떻게 생각하든지, 관계되었다고 생각하는 "모든"부분을 살필 필요가 있다.
여러분이 질문함으로써 다른 팀원이 자기 생각을 정리하는데 도움을 줄 수 있다.
여러분의 참신한 관점과 질문으로 인해 다른 사람들이 새로운 시야를 얻고 고민하던 무제에 대한 답을 찾을 수도 있다.
=> 질문이 생각나면 주저하지 말고 바로 얘기하는 용기 필요! (나의 경우)
<연습해 봅시다~>
"왜 그래요?"
API도 의심하라! 코드를 뜯어보자!
p.74 균형유지하기를 숙지합니다.
댓글