'XP'에 해당되는 글 3건

  1. 2007/08/06 좋은 개발자가 되기 위해서 어떤 것들이 필요할까? (13)
  2. 2007/08/06 진정한 XP는? (12)
  3. 2007/07/18 상호 이익 (18)
난 좋은 개발자가 되고 싶다.

좋은 개발자가 될수 있는 기준은 무엇일까? 정말 그 기준을 몇 줄로 적을 수가 있을까?

난 좋은 개발자의 기준을 정확히 생각을 해본적은 없는거 같다.

주위에서 좋은 개발자있으면 소개시켜달라는 이야기를 많이 듣고는 하는데, 그럼 좋은 개발자는 어떻게 표현을 할수가 있을까?

좋은 개발자가 되는 기준은 무엇일까? XP(p.52)에 보면 다음과 같은 이야기가 나온다.

  • 기본적인 안전 - 배고픔, 물리적 상해, 사랑하는 사람에 대한 위협에서 자유로워야 한다. 실직에 대한 두려움은 이 욕구를 위협한다.
  • 성취감 - 자신이 속한 사회에 기여할 수 있는 기회와 능력
  • 소속감 - 어떤 집단에 자신이 속함을 느끼고, 그 집단에서 자신의 존재이유와 책임감을 끌어내며, 그 집단 구성원들이 공유하는 목표에 기여할 수 있는 능력
  • 성장 - 자신의 기술과 시야를 확장할 수 있는 기회
  • 친밀감 - 다른 사람을 깊게 이해하고 다른 사람들에게도 깊이 이해 받을 수 있는 능력

팀이 원하는 일하고 개인이 원하는 일이 틀릴 수도 있다.
언제나 개인이 욕구를 희생하는 것은 좋은 결과를 얻을 수 없다.

회사의 비젼과 팀의 비젼, 그리고, 개인의 비젼이 어느 정도 일치를 해야 소속감과 함께 성취감을 맛볼수가 있다. 사람은 부품으로 생각되어지면 안된다.

Posted by ologist

2007/08/06 21:47 Developer

진정한 XP는?

최근에 각광을 받고 있는 XP과 애자일 방법론은 막연한 동경과 정말 실용주의(?) 개발을 위해서는 반드시 지켜야할 지침이 많이 이야기한다.

XP 2판도 읽어봤는데, 흥미롭고, 재미있는 내용도 많았다. 예전에 지금보다도 더 초보시절에 XP1판과 refactoring책을 읽고 개념 잘못잡고 헤매였던 기억을 생각하면, 그 동안의 시간동안 나도 어느 정도 성장을 이룬거 같아서 기쁘다.

프로젝트 경험이 많아질수록 좀더 가깝게 느껴지는 생각은 애자일이라는 것은 선택과 집중을 잘해야만 가능하다는 생각이 든다.

그져 코드 쉽게 만들고 원칙을 어겨가면서 클래스량을 줄이는 것이 애자일은 아니라는 것이다. 잘 바뀌지 않는 개념과 원칙을 형식에 얽매이지 않고, 조금 더 잘 할수 있게 하는 것이 더 중요하다.

그만큼 선택과 집중을 할 수 있게 해주는 리더의 역할이 중요하다. 팀원들의 불편함은 무시하고 리더 자신이 편한 것을 얻으려 한다면, 그것은 얼어있는 방법론과 다를 것이 없다.

불편하고, 형식적인 틀 안에서 좀더 편하게 일을 할수 있게 해주는 것, 이것이 진정한 XP이고, 애자일이 아닐까?

익스트림 프로그래밍, 제2판 : 변화를 포용하라

Kent Beck,Cynthia Andres / Insight (인사이트)

 변화를 무조건 포용하려면 너무나 많은 리스크가 발생을 한다. 변화를 위해서 리스크를 줄이는 방법을 이 책에서는 많은 부분 다루고 있다.

1판과는 거의 다른 내용이 들어있으므로, 1판을 본 사람은 다시 한번 이 책을 보기를 바란다. 나는 지금  일독을 거쳐서 2독을 진행 중이다.

Posted by ologist
 TAG Agile, XP

2007/07/18 08:34 Developer

상호 이익

문서를 작성을 할때에는 필요한 만큼만 하자. 문서화가 안되어 있다고 투정부리는 사람들이 있다. 가만히 살펴보면 이런 사람일수록 문서를 잘 안본다. 애써 문서화를 해두어도 전임자에게 구두로 물어보는게 일상이다. 참 귀찮은 일이다. coach나 teach에 관심이 있는 사람은 귀찮지 않을 수도 있다.

일단 코드를 문서화 없이 볼수 있게 가능한 만들고 부족한 부분을 문서화 하자. 문서화를 하고 코드를 작성하는 것도 미련한 짓이다. 정성들여 문서화한 내용이 개발이 완료할 때쯤이면 너무나 많이 달라져 있을 테니까.

개발 중에 이익을 얻으려면 최소화의 문서화를 하고 개발을 시작하는 것이 좋다. 이 문서화는 커뮤니이션을 통해서 나온 결과 중 잊혀지기 쉬운 것들 일수록 좋다.


소프트웨어 내부에 대한 설명 문서를 대량으로 작성하는 것은 상호 이익 원칙에 위배되는 한 예이다. 장래 누군지 알지 못하는 사람이 혹시 코드를 유지보수할지도 모르니깐 그것을 쉽게 해주기 위해서 지금 내 개발 속도를 현저하게 떨어뜨리라는 뜻이니까 말이다.


극단적으로 미래지향적으로 설계를 하고 개발하는 것은 올바른 행동이 아닐 수도 있다. 필요하게 될까봐 유연성을 극단적으로 고려하고 과다한 업무를 하는 것은 바보같은 짓이다.


나는 오늘 더 나은 설계와 구현을 하도록 도와주는 자동화된 테스트를 작성한다. 그리고, 그 테스트들은 미래 프로그래머들도 쓸 수 있게 남겨 놓는다. 이러한 실천방법은 지금 내게도 이익이 되고 미래 유지보수자에게 이익이 된다.

나는 우발적인 복잡성을 제거하기 위해 신중하게 리팩터링한다. 이것은 내게 만족감을 주며, 결함의 숫자도 줄여주는데다가, 나중에 코드를 볼 사람이 그것을 더 이해하기 쉽게 해준다.

나는 일관성 있고 명시적인 메타포 집합에서 이름을 골라서 쓴다. 그러면 내 개발속도도 높아지고, 새로 오는 프로그래머들에게 코드가 더 명확하게 보인다.


메타포 집합을 미리 정의를 해두면, 혼란스러운 네임을 만들지 않아도 된다. 혼자의 생각으로 만든 메타포들은 시처럼 감동적일 수는 있으나, 일반적이지 않을 수도 있다.

커뮤니케이션 부족으로 메타포가 2개의 되었을 때는 잘못된 이름의 메타포가 하나 있는 것보다 더 큰 해악을 만들어 낸 것이다. 하나의 잘못보다는 2개가 공존하는 상태가 더 복잡하기 때문이다. 하나의 잘못을 떠안고, 또 하나 알아야 할 것이 많아졌다는 이야기이다.


익스트림 프로그래밍, 제2판 : 변화를 포용하라

Kent Beck,Cynthia Andres / Insight (인사이트)



Posted by ologist
이전버튼 1 이전버튼

블로그 이미지
ologist

공지사항

Yesterday191
Today136
Total34,708

달력

 « |  » 2012.02
      1 2 3 4
5 6 7 8 9 10 11
12 13 14 15 16 17 18
19 20 21 22 23 24 25
26 27 28 29      

최근에 받은 트랙백

글 보관함