Skip to main content

소프트웨어 공학의 사실과 오해

소프트웨어 컨플릭트 2.0을 읽고 나서 이 책의 저자 Robert L. Glass자가 쓴 또 한권의 책을 찾아 읽게 되었습니다. 그 책의 제목이 바로 이 글의 제목인 소프트웨어 공학의 사실과 오해입니다.

이제는 일반적으로 인식되고 있는(제 생각에) 사실과 오해들이 담겨 있어 아주 새롭게 느껴지는 내용은 없었으나 소프트웨어 공학의 여러 문제점들에 대한 역사를 정리하기에 괜찮은 책인것 같습니다.

저자는 실무에서 경력을 시작하여 학계로 온 사람이라 그런지 유지보수에 대한 많은 의견을 적어 놓았습니다. 연구에 따르면 소프트웨어 비용의 약 60%가 유지보수에 사용되고 여기서 다시 60%는 오류 수정이 아닌 기능 개선에 쓰인다고 합니다. 유지보수 비용에서 오류 수정이 차지하는 비중은 단지 17%라고 하는군요. 그리고 유지보수를 꺼려하는 태도를 고치기 위해 유지보수를 문제로 바라보지 말고 해결책으로 바라보아야 한다고 조언하고 있습니다.

또한 사람들이 유지보수를 꺼려하는 이유는 그것이 개발보다 어렵기 때문이며 어려운 이유는 남이 작성한 코드를 이해하기 어렵기 때문이라고 합니다. 이 점에 대해서는 저도 동의합니다. 때론 처음부터 그 부분을 다시 작성하는 것이 더 좋은 경우도 많이 있었으니까요.

제 생각으로는 유지보수를 꺼려하는 또 하나의 이유는 유지보수로는 유명해질 수 없기 때문이 아닐까 합니다. 유명한 개발자라는 말은 있지만 유명한 유지보수자라는 말은 들어보지 못했으니까요. :roll:

우리 모두 하기 싫어하는 유지보수 작업을 누군가는 해야 하니 큰 문제가 아닐 수 없네요.

이밖의 내용을 간단히 요약해 보면

  1. 소프트웨어 공학의 silver bullet은 없고 앞으로도 없을 것이라는 것

  2. 비록 silver bullet은 아니지만 많은 도움을 줄 수 있는 도구나 방법들이 실제 사용하지 않고 있다는 것

  3. 학계는 실무를 좀 더 이해하고 고려하여야 한다는 것


정도였던 것 같습니다.

요새 이런 에세이류의 책들을 읽다보니 여기 쓰는 글도 비슷해지는 경향이 있는 것 같습니다. 아무래도 C++ 코드가 없으니 글쓰기가 어렵네요. ;-)
Labels:

Comments

  1. mkseoFebruary 24, 2007 at 7:53 AM

    이책 저도 서점에서 훑어본 기억이 나네요. 유명한 유지보수자라는 것 어려운 일이네요..

    ReplyDelete

Post a Comment

Popular posts from this blog

1의 개수 세기 - 해답

벌써 어제 말한 내일이 되었는데 답을 주신 분이 아무도 없어서 좀 뻘쭘하네요. :-P 그리고 어제 문제에 O(1)이라고 적었는데 엄밀히 얘기하자면 O(log 10 n)이라고 적었어야 했네요. 죄송합니다. ... 문제를 잠시 생각해보면 1~n까지의 수들 중 1의 개수를 얻기 위해서는 해당 숫자 n의 각 자리의 1의 개수가 모두 몇개나 될지를 구해서 더하면 된다는 사실을 알 수 있습니다. 예를 들어 13이라는 수를 생각해 보면 1~13까지의 수에서 1의 자리에는 1이 모두 몇개나 되는지와 10의 자리에는 모두 몇개나 되는지를 구해 이 값을 더하면 됩니다. 먼저 1의 자리를 생각해 보면 1, 11의 두 개가 있으며 10의 자리의 경우, 10, 11, 12, 13의 네 개가 있습니다. 따라서 2+4=6이라는 값을 구할 수 있습니다. 이번엔 234라는 수에서 10의 자리를 예로 들어 살펴 보겠습니다. 1~234라는 수들 중 10의 자리에 1이 들어가는 수는 10, 11, ..., 19, 110, 111, ... 119, 210, 211, ..., 219들로 모두 30개가 있음을 알 수 있습니다. 이 규칙들을 보면 해당 자리수의 1의 개수를 구하는 공식을 만들 수 있습니다. 234의 10의 자리에 해당하는 1의 개수는 ((234/100)+1)*10이 됩니다. 여기서 +1은 해당 자리수의 수가 0이 아닌 경우에만 더해집니다. 예를 들어 204라면 ((204/100)+0)*10으로 30개가 아닌 20개가 됩니다. 이런 방식으로 234의 각 자리수의 1의 개수를 구하면 1의 자리에 해당하는 1의 개수는 ((234/10)+1)*1=24개가 되고 100의 자리에 해당하는 개수는 ((234/1000)+1)*100=100이 됩니다. 이들 세 수를 모두 합하면 24+30+100=154개가 됩니다. 한가지 추가로 생각해야 할 점은 제일 큰 자리의 수가 1인 경우 위의 공식이 아닌 다른 공식이 필요하다는 점입니다. 예를 들어 123에서 100의 자리에 해당하는 1의 개수는 ((123/1...
3 comments
Read more

CodeHighlighter plugin test page.

This post is for testing CodeHighlighter plugin which uses GeSHi as a fontifier engine. ((Those code blocks are acquired from Google Code Search .)) ((For more supported languages, go CodeHighlighter plugin or GeSHi homepage.)) C++ (<pre lang="cpp" lineno="1">) class nsScannerBufferList { public: /** * Buffer objects are directly followed by a data segment. The start * of the data segment is determined by increment the |this| pointer * by 1 unit. */ class Buffer : public PRCList { public: Buffer() { ++index_; } PHP (<pre lang="php" lineno="4">) for ($i = 0; $i $value = ord( $utf8_string[ $i ] ); if ( $value < 128 ) { // ASCII $unicode .= chr($value); } else { if ( count( $values ) == 0 ) { $num_octets = ( $value } $values[] = $value; Lisp (<pre lang="lisp">) ;;; Assignment (define-caller-pattern setq ((:star var fo...
88 comments
Read more

std::map에 insert하기

얼마전 회사 동료가 refactoring한 코드를 열심히 revert하고 있어서 물어보니 다음과 같은 문제였습니다. 원래 코드와 refactoring한 코드는 다음과 같더군요. nvp[name] = value; // original code nvp.insert(make_pair(name, value)); // refactored 아시겠지만 위의 두 라인은 전혀 다른 기능을 하죠. C++03에 보면 각각 다음과 같이 설명되어 있습니다. 23.1.2/7 Associative containers a_uniq.insert(t): pair<iterator, bool> inserts t if and only if there is no element in the container with key equivalent to the key of t. The bool component of the returned pair indicates whether the insertion takes place and the iterator component of the pair points to the element with key equivalent to the key of t. 23.3.1.2/1 map element access [lib.map.access] T& operator[](const key_type& x); Returns: (*((insert(make_pair(x, T()))).first)).second. 원래 코드는 매번 새 값으로 이전 값을 overwrite했지만 새 코드는 이전에 키가 존재하면 새값으로 overwrite하지 않습니다. 따라서 원래 기능이 제대로 동작하지 않게 된것이죠. 그래서 물어봤죠. "왜 이렇게 했어?" "insert가 성능이 더 좋다 그래서 했지." :-? 사실 Fowler 아저씨는 Refactoring 책에서 refactoring은 성능을 optimizing하기 위한 것이 아니다라...
3 comments
Read more