내가 소스코드를 몰래 고치는 이유
2011/02/01 11:39 by 전규현
All of Software 블로그를 RSS Feed에 등록을 해 놓으시면 편리하게 받아보실 수 있습니다.
RSS Feed
여러 소프트웨어 회사를 분석해보면 소스코드를 공유하는 정도에서 정말 많은 차이가 난다.
RSS Feed
여기서 소프트웨어 회사란 소프트웨어를 개발하고 있는 회사로서 흔히 얘기하는 팩키지 소프트웨어 회사가 아니다.
SI회사, 가전회사, 산업로봇회사, 반도체장비회사, 인터넷회사, 게임회사, 금융회사 등의 다양한 회사를 모두 말한다.
이들 회사 중에서는 개발자가 소스코드를 몰래 고치고 공유도 하지 않는 회사들이 의외로 많다.
개발자가 소스코드를 몰래 고치는 이유에는 이건 것들이 있다.
| 내 소스코드는 나만 알아야 회사에서 나의 파워가 유지된다. |
일부 일리가 있는 이론이다. 내가 없으면 내가 작성한 소스코드를 이해하지도 고치지도 못하면 나는 절대로 짤릴 수가 없다. 문제가 있을 때마다 나에게 달려와서 이것 좀 고쳐달라고 하면 내가 좀 대단한 사람이 된 것 같은 생각도 든다. (이전에 블로그에 포스트한 글 참고)
실제로 실력이 있는 개발자들이 이런 행동을 하기도 한다. 하지만 이런 행동은 본인의 성장에 방해가 된다. 더 어렵고 가치있는 해야 할 사람이 과거의 소스코드에 발목잡혀서 휴가도 마음대로 못가게 된다. 개발자의 파워 및 가치는 과거에 있는 것이 아니고 미래에 회사에 필요한 가치에 있다는 것을 알아야 한다. 그것이 회사와 개발자의 상생의 기초이다.
| 내가 작성한 소스코드의 품질이 형편없어서 보여주기 창피하다. |
어떤 천재 개발자도 공유하지 않고 혼자 개발을 해서는 좋은 코드를 작성하기 어렵다. 꾸준히 공유를 하면서 다른 사람들과 의견 교환을 통해서 점점 나아진다. 혼자 개발한 코드는 이상한 코드로 가득차 있기 마련이다.
세 사람이 걸어가면 그 중에는 꼭 스승이 있듯이 신입사원과 코드 리뷰를 해도 배울 것이 나오게 된다.
소스코드를 보여주는 것을 창피해 할 것이 아니라 자꾸 보여주고 교류를 해야 나아진다.
| 엄청 어려운 것을 개발하고 있는 것처럼 행동했는데 소스코드를 보면 별 것 아니라는 것이 들통날 것 같다. |
종종 접하는 문제다. 심지어는 오픈소스코드를 가져다가 동료들에게는 자기가 개발한 것 같이 자랑하는 경우도 있다. 이것은 회사입장에서 더 큰 문제가 될 수도 있다. 오픈소스 라이센스 규정을 어겨서 소송을 당할 수도 있다.
스펙을 적절하게 작성하고 설계를 하는 과정들에서 서로 리뷰를 적절하게 한다면 서로 어떤 컴포넌트를 어떤 Technology를 이용해서 개발하는지 다들 알게 된다. 어떤 것은 어렵고 어떤 모듈은 신입사원이 구현해도 될 만큼 쉬운 것인지 모두 알게 된다.
SRS를 제대로 작성하게 된다면 모든 프로젝트 관련자가 프로젝트가 어떻게 구성되어 있고 어떻게 진행되고 있는지 훤히 할게 된다.
| 너무 바빠서 공유할 시간도 없다. |
이미 불끄기 모드로 들어간 회사는 단기적인 해결책이 없다. 이런 회사에서는 서로 자기일 하기 바빠서 점점 서로 더 단절되게 된다. 또 다시 악순환이 진행된다.
시간이 좀 걸리겠지만 악순환의 고리를 끊어야 한다.
| 공유를 해봤자 관심도 없다. 다들 바쁜데... |
공유문화가 정착되지 않은 회사이다. 이런 회사에서 코드리뷰는 별 의미도 없다.
시도를 해봤자 시간 낭비일 것이다. 내용을 모르는데 코드리뷰를 해도 기껏해야 Syntax 검사밖에 못할 것이다.
SRS리뷰를 먼저 시작하는 것이 좋다. SRS가 리뷰를 해야 할 것도 더 많고 SRS가 제대로 작성되어야 다음 단계인 설계, 구현이 제대로 진행되며 리뷰를 해도 내용을 알고 리뷰를 할 수 있게 된다.
이렇게 되면 "바쁜데..."라는 핑계가 조금씩 줄어들만큼 시간을 절약할 수 있게 된다.
| 결론 |
개발자가 작성하는 모든 소스코드는 기록이 남아야 하고 남게 된다. 물론 분석, 설계도 마찬가지이다.
Baseline에 포함되는 소스코드와 문서들은 소스코드 관리시스템에 들어갈 때 설명을 적절하고 충실하게 달아야 한다. 이때 이 소스코드를 누가 리뷰했는지 기록을 남기기를 권장한다. 리뷰를 했다는 의미는 소스코드 작성자와 같이 이 소스코드에 대해서 공동책임을 진다는 의미이기도 하다. 이것이 부담스러워서 리뷰를 하지 않는다면 아무도 리뷰를 하지 않을 것이다. 서로 리뷰를 해주는 것은 모두에게 도움이 되는 것이다. 이것은 규칙으로 강요를 해서는 효과가 없고 분위기가 조성되어서 오랫동안 시행을 하여 문화로 자리를 잡아야 한다.
소스코드관리시스템에 소스코드를 올릴때는 버그ID(이슈ID)가 꼭 있어야 한다. 개발자가 원한다고 아무때나 마음대로 소스코드를 고치면 안된다. 개발자가 스스로 발견한 버그를 고칠 때도 버그관리시스템에 등록을 하고 고쳐야 한다.
이렇게 개발자가 생성한 모든 소스코드는 투명하게 모두가 볼 수 있게 한다면 이 혜택은 회사 뿐만 아니라 모든 개발자 그리고 본인에게도 돌아한다.
* 이 포스트는 blogkorea [블코채널 : 꿈꾸는 소프트웨어 개발자 세상] 에 링크 되어있습니다.
image by Susan NYC
'개발문화' 카테고리의 다른 글
| 주먹구구를 더 좋아 하는 이유 (11) | 2011/07/17 |
|---|---|
| 나쁜 습관 (2) | 2011/06/19 |
| 내가 소스코드를 몰래 고치는 이유 (13) | 2011/02/01 |
| 평가를 어떻게 해야 할까? (4) | 2011/01/18 |
| 기존 소프트웨어를 버리고 언제 새로 만들어야 할까? (16) | 2011/01/17 |
| 왜 나만의 방법이 실패하는지? (NIH 신드롬) (12) | 2011/01/09 |
Trackback Address: http://allofsoftware.net/trackback/211
비슷한 얘기가 생각나네요. 두 청년이 바둑의 명인이 되기위해 산으로 가서 바둑에만 전념한지 10년째, 자신감에 찬 두 청년은 산을 내려와서 다른사람들과의 대전을했는데, 매번 졌다는 얘기에요;;
여쭙고 싶은게, 포스팅에 대부분 SRS을 강조하셔서 제 나름대로 개발진행하면서 기능과 이렇게 개발한 이유같은걸 문서로 만듭니다. 근데 혼자하다보니 이게 과연 잘 진행되는건지 의심이 가는건 어쩔수없네요.
SRS 세미나 혹은 교육같은게 있나요? SRS의 개념을 익히고싶습니다.
새해복 많이받으세요~
오산돌구님 안녕하세요.
개발하면서 기능과 그 이유를 적는다고 한 것으로 봐서 문서를 개발하고 나서 적는 다는 의미 같습니다.
문서는 원래 개발을 하기 위해서 더 빨리 개발하기 위해서 만드는 것입니다. 지금은 문서가 나중에 필요할 것 같아서 만드시는 거죠? 이런 문서는 용도가 많이 떨어집니다.
SRS세미나나 교육이 있기는 하지만 SRS를 익히려면 직접 SRS를 직접 쓰고 프로젝트를 진행해 보는 것을 몇년 해봐야 합니다. 그러기 위해서 처음에는 좀 배워야 하는 과정이 필요합니다.
제 책에 보면 SRS를 배우는 방법에 대해서도 소개가 되어 있습니다.
책을 읽어봤는데 그렇게 하면 되겠구나 라고 하는 느낌까지는 들지 않았습니다.
안녕하세요. bluemonk님
그것이 책의 한계인 것 같습니다. 비디오 보고 골프를 배울 수 없듯이 직접 해보면서 경험하지 않으면 알 수 없는 것이 소프트웨어 공학입니다.
지금은 좀 덜 하지만 저 같은 경우는 몰래 고치는 게 재미있어서 그런 적도 많아요. 새로운 패턴이나 프레임워크 보면 이전 소스를 고쳐보고 싶은...
좋게 말하면 리팩토링인데 사실 코드 갖고 놀기....회사 자산 갖고....ㅡ.ㅡ;
안녕하세요. 별의파편님
작은 회사에서는 흔히 있는 일이죠.
회사의 소스코드의 아키텍쳐를 바꾸는 일이라면 여러 개발자와 리뷰를 많이 하면서 더 좋은 방법들을 계속 찾는 작업이 필요할 겁니다.
소스코드가 변경되면 테스트가 많이 필요하고 코딩 작업 외에도 많은 작업이 필요합니다. 따라서 개인이 혼자서 마음대로 변경하는 것은 나중에 문제가 될 수도 있습니다.
작은 회사 또는 작은 팀이라서 가능한 걸 겁니다.
SRS가 뭔가요?
안녕하세요. 중원님
스펙문서를 말합니다. 제 블로그에서 SRS로 검색을 해보시며 많이 나옵니다.
비밀댓글입니다
감사합니다. ^^
협업에 관련된 포스트를 읽다가 이 포스트로 넘어왔네요.
소스를 팀의 산출물로 협업을 통해 관리하는 경우에는 생각보다 투명하게 일이 진행됩니다.
그러나 중소규모의 회사일수록 그런 경우는 많지 않으며..
오히려 소수의 인원이 거대 모듈들을 작업하는 경우가 많고, 협업을 하는 케이스가 적습니다.
그러다 보니.. 소스에 대한 관리 책임이 순전히 개인에게 넘어가버립니다.
이런 경우 버그가 발생하면 결국 개인의 능력과 실력을 의심당하게 되고..
회사에 피해를 끼치는 식으로 인식되어 버립니다.
소위 욕먹고 깨지고 페이에도 문제가 생길수 밖에 없는 구조가 되어 버리죠.
결국은 책임 회피를 위한 나몰라, 거짓말, 몰래 체크인, 다른 이의 계정으로 체크인 등...
시스템과 프로세스를 무력화 시킬 수 있는 온갖 방법들이 동원되기도 합니다.
코드를 대하는 마인드가 변하지 않는 한, 소위 이 '나쁜 습관'들은 쉽게 고쳐지지 않을 것 같습니다.
안녕하세요. ymir님
다른 사람 계정으로 체크인은 좀 심하네요. ^^
다행(?)히도 그런 사례는 서너개의 회사를 거치는 동안 딱 한 번 봤습니다. =)