- 실타래를 풀려면, 실이 엉켜있다는 사실을 알아차려야 시작할 수 있다. 따라서, 실타래를 풀어야 할 필요성을 더 일찍 깨달을 수록 작업량은 적어진다.
코드 정리 시점
- 다음과 같은 상황에서는 코드 정리를 하지 마라
- 앞으로 다시는 코드를 변경하지 않을 때
- 설계를 개선하더라도 배울 것이 없을 때
- 다음 상황에서는 나중으로 정리를 미뤄라
- 정리할 코드 분량이 많은데, 보상이 바로 보이지 않을 때
- 코드 정리에 대한 보상이 잠재적일 때
- 작은 묶음으로 여러번 나눠서 코드를 정리할 수 있을 때
- 다음 상황에서는 동작 변경 후에 정리하라
- 다음 코드 정리까지 기다릴수록 비용이 더 불어날 때
- 코드 정리를 하지 않으면 일을 끝냈다는 느낌이 들지 않을 때
- 다음 상황에서느 코드 정리 후에 동작을 변경하라
- 코드 정리를 했을 때, 코드 이해가 쉬워지거나 동작 변경이 쉬워지는 즉각적인 효괄르 얻을 수 있을 때
- 어떤 코드를 정리해야하는지 알고 있을 때
요소들을 유익하게 관계 맺는 일
- 소프트웨어 설계는 인간관계 속에서 벌어지는 활동
- 소프트웨어 설계는 요소들을 유익하게 관계 맺는 일
- 요소를 만들고 삭제한다.
- 관계를 만들고 삭제한다.
- 관계의 이점을 높인다.
- 즉 시스템 구조는
- 요소의 계층 구조
- 요소사이의 관계
- 이러한 관계가 만들어내는 이점
코드정리부터 해야할 때
- 비용(코드 정리) + 비용 (코드정리 후 동작 변경) < 비용 (동작변경)
결합도
- 한 요소를 변경하려면, 다른 요소도 변경해야하는 것
- 한 종류의 코드변경에 대한 결합도를 줄일 수록, 다른 종류의 코드 변경에 대한 결합도가 커진다.
- 모든 결합을 다 색출하듯 없애려고 애쓰지 말아야한다.
응집도
- 결합된 요소들은 둘을 포함하는 같은 요소의 하위 요소여야한다.
- 밭에 거름을 주는 일에 비유하자면, 모든 거름을 삽으로 퍼서 한 더미로 담는 것 과 같다.
- 이 때, 응집도는 거름이 아닌, 이물질(결합되지 않은 요소)은 이 더미가 아닌 다른 곳으로 이동해야한다는 것
코드 정리가 먼저인가?
- 비용
- 코드를 정리하면 비용이 줄까요? 아니면 나중에 하는 편이 나을까요? 아니면 줄일 가능성이 있을까요?
- 수익
- 코드를 정리하면 수익이 더 커질까요? 혹은 더 빨리 발생하거나 커질 가능성이 있을까요?
- 결합도
- 코드를 정리하면 변경에 필요한 요소의 수가 줄어드나요?
- 응집도
- 코드를 정리하면, 변경을 더 작고 좁은 범위로 집중시켜 더 적은 수의 요소만 다룰 수 있을까요?