clean code
제 생각은 그렇습니다. 코드를 유지보수하거나 신규로 작성을 하다가 보면 항상 선택이 순간들을 맞이 하게 됩니다.
이 때, 대부분의 개발자들은 욕심을 가지게 됩니다.(물론 저도 자주 그래왔구요...^^;)
욕심...이것을 잘 통제해야 합니다.
1. 테스트 커버리지를 높이고 싶은 욕심에 테스트가 필요없는 메소드를 테스트를 만들어서 테스트 유지보수를 더 힘들게 하는 경우도 있습니다. 정말 만들어야 하는 부분은 반드시 만들어야 하는 것이 테스트 코드지만, 작성시에도 적은 코드량으로 테스트를 만들 방법을 고민해야 합니다.
2. 내가 만든 코드들이 지나친 일반화나 강제화때문에 사용하는 개발자들이 불편해 합니다. 세부적인 영역의 내용들은 캡슐화를 통해서 적게 보여야 정확한 비즈니스 로직이 보입니다.
선택의 순간
설계를 하다가 선택의 순간이 왔을 때 가장 중요한 것은 무엇일까요?
신규 코드를 작성하거나 코드 개선시에 제가 중요하게 생각하는 요소는 다음과 같습니다.
1. SAFE and SAFE: 솔루션이던지, 서비스던지 첫째는 안정적이어야 합니다.
2. 중복제거
중복의 해악에 대해서 다들 아시겠지만, 중복이라는 것을 발견하는 sensing이 필요합니다. ex) 코드 중복, 로직 중복, 라이프싸이클 관리 중복 등등
블로그같은 경우의 예를 들어보죠. 프레임워크 중복, 프로젝트의 중복, 코드상의 중복, dependency의 중복.
중복이 없게 아키텍쳐를 설계하거나 코드를 작성을 하다가 보면, 좋은 디자인이 나오는 경우가 많습니다.
2. 가독성(composed method, good naming, etc)
3. 의존성 최소화
cyclic의 방지
테스트 작성의 용이함
변경시에 영향도 최소화
현재 상태에서 고민을 해봅시다.
프레임워크를 변경(자주 일어나는 일은 아니지만 아예 없는 일은 아니죠?) webwork에서 struts2.0으로 간다면? spring에서 google juice로 dependency framework를 변경한다면?
외부 라이브러리들이 버젼이 올라가면서 하위버젼을 지원하지 않는 경우가 많다면?
클래스의 인터페이스를 변경해야 한다면?
4. 성능(구현 후 tuning을 하는 것이 설계시 덜 헷갈립니다.)
긍정적인 마음
실무에서 정확한 판단을 하기는 쉽지 않습니다. 잘못된 구현이나 판단을 할수도 있습니다.
항상 베스트 프랙티스로 만드는 사람들은 훌륭한 개발자라기보다는 훌륭한 예언가일 것입니다.
결국엔 점진적으로 더 나은 방향으로 개선을 해야겠다는 에너지와 의지가 더 중요할 수 있습니다. 노력을 한다면, 좋아 질수 있습니다.
트랙백 보낼 주소 :: http://www.ologist.co.kr/trackback/936
-
발상의 전환
from ologist2.0 입니다~!2009/03/17 19:47
발상의 전환 http://news.naver.com/main/read.nhn?mode=LSDmid=secsid1=101oid=001aid=0002553366 사람을 위한 것은 언제든지 환영이다. 홈플러스 그렇게 안봤는데, 좋은 기업이군! -
Clean Code - A Handbook of Agile Software Craftsmanship
2009/04/03 08:52 Clean Code - A Handbook of Agile Software Craftsmanship Robert. C. Martin Object Mentor의 대표인 Robert. C. Martin의 2008년 8월에 출간된, "클린 코드를 작성하는 핸드북" 정도가 되겠다. Steve Mcconnell의 Code Complete가 개발 전체를 망라한리스트이고, Martin Fowler의 Refactoring이 작성된 후의 코드 덩어리를 재구성하는 것.. -
Heart의 생각
from heartsavior's me2DAY2009/05/14 10:34 clean code 이야기코딩 시에 발생하는 선택의 순간… 말 그대로 clean code 를 향해야 한다
