ologist`s blog2.0

코드의 의도
http://www.ologist.co.kr/507

위에 많은 덧글들이 달려서 덧글 및 트랙백을 통해서 느낌점을 얘기해보려 합니다.

cycle length calculator
http://cavin.egloos.com/3049122

이 이야기의 시작은 바로 위에 있는 링크입니다.

네이밍을 잘 지으면, 구현이 단순해질수 있다는 교훈을 희승님이 남겨주셨습니다. 하지만, 3n+1 문제를 가지고 더 좋은 이름을 지어 보려고 하는데, 생각이 잘 안나더군요...OTL

그래서, 저도 cavin님과 똑같이 이름을 짓고, extract local varibable이나 extract method를 통해서 의도를 전달을 했을 것입니다.

일단, 여기까지 코드를 작성을 합니다. 그리고, 좀더 많은 부분을 구현을 하다가 보면, 또는 pair나 코드리뷰를 통해서 더 좋은 이름이 나오면 refactoring을 통해서 불필요한 코드들을 제거를 하면 됩니다. cavin님은 테스트 케이스가 있어서 더욱더 쉽게 refacotring을 할수가 있습니다.

희승님의 아름다운 작명을 기대를 했는데, 조금 바쁘신듯 합니다...^^

3n+1문제 관련하여..
http://cavin.egloos.com/3085039

오픈마인드는 많은 경험을 갖게 하는 듯하다. 자신이 만든 소스를 공개를 한다는 것은 쉬운 일이 아니지만, 공개를 하면 더욱더 많은 경험과 좋은 의견들을 들을수가 있다.

과거에 1999년도쯤 자바를 처음하면서 고수들의 코득다 무척 궁금했을 때가 있었지만, 이원영님을 제외하고는 대부분의 사람들이 소스를 공개를 잘 하지 않아서 실제 잘 만들어진 코드를 보기 어려웠다. 지금은 오픈소스도 많이 있고, 주위에 많은 분들이 소스를 공개를 하셔도 많은 도움이 된다.

팀내에서 코드리뷰를 통해서 내가 너무 형식적으로 구현한 것들에 대한 불편함을 알수도 있게 된다. 사실 구현을 해두고 시간이 지나면서 좀더 도메인 영역을 자세히 알면서 매일 꾸준히 리팩터링을 하고 있지만, 정말 꼭 맘에 드는 아름다운 코드를 만들어 내는 일은 쉬운일이 아니다.

API 및 코드가 오픈이 되고, 사용자들의 의견이 더해질때 좀더 의미있는 객체들이 탄생을 하게 된다고 생각을 합니다.

김창준임이 가독성에 대한 좋은 이야기를 해주셨습니다.
prefactoring을 책을 보다가 보면, 극단적인 가독성과 추상화에 대한 좋은 이야기들이 나온다.

저의 생각은 최소한 클라이언트가 사용하는 인터페이스에서는 극단적으로 가독성과 추상화를 지켜주었으면 하는 생각이다. 내가 만든 코드가 애매하게 보일때, 메타포에 대한 지식이 있는 사람과 없는 사람은 가독성에 대해 현저한 차이가 난다.

아래 이야기는 비슷한 관점에서 나온 것이 아닐까 생각을 해봅니다.

자바지기 아저씨도 그와 관련해서 좋은 이야기를 적어주었다.
http://wiki.javajigi.net/pages/viewpage.action?pageId=7565

프리팩토링

Ken Pugh / 한빛미디어

김창준님의 흥미로운 객체에 대한 이야기는 DDD책에서 나오는 이야기와 일맥상통한다. cohesive하고, 도메인 객체 자신이 많은 이야기를 할수 있는 객체는 내가 코딩을 할때 큰 기쁨을 줍니다. DDD에서는 RIch Domain을 만들어가는 것은 쉽지 않은 일이지만, 진정한 Rich한 Domain객체를 만드는 일은 정말 의미있는 일이라고 나옵니다.

객체지향을 하다가 보면, 흥미로운 객체, Rich한 Domain객체에 대해 만들고 싶은 마음이 많습니다. 하지만, 제 경우에는 한번에 만들어지지 않고, 이리저리 refactoring을 하다가 발견이 되더군요. 김창준님 애기처럼 발견이라는 말이 더 어울립니다.

김창준님, 이희승님, cavin님 덧글 고맙습니다...^^