주네의 열린 소프트웨어

이 가운데 쓸만한 몇가지 원칙을 뽑아 본다면..

일반원칙

• 품질이 제일이다.
• 사후에 품질을 만들어 넣으려하지 마라.
• 성능보다 신뢰성이 더 중요하다.
• 시제품을 고객에게 빨리 보여준다.
• 처음 시도하는 것은 폐기할 작정으로 개발한다.
• 보면 볼수록 더 많은 것을 원한다. (변경에 대비하자)
• 개발중의 변경은 피할 수 없다.
• 가능하면 개발하기 보다는 구매한다.
• 사용자 메뉴얼이 간단하게 되도록 소프트웨어를 개발한다.
• 아무리 복잡한 문제라도 해결책은 있다.
• 소프트웨어 도구는 우수한 개발자에게 제공한다.
• 대세를 따를 때는 주의해야 한다. (신기술대한 맹목적 수용은 위험)
• 문서표준을 사용한다
• 모든 문서에 용어정의를 한다.

요구사항 원칙

• 요구사항이 불명확할수록 비용예측이 어렵다.
• 시제품으로 사용자 인터페이스 선정의 위험을 줄인다.
• 요구사항의 우선순위를 정한다.

설계원칙

• 설계산출물에서 요구사항을 추척한다.
• 문서가 없는 설계는 설계가 아니다.
• 캡슐화한다.
• 가능하면 재사용한다.
• 단순하게 개발한다.
• 특수한 경우를 많이 만들지 않는다.
• 변경이 쉽게 설계한다.
• 효율적인 알고리즘을 사용한다.
• 뛰어난 설계는 뛰어난 설계자가 한다.
• 무모한 값을 입력하면 적절한 오류 메시지를 출력하도록 한다.

코딩원칙

• 글로벌 변수를 사용하지 않는다.
• 의미있는 명칭을 사용한다.
• 사람을 위한 프로그램을 작성한다.
• 최적의 자료구조를 사용한다.
• 코드를 완성하기 전에 주석을 작성한다.
• 코딩을 시작하기 전에 문서화한다.
• code 검토를 실시한다.
• 너무 깊이 중첩시키지 않는다.

시험원칙

• 시험에서 요구사항을 추척한다.
• 시험하기 훨씬 이전에 시험을 계획한다.
• 자신이 개발한 소프트웨어는 자신이 시험하지 않는다.
• 블랙박스 시험과 화이트박스 시험을 실시한다.
• 항상 스트레스 시험을 한다.
• 단위시험이 끝나기 전에 통합하지 않는다.
• 소프트웨어에 특정한 시험용 코드를 내장시킨다.

관리원칙

• 뛰어난 관리는 뛰어난 기술보다 중요하다.
• 고객의 우선순위를 알아야한다.
• 많은 사람보다는 소수정예요원이 낫다.
• 항상 기대치를 높이 가진다.
• 능숙한 의사소통 기술은 필수적이다.
• 인력과 시간은 대체할 수 없다.
• 소프트웨어 개발자의 능력차이는 크다.
• 불가능한 것은 피한다.
• 적절한 프로세스 모델을 사용한다.
• 직면한 위험을 이해한다.
• 방법론이 당신을 구제해 주지는 못한다.

제품보증 원칙

• 형상관리 절차를 조기에 확립한다.
• 모든 중간산출물에 명칭과 버전 번호를 부여한다.
• 기준선을 통제한다.
• 모든 것을 보존한다.
• 변경관리를 해야 한다.

진화원칙

• 소프트웨어는 계속 변화한다.
• 증상이 아닌 근본적인 문제를 수정한다.
• 최악의 구성요소는 처음부터 다시 개발한다.
• 변경한 후에는 반드시 회귀시험을 실시한다.
• 비구조적인 코드는 구조화해도 개선되지 않는다.

이상입니다~

소프트웨어 개발자는 공부를 많이 해야 한다. 새로운 기술이 늘 쏟아지다 보니 지금 유행하는 기술도 어느새 최신 기술에 밀려 찬밥 신세가 되고 만다.

모뎀으로 겨우 통신이 가능하던 시절에는 대부분의 개발자가 단독으로 실행되는 프로그램을 개발했지만 인터넷이 등장하고 웹이 일반화되면서 웹개발이라는 새로운 영역이 생겨나기 했다.

C, C++이 보편적으로 쓰이던 때에 갑자가 Java, C#이 이라는 언어가 나타나서 개발자들에게 배울거리는 던져주기도 했다.

그러고 보면 그 옛날 열심히 공부했던 VB, Win32API, MFC는 최근 2년간 거의 사용하지 않고 C, C++ 기본 라이브러리로만 개발을 해왔었다.

툴과 언어는 계속 진화하고 또 사라진다. 특히 10여년전에 만들어진 언어는 지금도 버전업하면서 더 복잡해지고 있다. 특히 툴이나 특정 프레임웍 또는 API에 의존적으로 개발을 하다 보면 변화에 둔감해 질 수 있다. 당장 MFC는 앞으로 거의 사용되지 않을 전망이고 Win32 API 미래도 그리 밝아보이지 않는다. 새롭게 출시될 롱혼에서는 이 들을 가지고는 롱혼 전용 애플리케이션 개발은 불가능할 것이다.

그래도 우리가 배우고 익힌 소프트웨어 기술 가운데 변하지 않는 핵심은 분명 존재한다. 하지만 바쁘게 개발을 하다보면 이런 것들을 잘 못느끼고 엉뚱한 것들에 가치를 두는 경우가 많다. 대표적인 것이 툴과 언어에 대한 집착이다.

그렇다면 변하지 않는 것은 무엇이 있을까?

“Professional 소프트웨어 개발”이란 책에서는 SWEBOK에서 식별한 전문 소프트웨어 엔지니어가 갖추어야 할 능력을 구성하는 지식 영역을 다음과 같이 소개하였다.

* 소프트웨어 요구사항(Software Requiremenet)
* 소프트웨어 설계(Software Design)
* 소프트웨어 구축(Software Construction)
(상세설계, 코딩, 디버깅, 단위시험, 코드리뷰, 최적화)
* 소프트웨어 시험(Software Testing)
* 소프트웨어 유지보수(Software Maintenance)
* 소프트웨어 형상관리(Software Configuration Management)
* 소프트웨어 품질(Software Quality)
* 소프트웨어공학 관리(Software Engineering Management)
* 소프트웨어공학 툴과 방법론(Software Engineering Tools and Method)
(CASE 도구, 재사용 코드 라이브러리, 정형 방법론 같은 도구와 방법론의 지원, 조직 내에서 도구와 방법론 채택, 전파하는 기법)
* 소프트웨어공학 프로세스(Software Engineering Process)
(소프트웨어 개발 품질, 일정, 생산성 및 프로젝트와 제품의 특성을 향상시키기 위한 활동)

사실 여기서 많은 개발자들이 앞부분의 2-3개 분야가 모든 것인양 알고 공부해왔을 것이다. 오직 코딩이라는 측면만 보면 그 말도 맞긴 하다. 하지만 우리가 생각하는 것외에 더 많은 지식 영역이 존재하고 이는 더 좋은 소프트웨어를 개발하는데 필수적인 지식이다. 그럼에도 불구하고 많은 개발자들이 품질이나 프로세스와 같은 SE측면을 간과하고 있는 것은 안타까운 부분이다.

나만 좋은 소프트웨어를 개발하는데는 많은 지식이 필요하지 않지만 남이 좋아하는 소프트웨어를 개발하기 위해서는 몇배의 지식이 필요하다.

오늘도 나만을 위한 개발을 위해 엷은 지식에 만족하고 있는지 되묻고 싶다.

참고문헌
* Professional 소프트웨어 개발, 스티브 맥코넬, 2003
* SWEBOK (http://www.swebok.org)

읽을거리
* 프로그래머가 알아야할 것