블로그 이미지
소프트웨어 개발 경험을 공유하고 싶은 재밌게 사는 소프트웨어 엔지니어입니다^^

카테고리

Chungha Story (41)
Agile Experience (22)
My Family (0)
Life Style (7)
Programming (8)
Android (2)
Total
Today
Yesterday

달력

« » 2024.4
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 30

최근에 올라온 글

최근에 달린 댓글

저희 회사에서 제품의 품질을 높이기 위해 지난 1년간 코드리뷰를 전사적으로 진행했습니다.
하지만 리포트 형식만 던져주고 어떠한 교육이나 코칭이 없는 상태에서 진행되다 보니 업무에 부담만 되었습니다.
소스코드 출력해서 수정된 부분 체크하고 이전 버전도 체크하고..등등..ㅠㅠ

몇달전에 박형근님 블로그(코드리뷰, 좀 쉬운 방법은 없을까?)에서 공짜로 책을 준다는 글을 읽고 바로 신청했습니다.
지금도 공짜로 보내주고 있네요^^

책을 읽어보니 이메일로 코드리뷰를 하는 방법이 소개되어 있었습니다. 그래서 가장 간단한 형태로 적용해보기로 했습니다
그 형태는 체크아웃된 소스코드를 작업하고 체크인할 때 수정내용을 입력하도록 하고 이전 버전과의 차이점을 이쁘게!!! 팀원 전체에게 이메일로 보내는 것이었습니다. 이렇게 하면
  1. 팀원들이 쉽게 볼수 있기 때문에 코드 정리에 더 신경쓰게 된다.
  2. 어떤 내용을 수정했는지 히스토리가 명확하게 남을 수 있다. (모두가 보고 있음..ㅋㅋ)
살짝 이 정도의 장점이 생기는것 같습니다.
물론 반발을 최소화 하기 위해 저 방법을 안써도 체크인 할 수 있도록 했습니다. 
하지만 요즘은 팀장님이 리뷰할 수 있게 체크인 해달라고 요구하십니다.ㅋㅋ 팀장님은 상시 리뷰어로써의 역활을 하고 계시죠..
굉장히 단순한 형태이긴 하지만 그 효과는 괜찮은것 같습니다.

저희 코드리뷰 이메일은 다음과 같이 vim에서 보는 것과 동일한 형태로 보내집니다.
  • vim에서 C syntax highlight에 diff highlight를 추가하였습니다.
  • vim에서 :runtime! syntax/2html.vim 을 실행하면 highlight 된 형태를 html 포멧으로 저장해줍니다.
Posted by 윤청하
, |
최근에 신입 개발자 분이 들어오셨습니다.
팀에서 데일리 미팅을 진행하고 스프린트 회고/계획 회의를 진행합니다.
모르는 내용이 나오면 옆에 사람 붙잡고 물어봅니다.
열정이 있어보이셔서 제가 슬쩍 책을 한권 건냈습니다. (패턴 그리고 객체지향적 코딩의 법칙)
신입에게는 살짝 어려울수 있는 내용이지만 쉽게 이야기 형식으로 풀어 쓴 내용이라 읽는데에는 문제가 없을거라 생각되었습니다.
일주일 내에 읽기로 약속했습니다. (브라보~) 
그리고 하루만에 리액션을 주셨습니다. (데일리 미팅에서 살짝 귓속말로..ㅋㅋ)
"책 너무 재미있게 읽고 있습니다. 제가 잘못하고 있었다는게 느껴지네요.."
이분과 같이 일하면 즐거울거라 예상됩니다.

비교하면 안되지만..ㅠㅠ 2년전에 들어오신 신입분은 제가 책을 건내면..
"전 잘 모르는데.."
그 뒤로도 리액션이 없었습니다.
스터디를 제안해도, Pair Programming을 제안해도 해본적 없고, 잘 모른다고 빼기만 하십니다.
리액션 부탁도 해보고 얘기도 많이 시도해봤지만, 솔직히 같이 일하기 어렵습니다.
술도 안드셔서 술한잔 하자고도 못합니다.ㅠㅠ

리액션이 없으면, 상대방이 뭘 원하는지, 어떤 생각을 하시는지 공유하기 너무 어렵습니다.
강호동 만큼은 아니더라도 살짝~ 리액션 부탁드릴게요~ㅠㅠ

'Life Style' 카테고리의 다른 글

처음으로 이직 했습니다.  (6) 2010.03.11
당신의 꿈은 무엇인가요?  (2) 2010.01.13
개발자와 다이어트  (6) 2009.12.26
Posted by 윤청하
, |
저는 스크럼, 테스트 주도 개발, 짝프로그래밍, XP의 원칙과 가치 등을 처음 접했을 때 큰 영감을 받았던 기억이 있습니다.
이런 것을 팀에 도입한다면 한단계 발전하는 팀이 될 수 있을 거라는 확신이 들었습니다.
고민했던 생각들을 실천하고 주변사람을 선동하는데 익숙한 저는 바로 실행에 옮겼습니다.
우리는 XXX 문제들이 있기 때문에 YYY를 도입해서 해결해야 합니다.
그리고 우리는 YYY를 도입했습니다.

새로운 것을 도입하는 것이 끝은 아니다.
스크럼은 정말 쉬워보였습니다. 그래서 우리는 스크럼을 가장 먼저 도입하기로 하였습니다.
약 1년간의 스크럼을 해보면서 느낀 것은 새로운 프로세스와 방법을 도입하는 것은 단순한 액션에 불과하다는 것이었습니다.
새로운 것이 정착하기 위해서 우리는 기존의 것을 포기해야 했습니다. 
적게는 수년에서 많게는 십수년의 경력동안 유지했던 자신만의 틀을 깨야 했습니다.

  • 매일매일 자신의 일정과 업무 진행 상황을 모든 팀원에게 솔직하게 공개해야 했습니다.
  • 팀장님은 외부와의 업무 상황 및 요구사항의 출처 및 발생 이유에 대해서 모두 공유해야 했습니다.
  • 특정 개발자만 처리할 수 있는 소스코드가 없어져야 했습니다.
  • 우리 팀의 상황을 타 팀(영업, 마케팅, QA 등)에게 여과 없이 공개해야 했습니다.
이 외에도 여러가지가 있습니다. 하나하나의 틀을 팀원 각자가 깨나가야 했습니다. 정말 어려웠습니다.

틀을 깬다는 것은 안해봤던 일을 시도해보고 새로운 틀을 만드는 것이다.
기존의 틀이 개발 생산성에 문제가 된다면 과감하게 깰수 있어야 합니다. 단, 단순한 현상이 아닌 핵심이 되는 원인을 깨야 합니다.
그리고 새로운 틀을 만들 수 있어야 합니다. 그 틀이 멋진 선배들이 만들어 놓은 것이라면 자신에게 맞게 고칠 줄도 알아야 합니다.
새로운 기술, 새로운 방법, 새로운 환경이 매일 차고 넘치기 때문에 소프트웨어 엔지니어라면 항상 틀을 깰수 있어야 합니다.
이미 아는 기술, 써봐던 방법, 경험했던 환경이 아니라고 해서 할 수 없다고 말씀하시는 분은 진정한 소프트웨어 엔지니어가 되기 힘들것입니다.
저는 그 틀을 깨는 경험들을 공유하고 싶습니다.^^ 같이 깨보실래요?ㅋㅋ
Posted by 윤청하
, |