태터데스크 관리자

도움말
닫기
적용하기   첫페이지 만들기

태터데스크 메시지

저장하였습니다.

빈 줄도 지워서는 안된다.

2015.04.13 14:25 by 전규현


잠시 후 Google blogger로 이동됩니다.






SVN 쓸까? Git 쓸까? 주제로 얘기를 하면 논쟁이 심하다. 하지만 이보다 중요한 것은 SVN이나 Git 상관없이 어떻게 하면 여러 개발자들과 협업이 되도록 코딩을 하느냐다.


많은 개발자들은 혼자서 또는 소수의 인원과 개발을 한다. 또는 여러 명이 개발을 하더라도 자신의 소스코드가 정해져 있어서 혼자 개발하는 경우가 많다. 이러다 보니 협업을 위한 개발에는 별로 관심이 없다. 하지만 협업은 혼자서 때도 필요한 것이고 여러 명이 개발할 때는 더욱더 필요하다. 방법을 모르거나 문제를 피해 다니면 개발 효율이 떨어지고 한계를 넘지 못한다.


혼자서 개발을 하더라도 수많은 브랜치가 발생할 있고 한두 명끼리는 그럭저럭 개발을 하더라도 개발팀이 조금만 커져서 뒤죽박죽이 되곤 한다.


그럼 어떻게 코딩을 하는 것이 좋을까?


첫째, 줄도 고쳐서는 된다.


내가 고치고 있는 모든 소스코드는 다른 개발자들도 지금 고치고 있다고 생각해야 한다. 설사 혼자서 고치는 소스코드라고 하더라도 습관이 된다. 협업을 하고 있다는 마인드는 꾸준히 유지를 해야 한다. 


뿐만 아니다. Indentation 맞지 않는다고 고치는 것도 좋지 않다. 괜히 연산자 사이에 보기 좋으라고 빈칸을 추가하는 것도 나쁘다. 무조건 처음에 잘해야 하고 나중에는 그냥 놔두는 것이 낫다.


둘째, 파일 이름을 바꾸지 말아야 한다.


처음에 대충 파일을 만들다 보면 파일이름이 마음에 드는 경우가 있다. 그렇다고 파일을 이름 바꾸면 수많은 사람들에게 영향을 준다. Git에서는 파일을 이름 변경을 추적해주는 기능이 있지만 혼란을 피할 길을 없다. 처음에 정해야 한다. 


셋째, 함수 이름과 정의를 바꾸지 않아야 한다.


대충 만들어 놓고 자꾸 바꾸는 것은 협업 습관이 없기 때문이다. 그리고 대충 만들고 나중에 수정하는 것은 비용이 많이 든다. 아주 작은 시스템만 경험해 개발자는 이런 방법이 빠르다고 주장할지 몰라도 시스템에 개발자가 수십 명이라면 얘기가 달라진다. 대충하고 바꾸는 습관이 들어서는 안된다.


넷째, 소스코드를 재배치하지 말아야 한다.


파일의 아래쪽에 있는 함수를 위로 올리고 정리를 하면 소스코드 Merge 어려워진다. 처음에 생각해서 정하고 나중에는 고치지 말아야 한다. 여러 사람이 동시 소스코드를 정리하면 소스트리는 완전히 뒤죽박죽이 된다.


이미 문제가 발생한 경우 리팩토링이 필요하게 되고 계획을 잘 세워서 시행해야 하고 상당한 비용을 치뤄야 하는 경우도 있다. 이런 경우는 최소화하고 처음부터 제대로 하는 것이 훨씬 낫다.


외에도 변수를 어떻게 선언하느냐는  협업을 위한 수많은 코딩 노하우들이 있다. 항상 개발은 혼자 하는 것이 아니다라는 것을 염두해 두고 개발하는 자세가 필요하다.

물론 위 내용들은 개발자 본인이 처한 환경에 따라서 천차만별로 생각할 수 있다. 혼자 개발하는 사람도 있고 수백명이 개발을 해도 혼자 일하는 것처럼 개발하는 경우도 많다. 수천명이 동시에 개발하는 환경에 있는 개발자도 있다. 

필자는 원칙과 원리에 대해서 얘기를 하는 것이니 원리에 대해서 이해를 해보는 노력을 해보자. 일하는 환경은 언제든지 바뀔 수 있지만 습관은 쉽게 바뀌지 않는다. 좋은 습관을 만들어가는 것은 본인의 몫이다.





저작자 표시 비영리 변경 금지
신고

전규현 기반시스템/소스코드관리 , ,

  1. Blog Icon

    비밀댓글입니다

  2. Blog Icon
    저는 조금 반대입니다.

    저는 조금 반대인게 변경해야 하는 내용이 규격화된 내용과 맞지 않는 형식이라면 고치는게 맞다고 생각합니다.
    머지를 하는게 처음엔 힘들수 있지만 일정한 표준화가 되고 난 다음부터는 그렇게 힘들지 않습니다.
    일단 제 경험상으론 그렇네요.

  3. Blog Icon
    나그네

    이럴때 필요한게 리팩토링 이지요...

    프로젝트 중간 팀원들과 리팩토링을 하여 정보를 공유하는게 좋을듯합니다..

    빈줄도 지워서는 안된다는 좀 심한듯..

블로그 호스팅을 Google Blogger로 이전합니다.

최근에 블로그에 보안 문제가 발생하여 좀더 안정적으로 블로그를 운영하기 위해서 Google Blogger로 이전합니다. 기존에 http://allofsoftware.net 과 http://www.allofsoftware.net..

한국어(한글) 코드 이야기 (8)

유니코드에 대해서 좀더 알아보기 전에 한국어 코드(문자세트)와 인코딩에 대해서 좀더 알아보자. 1991년에 유니코드가 탄생한 후에 유니코드는 점점 많은 개발자들이 사용하기 시작해서 영역을 넓혀가고 있다. 물론 언젠가는 유니코..

유니코드 영토 전쟁의 승리자는? (7)

이번에는 유니코드의 코드 체계에 대해서 간단하게 알아보고자 한다. 소프트웨어 국제화를 필요로 하는 개발자라면 자주는 아니지만 유니코드 내부 코드 체계를 알아야 할 때가 있다. 다양한 플랫폼에서 개발을 할 때 폰트 등과 관련하..

유니코드는 어떻게 탄생했을까? (6)

소프트웨어 국제화를 이해하기 위해서는 유니코드에 대해서 필수적으로 잘 알아야 한다. 유니코드란 말을 들어보지 않은 개발자는 없지만 관련 용어가 매우 많아서 종종 헷갈린다. 게다가 유니코드가 탄생한지 20년도 더 넘었지만 아직..

직원을 잠재적인 도둑 취급하는 회사

필자는 몇 년 전 A그룹에 강연을 하러 갔다가 곤란한 일을 겪은 적이 있다. 한국 대부분의 대기업이 그렇듯이 보안이 매우 엄격한 회사였다. 나는 직원들의 안내대로 메모리, 외장하드를 모두 빼놓고 회사로 들어갔다. 하지만 강연..

외국에서 팔리는 소프트웨어의 아키텍처 디자인 원칙 (5)

김과장은 그 동안 한국어만 지원하는 소프트웨어 A를 개발해 왔는데 최근에 사장님이 A의 일본어 버전을 만들라고 했다. 그리고 개발 기간도 한달 밖에 주어지지 않았다. 그래서 기존 소스코드를 복사해서 한국어가 들어 있는 모든 ..

소프트웨어 개발자 성장에 꼭 필요한 리뷰

우리나라 개발자들은 프로그래밍은 잘 하는데 대접을 못 받는다는 얘기가 있다. 또, 머리는 좋은데 환경이 나쁘다는 얘기도 있다. 젊은 개발자들은 외국의 개발자들에 전혀 뒤지지 않는데 나이를 먹을수록 실력이 떨어진다는 얘기도 있..

외국에 출시한 소프트웨어가 날짜 때문에 낭패 본 사연 (4)

10년차 개발자인 김과장(가상의 인물)은 최근에 소프트웨어를 영어를 지원하도록 만들었다. 어플리케이션에서 표시되는 모든 메시지(메뉴, 버튼, 다이얼로그 등)를 영어로 번역했다. 그렇게 해서 영어버전을 출시했는데 얼마 안 가서..

독일어 버전 소프트웨어란 말이 잘못된 이유 (3)

본 시리즈는 차례대로 읽으면 소프트웨어 국제화가 전체적으로 이해가 되어서 소프트웨어 개발자에게 도움이 되는 방향으로 진행하려고 하고 있다. 개발자마다 지식과 경험이 천차만별이라서 초급 개발자를 기준으로 작성하고 있다. 경영자..

소프트웨어를 외국에 출시 하면서 흔히 빠지는 함정 (2)

우리나라 소프트웨어 중에서 외국에서 크게 성공했다고 하는 소프트웨어가 있는가? 온라인 게임을 제외하고는 거의 없다. 사실 게임은 국제화, 지역화를 잘 못하더라도 큰 흉이 안 된다. 하지만 그 외의 많은 소프트웨어들은 제품이든..

티스토리 툴바