일단 코드를 문서화 없이 볼수 있게 가능한 만들고 부족한 부분을 문서화 하자. 문서화를 하고 코드를 작성하는 것도 미련한 짓이다. 정성들여 문서화한 내용이 개발이 완료할 때쯤이면 너무나 많이 달라져 있을 테니까.
개발 중에 이익을 얻으려면 최소화의 문서화를 하고 개발을 시작하는 것이 좋다. 이 문서화는 커뮤니이션을 통해서 나온 결과 중 잊혀지기 쉬운 것들 일수록 좋다.
소프트웨어 내부에 대한 설명 문서를 대량으로 작성하는 것은 상호 이익 원칙에 위배되는 한 예이다. 장래 누군지 알지 못하는 사람이 혹시 코드를 유지보수할지도 모르니깐 그것을 쉽게 해주기 위해서 지금 내 개발 속도를 현저하게 떨어뜨리라는 뜻이니까 말이다.
극단적으로 미래지향적으로 설계를 하고 개발하는 것은 올바른 행동이 아닐 수도 있다. 필요하게 될까봐 유연성을 극단적으로 고려하고 과다한 업무를 하는 것은 바보같은 짓이다.
나는 오늘 더 나은 설계와 구현을 하도록 도와주는 자동화된 테스트를 작성한다. 그리고, 그 테스트들은 미래 프로그래머들도 쓸 수 있게 남겨 놓는다. 이러한 실천방법은 지금 내게도 이익이 되고 미래 유지보수자에게 이익이 된다.
나는 우발적인 복잡성을 제거하기 위해 신중하게 리팩터링한다. 이것은 내게 만족감을 주며, 결함의 숫자도 줄여주는데다가, 나중에 코드를 볼 사람이 그것을 더 이해하기 쉽게 해준다.
나는 일관성 있고 명시적인 메타포 집합에서 이름을 골라서 쓴다. 그러면 내 개발속도도 높아지고, 새로 오는 프로그래머들에게 코드가 더 명확하게 보인다.
나는 우발적인 복잡성을 제거하기 위해 신중하게 리팩터링한다. 이것은 내게 만족감을 주며, 결함의 숫자도 줄여주는데다가, 나중에 코드를 볼 사람이 그것을 더 이해하기 쉽게 해준다.
나는 일관성 있고 명시적인 메타포 집합에서 이름을 골라서 쓴다. 그러면 내 개발속도도 높아지고, 새로 오는 프로그래머들에게 코드가 더 명확하게 보인다.
메타포 집합을 미리 정의를 해두면, 혼란스러운 네임을 만들지 않아도 된다. 혼자의 생각으로 만든 메타포들은 시처럼 감동적일 수는 있으나, 일반적이지 않을 수도 있다.
커뮤니케이션 부족으로 메타포가 2개의 되었을 때는 잘못된 이름의 메타포가 하나 있는 것보다 더 큰 해악을 만들어 낸 것이다. 하나의 잘못보다는 2개가 공존하는 상태가 더 복잡하기 때문이다. 하나의 잘못을 떠안고, 또 하나 알아야 할 것이 많아졌다는 이야기이다.
트랙백 보낼 주소 :: http://www.ologist.co.kr/trackback/703
-
좋은 개발자가 되기 위해서 어떤 것들이 필요할까?
from ologist`s blog2.02007/08/06 22:01
난 좋은 개발자가 되고 싶다.좋은 개발자가 될수 있는 기준은 무엇일까? 정말 그 기준을 몇 줄로 적을 수가 있을까?난 좋은 개발자의 기준을 정확히 생각을 해본적은 없는거 같다.주위에서 좋은 개발자있으면 소개시켜달라는 이야기를 많이 듣고는 하는데, 그럼 좋은 개발자는 어떻게 표현을 할수가 있을까?좋은 개발자가 되는 기준은 무엇일까? XP(p.52)에 보면 다음과 같은 이야기가 나온다. 기본적인 안전 - 배고픔, 물리적 상해, 사랑하는 사람에 대한 위협..
