1. 명확한 이름붙이려다 코딩양이 증가하면 해롭다.
명확하게 하려다 이름 길어지면 로직 변경될때마다 이름 다 바꿔야한다
물론 간략하면서 명확하면 좋겠지만 그렇게 할 수 있는 경우 많이 없다
그냥 주석을 붙여라
기획이나 설계 잘하면 로직변경 안할 것 같지?
일하는 중에 스스로 만든 코드에서 로직 변경해야한다는 생각이 안들면
지나치게 쉬운 작업이거나 생각이 없는거다.
보통은 생각은 드는데 마감에 쫓겨 시간이 없거나 워라벨때문에 안고치는거지.

2. 단일 기능 함수만들려다 로직이 파편화되면 더 해롭다.
단일 함수가 10개 있는 것보다 여러 기능하는 함수 하나가 더 동작 파악하기 유리할 때가 있다
그냥 스크롤 한두번 밀면 파악되는 코드와 스크롤 아래위로 열심히 하면서 왔다갔다해야하는 코드 어느쪽이 좋을까?
단일 기능으로 하려는 것은 결국 읽기 쉽게하려는 것인데 의도를 벗어나면서까지 원칙을 지킬 이유는 없다.
재사용이 필요한 함수라면 그래도 분리해야지

3. 예외처리가 이로울때는 케바케
때때로 언어에 따라 예외처리하면 메모리 리와인딩이 망하는 경우가 있다
언어에 따라 리턴값이 bottom을 지원하면 예외가 필요없다
예외처리 제대로 지원하는 언어라도 리턴값보다 퍼포먼스가 느리다
예외처리하면 코드가 지저분해진다.
예외처리하는데 aop를 쓰면 로직 파편화로 인한 한계가 있다
써야할때는 써야하지만 안쓰고 이해가면 안쓰는게 더 좋다.

4. tdd는 기획이나 개발계획이 안바뀔때나 적용가능하다
고객 요구가 수시로 바뀌고 설계변경되는데다 리펙토링 시간까지 안주는 불지옥반도에서는 어렵다.
tdd 하다간 테스트만 작성하다 프로젝트 마감일본다.