Coding conventions 만들기가 힘들군요.

1. coding guideline을 작성합니다.
2. coding guideline을 다 함께 review 합니다.
--- 모든 사람들의 생각을 합치고 암묵적 동의를 얻어냅니다.
3. 흩어져 각자의 일을 시작합니다.
4. 다함께 code review를 합니다.
5. 조금이라도 coding guideline에 어긋난 부분에 대해서 지적합니다.
--- 많이 어긋났으면 아예 review를 중단합니다.
6. review를 coding guideline에 완벽하게 맞을때까지 반복합니다.

누구 한사람이 경고를 주는 방법도 좋지만
보다 효과적인 방법은 암묵적 합의 후 자신이 합의를 깬것에 대해
인식하게 해주는것이 좋을것 같습니다.

안그러면 자신의 잘못을 인식하지 못하고 잘못을 지적하는 사람을 귀찮은 존재로 인식할수 있죠.

이 바닥은 불확실한 전망과 처절한 대우로 이직률이 높을 뿐더러..
대부분 최소한의 인력과 비용으로 최대의 퍼포먼스를 내기를 원하기 때문에..
체계적으로 스킬 업을 시키기 위한 장치도 별로 없고...
대부분 인력이 낼 수 있는 한계치 이상으로 일을 시키는 경향이 많습니다.

게다가 사람들은 대부분 자기만의 개발 환경을 갖고 있으며 자기만의 스타일을 가지고 있는데..
뭔가 새로운, 익숙하지 않은 일을 자기 개발 환경으로 끌어오려면...
소위 러닝 커브 (learning curve) 에 의해 초반에는 생산성이 많이 떨어집니다.
즉, 이를 고려해서 일정이라던가, 인력 구성이 우선적으로 변해야 하지 않나 싶습니다.

충분히 시간이 주어졌다고 판단 될 때..
비로소 새로운 도구나, 시스템, 프로세스들을 검토해 볼 만한 여유가 생기는 것이죠..

물론, 결과적으로는 하나의 convention 을 갖고 공동 작업을 하는 것이..
추후 발생할 유지보수에 대해 어느 정도는 플러스 요소가 된다는 걸 알고는 있겠지만...
크런치 모드로 일하고 있는데, 새로운 것들 때문에..
당장 내 퍼포먼스가 떨어지고, 일정이 지연되는 사태가 발생한다면...
결과적으로는 자신이 가장 퍼포먼스를 잘 낼 수 있는 형태로 회귀하게 되어 버립니다.

충분히 여유가 있고, 동료간에 우호도가 높고, 이직률도 낮고, 로열티도 높은 편이라면...
위에 anfl 님께서 말씀하신 것처럼.. 공동으로 guideline 을 작성하고..
peer review (동료 검토) 등을 통해 check-in 하는 프로세스를 도입하는 정도면..
적당하지 않나 싶습니다만..

그렇지 않은 경우라면, neogeo 님 의견처럼.. 차라리 우선적으로 S/W 아키텍터를 별도로 선임하여...
library dependancy 나 module 배치, review, checkin 을 담당하게 하는게 좋지 않을까 합니다.
실제로 repository 를 직접 관리하면서, convention 등을 정리하고...
정리한 내용을 계속해서 announce 한다면, 실제 개발자들은 조금씩 변경된 convention 이 반영된
코드를 checkout 해서 작업을 하게 될 것이고, 시간이 지나면서 점점 익숙해 질 겁니다.

심리적으로 하나의 스타일로 만들어진 파일에, 자기만의 스타일을 끼워 넣는 일은...
쉽게 눈에 띄기 때문에, 그리 쉽지 않은 일이라..

아.. 그리고 가장 중요한 건...
반드시 '합리적'인 근거를 통해 반대자,비협조자들을 '납득'시키고..
사후라도 동의를 얻고.. 공감대를 형성해 가야 한다는 겁니다..

회사에 대한 기대치가 높은 곳이라면.. 어떻게든 따라오겠지만...
그렇지 않다면.. 까짓거 귀찮고 맘에 안 들면 딴 데 가면 그만이라고 생각하는 사람들도..
의외로 있을지도 모르거든요.. ㅎㅎ

그리고, 끝으로 일정이 폭주하지 않도록 절대적으로 관리를 잘 하셔야 할겁니다.
결정적으로 일정이 폭주하면, 코드가 폭주하게 됩니다.
바쁘니까, 급하니까.. 좋은 관행은 생략되고, 절차가 사라지고..
중복 코드라던가, 임시 변수, 매직 키워드가 난무하게 됩니다.

오랫동안 구축해 온 좋은 시스템도, 하루 아침에 무용지물이 될 수 있습니다.

한동안 고민해 오던 주제라, 이런 저런 생각을 늘어놓았습니다만..
현실적으로, 처음 부분에서 언급한 이유 때문에..
이러한 컨벤션을 만드는 것도 어렵고, 유지하는 것도 쉽지 않습니다.
어떻게든 최소한의 관리 비용이 들어가는 좋은 방안을 찾으시길 바랍니다.

되면 한다! / feel no sorrow, feel no pain, feel no hurt, there's nothing gained.. only love will then remain.. 『 Ｍｉｚｚ 』

제 경우엔 전 일반사원인 팀원인데 이런걸 좀 도입하고 싶습니다.
팀장도 같이 코딩을 하는데.. 코딩스타일이나 문법이 영 통일이 안돼서....

저도 저런 규칙따라가며 해본적이 없다보니 의견을 내기도 뭐하고...