AS-IS 코드의 의존관계를 그려본다.

TO-BE 의존도를 그려본다.

2개이상 의존하고 있는 클래스들을 common으로 만든다.

모든 도메인 클래스들이 갈 필요는 없고, 의존하는 만큼의 정보만 패키징에서 이동을 하자.

의존하는 것이 구체적이면 common에서 추상화를 하고 하위에서 구체화 클래스를 만들자.

대부분 구체적인 로직의 클래스가 common에 있을때 제약사항이 발생을 하고, 별생각없이 그 클래스들을 마구 사용할때 나중에는 dependency파악도 어려워지는 시점이 온다.

common에는 가능한 추상화된 것만, 자주 안 바뀔만한 것만 유지를 하는 것이 좋겠다.

PS.
그나저나 refactoring을 할때는 SVN보다 CVS가 좋은거 같다.
아직까지 SVN의 장점이 먼지 잘 모르겠다.
많은 dependency와 잘못된 dependency로 인해서 코드변경이 어렵다.

기존에 있던 코드의 잘못된 디자인으로 시작된 옳지 않은 dependency때문에 계속해서 문제가 발생을 한다.

이걸 break를 하고 가야 하는데, 오픈이 얼마 남지 않아서 못하는구나.

이 작업은 다음 프로젝트에는 꼭 하고야 말겠다. 내가 만든 코드는 아니지만, 더 이상 미루면 안될거 같다.

조금 귀찮지만, 다음에 작업을 위해서 조금만 더 수정을 해야겠다.
변경에 잘 대처하기 위해서 우리는 유연한 디자인(supple design)으로 코드 개발을 한다.

우리가 만든 대부분의 코드는 변경되는 것과 변경되지 않은 것이 섞여 있는 경우가 많다.

변경이 되는 부분과 변경이 자주 되지 않은 부분을 분리(separate)만 잘 해도 좋은 코드를 만들 수가 있다. 클래스를 변경하는 이유를 하나로 만드는 것(SRP)은 중요한 원칙이 될 것이다.

분리가 잘 되어 있어서 조금 더 욕심을 낸다면, 격리(isolation)까지 도전해보는 것도 좋을 것이다. 격링레 도전시에는 처음부터 격리에 치중을 하다가 보면 나의 코드는 응집성(cohesive)에서 멀어질 수도 있다. 점진적으로 격리를 해야 겠다.

변경이 자주 되는 부분만 유연하게 코드를 개발하면, 복잡한 부분을 최소화를 할 수 있어서 더 가독성도 좋아 질것이다.

유연한 코드를 만들면 복잡해진다. 그래서, 유연하게 만드는 부분은 최소화를 해야만 더 가독성이 좋은 코드를 만들 수 있는 것이다. 변경이 많지 않은 부분은 유연하지 않게 내버려두자. 변경이 되지 않는 코드를 유연하게 만드는 것은 리소스 낭비이고, 미련한 짓이다.

모든 것이 유연한 코드가 되어야 한다는 환상은 빨리 잊어버리자.

큰 문제라고 생각지 않은 것들이 일관적이 못한 의미를 갖지 못해서  문제가 생기는 경우가 있다.

처음에 문제가 발생을 한 것을 가지고, 변경을 가하는 것은 나의 생각한 것보다 많은 비용이 들수 있기때문에 큰 문제가 없으면 피해가거나 그 문제를 위해서 몇 가지를 추가적으로 작업을 한다.

주의할 것은 꼭 코드가 적다고 변경할 부분을 적게 가져간다고 좋은 해결 방법은 아니라는 것이다. 원칙만 따져서 무리하게 하는 것도 문제지만, 의도를 무시한채 변경시 수정만 적게 하려고 하고, 코드량만 적게 하다가 보면, 다른 문제들이 생겨서 생각지 못한 비용이 더 발생을 할수가 있다.

우리는 이것을 속된 말로 꽁수 또는 일시적인 땜빵이라고 한다. 이런 것들은 시간이 지나면 자신도 의도를 잊어 버릴뿐만 아니라, 타인이 보면 이해할수 없는 것들을 만들어 낸다.

"계속해, 지름길로 가라구, 네 시간을 절약해 줄거야, 정말이야. 아무도 모를 거구, 넌 이 일을 끝내고 빨리 다음으로 옮겨갈 수 있어, 그게 전부야" - 애자일 프랙티스 P.27


땜빵으로 구현한 코드의 장소에서 2번,3번 발생하면 그 시점에서는 올바르게 변경을 가할때가 온것이다.코드를 이해하는 비용이 많이 들고, 오해의 소지가 있는 부분은 발생을 할때 수정(refactoring)을 하자.

만약에 만약에 정말 꽁수를 쓸수 밖에 없는 상황이면 다른 곳에 제약을 만들지 말아야 하며, 문서화 및 주석을 잘 달아두자.

기존에 있던 코드를 변경하다가 보면, 내가 잘 모르는 코드와 설정들이 있을 수 있다.

아무리도 잘 만들어진 코드라도 남이 만든 코드를 한눈에 이해하는 것은 쉬운 일이 아니다.

남이 만든 코드를 이해하는 것은 일단 어렵다. 하지만, 조금이라도 가독성이 쉬울수는 있다.

대부분 코드를 언어적인 코드를 생각한다. 하지만, 랭귀지에 상관없는 설정파일도 마찬가지다.

우리는 설정파일이 많아지는 것과 이해하지 못하는 것에 대해서 대수롭지 않게 생각을 한다.

설정파일도 코드의 일부이다.

설정파일을 줄일 필요가 있고, 가독성이 좋게 해야 할 필요가 있다.

태그 EP3
모델1의 구조를 가지고 있는 코드를 모델2의 구조로 변경을 하면서 리팩토링을 하는 것은 지루하면서 힘든 일이다.

그리고, 테스트를 하기 어려운 SP는 로직이 들어가 있는 부분을 자바코드로 끄집어 내는 것은 노가다성 일이 강하다.

하나씩 지워가면서 의미를 코드로 옮기는 것이다.

이 부분은 테스트를 만들기가 너무 어렵거나 불가능하다.

나는 지금 일단 테스트가 가능한 구조로 변경을 하고 있다. 거의 재개발에 가까운 작업이다. 이 과정에서는 기계적인 도움을 받기가 어렵기때문에 주의를 기울일 수 밖에 없다. 그래서 더 피곤한 작업이 된다.

지금 내가 하는 작업은 refactoring일까? 재개발일까?

<2007년 11월 23일 오전에 추가>

"성글다"의 사전적인 의미
http://krdic.naver.com/search.nhn?query_euckr=%BC%BA%B1%DB%B4%D9

EP님의 의견으로 성글은 테스트가 있다면 refactoring이 맞다는 이야기를 했습니다.

좋은 이야기라고 생각이 들어서 사족을 달아서 업데이트를 합니다.
하나의 테스트만 있어도 refactoring이 되는 것이겠죠. 반드시 코드가 아니더라도 대략 바꿀려는 코드의 기능을 실행할 수 있는 방법이 존재를 한다면 refactoring이 되겠습니다.

물론, 성글은 테스트보다는 커버리지가 높은 테스트들이 버그가 생길 확률을 줄여줄수 있겠죠 
나 혼자 뚝딱해서 개발하는 프로젝트는 나 자신의 능력만 파악하면, 즉 주제파악만 잘 하면 오차의 범위가 적은 편이다

지금까지의 업무를 생각해보면, 나혼자 열심히해서 만든 프로젝트는 거의 없는거 같다.

여러가지 시스템이 연결이 되어야 하고, 담당하는 회사, 부서가 많아질 수록 일정을 깔끔하게 만들기는 쉽지가 않다. 수많은 사람들의 현재상황과 제약상황을 고려해서 하나하나 협의를 해야하기때문이다.

더군다나 확정되는 것이 없이 변경되는 부분이 계속 진행이 된다면, 더욱더 어려질 것이다.

나는 결심을 했다. 지금까지 상황을 분석을 해서 확실한 것과 불확실한 것을 나누어서 정리를 하고, 불확실한 것은 불확실하게 내버려두고, 확실한 것을 바탕으로 일정을 재산정을 하는 것이다.

당연한 이야기처럼 보일지 모르지만, 일의 순서에 있어서 가장 중요한 포인트가 될 것이다.
 
어려운 일은 먼저 처리를 해서 리스크를 줄이는 방법과 명확한 일을 먼저 하는 방법, 이것을 선택하는 기준은 객관적,주관적으로 업무의 중요성 파악을 잘 하는데 있다.

모듈에 대한 예상치를 만들 때 너무 변수를 강조하다가 보면, 예상치를 만들기는 쉽지 않다. 리스크와 변수를 제거하고 예상치를 만들어야 하는 것이다.

리스크와 변수를 제거하는 테크닉은 그때그때 다르겠다. 주위 사람들이 내가 생각한 예상치보다 잘 해주어서 리스크가 줄어들었다면, 이거 참 고마운 일이다....^^

BLOG main image
OOP and Java by ologist

공지사항

카테고리

All (649)
private!! (106)
WEB & IT (140)
Developer (400)