. 대학교에서는 테스트에 대해 많은 걸 다루지 않는다.소프트웨어공학 시간에 단위테스트, 통합, 시스템, 화이트박스, 블랙박스 등 간단하게 넘어갔던 걸로 기억한다. (아닌가?) 아무튼 학부시절에 실제 로직을 작성하는 시간은 극히 짧았고, 문서작성 등의 코딩 외의 일과, 디버깅에 가장 많은 시간을 할애했었다.책에서의 예처럼 테스트를 작성했다면 몇분 이내에 찾고 해결할 문제들을 몇 시간, 몇 일을 고생한 경험이 한 두번이 아니었다. 거기다 Junit과 같은 프레임워크의 도움을 받아 자동화된 테스트를 작성했다면 고통을 더 줄일 수 있었을텐데..(그러나 이러한 경험으로 테스트의 중요성을 더 느낄 수 있지 않나 싶기도 하다).. 리팩토링을 하기 위해서는 테스트가 미리 작성되어 있어야한다. 테스트라는 안전 장치 없이..
. 16. 과잉 중개 메소드(Middle Man) - 내부의 세부적인 처리를 외부에서 볼 수 없게 은폐하는 캡슐화는 객체지향의 주요 특징 중 하나다.- 어떤 작업을 중개(위임)해서 처리하는 메소드는 변경에 강하고 유지보수에 도움이 된다.- 그러나 이것도 지나치면 문제가 된다고 하니, 어느정도는 직접 접근하자.- 실제 구현 코드가 너무 가려져 있으면 오히려 가독성을 떨어트리게 되는 건가보다... 17. 지나친 관여(Inappropriate Intimacy) - 클래스끼리 지나치게 깊게 연결된 경우를 말한다.- 공통 필요 부분을 클래스로 빼거나 중개 메소드를 만드는 등으로 의존성을 줄인다... 18. 인터페이스가 다른 대용 클래스(Alternative Classes with Different Interfac..
. 7. 잘못된 소속(Feature Envy) - 먼저 객체는 데이터(필드)와 그 데이터에 사용되는 프로세스(메소드)를 한 데 묶는 기술이 핵심이다.- 어떤 메소드가 자신이 속하지 않은 클래스에 더 많이 접근한다면 잘못된 소속의 구린내가 풍길 것이다.- 이 때는 더 많이 호출되는 클래스로 메소드르 옮기자.- 메소드의 일부분만 그렇다면 메소드를 추출하여 적절한 클래스로 이동 조치한다... 8. 데이터 뭉치(Data Clumps) - 데이터 항목은 거리의 꼬마들처럼 몰려다니는 습성이 있다. - 이렇게 몰려 있는 데이터 뭉치는 객체로 만들어야 한다.- 음.. 와닿지는 않지만, 확실히 클래스로 추출한다면 코드가 가벼워질 것 같다... 9. 강박적 기본 타입 사용(Primitive Obsession) - 객체를 ..
. 리팩토링의 중요성과 효과는 인정하겠는데 대체 언제 리팩토링 해야하지?? 소프트웨어는 과학이 아니라 공학이다. 아트라고도 할만큼 개발자나 기획자의 주관에 따라 쉽게 바뀌기 마련이다.리팩토링의 시점은 정확하게 정해져 있는 것은 아니다. 단지 일반적으로 어느 문제에 대해 리팩토링하는 것이 더 좋다는 가이드가 있을 뿐이다.사람의 직감이 나설 때다. 그러나 우리는 초짜 프로그래머이므로 고수들이 알려주는 패턴부터 머릿속에 집어넣자. 연습만이 살 길이다... 1. 중복코드(Duplicated Code) - 구린내의 제왕 - 중복코드를 제거하려면...- 메소드추출(Extract Method) - 메소드 상향(Pull Up Method)- 템플릿 메소드 형성(Form Template Method)- 알고리즘 전환(S..
- 리팩토링을 통해 개발자는 수정할 때 따르는 위험성에 다른 각도로 대처할 수 있다. 개발자는 여전히 잠재적 수정 가능성을 생각하고 유연한 솔루션을 고려한다. 하지만 무작정 유연한 솔루션을 구현할 것이 아니라 먼저 "단순한 솔루션을 구현해 놓고 그걸 나중에 유연한 솔루션으로 리팩토링하려면 얼만큼 수고가 들까?" 하고 스스로 고민해보자. 그래서 만약 웬만한 경우처럼 어려움이 없다고 판단되면 고민할 것 없이 단순한 솔루션을 구현하면 된다.- 리팩토링을 실시하면 유연성을 낮추지 않고도 더 간결한 설계가 가능해진다. 그래서 설계 과정이 쉬워지고 스트레스도 줄어든다. 리팩토링을 쉽게 할수 있는 감각을 넓히게 되면 그땐 유연한 솔루션은 떠오르지도 않는다. 때가 되면 어련히 리팩토링하게 되리란 확신이 있기 때문이다...
교재 : 마틴파울러 - REFACTORING - 리팩토링은 기존의 소스코드를 가독성, 재활용, 체계적 구조 측면에서 개선하는 총괄 작업을 뜻한다.- 설계를 좋아지게 고치면 구조가 체계적이 된다. 구조가 좋아지면 가독성과 재활용성은 저절로 얻는다. - 직관적인 변수명은 코드의 기능을 분명히 드러내는 열쇠이다. -> 용도가 확실히 드러나는 코드- 메소드가 엉뚱한 클래스에 들어 있는 건 아닌가?- 임시변수를 줄이자 리팩토링은 왜 해야 하나?- 소프트웨어 설계가 개선되니까- 소프트웨어를 이해하기가 더 쉬워지니까- 버그를 찾기 쉬워지니까- 프로그래밍 속도가 빨라지니까 리팩토링은 어떨 때 필요한가?- 같은 작업의 삼진 아웃 때 (중복코드)- 기능을 추가할 때- 버그를 수정할 때- 코드를 검수할 때 프로그램은 다음 ..