'Ruby On Rails/agile note'에 해당되는 글 4건

  1. 2012/05/04 코딩하기전 생각하는 습관을 가져라.
  2. 2008/05/26 Code Review
  3. 2008/02/25 Getting Real~!
  4. 2007/11/26 start agile!
Ruby On Rails/agile note2012/05/04 17:32

내 주변에 나이는 어리지만 코딩을 잘하는 친구들이 몇몇 있다.

그 나이 또래 아이들과 비교하면 잘한다. 인정한다.

하지만 결과물만 만들어 낼뿐 그 과정이나 코드를 보면.. 막막하다.

그리고 이 결과물도 사실은 굉장히 내구성이 약하다.

그 이유야 여러가지가 있겠지만, 딱 하나를 꼽으라면

생각없이 그냥 막 코딩을 하기 때문이다.



생각없다는 표현이 좀 심했나? 그래 인정한다. 표현이 심했다. 사실 나도...

좀 더 순화시키고 디테일하게 말을 하자면 설계하는 과정이 없다는 것이다.

설계라고 하니 거창해 보이지만 내가 말하는것은 전체적인 구조를 짜는거 말고 어떻게 코딩할것인지 생각하는 과정이 없다는 것이다.


설계하는 과정이 없으니, 코드는 당연히 스파게티가 되고


음식 스파게티 사진맛있어보이는가? 저거 한가닥 한가닥 풀어볼 생각해봐라 ㅋㅋ


스파게티가 되니 버그가 많아지고

스파게티가 되니 디버깅도 힘들어지고

스파게티가 되니 협업하는 다른 개발자가 코드를 보기 힘들어지고

그렇다보니 다른 개발자도 "이미 버린 코드구나"하고 스파게티로 짜게 될 확률이 높아진다.

결국 코드는 산으로 가고

간단한 기능 수정하거나, 디버깅하는데 하루를 다 허비하게 되고

일정은 다가오고

일정을 맞추기 위해 맨날 밤새고


월화수목금금금 코딩하는 개발자


그러다 답이 없어서, 다른 프로젝트를 진행중이던 다른 개발자도 참여하게 되고

땜빵으로 들어간 다른 개발자는 코드를 보고 한숨을 쉬고 멘붕

땜빵 개발자는 억울하지만 어쩔 수 없이 같이 계속 밤새며 타이핑 한번, 한숨 한번, 타이핑 한번, 한숨을 반복하며 "내가 왜 여기있지?"라는 의문과 함께 코딩을 하고 (내 경험담이라 감정 이입해서 쓴거다.. ㅋ)

어찌어찌 오픈을 해도, 유리같은 결과물이라 툭 하면 에러나고, 컴플레인 들어오고



또 다시 디버깅을 위해 밤을 새고..

다음 릴리즈 일정은 다가오고

또 다시 밤을 새고

결국 회사는 망하게 되고


출근 안해도 된닼ㅋㅋㅋ


뭐 이런 악순환의 반복이 된다.


단순히 어떻게 코딩할 것 인지 고민을 안한것 만으로 도미너 처럼 하나하나 넘어져 결국 회사를 망하게 하거나 동료 개발자를 멘붕시킬 수 있다.

"문 헛소리냐? 님 쪼랩임? 애자일 모름? ㅋㅋ 난 애자일하게 하는거거든?" 이라고 카우방에서 젖소가 블리쟈드쓰는 소리를 한다면. 이런말 하는 사람은 디아2 해보지도 못한놈이 카우방 얘기하는거나 마찬가이다.

애자일을 이런 상황에 가따붙이라고 만든거 아니거든요? ㅋㅋㅋ

암튼, 여기서 교훈은 동료 개발자가 싫거나, 회사가 맘에 안들면 생각 따윈 집어치고 그냥 막 코딩을 하면 된다는 귀중한 가르침이다.

끝.










이라고 한다면 안그래도 방문자 없는 블로그인데

응? 방문자 없는 블로그니깐 이렇게 끝내도 아무도 모르겠구나.ㅋㅋㅋ

나 천재인가봐? ㅋㅋㅋ

불평만 하는 글이 됨으로, 부족한 사람이지만 몇가지 가이드를 책임없이 던져본다.

다시 말하지만 책임없이 던진다. 나한테 뭐라하기 없기다? ㅋㅋ


내용이 아주 오래전부터 할아버지 선배님들때부터 해오던 얘기들인것 같아 고리타분해지는것 같은데..


사실 코딩을 잘못해도 상관없다.

코딩은 그냥 하면 된다. 중요한것은 어떻게 코딩할것인가다.

설계를 어떻게 할 것인가? 이런거 얘기안할거다. 이건 책 봐라. 책 많다.

난 코딩하기전 이런 습관을 가져라 라고 얘기하고 싶다.



전체적인 그림을 그려라.



혼자하는 프로젝트일 경우, 생략할 수 도 있지만.. 이것도 짬이 없으면 해야 한다.

암튼 하면 좋다. ㅋㅋㅋ

정확할 필요는 없다. 많은 시간을 할당하지 않아도 된다.

빼먹는 부분(구멍)만 없으면 된다. 열심히 그렸는데 화장실 빼먹으면 망하는거다 ㅋㅋ


전체적인 그림을 그리는것은 설계의 기본이다.

그리고 일정을 산출해 내는데 유리하다. 

일정 다되서 막판에 회사에서 먹고자고 할텐가?



당신이 말단(신입)이라면 "내가 해봤자 어차피 팀장 따라 가야하는데 무슨 소용이냐?"라고 생각할 수 있다. 

이런 생각을 한 당신.. 평생 말단(신입)으로 있을것 같나? 언젠가 당신도 팀장이 된다.

그 때를 위해 미리 경험치를 쌓아둔다고 생각해라. 팀장이라는 훌륭한? 교본도 있지 않은가? (팀장님들 긴장트리좀 타삼 ㅋㅋ.. 근데 나부터 타야하네;; ㅋㅋ)



차분히 내가 해야 할 일이 무엇인지 파악하라.



전체적인 그림을 그렸는가? 잘했다. 쓰다듬어 드림. 쓰듬쓰듬..?

그럼 이제 내가 해야할 일이 무엇인지 테스크를 파악해야 한다.

매일매일 출근해서 가장 먼저 할 일은 오늘의 할일을 선정하는것이고

퇴근할때 얼마나 했는지, 내일은 무슨 일을 할 것인지 선정하는 것이다.

다음날 출근시 오늘의 할일을 다시 선정할 필요는 없고.. 어제 퇴근하면서 선정한 테스크들을 보며 체크만 하면 된다.

테스크 추출하는것.. 처음엔 귀찮을 수 있다. 그리고 쉽지 않다.

하지만 꾸준히 반복적으로 해라. 아주 중요한 것이다. 그냥 습관으로 만들어라.


단순히 오늘의 테스크만 뽑았다고 끝나는 것이 아니다.

다음 단계가 있다. 바로 뽑아낸 테스크 하나하나를 어떻게 코딩할 것 인지 고민하는 것이다.

네임스페이스를 정하는것만 해도 상관없다.


처음에 큰 그림을 그리면, 추상적인 설계가 어느정도 머리속에 있게 된다.

하지만 테스크를 발라내게 되면.. 이 설계가 조금은 실제화가 되는데

이때 네임스페이스를 정해주는게 훨씬 쉽고, 

구조를 수정하는 일이 상대적으로 적어진다.



네이밍에 허비하는 시간을 아깝게 생각치 마라



메소드를 만들든, 프로퍼티를 만들든, 펑션을 만들든, 변수를 만들든.

제발좀 네이밍에 신경을 써라.

상황에 따라선 코딩하는 시간보다 네이밍하는데 시간을 더 써야 될 때도 있다. 물런 항상 그러면 안된다. ㅋㅋ

제발 좀!!

의미에 맞는 네이밍해라. 영어사전 항상 열어놓아라. 아님 구글번역기라도 돌려봐라.



스스로 먼저 리뷰를 요청해라



리뷰를 꼭 해라. 혼자 하지 말고 최소한 같이 프로젝트한 팀원들과 해라.

이 프로젝트에 참여하지 않은 사람들은.. 첨부터 끝까지 설명해야 해서 귀찮긴 하지만.. 

서로에게 자극을 주고 배움을 주는거니 거절하지는 마라.

가능하다면 고수도 껴넣어라. 없어도 상관은 없다.

혹 코드리뷰하는 분위기가 아닌가? 그럼 당신이 만들어라.

용기 있는자가 미인을 쟁취한다는 말도 있지 않은가?

...........? ㅋㅋㅋㅋ

도저히 용기가 안난다면, 맘 맞는 몇명만 불러서 해라.

맘 맞는 사람이 없나?

그럼 친하고 신뢰할 수 있는 사람을 불러서 해라.

커피 한잔 사준다고 꼬득여서 해라.

어쨋든 해라.

그리고 가능하면 사수는 꼭 넣어라.

아에 신입이면 페어프로그래밍 하면서 이런것 하나하나 일일이 지적할 수 있지만.

겅력 2년정도 된 사람들은, 페어프로그래밍하면서 하나하나 지적하기가 힘들다.

왜냐면.. 이미 나쁜 습관이 들어있고.. 경력이 있다보니 쫀심이 있어서.. 되려 카운터 얻어맞을 수 있기 때문이다.

물런. 착한 사수는 그런거 신경안쓰고 열심히 가르켜주겠지만.. 난 한번 당한 경험이 있어서 말이지..

요즘 아이들 무섭다 ㅠ,.ㅠ 어른을 존경하는 마음을 떠나.. 이타심 자체가 부족하다.

암튼. 아무래도 경력이 있다보니 기본적인 구조, 네이밍을 지적하기가 여간 조심스러운게 아니다. 그래 나 소심하다 ㅋㅋ

리뷰타임에서는 페어프로그래밍할때 못했던 말들, 페어프로그래밍하면서 놓쳤던 부분, 혹은 페어프로그래밍할때 잘못 작성한것들 등등을 발견하고 서슴없이 깔 수 있기 때문이다.



하지만 사장님에겐 따뜻하겠지..

여기서 중요한것은 코드리뷰할때 내가 작성한 코드는 없다. 우리가 작성한 코드만 있을뿐이다.

그러니 발끈하거나 감정 상하지 마라.


쓰다보니 해주고 싶은 말이 너무 많지만.. 그런거 다 쓰자니 내가 귀찮아서 ggㅋㅋㅋ

쓰고보니 결국은.. 수백번은 봤을 수 도 있는 이야기들이다. 봤으면 뭐하나.. 실행을 안하는데..

제발 좀 행동으로 옮겨라!!!




간만에 포스팅이라 제가 감(글쓰는 법, 개그감)을 잃었나봅니다.

죄송합니다. ㅠ,.ㅠ


도망가자. ㅋㅋ

하지만 읽어준 당신에겐 감사. 

크리에이티브 커먼즈 라이선스
Creative Commons License

'Ruby On Rails > agile note' 카테고리의 다른 글

코딩하기전 생각하는 습관을 가져라.  (0) 2012/05/04
Code Review  (0) 2008/05/26
Getting Real~!  (0) 2008/02/25
start agile!  (0) 2007/11/26
Posted by Johan Kim hiphapis

TRACKBACK http://hiphapis.net/trackback/201 관련글 쓰기

댓글을 달아 주세요

Ruby On Rails/agile note2008/05/26 21:38
Code Review를 하면 Code를 짠 개발자는 얼굴이 붉어지고 기가 죽게된다.
한마디로 발가벗겨진 느낌이 든다.
아마 개발자의 자아가 Code에 담기기 때문이 아닐까..?

하지만 발가벗겨진만큼 배우게 된다.

ps. 그렇다면 많이 발가벗겨질수록 좋은건가..?
크리에이티브 커먼즈 라이선스
Creative Commons License

'Ruby On Rails > agile note' 카테고리의 다른 글

코딩하기전 생각하는 습관을 가져라.  (0) 2012/05/04
Code Review  (0) 2008/05/26
Getting Real~!  (0) 2008/02/25
start agile!  (0) 2007/11/26
Posted by Johan Kim hiphapis

TRACKBACK http://hiphapis.net/trackback/126 관련글 쓰기

댓글을 달아 주세요

Ruby On Rails/agile note2008/02/25 17:42
알만한 사람은 다 알겠지만 얼마전 37signals에서 새로운 책 Getting Real 이 나왔다.
Getting Real37signals에서 사용하는 방법론인데 읽어보면 알겠지만 많은 부분들이 Agile 방법론과 일치한다.
상당히 유익한 내용이 많기때문에 관심있는 사람은 한번 읽어보길 추천한다.

책으로 발매된것은 돈을 내고 구매를 해야 되지만, 온라인으로는 공개가 되어 있어 무료로 볼 수 있다. 그리고 다행스럽게 한국어로 번역도 되어 있다.

크리에이티브 커먼즈 라이선스
Creative Commons License

'Ruby On Rails > agile note' 카테고리의 다른 글

코딩하기전 생각하는 습관을 가져라.  (0) 2012/05/04
Code Review  (0) 2008/05/26
Getting Real~!  (0) 2008/02/25
start agile!  (0) 2007/11/26
Posted by Johan Kim hiphapis

TRACKBACK http://hiphapis.net/trackback/107 관련글 쓰기

댓글을 달아 주세요

Ruby On Rails/agile note2007/11/26 22:43
오늘은 개발자인생에서 뜻깊은 날 중 하나이다.
그 이유는 바로 애자일 방법론, 즉 XP(Extreme Programming)와 TDD(Test Driven Development, 테스트 주도 개발)를 시작한 날이기 때문이다.
첫날인 오늘은 부담없이 간단한 새기능을 TestCode(Unit Test)부터  짝프로그래밍(Pair Programming)으로 개발을 했다

사실 짝프로그래밍은 몇번 경험해봤지만 이렇게 심도있는 짝프로그래밍은 처음이었다.(아니 어쩌면 내가 경험했던 짝프로그래밍이 짝프로그래밍이 아닐 수 도 있다..?)
짝프로그래밍을 하면서 가장 어려웠던것은 짝이
이렇게 해보자
이건 이렇게 구현이 되어야 할것 같아
같은 의견을 내놓으면 키보드맨인 내가 코딩을 해야 하는데 그러다 보면 나의 생각이 끊겨버리는 경우가 많았다. 생각이 자꾸 끊기다보면 내 생각은 없어지고 옆에서 짝이 말하는대로만 타이핑하고 있는 멍함과 "내가 무슨생각하고 있었지?" 하는 혼돈이 머리속에 공존하는 타이핑로봇으로 변신을 해버리는데 이게 정말 힘들었다.
오늘 내가 뭘 코딩한건지 사실 아직까지 한 20%는 잘 모르겠다...;;
물런, 익숙하지 않은 언어인 ruby를 사용했고 내가 개발에 전혀 관여하지 않았던 코드라
이 코드가 어떤 프로세스에 대한 기능인데 이러저러한 filter를 거치고 이러저러한 일을 해서 이러한 일을한다
라는 큰흐름에 대한 이해도도 부족한데 거기다 언어까지 생소하니...
(물런 변명으로 들리겠지만 사실 변명이다. 하지만 20%정도는 진실이다!)

오늘 작업한 check_conflict 는 login이 필요한데 test code에서 login처리가 잘 안되서 3시간 삽질을 했다.
ruby가 unit test기능을 제공해줘서 고맙긴 한데..이 자식, 에러가 나면 정확한 Hint좀 줄것이지..IE에서 Javascript Error처럼 막연하게 무슨에러인데 몇번째 라인이다. 라고만 나온다.
삽질했던건 login session 처리와 redirect에 대한거였는데 좀 정확한 Hint를 줬었더라면 1시간만에 끝낼 수 도 있었을텐데...나쁜놈...


멍청한 타이핑로봇이 되지 않기 위해 앞으로 짝프로그래밍에 좀 더 적응해야 할 거 같다.
나의 가장 큰 문제점은 생각을 공유하지 않았다는 점에 있는것 같다.
짝의 의견을 바로 타이핑하지 않으면 왠지 짝의 의견을 무시하는것 같아서 내 생각을 끊고 타이핑로봇으로 변신을 하게되는데 역시 이건 애자일 스럽지 않은것 같다.
짝도 나도 이런것으로 부터 자유로와지는것이 애자일인데 아직 난 준비가 덜 되었나보다.
좀 더 애자일 스러워지도록 노력해야겠다. 무조건 받아적는 타이핑로봇이 아니라 생각을 공유하며 함께 프로그래밍을 해 나가도록 말이다.


첫걸음은 괜찮은것 같다.
비록 애자일스러운 짝프로그래밍을 완벽하게 못했지만 옛말에 "첫술에 배부르랴" 했다.
이제 시작이다. "애자일스러운 짝프로그래밍을 못했다"라고 인식하고 그것에 대한 원인을 발견한 것 만으로 난 만족한다.

몇마디 더 쓰고 싶은데.. 와이프가 밥먹으로 난리다;;
그래서 오늘의 일기 끝~
크리에이티브 커먼즈 라이선스
Creative Commons License

'Ruby On Rails > agile note' 카테고리의 다른 글

코딩하기전 생각하는 습관을 가져라.  (0) 2012/05/04
Code Review  (0) 2008/05/26
Getting Real~!  (0) 2008/02/25
start agile!  (0) 2007/11/26
Posted by Johan Kim hiphapis

TRACKBACK http://hiphapis.net/trackback/79 관련글 쓰기

댓글을 달아 주세요