악세사리는 :

1. 이뻐야 한다.
   
   이쁘고 조잡하지 않고 간결하고 깔끔해야한다. -> Clean Code를 홍보하는 거니까...
   
2. 몸에 지닐수 있으면 최고
   
   팔찌, 핸드폰 걸이
   
3. 일하는 장소에서 자연스럽게 눈에 자주 띄여야 한다.
   
   노트북, 모니터나 책상 근처에 둘 수 있는 것 (스티커)
   

1. 전제조건
   
   • 개발자와 함께 작업하기
     
     대부분 담당 개발자가 참여하지 않고 리팩토링한 코드를 넘겨줬더니 반영을 하지 않는 경우가 많더라. 따라서 개발자와 함께 작업하는게 중요함.
     
   • 분명한 스펙
     
     동작에 대한 문서로 된 스펙이 있어야 한다.
     
   • 수정 레벨
     
     어느 정도의 리팩토링이 좋을까? 시간과 자원에 따른 문제일 수 있음. Rename, Extract method 정도냐 아니면 Redesign을 할 것인가?
     
2. 시작하기
   
   • 현재 코드 Review
     
     Output -> 복잡도, 구조도
     
   • 복잡도 낮추기
     
     Test코드가 없더라도 Extract method나 Rename을 했을 경우 문제가 없는 부분부터 먼저 작업 가능
     
   • Coverage 구하기
     
     Coverage를 통해 어떤 상황에서 코드의 유효성이 아직 검증되지 않았는지를 확인할 수 있다.
     
3. Firmware Test
   
4. UI Test
   
5. 어려운 점
   
   • 기존 코드가 복잡한 경우 Test를 작성하고 리팩토링이 불가능한 경우가 많다.(Test 코드 다는데 드는 비용이 너무 큼)
     
   • 개발자와 함께 작업하기 (개발자는 항상 바쁘다. 그래서 대신 작업해 주는 경우가 많다.)
     
   • 시나리오 기반 or Code 기반 (Firmware의 경우 시나리오가 명확하지 않고 예외처리 관련된 사항에 대해서 history가 제대로 관리되지 않는 경우가 많더라. Code기반으로 작업했던 적이 있다.)
     

의뢰 : xxx의 s/w 구조의 문제점은 무엇인가? (왜 자꾸 코드가 바뀌나?)
방법 :

1. OCP(Open Close Principle)을 위반한 경우 찾기
   
2. 개발초기 Base Code와 현재(약 6개월 지난) 코드를 비교해서 바뀐 부분의 특징 조사