2008/02/12 09:30 Developer
변경이 안되는 것 유연하게 만들지 말기
변경에 잘 대처하기 위해서 우리는 유연한 디자인(supple design)으로 코드 개발을 한다.
우리가 만든 대부분의 코드는 변경되는 것과 변경되지 않은 것이 섞여 있는 경우가 많다.
변경이 되는 부분과 변경이 자주 되지 않은 부분을 분리(separate)만 잘 해도 좋은 코드를 만들 수가 있다. 클래스를 변경하는 이유를 하나로 만드는 것(SRP)은 중요한 원칙이 될 것이다.
분리가 잘 되어 있어서 조금 더 욕심을 낸다면, 격리(isolation)까지 도전해보는 것도 좋을 것이다. 격링레 도전시에는 처음부터 격리에 치중을 하다가 보면 나의 코드는 응집성(cohesive)에서 멀어질 수도 있다. 점진적으로 격리를 해야 겠다.
변경이 자주 되는 부분만 유연하게 코드를 개발하면, 복잡한 부분을 최소화를 할 수 있어서 더 가독성도 좋아 질것이다.
유연한 코드를 만들면 복잡해진다. 그래서, 유연하게 만드는 부분은 최소화를 해야만 더 가독성이 좋은 코드를 만들 수 있는 것이다. 변경이 많지 않은 부분은 유연하지 않게 내버려두자. 변경이 되지 않는 코드를 유연하게 만드는 것은 리소스 낭비이고, 미련한 짓이다.
모든 것이 유연한 코드가 되어야 한다는 환상은 빨리 잊어버리자.
우리가 만든 대부분의 코드는 변경되는 것과 변경되지 않은 것이 섞여 있는 경우가 많다.
변경이 되는 부분과 변경이 자주 되지 않은 부분을 분리(separate)만 잘 해도 좋은 코드를 만들 수가 있다. 클래스를 변경하는 이유를 하나로 만드는 것(SRP)은 중요한 원칙이 될 것이다.
분리가 잘 되어 있어서 조금 더 욕심을 낸다면, 격리(isolation)까지 도전해보는 것도 좋을 것이다. 격링레 도전시에는 처음부터 격리에 치중을 하다가 보면 나의 코드는 응집성(cohesive)에서 멀어질 수도 있다. 점진적으로 격리를 해야 겠다.
변경이 자주 되는 부분만 유연하게 코드를 개발하면, 복잡한 부분을 최소화를 할 수 있어서 더 가독성도 좋아 질것이다.
유연한 코드를 만들면 복잡해진다. 그래서, 유연하게 만드는 부분은 최소화를 해야만 더 가독성이 좋은 코드를 만들 수 있는 것이다. 변경이 많지 않은 부분은 유연하지 않게 내버려두자. 변경이 되지 않는 코드를 유연하게 만드는 것은 리소스 낭비이고, 미련한 짓이다.
모든 것이 유연한 코드가 되어야 한다는 환상은 빨리 잊어버리자.
