조엘 온 소프트웨어 _ 비트와 바이트 : 프로그래밍 실전(1)

 

2장 기본으로 돌아가기

기본으로 돌아가기에서는 문자열을 덧붙이는 strcat 이라는 함수를 예시로들며 나오게 됩니다.

위 2장에 대한 저의 생각을 작성하기 전에 잠깐 이 함수에 대해서 알아보겠습니다.
( 이렇게 코드를 설명하는 내용은 책에 많지않아 코드에 대한 내용은 간간히 작성할 것 같습니다. )

 

strcat

strcat 이라는 함수는 C/C++ 언어에서 기본적으로 사용되는 문자열을 연결하는 함수입니다.

해당 함수의 코드구성을 살펴보면 아래와 같습니다.

char* strcat(char* dest, const char* src)
{
    char* original_dest = dest;  // 원본 포인터 저장
    
    // 1. dest의 널 종료 위치로 이동
    while (*dest != '\0') {
        dest++;  // 1바이트씩 전진
    }
    
    // 2. src의 내용을 dest 끝에 복사
    while (*src != '\0') {
        *dest = *src;  // 1바이트 메모리 복사
        dest++;        // dest 포인터 1바이트 전진
        src++;         // src 포인터 1바이트 전진
    }
    
    // 3. 새로운 문자열의 끝에 널 문자 추가
    *dest = '\0';
    
    return original_dest;  // 원본 포인터 반환
}

위 코드를 이미지로 쉽게 풀어보면 이렇습니다.

null을 찾는 코드

char 배열에서는 배열중에서 끝나는 곳 ( null = \0 )을 찾아야만 해당 배열이 끝났다는 것을 알 수 있습니다.

위 이미지 처럼 dest라는 char 배열에서는 H e l l o 이후 null 이라는 빈공간을 발견해야 배열이 끝나는 것을 알 수 있는것이죠.

 

 

그런데 여기에 "World" 라고 저장되어있는 src char배열을 위 dest 배열에 붙여서 하나의 문장으로 만들고 싶은겁니다.

 

그래서 빈공간이 있는 부분부터 w o r l d 의 화물들을 하나 하나 순서대로 갖다 붙이는 겁니다.

 

 

얼핏 보면 이러한 방식은 당연하다고 볼 수 있습니다.

하지만 책에서는 "러시아 페인트공 알고리즘" 이라는 말을 하며 아주 비효율적인 방식이라고 이야기하고 있습니다.

러시아 페인트공 알고리즘

 

즉, strcat의 첫부분은 매번 null 문자를 찾아 목적지 문자열을 헤매다녀야하기 때문에 작업 규모가 커지면 성능이 떨어지기 때문이라고 합니다.

 

그래서 좀 더 효율적인 알고리즘을 사용하여 위와같은 시간적인 문제를 해결할 수 있다고 말합니다.
( 자세한 부분은 책 참고 )

 

생각할만한 부분

이러한 문자열 처리 알고리즘 하나가 프로젝트의 성패를 가를수 있다는 것에 놀랐습니다.

예를들어 데이터를 로그파일에서 지속적으로 쌓아올려야 하는 프로젝트에 A,B회사가 참여하게되었고,
두 팀 모두 데이터가 크지 않을때에는 무리없이 프로젝트를 진행할 수 있었지만 
만약 데이터가 대용량으로 전환되었을 때

strcat을 그대로 사용한 A회사의 프로그램에 점점 문제가 발생할것이고 
strcat의 문제점을 미리 인지하여 효율적인 알고리즘을 사용하는 B회사의 프로그램은 수월하게 돌아갈 것입니다.

여기서 프로그램의 유지보수에 대한 비용이 증가하는 것은 물론이고 더 중요한 문제는
외주를 맡긴 고객에게 신뢰도를 점점 잃어버릴 수 있다는 것입니다.

단순히 프로그램을 효율적으로 만드느냐 아니냐? 에대한 관점을 넘어서서 
함수 하나의 비효율적인 문제로 인해 회사의 성패가 갈릴 수 있다는 관점에 대해서 시야가 넓어질 수 있는 내용이었습니다.

 

또한 조엘이 권장하는 '대학생이 갖춰야 할 지식' 목록에 대한 내용 중 

" 구식 취급을 받는 C대신, 요즘 대학교에서는 C++이나 자바와 같은 신형 프로그래밍 언어를 가르치고 있기에 조엘이 제시한 목록이 시대에 역행한다는 생각이 들지도 모르겠습니다. 하지만 정말 결정적인 순간에 C프로그래밍 기법이 당신을 살릴 수도 있습니다. 특히 임베디드에 입문하려 한다면 제발 C 프로그래밍에 익숙해집시다. "

에 대한 내용을 보면서 직전 회사에서 있었던 일이 하나 생각났는데...

 

Vision 처리 중 한 지점에서부터 반지름과 각도를 주면 해당 각도만큼의 호를 그리면서 검사를 해주는 함수가 있었습니다.

연차가 있는 회사였기 때문에 자체라이브러리를 사용하고 있었고 아무생각없이 해당 함수를 호출해서 사용하고 있었는데

선임이 " 그 함수 쓰지말고 너가 직접 원그리면서 검사해봐 " 라고 했었던 경험이 있습니다.

 

지금이야 간단하게 구현할 수 있지만 당시 아무생각 없이 함수를 사용했었던 저는 당황하고 창피하지만 그 문제를 가지고 이틀이나 머리를 쥐어 짜내다가 구현할 수 있었습니다. 

즉, 원이 사실 점으로 이루어져 있다고 알고있는 A개발자와 
처음부터 점이라는 개념없이 '원'이라는 도형만을 접하고 시작한 B개발자는
목적을 달성할 수 있는 유연성과 시간에서 차이가 날수밖에 없는 것인거죠.

예를들어 고객이 10개의 원을 그리며 검사하는데 0도부터 90도까지는 반지름 1 , 90도부터 180도까지는 2 ... 이런 검사방식을 원한다면 A개발자는 각각의 구성에 대한 부분을 점으로 표현하여 한개의 메서드로 끝낼 수 있지만 
B개발자는 방법을 모르니 10번의 메서드를 호출하며 개발하게 되니 더 많은 리소스를 사용하게되고 시간적인면에서도 비효율적일수밖에 없습니다.

 

3장 조엘 테스트 : 더 나은 코드를 위한 12단계

3장에서는 더 나은 소프트웨어 개발 및 구성을 위한 12단계로 구성되어있는데 다음과 같습니다

1. 소스코드 관리시스템을 사용하고 있습니까?
2. 한방에 빌드를 만들어낼 수 있습니까?
3. 일일 빌드를 하고 있습니까?
4. 버그 추적 시스템을 운영하고 있습니까?
5. 코드를 새로 작성하기 전에 버그를 수정합니까?
6. 일정을 업데이트하고 있습니까?
7. 명세서를 작성하고 있습니까?
8. 조용한 작업 환경에서 일하고 있습니까?
9. 테스터를 별도로 두고 있습니까?
10. 경제적인 범위 내에서 최고 성능의 도구를 사용하고 있습니까?
11. 프로그래머 채용 인터뷰 때 코딩 테스트를 합니까?
12. 무작위 사용편의성 테스트를 수행하고 있습니까?

각각 1점의 점수를 부여하여 현재 소프트웨어 개발팀들의 점수를 확인하라고 말하는데

저와 같이 일하는 2명의 팀구성으로 점수를 내봤을때에는 3점의 형편없는 점수가 나왔습니다.
( 8, 10, 12 )

 

규모가 작은 팀이라 일일빌드 및  테스터, 코딩 테스트 등의 단계는 사실 불필요하다고 생각하지만

나머지 소스코드 관리시스템, 버그 추적시스템, 명세서작성 에대해서는 

어렴풋이 알고는 있었지만 사실상 귀찮음 때문에 하지 않았다는 점에서 반성을 하게되기도 했습니다.

 

그런데 여기서 "일일 빌드를 하고 있습니까?" 에 대해서는 사실 이해가 잘 안되는 부분이 많았습니다.

저는 반도체, 디스플레이 검사장비를 만드는 회사에서 약 3~4년정도 근무를 하는동안 

한개의 프로젝트(설비)를 1~2명의 개발인원이 붙어서 개발하는 경우가 대다수였고, 개발 또한 초기개발이 아닌 단순히 설비구동 시퀀스 순서를 바꾸거나 몇가지 기능을 추가하는 CS업무가 대부분이었습니다.

그나마 경험해본 초기개발이라고 한다면 설비 도화지 프로젝트를 하나 긁어오거나 현재 설비와 가장 비슷한 코드를 가져와서 해당 코드를 수정하는 방식으로 대부분 작업을 했죠.

그리고 그 소스를 2명에서 동시에 개발하는경우가 있다라고 하더라도 둘이서 작성한 코드를 하루하루 
Beyond Compare라는 Merge 프로그램을 사용하여 하루동안 작업한 것을 직전 소스를 기반으로 Merge하는 방식을 사용했습니다.

 

그래서 사실 " 소스파일을 코드 저장소에 추가한다." , "빌드를 깨지 않게 만든다 " 라는 문장 자체가 대규모 팀에서 일을 해보지 않았으니 어떠한 개념인지 이해가 잘 되지 않았습니다.

그래서 남은 기간동안 "10장. 일일 빌드는 당신의 친구입니다"을 읽으며 현재 2명으로 구성되어있는 현재 상황에서도 적용할 수 있는 개념인지 파악해보려 합니다.

 

그리고 나머지 단계들 또한 책을 읽으며 꼭 필요한 단계들이라는 것을 다시금 느꼈기에 
"5~8장 손쉬운 기능명세 작성법", "9장 손쉬운 소프트웨어 일정 관리법", "10장 일일빌드는 당신의 친구입니다." 에대해서 내일 꼼꼼히 읽어볼 예정입니다.

 

마무리하며

2장의 내용은 사실 요즘 나오는 PC들의 성능과 프레임워크 구성이 워낙 좋아서 위 내용들에 대해 큰 문제가 되지는 않겠지만

프로그램에 대해서 본질적으로 생각해볼 수 있는 기회가 되었고,

3장을 읽으며 소프트웨어 프로젝트를 실현해 나아가는 명확한 규칙과 구조가 있는다는 것에 안도의 한숨을 내쉬기도 했습니다.

 

"소프트웨어 장인"에 나오는 내용과도 닮아있지만 조금 더 체계적인 구조를 알수 있게하고,
시야를 넓혀줄 수 있는 책을 소개해주신 멘토님께 감사하며 글을 마칩니다.