대한민국에는 소프트웨어가 없다 (김익환 저)를 읽고 나서 급 내용정리....

  저자는 한국에서 서울대학교 공대를 졸업한 후 미국 실리콘밸리 등지에서 미국의 소프트웨어 개발 문화를 배웠다. 또 미국에서 일하면서 한국 IT관련 종사자들과 접촉하며 미국과 한국 양측의 소프트웨어 개발 문화의 차이를 직접 느낀 사람이다. 이 책에는 저자가 이렇게 두 나라의 소프트웨어 개발 문화를 접하면서 느낀 점과, 우리나라의 소프트웨어 개발 문화 발전을 위한 조언들이 담겨 있다.

  내용 전개를 보면, 먼저 소프트웨어는 기술적 관점이 아니라 문화적인 관점에서 접근해야 함을 강조한 뒤 정부, 경영자, 중간 관리자, 프로그래머에게 각각에 맞는 조언을 던지고 있다. (물론 그것이 이 책이 쓰여진 2003년도 즈음에 적합했을 조언인 경우도 있지만.)

  맨 처음 강조하는 내용은 소프트웨어 산업의 발전은 기술 도입 등으로 이루어 지는 것이 아니라 프로그래머, 소프트웨어 엔지니어, 시스템 분석가, 아키텍트가 각자 자기 역할을 맡아 조직적으로 소프트웨어를 개발하는 문화가 이루어질 때 가능하다는 것이다. 또 이러한 문화가 사회에 뿌리내려야 현재 한국의 상황처럼 프로그래머가 그저 도구처럼 사용되는 현실을 개선할 수 있다고 주장한다. 나아가 이런 문화가 정착되어야 프로그래머가 경험을 쌓아서 소프트웨어 엔지니어, 시스템 분석가, 아키텍트 같은 고위 기술직에 종사할 수 있게 되고 대한민국의 소프트웨어 산업이 안정화될 수 있음을 역설한다.
  필자는 건강한 소프트웨어 문화 정착을 위해 정부, 경영자, 중간관리자, 프로그래머가 알아야 할 것들을 책의 남은 부분에서 언급하고 있다. 

  정부에 대해서는 IT강국이라는 명성에 걸맞지 않은 허점들 (잡초같은 회사를 키워 주는 자금 지원, 쓸데 없는 지원금, 외국 인력 유치 정책의 맹점, 외국인이 겪게 되는 제한적인 IT 서비스, 허접한 영어) 을 지적한다. 돈을 지원하는 정책은 비리로 얼룩지지 않도록 주의하며, 정말 해당 정책이 소프트웨어 산업 발전에 도움이 되는지 숙고한 후에 예산을 들이라고 이야기한다. 또 그저 코딩도구로 사용할 외국인 프로그래머가 아니라, 소프트웨어 개발 및 문화 발전에 큰 도움을 줄 수 있는 정말 능력있는 외국 소프트웨어 엔지니어를 많이 한국으로 부를 수 있는 정책을 만들기를 요구하고 있다. (보조금 뿐만 아니라, 외국인이 한국에서 IT환경을 누릴 수 있는 편의 보장 등등...)

  경영자에게는 소프트웨어 개발이 일반적인 생산업과는 완전히 다른 것임을 설명하고, 그에 따른 회사 문화의 차이, 가져야 할 마인드의 차이 (ex. 개발 및 유지보수의 중요성, 커뮤니케이션의 중요도, 도전정신, 개발을 위한 철저한 계획의 필요성, 자문받는 것의 중요성, 무조건 결과물만 요구하지 않기 등등....) 를 역설하고 있다.

  중간관리자에게는 프로그래머들의 일을 관리하는 방법에 대해 이야기하고 있다. 버전 관리 프로그램, 회의 >>>>>>> 코딩, 서로 이해하기 쉬운 코드 짜기, 소프트웨어 개발 기간 예측, 조직 차원에서의 코드 검토 (line by line..., 소프트웨어를 만드는 조직 문화의 중요성), 시작 전의 충분한 분석, 충분한 지식, 독립된 DB관리자의 필요성, 개발 model (요구사항 분석 -> 설계 -> 구현 -> 테스트 -> 운영 및 유지보수), 커뮤니케이션의 중요성 (어딜 가나 중요하다..) 등등에 대해서 알아야 할 필요가 있음을 이야기하며,

  프로그래머에게는 (가장 직접적으로 배울 내용이 많았던 부분.....)
 
1. OOP를 제대로 아는지, OOP의 기본은 지키는지, 구동이 된다고 해서 프로그램이 전부는 아니라는 것

ex) 의미상 private으로 선언해야 하는데 public으로 선언하여도 동작이 되는 경우....
-> 이런 경우 꼭 private으로 선언 해야 프로그램 확장, 보수할 때 생각을 하기 편해진다. 

2. 프로그램 테스트의 중요성
  - 분류
     : 목적에 따른 분류
         Positive test (원하는 기능이 정상적으로 작동하는지 테스트)
         Negative test (모든 비정상적인 입력에 대해 프로그램이 어떻게 동작하는지 테스트
       방법에 따른 분류
         Black box test (소스 코드 참조 없이 기능 정의한 내용만 보고 테스트)
         White box test (소스 코드를 한줄한줄 보면서 모든 줄이 제대로 작동하는지 테스트)
         Gray box test (소스 코드를 참조하지만, 기능 정의한 내용을 이해하기 위한 것일 뿐, 모든 줄이 테스트되지는 않음)

3. 라이브러리 활용 능력

4. case 1, 2 ... 따위의 숫자 대신 이해하기 쉽고, 코드에 추가, 수정하기도 쉬운 enum 이용하기

ex)
boolean handleOperation (int operation, String data)
{
    switch (operation) 
    {
        case 1 :
        ...
            break; 
        case 2 :
        ...
            break; 
        case 3 :
        ...
            break; 
        case 4 :
        ...
            break;  
        default :
    }
}

이렇게 알아볼 수 없는 1, 2, 3, 4 대신에....

class Constant
{
    public static final int OP_SAVE = 1; 
    public static final int OP_OPEN = 2; 
    public static final int OP_DELETE = 3; 
    public static final int OP_UPDATE = 4;  
}
 

boolean handleOperation (int operation, String data)
{
    switch (operation) 
    {
        case Constant.OP_SAVE :
        ...
            break; 
        case Constant.OP_OPEN : 
        ...
            break; 
        case Constant.OP_DELETE : 
        ...
            break; 
        case Constant.OP_UPDATE : 
        ...
            break;  
        default :
    }

}
  이런 식으로....
  절대 이상한 숫자들이 코드에 이용되어서는 안된다... 

5. assert 이용

6. 물샐틈 없는 코딩 (if,else, case~switch 등에서 빼먹는 case가 없도록 하기..)

ex)
boolean handleOperation (int operation, String data)
{
    switch (operation) 
    {
        case Constant.OP_SAVE :
        ...
            break; 
        case Constant.OP_OPEN : 
        ...
            break; 
        case Constant.OP_DELETE : 
        ...
            break; 
        case Constant.OP_UPDATE : 
        ...
            break;  
        default :
            Debug.assert (false);
    }
} 

  이런식으로 default같은거 빼먹지 말고, 오류가 발생할 경우 assert 같은걸 써 둬서 어디서 오류가 발생했는지 쉽게 확인하도록 코딩한다. 

7. 코드 동작에 군더더기가 없게 하기

ex) str = str + message;      (vs)  str = str.append (message);

  왼쪽 코드에서는 str이라는 string을 memory에 계속 복사하게 됨.
  오른쪽 코드에서는 str을 계속 복사하지 않고, 뒷 부분에다 message 내용만 추가함.
  오른쪽 코드의 동작이 더 적음

  많이 반복되는 loop에서, 왼쪽과 같이 군더더기가 많은 코드가 오른쪽 코드 대신에 실행되면 프로그램의 수행속도는 급 감소한다..

8. NULL pointer 주의

9. 코드의 일부를 복사하여 수정해서 사용하는 일은 금물

ex1)
if (x>y) {
    price = getPrice(x);
}
else {
    price = getPrice(y);
}

=> getPrice변수에 item이 추가, getPrice할 때 마다 log를 작성할 필요성이 생김, getPrice의 오류 처리 부분 추가

if (x>y) {
    try {
        price = getPrice(x, item);
    }
    catch (Exception ex) {
        ex.printStackTrace();
    } finally {
    .........
    }
    writeLog (x, item, price);
}
else {
    try {
        price = getPrice(y, item);
    }
    catch (Exception ex) {
        ex.printStackTrace();
    } finally {
    .........
    }
    writeLog (y, item, price); 
} 

ex2)
int z;
if (x>y) {

    z = x;
}
else {
    z = y;
}
price = getPrice (z);

=> getPrice변수에 item이 추가, getPrice할 때 마다 log를 작성할 필요성이 생김, getPrice의 오류 처리 부분 추가 

int z;
if (x>y) {

    z = x;
}
else {
    z = y;
}

try {
    price = getPrice (z, item);
} catch (Exception ex) {
    ex.printStackTrace();
} finally {
    ........
}
writeLog (z, item. price)
 
이런 식으로 처음에 코드를 잘 짜야 중복을 피할 수 있음... 

10. debug나 log출력 on/off 가능하게 하기

  등등을 알려주고 있다.

  글을 읽다보면 내용이 두루뭉술하게 다가올 수도 있고, 구체적으로 다가오기도 하는데, 조금만 곰곰히 생각해 보면 당연한 내용이라서 절로 고개를 끄덕이며 쉽게 읽을 수 있던 책이었다.
  또 소프트웨어를 제대로 개발하는 것은 학교에서 간단히 나오는 프로젝트나 과제 수준이 아니라 유지, 보수 등 생각보다 고려해야 할 것이 훨씬 많다는 사실이 충격이었다. 현재 내 입장에서는 '프로그래머에게 하는 조언' 부분이 가장 크게 와닿았고, 배워야 할 내용이 많았던 것 같다. 하지만 소프트웨어를 개발할 때 필요한 사전 준비와 개발 framework 같은 내용들을 절대 잊지 말아야 할 것 같다. 이러한 기본기를 철저히 쌓아서 훌륭한 사람이 되어야지...... ㅠㅠ