eedler

안녕하세요.

이들러입니다.

오늘은 코딩 작업 협업시 유의해야할 사항을 이야기하고자 합니다.

이러한 사항은 아래의 제품들을 제작하면서 겪었던 사항을 정리한 것입니다.

쉬운환율계산 : https://goo.gl/YUbPqd

쉬운환율계산무료버젼 : https://goo.gl/FhVBSl

모노리얼 다이어리(무료) : https://goo.gl/Ti93mz

오늘 이야기할 부분은 습관적인 부분입니다.

프로그램 관련해서 작업을 하다보면 협업은 불가피합니다.

그 어떤 사람도 규모가 큰 프로젝트를 혼자서 처음부터 끝까지 해낼 수는 없습니다.

만약 혼자서 처음부터 끝까지 해냈다면 규모가 크지 않은 프로젝트였거나, 아주 긴 기간이 걸렸거나, 

또는 개발자가 초초초천재! 개발자였을 것입니다.

따라서 협업은 개발에 있어서는 어쩔 수 없이 따라오는 부분입니다.

협업에는 도구가 필요합니다.

소스관리 시스템이라던지, 아니면 태스크관리 시스템, 이슈 트랙커 등 다양합니다.

이러한 도구를 안쓴다고 운영이 불가능한 것은 아니지만 쓴다면 실수를 줄이며 여러가지 면에서 더없이 좋습니다.

제가 오늘 말씀 드릴 부분은 이러한 관리적인 툴 부분이 아닙니다.

개발자가 사람으로서 실수할 수 있는 습관적인 부분을 말씀드리려고 합니다.

이미 조직문화나 정규화가 잘 되어 있는 규모있는 팀에서는 없는 일일 수도 있으나,

저희처럼 작은 조직에서는 흔히 일어나는 일입니다. 이 글은 저희 스스로의 경각심을 위해 작성하였습니다.

소설 처럼 내려읽어가는 형태를 취하다보니 코드는 의미만 통하도록 작성하였습니다.

1. 정해진 규칙을 따르지 않는다.

의외로 많습니다. 많은 개발자들이 종이 또는 화면 상의 문서를 보는 것을 좋아하지 않습니다.

물론 저도 좋아하지 않습니다. 이유는 잘 모르겠습니다.^^;;

빨리 뭔가를 따닥따닥 쳐서 눈에 보이고 손으로 만질 수 있는 무엇인가를 만들기를 바랍니다.

그래서 팀내부에 이미 정해져있는 문서를 제대로 읽지 않는 경우가 많습니다.

예를 들어 생활코딩이라는 커뮤니티에서도 가끔 올라오는 질문 중에 if 의 형태에 대한 것이 있습니다.

//if의 형태
// 1번
if ( isExistIdea() == true ) {
    print("존재함")
}

// 2번
if ( isExistIdea() == true )
{
    print("존재함")
}

if 의 두 형태 중 어떤걸 주로 사용하냐의 질문입니다. {} 의 시작지점에 대한 이야기인데 당연히 정답은 없습니다. 그냥 사람따라 다르고 팀따라 다릅니다. 

문제는 1번 형태로 쓰자고 모든 팀원이 논의가 끝난 상태에서 혼자 2번 형태를 사용하는 사람입니다. 정답이 없다보니 누가 뭐라고 하지도 않습니다. PSR 등의 코딩 스타일 가이드가 있긴 한데 강제는 아닙니다. 안따라도 오류가 나진 않으니, 잘 따르다가도 시간이 지나면 스멀스멀 하나씩 올라오기도 합니다. 자동으로 신텍스를 조정해주는 툴을 사용하거나 환경세팅을 통일하거나 하는 방법도 있습니다. 하지만 역시나 중요한 것은 개발자 스스로 끊임없이 자신의 코딩스타일이 가이드에 어긋나지 않았는지 확인하는 것입니다. 예시를 if로 들었을 뿐이고, 실제로 개발시에는 더 많은 논의가 생깁니다. 변수의 작명부터 클래스의 작명, 제어문의 형태, _의 쓰임, 공백의 활용 여부, 라인의 길이까지도 모두 논의 대상입니다. 위에 예시를 든 if문의 경우 팀이 둘 다 허용한다고 하면 둘 다 쓰면 그만입니다. 다만 협업시 이러한 부분은 한 번쯤은 꼭 체크하시길 바랍니다.

2. 있는걸 또 만든다.

반복적인 업무에 사용하는 함수는 참으로 편리합니다. 당연히 이런저런 유지보수를 하다보면 기능이 추가되고 그래서 필요한 함수를 추가할 경우가 생깁니다. 클래스의 메소드 등을 만들다 보면 다른 사람이 만든 클래스나 모듈을 수정하는 일도 있습니다. 급하게급하게 진행하는 경우 문서가 제대로 작성되어 있지 않으니, 코드를 위부터 아래로 쭈욱 훑어본 후에 자신이 원하는 함수가 없으면 함수를 만들기 시작합니다. 문제는 업무를 하다보면 이미 있는 함수를 다시 만드는 경우가 생깁니다. 물론 완전히 같은 함수를 두 번 만드는 경우는 별로 없습니다. 어설프게 같은 함수가 중복되는 경우가 문제입니다.

// 1번
func isBrake(Car) {
    if Car.brake == true {
        return true
    } else {
        return false
    }
}

// 2번
func isNotStopPedal(Car) {
    if Car.brake == false {
        return true
    } else {
        return false
    }
}

위의 두 함수는 같은 일을 하는 함수입니다. 함수명만 다르고 true, false가 뒤집혀 있습니다. 위에 예시는 매우 극단적이지만 조금 확장해서 생각해보면 이러한 경우는 꽤 많습니다. 위의 두 함수가 각각 따로따로 쓰여지게 되면 어느 순간 함수를 고쳐야할 순간에 혼동이 오기 시작합니다. 이러한 경우는 사실 개발자들 사이에서는 그냥 쉬쉬하는 일입니다. 일단 지금 당장 내가 짠 코드는 돌아가니 리팩토링 같은 코드 갱신 작업도 하지 않습니다. 괜시리 만졌다가 문제를 일으키고 싶지 않은 것이죠.^^;; 이 함수들의 문제는 나중에 리팩토링 등을 할 때도 꽤 많은 고민을 하게 만든다는 것입니다. 초기에 빠르게 성장하는 팀에서는 자주 발생하는 일입니다. 이 상태에서 어느 정도 성장 후에 코드를 정리하고자 하면 이미 더욱 커져버린 코드에 짊어져야할 출혈도 만만치 않습니다. 함수든 클래스든 생성 전에 반드시 문서를 확인하시고, 또한 다른 사람과의 크로스체크도 꼭 하시기 바랍니다.

3. 내꺼만 소중하다.

새로 추가된 인력이 주로 하는 실수입니다. 내가 하는 일은 너무너무 중요해서 눈에 잘 띄게 해야지 라는 강한 의식을 가지고 있을 때 발생합니다. 가령 클래스에 새로운 메소드를 추가한다면

//Car Class
Class Car() {
    var brake: Bool = flase

    func setBrake(bool) {
        self.brake = bool
    }

    /////////////////////////////////////////////////
    // isBrake : 브레이크의 존재여부를 알려줍니다
    // 시작
    ////////////////////////////////////////////////
    func isBrake() {
        if self.brake == true {
            return true
        } else {
            return false
        }
    }
    /////////////////////////////////////////////////
    // isBrake : 종료
    ////////////////////////////////////////////////
}

우리는 당신이 짠 소스가 얼마나 대단한 것인지 잘 알고 있습니다. 그러니 그냥 다른 함수 또는 변수들과 같은 형태의 정렬 또는 형태를 사용하세요. 그렇게 눈에 띄게 크게 표시 하지 않아도. 해당 모듈에 문제가 있다면 당신에게 가겠습니다.

이는 1번 규칙을 따르는 문제와 연관이 있습니다. 실제 운영을 하다보면 이러한 형태를 많이 보게 됩니다. 물론 코드는 잘 돌아가고 눈에 띄니 보기도 좋습니다. 하지만 개발 때 뿐입니다. 시간이 지나면 해당 함수는 다른 함수들과 같은 함수이며, 가령 다른 사람이 다른 함수를 수정하기 위해 저 코드를 열어보기라도 한다면 그 사람은 잠시 깊은 사색에 잠길지도 모릅니다.^^

4. 주석을 함께 수정하지 않는다.

주석은 잘못 사용하면 독입니다. 잘못된 주석은 주석이 없는 것보다 훨씬 위험합니다.

최근에는 문서를 자동으로 작성해주는 좋은 프로그램들도 있으니 문제가 안일어날 수도 있겠지만,

저는 여전히 웹소스 등을 수정할 때 에디터툴을 많이 사용하며 코드 중간중간에 주석을 넣기도 합니다.

//Car Class
Class Car() {
    var brake: Bool = false
    var smartKey: Bool = false

    func setBrake(bool) {
        self.brake = bool
    }

    /////////////////////////////////////////////////
    // 브레이크의 존재여부를 알려줍니다
    // 시작
    ////////////////////////////////////////////////
    func isSmartKey() {
        return self.smartKey;
    }
    /////////////////////////////////////////////////
    // isBrake : 종료
    ////////////////////////////////////////////////
}

또다시 극단적인 예이긴 하지만 3번 예시의 코드를 수정해 보았습니다. 관련 코드의 수정은 곧 관련 주석의 수정을 의미합니다. 위의 주석은 차라리 없는게 낫습니다. 주석을 수정할 여유가 없었다면 차라리 주석을 지워버리세요. 그러면 다음 사람은 코드만으로 함수를 이해하려고 노력할 것입니다. 코드가 명확하면 주석이 필요 없다는 말이 있습니다. 물론 그렇긴 하지만 이런저런 일을 하는 모듈일 경우 설명 한 줄 없이 모든 코드가 명확하기란 사실 쉽지 않습니다. 바쁘다보면 코드의 주석은 수정하지 않은 채 코드만 수정하는 일은 사실 굉장히 흔한 일입니다. 그러나 이 작은 실수가 추후 커다란 재앙이 되어 돌아오리라는 것을 ....... 개발자들은 다 알고 있지만 잘 안합니다. -_-ㅋㅋㅋ

따라서 주의해야 합니다.^^

정리

오늘은 흔히 하는 습관적인 실수에 대해서 이야기했습니다. 이러한 사항들은 협업 시에 특히 도드라지는데요. 혼자서 작업할 때는 잘못된 주석도 다 이해하면서 넘어가기 때문입니다. 하지만 한 두 달만 지나면. 자신이 작성해놓은 코드도 타인이 작성해 놓은 코드인것처럼 새록새록했던 기분은 누구나 다 겪어보셨을 것입니다.^^;

이 모든 글은 저 자신에게 하는 말이며, 저 역시 이런 부분이 잘 안되기 때문에 명심하고자 하는 마음에서 작성하는 것입니다.

저 역시 이러한 실수를 자주합니다. 오늘 이런 글을 작성하고, 한 두 시간 후에 또 실수를 하곤 합니다.

하지만 중요한 것은 점점 더 나아지고 있으며, 어제보다 나은 오늘이었고, 내일은 오늘보다 더 좋아질 것이라는 것입니다.

이상 이들러 개발팀이었습니다.^^

쉬운환율계산 : https://goo.gl/YUbPqd

쉬운환율계산무료버젼 : https://goo.gl/FhVBSl

모노리얼 다이어리(무료) : https://goo.gl/Ti93mz