jobGuid 꽃미남 프로그래머 "Pope Kim"님의 이론이나 수학에 치우치지 않고 실무에 곧바로 쓸 수 있는 실용적인 셰이더 프로그래밍 입문서 #겁나친절 jobGuid "1판의내용"에 "새로바뀐북미게임업계분위기"와 "비자관련정보", "1판을 기반으로 북미취업에 성공하신 분들의 생생한 경험담"을 담았습니다. 3ds Max를 사용해서 게임용 3D 캐릭터를 셋업하는 방법
이를 위해 오랜 실무를 경험해 온 저자의 고급 노하우들이 공개
위 내용은 GameDevForever의 저자분들의 홍보를 위하여 운영진 자체적으로 올린 광고이며 일체의 수익이 없습니다.(밥좀사줘요~)
Posted by 김포프

이젠 피할 수 없는 진실이 되고 말았습니다. 사실 실력도 좋은데... 워낙 꽃미남이 되어놓으니... 비주얼로 자꾸 기억해주시는군요.... 뭐 사실은 사실 겸허하게 받아들이겠습니다... -_-

거부할 수 없는 진실은 힘들다.. 어쩌지 이제 잡지 표지모델 제의도 들어오는데...



왠만한 게임 회사에는 프로그래머가 준수해야하는 코딩스탠다드(코딩 스타일이라고도 하죠)가 있는 것 같습니다. 제가 여태까지 프로그래밍을 해오면서도 상당히 많은 코딩 스탠다드들을 봤는데요  (수백만장씩 팔린 패키지 게임에 사용한 엔진만도 5~6개 만져봤으니 뭐 온갖 꼴은 다 봤죠) 요즘들어 코딩스탠다드가 정말 이렇게 빡셀 필요가 있나 하는 의문이 들고 있답니다. (잡생각이 많죠.. 때로...)

우선, 대충 배경지식..... 코딩스타일에서 정의하는 것은 대충 다음과 같습니다.
  • 인덴테이션/줄바꿈
  • 빈칸의 사용
  • 변수이름 짓는 법
  • 함수이름 짓는 법
  • 주석다는 규칙
  • 등등...

코딩스타일의 존재이유?
결국 코딩스타일을 강제함으로 인해 회사에서 얻으려고 하는 건 가독성입니다. 코드 스타일을 통일시키면 다른 프로그래머의 코드를 읽을 때 쉽게 이해할 수 있고, 따라서 생산성을 높일 수 있다는 미신적인 믿음이 존재하죠.

이렇게 하면 프로그래머의 생산성이 높아진다는 부두교의 미신이 있다..... (믿거나 말거나)



코딩 스타일에서 정의하는 것들의 예
우선 코딩 스타일의 예부터.....

인덴테이션/줄바꿈
다음 형태 중에 어떤 놈을 이용할까? 하는 고민...

a)

for ( int i = 0; i < 10; ++i ) {
  sum += i;
}


b)

for ( int i = 0; i < 10; ++i )
{
    sum += i;
}


c)

for ( int i = 0; i < 10; ++i )    sum += i;



등등

빈칸(white space)의 사용
대충 이런 것들 중에 어떤 놈을 써야하는지...

a)

int a = c * ( d + e );


b)

int a=c*(d+e);


등등

변수이름 짓는 법
단어별 대소문자, 멤버변수앞에 m 접두어를 붙이는지 등등...

a)

mMemberVariable = temp_variable * 2.0f;


b)

MemberVariable = tempVariable * 2.0f;


등등

함수이름 짓는 법
단어별 대소문자, private, public 대소문자 등등

a)

int MyClass::getNumPrivate();
int MyClass:GetNumPublic();
int do_something();


b)

int MyClass::_getNumPrivate();
int MyClass:getNumPublic();
int doSomething();


등등

주석다는 규칙
  • 클래스 선언 마다 주석을 달아야 하는가?
  • 함수 선언마다 주석을 달아야 하는가? 변수명 설명? 반환값 설명?
  • 그 외 어떤 코드에 주석을 달아야하는가?
  • 주석 달때 스타일은 어떤걸로? /* ... */,  //, ///, /**...**/ 등등
  • 기타 잡다한 것들...

하지만 의문이 들다
저도 좀 뭔가 깔끔하게 정리되어 있는 걸 좋아하는 놈이라 한동안 이런 미신에 푹 빠져살았습니다. 그런데 최근 몇 년 동안에 '정말정형화된 코딩스타일이 생산성을 향상시키나?'하는 의문이 들더군요. (물론 게임업계에 한정된 이야기입니다. 의료업계에서는 계속 빡세게 해주세요... 수술대 올라갔다가 버그 때문에 뻗은 기계 대문에 죽긴 싫습니다... -_-)

사실 코딩 스타일이란게 종교와도 같은 것이어서 이렇다 할 정답이 없습니다. 프로그래머 10명 잡고 물어보면 다들 선호하는 코딩 스타일이 다릅니다. 일례로 함수이름만 들어도 어떤 프로그래머는 private함수는 getNum() 이란식으로 작성하고 public 함수는 GetNum()이라고 작성하자고 하는 반면 다른 프로그래머는 get_num()과 GetNum()이라고 하자고도 할 겁니다.

어차피 회사란 집단체니까 그냥 일률적으로 정해놓고 프로그래머들을 다 강요하면 된다고 생각하는 건데... 정작 문제는 이 스타일로 개종해야하는 사람들에게는 이게 오히려 생산성 저하의 요소가 됩니다.

중요한건 프로그래머의 상식/배려/역량
그리고 참 웃겼던건.. 제가 지금까지 함께 작업했던 프로그래머만 해도 수백명인데... 그리고 이 엔진 저 엔진 옮겨다니면서 거친 코딩 스탠다드만도 대여섯은 될텐데..... 코딩 스탠다드하고 가독성은 정말 별 상관이 없었단 겁니다. 그보다는 오히려 어떤 코딩 스타일을 사용하던 간에 깨끗한 코드를 작성할 수 있는 프로그래머의 역량이 더 중요하더군요. 이런 분들이 대부분 이었습니다. 즉 굳이 코딩 스탠다드가 필요없는 인간들이 대부분...

회사에서 아무리 철저한 코딩 스탠다드를 만들어 놓아도 코드 드럽게 쓰는 애들(소수에 그칩니다)은 여전히 코드 이해 안되게 쓰더군요. 그래서 이런 애들을 좀 더 잘 관리하려고 코딩 스탠다드에 규칙을 더 추가합니다. 이러면 얘네들이 좀 나아질까요? 아닙니다. 얘네들이 코드가 드러운 이유가 있습니다. 남생각을 별로 안하거든요. 규칙이 얼마나 철저하던 간에 어떻게든 빠져나갑니다. 그 덕에 오히려 원래부터 깔끔한 코드 쓰던 사람들만 고생하죠. 이 사람들은 악법도 법이라고 존중하고, 다른 프로그래머들도 배려할 줄 아는 분들이므로 새로 생긴 규칙에 맞게 또 열심히 코드를 작성합니다. 이 규칙 없어도 원래부터 이해잘되는 깔끔한 코드를 작성하던 사람들인데 따라야 할 규칙만 늘어버렸죠. 

이게 배려라는 거다.... 밥그릇 까지도 깔끔하게... (이미지 출처: http://garul.tistory.com)



결국 제값주고 산 놈들만 손해란 건가?
이렇게 생각을 하다보니.... 꼭 게임에 DRM 입히는거와 마찬가지란 생각이 들더라구요. DRM을 아무리 빡세게 입혀도 해적질 할 애들은 다 해적질하고 쓰니 아무 상관없는데, 정가내고 산 사람들만 그 DRM에 얽매여서 온갖 귀찮은 일을 다 당해야 하는....

해석은 귀찮으니 생략..... 그림만 봐도 대충 뭔 귀찮은 일을 당하는 지 알거다...



차라리 개별적으로 갈구자. 짜르던가. 칼부림도 가끔?
결국 제가 내린 결론은 저희가 너무도 당연하게 여기며 쓰던 코딩 스탠다드가 생각보다 별로 효과적이지 않단 겁니다.

물론 코딩스탠다드를 싸그리 없애자는 건 아닙니다. 좀 최소한으로 줄이자는 거죠. 그리고 코드 드럽게 쓰는 애들을 개별적으로 갈궈서 좀 고치게 하던가... (인간이 직접 갈구는게 문서 던져주고 따라하라는 것보다 훨씬 효율적입니다... 칼부림이 가끔 날 뿐이지... -_-)...... 안되면 그냥 짜르던가....

이런 생각을 하게 된 또 다른 계기는 게임업계가 엄격한 코딩스타일이 필요한 분야가 아니란 겁니다. 어차피 코드작성한 건 다 내부적으로 쓰는거고, 문제 있으면 소스코드가 다 떡하니 있으니 아무나 가서 고칠 수 있으니까요. 게임업계가 아니라 미들웨어를 만들어서 판매하는 회사라던가 군사업체 및 의료장비에 들어가는 소프트웨어를 만드는 회사에서는 이게 좀 더 엄격해야겠죠. 미들웨어 회사는 라이브러리만 던져주는 경우가 많으니 그렇고, 군사업체 및 의료장비는 사람 생명이 걸린 일이라서 어쩌다 뭔 짓을 하더라도 버그를 아예 처음부터 만들지 않는게 중요하니까요. 어차피 게임이 엔터테인먼트 산업이고, 게임의 요구사항은 하루가 멀다하고 바뀌므로 차라리 유연하게 재빨리 코드를 작성할 수 있는게 게임 품질 향상에 더 기여한다고 봅니다. 게임의 품질이란건 사실 게이머가 느끼는 품질일 뿐이거든요. 인간의 목숨이 걸린 의료소프트웨어에서의 품질하고는 전혀 다르죠.

그냥 이정도면 하면 안될까요?
그래서 과연 '코딩스탠다드를 어디까지 줄일 수 있을까?' 하는 걸 좀 생각해봤죠. 이게 좀 간단해야 정작 남 배려할 줄 아는 프로그래머의 인생도 편해지지 않을까 해서....

나도 좀 단순히 편하게 살고 싶다... 물론 패리스 힐튼과 함께.... 근데 토토샵 질이 좀 심한데? -_-



위에서 들었던 목록을 한번씩 살펴보면서 이야기하죠.

인덴테이션
코드의 가독성을 위해서는 여전히 중요하다고 생각합니다. 특히나 코드의 scope를 보여주는데 도움이 되니까요. 근데 이제 Visual Studio 가 이런 인덴테이션을 직접 알아서 해주므로 크게 걱정할 필요가 없습니다. 20년 전에 이런 게 자동으로 안될때나 문제였지...

빈칸사용
뭐 이건 사실 int k = a * ( b + c );로 해주냐 int k=a*(b+c);로 해주냐 차인데... 어떻게 쓰던 코드 이해하는데 별 차이가 없습니다.... 굳이 목숨 걸 필요 없지 않나요? -_-

변수명/함수명
일단 멤버변수 이름앞에 m을 붙이니 public 함수는 대문자로 시작하니 마니 하는 건 이젠 별 의미가 없는거 같습니다. 어차피 IDE가 워낙 좋아져서 그냥 마우스만 올려도 나오는 경우가 많고 아니면 F12키 한번 누르면 곧바로 선언된데로 이동하니까요. 그리고 다시 돌아올땐 Ctrl + -키 누르면 끝이고... Visual Studio의 인텔리센스가 잘 작동안하면 Visual Assist 를 깔아도.....

단, 가독성을 위해 변수명이나 함수명을 잘 작성해주는 건 찬성입니다. 즉 int a = 1; 이라기보단 int numLoop = 1; 이란 식으로 변수명을 작성해주는거죠.. 딱 보면 이해가 되게... 함수명도 마찬가지고요.

주석다는 규칙
사실 주석달아야 할 곳에 안달아서 헷갈리는 경우도 많고, 달지 않아도 될 곳에 달아서 오히려 코드만 지저분해지는 경우 허다하죠... 이건 사실 어떻게 정의해도 코드 드러운 애들은 여전히 드럽고 코드 깔끔한 분들은 여전히 깔끔한.. 그런 부분...

저 개인적으로는
  1. 클래스 이름만 잘 정하면 굳이 클래스마다 주석을 달 필요가 없다. 이름보고 이해안될때만 기재.
  2. 함수/변수 이름만 잘 정하면 굳이 함수/변수마다 주석을 달 필요가 없다. 이름보고 이해 안되거나 변수의 반환값이 기묘할 때만 기재.
  3. 코드에서 곧바로 이해되면 주석은 필요없다.
  4. 옆에 앉은 놈이 코드만 보고 곧바로 이해가 안되면 코드블럭 별로 그 위에 주석으로 기재
정도가 젤 난거 같습니다.

대충 정리
이렇게 써보고 보니 결국 제가 괜찮다고 생각하는 법은 코딩 스타일의 통일성을 유지하려고 괜히 쓸데없는 규칙을 만드는 대신에 개발자들의 상식을 믿으란 쪽이 되어버린듯...

어쨌든 제가 좋다고 생각하는 코딩스타일은 이것 정도입니다.
  • 변수명/함수명에 의미를 담을 것
  • 코드의 스코프를 보여주기 위해 인덴테이션을 잘 할 것
  • 동료 프로그래머가 코드에서 곧바로 이해못할 만한 내용이면 코드 블럭 위해 간단히 주석을 달 것

개종 안하셔도 되요~
뭐, 다들 이러세요~ 라는 걸로 쓴 글은 아니고.... 그냥 한 번 생각해보시라고... 그리고 토론 좀 해보잔 의도로... (어차피 종교적인 토론이라... 난장판이 될 가능성이 높지만...-_-)






댓글을 달아 주세요

  1. Favicon of http://gamedevforever.com zinzza 2012.02.28 09:55 신고  댓글주소  수정/삭제  댓글쓰기

    많은 부분 동의합니다.
    변수명에 의미를 담고, 간단한 주석을 달것...

    사실 나머지에 대해 이야기 하는건 좀 이상하더라구요, 비주얼 스튜디오가 워낙에 알아서 다 해줘서 그런가?

    • Favicon of http://gamedevforever.com 김포프 2012.02.28 15:07 신고  댓글주소  수정/삭제

      특히 이젠 왠만한 게임회사에서 C#과 C++을 같이 써주는 경우라... C#에서 ctrl + k + d만 눌러도 자동으로 다 포맷을 해주는데.. 그거하고 어긋나는 코딩 스탠다드를 C++용으로 쓴다는게.. 쫌.. 무모하게 생각되요...

  2. Favicon of http://gamedevforever.com 끼로 2012.02.29 10:42 신고  댓글주소  수정/삭제  댓글쓰기

    아.. 저희팀 코딩 스탠다드는 한페이지 분량이라 우리는 엄청 가볍게 쓴다! 라고 생각했는데.. 퐆프삼촌 글을 읽어보니 우리꺼도 빡세다는 생각이 좀 드네요..

    • Favicon of http://gamedevforever.com 김포프 2012.02.29 15:40 신고  댓글주소  수정/삭제

      한페이지면 엄청 가벼운게 맞긴 하네요. 그정도 분량이면 크게 무리는 없다고 생각해요.. (그 속에 뭘 정해놨는지는 모르겠지만... ㅎㅎ)

  3. Favicon of http://gamedevforever.com 죠쉬 2012.02.29 11:04 신고  댓글주소  수정/삭제  댓글쓰기

    사실, 코드를 읽다보면 진짜 신경 쓰이는 부분은 인덴테이션과 이름의 의미가 뭔지 뿐이지요

    나머지야 뭐, 조금 답답해 보인다던가, 허전해 보인다던가 이정도 인데 그게 가독성에 영향을 주는지는 정말 의문이지요.

    헝가리언 표기법은 쓰는 사람 마음대로 인지라, 접두어를 봐도 그게 뭔지 상상이 안가는지라 마소에서 정해준 정말 확실한 몇개 외에는 믿지도 않습니다.

    그래도, 그런거에 목숨거는 사람들이 있으니, 대충 다른 코드 보고 그거에 맞춰 코딩 해줍니다.
    그러다보니 예전에는 '내 스타일' 이라는게 있었는데, 요즘은 코딩 할 때 마다 바뀝니다.
    헷갈려요 ㅋㅋㅋ

    아! 주석다는 규칙! 그건 그냥 JavaDOC 스타일로 해버립니다. 지금 하는 일이 SI 인지라, 갑이 문서 달라고 하면 맹글어 줘야 하니까

    • Favicon of http://gamedevforever.com 김포프 2012.02.29 15:42 신고  댓글주소  수정/삭제

      그런거에 목숨거는게 오히려 다른 사람들의 능률을 저하시키는거라면 차라리 살포시 밟아주는게 낫긴 하지요...

      저도 코딩스타일 바꾸는건 아무 문제 없이 해요. 근데 죽어도 못바꾸시는 분들이 있지요... 그럼 괜히 코딩스탠다드가 있으니 거기에 맞추라고 해드려야 하는데... 그러면서도 왜 그러야 하는지 모르겠고.... 악법도 법이다.. 분위기랄까요..

      주석은 그렇게 문서로 뽑아내실 일이 있다면... doxygen에서 지원하는 방법(javadoc도 그 중 하나)으로 하시는게 맞죠.... 근데 대부분 게임코드는 문서로 뽑아낼 일이 없지 않나요 ㅎㅎㅎ

  4. 지라스 2012.03.01 00:55 신고  댓글주소  수정/삭제  댓글쓰기

    저는 주석을 다는게 참 어렵더라구요.

    아니 뭐 귀찮다 이런 문제가 아니라 분명 몇달전에 내가 짠 코드 같은데

    왜 이런 주석이 달려있는지 모를때도 @_@

    그럴때마다 한번에 이해하지 못하게 짠 프로그램 구조도 그렇고

    알아먹지 못하게 달아놓은 주석 적는 능력도 그렇고 아직도 많이 미숙하다는걸 느끼네요 ㅎㅎ

    • Favicon of http://gamedevforever.com 김포프 2012.03.01 09:02 신고  댓글주소  수정/삭제

      주석을 엄청 달아놓은 코드의 문제점중 하나가... 나중에 코드를 바꾸면서 주석을 안바꾸는 경우가 너무 흔히 생긴다는거죠... 코드 바꿀때마다 주석 읽어보고 바꾸는게 얼마나 힘든데요 ㅎㅎ

      뭐 주석이나.. 구조나... 경험쌓이면서 점점 나아지겠죠.. 보통 본인이 미숙한지도 모르는 사람들이 위해서 본문 말한 남 신경도 안쓰는 애들(?).. 이라죠 ㅎㅎ

  5. Favicon of http://gamedevforever.com 대마왕J 2012.03.01 00:58 신고  댓글주소  수정/삭제  댓글쓰기

    흠 몇 년 전에는 이게 뭔소리야 .? 하던 내가 지금은 이 글을 보고 끄떡이고 있다... OTL

  6. Favicon of http://gamedevforever.com 친절한티스 2012.03.01 14:01 신고  댓글주소  수정/삭제  댓글쓰기

    이런거 보면 전 참 깨끗하게 코딩하는것 같아욤. 후훗~ (자화자찬)

  7. ipkn 2012.03.01 19:55 신고  댓글주소  수정/삭제  댓글쓰기

    글에 전적으로 동의합니다. 모든 프로그래머의 실력을 믿을 수 있는 팀에서 일할 수 있다면 코딩 스탠다드는 그냥 시간 낭비일 뿐이거 같아요.

    • Favicon of http://gamedevforever.com 김포프 2012.03.02 03:24 신고  댓글주소  수정/삭제

      그쵸. 그리고 믿을수 없는 프로그래머는 개별적으로 갈궈주던가... 그래도 나아지지 않음 짜르던가... -_-

      문서를 만들어서 던져준다고 절대 나아지지 않는거 같아요....

  8. Favicon of http://gamedevforever.com ozlael 2012.03.02 11:45 신고  댓글주소  수정/삭제  댓글쓰기

    우와 꽃미남이당

  9. Favicon of http://gamedevforever.com Rhea Strike 2012.03.06 18:23 신고  댓글주소  수정/삭제  댓글쓰기

    그냥 팀내에서 서로 싸우지 말고 코딩스탠다드가 지켜지지 않으면 빌드가 안되면 참 편하겠습니다. -_-;;
    분명 그것을 검사할수 있는 방법이 있을텐데요... 어떤 방법이 있을까요?

    • Favicon of http://gamedevforever.com 김포프 2012.03.09 05:14 신고  댓글주소  수정/삭제

      그냥 코드 beautifier를 실행해서 코딩스탠다드에 맞게 바꿔주던가... 아니면.. prebuild스크립트를... 근데 저 prebuild스크립트 싫어해요.....

    • Favicon of http://blog.dalinaum-kr.tumblr.com 달리나음 2012.03.10 16:02 신고  댓글주소  수정/삭제

      코딩 컨벤션 체커는 오픈소스로도 있고 인하우스 툴들도 있습니다. (C++과 같이 파싱이 어려운 언어라면 인하우스 툴을 만들기 위한 노력은 좀더 증가하겠지만요.)

      이것도 힘들다면 적절한 beautifier를 호출해서 원래 소스와 diffstat를 비교하는 방법도 있습니다.

      아마 사용하는 언어를 적어두면 다른 사람들이 적절한 체커를 이야기할 수 있을 듯 합니다.

      PS: 저희는 GIT의 프리 훅으로 등록해서 애당초 커밋을 막을려고 하였는데 회사 외부의 사정으로 실패했던 아쉬움이 있네요.

  10. TZN 2012.03.08 11:01 신고  댓글주소  수정/삭제  댓글쓰기

    주석없이 변수명이나 함수명을 보고 딱 알아볼 수 있는 코드가 좋은 코드겠죠?

    주석도 자기생각대로 적어놓으면 다른사람이 봤을때 더 헛갈립니다. 그리고 자신없으면서 영어로 좀 달아주지 마세요 콩글리쉬로 달아 놓으면 더 헛갈려요 T_T

  11. Favicon of http://blog.dalinaum-kr.tumblr.com 달리나음 2012.03.10 16:05 신고  댓글주소  수정/삭제  댓글쓰기

    저는 컨벤션은 최소한의 기준이라고 생각합니다. 컨벤션마저 없다면 소스 트리가 어떤 길을 걸을지 상상할 수 없습니다. 같은 소스 파일을 여러 사람이 자신의 컨벤션으로 계속 고친다고 생각해보세요. 어떤 스타일도 정답은 없지만, 여러 스타일이 하나의 소스 파일에 집약되는 것은 죄악이라 생각됩니다. 모든 사람이 다른 파일들을 맡고 있고 다른 사람이 거기에 대해 간여할 일이 없다면 모를까 그렇지 않다면 컨벤션은 꼭 있어야 합니다. 구글이나 페이스북 같이 사내의 직원이 어느 프로젝트나 기여할 수 있는 문화를 가진 회사들은 코딩 컨벤션이 매우 엄격합니다. ( http://code.google.com/p/google-styleguide/ ) 만약에 개인 작업물들을 object 파일로 공유한다면 컨벤션의 중요성은 더 낮아지겠죠. 그래도 무시할 순 없습니다. IDE에서 자동완성을 이야기하셨는데 컨벤션이 일관성이 있다면 자동완성을 하지 않아도 될 가능성이 높아집니다. 그냥 머리 속에서 예측하고 짠 코딩이 맞아 떨어질 확률이 더 높아지는 거죠. 이런 종속성은 아마존 수준으로 다른 사람들과 교류하는 것이 소스도 오브젝트도 아닌, "API" 수준으로 떨어질 때만 완전히 사라질겁니다.

    이런 컨벤션의 강요는 어려운 일이 아닙니다. 요즘에는 IDE 수준에서 포매터를 지원해주는 경우가 많기 때문에 컨벤션의 강제에는 큰 비용이 들지 않습니다. 회사 내 혹은 팀내의 컨벤션 설정 파일을 전달해주고 IDE에서 일괄 맞추면 되죠. 또 DVCS(혹은 아직도 VCS쓰는 곳이라면 VCS에서...) 수준에서도 훅킹 레벨에서 컨벤션이 잘못된 코드를 추방하는 방법도 있습니다.

    물론 컨벤션은 최소한의 제약이기 때문에 거지같은 코드를 짜는 사람, 빌드도 확인해보지 않는 사람, 내제된 버그를 증가시키는 사람을 막지 못합니다. 여기에 대해서도 여러 글로벌 기업이나 오픈소스 커뮤니티에서 쓰고 있는 방법이 있습니다. 빌드를 확인해보지 않는 사람을 위해 빌드 봇이나 CI를 써야합니다. 빌드가 되지 않을 때 누구의 잘못인지 검증하고 경고하고 그 커밋을 물러야 합니다. 내제된 버그를 증가시키는 사람에게도 역시 빌드 봇이나 CI를 쓰는게 메인이고 정적 분석기를 쓰는 것도 도움이 됩니다. (정적 분석은 C/C++에선 어렵습니다만...) 매일 워닝의 수를 증가시키는 사람을 경고하고, 정적 분석 리포트가 나빠지는 사람을 경고해야 합니다.

    거지같은 코드를 막는 방법. 이것은 구글, 페이스북이나 삼성의 일부 앞서있는 팀(커널팀)처럼 리뷰 시스템을 도입해야 합니다. 구글이나 페이스북은 프로젝트 당 2명의 리뷰어를 배치하고 그 리뷰어가 승인한 코드만 소스트리에 올려야 합니다. 리뷰어는 보통 시니어 이상의 개발자로 프로젝트에 대해 가장 잘 알고 있고, 다른 수준이 낮은 프로그래머를 견인할 수 있는 사람으로 배치됩니다. 리뷰는 한번에 끝나는게 아니고 계속 첨삭과 피드백이 동시에 이루어지는 형태입니다. 만약에 리뷰어에게 할당되는 커밋량이 많아서 어려워진다면 프로젝트를 기능 단위 등으로 분리해서 새로운 리뷰어를 할당해야죠. 구글이 운영하는 안드로이드 프로젝트도 구글 내부의 시스템과 매우 흡사하게 운영하는데 다음의 링크를 참고할만합니다. ( http://review.source.android.com/ ) 오픈소스 프로젝트에서는 별도의 리뷰 시스템을 가지거나 혹은 메일링 리스트에서 패치에 대한 토론을 합니다. 구글의 경우에도 처음에 리뷰 시스템을 만들지 못했을 때는 사내 메일링 리스트에서 통과한 패치만 반영했습니다.

    • Favicon of http://gamedevforever.com Rhea Strike 2012.03.10 23:41 신고  댓글주소  수정/삭제

      찬성합니다!

    • Hybrid 2012.03.16 22:27 신고  댓글주소  수정/삭제

      빡쎈 컨벤션은 (귀찮기 때문에) 싫어하면서도,
      점점 그게 차라리 나은건가 생각이 들 때가 많더라구요.
      그래서 일단 동의하면서 좋은 글 하나 투척.

      <도대체 이유를 알 수 없는 코딩 컨벤션도 알고보면 다 나름의 이유가 있는 경우가 많다.>
      http://blog.dahlia.kr/post/18035893350

  12. Favicon of http://ruwin.kr ruwin126 2012.03.16 20:52 신고  댓글주소  수정/삭제  댓글쓰기

    사실 저런 빡센 컨벤션은 코더가 지켜야 하는 부분이 아니라, 스크립트를 잘 짜야 하는 부분이라고 생각해요.
    요새 어떤 에디터를 쓰던지(사실 vs랑 vim밖에 안쓰지만) indent나 공백같은것 자동으로 맞춰주도록 스크립트를 작성할 수 있잖아요.
    이런 스크립트만 공통으로 쓴다면 코더가 신경써야 할 일은 업죠.

    문제는 그런 스크립트가 없을때인데, 위에서 어떤 분이 말씀하신것처럼, 소스코드 트리가 엉망이 되더라고요.



티스토리 툴바