작도닷넷 블로그
작도닷넷 블로그

리뷰 - 출판

Steve McConnell - Code Complete 2

09/08/12 12:02(년/월/일 시:분)

코드 컴플리트로 유명한 스티브 맥코넬씨가 우리 회사에 와서 강연을 했다.

책 내용을 1시간 30분 정도로 줄여서 얘기했는데.



책에서도 느꼈지만

전혀 재미가 없었다... 이 사람 스타일이 그런 것 같다.

무척이나 졸리고 고리타분했음. 하긴 원리 원칙 위주였으니. 귀에 솔깃한 얘기보다는.


하여간 이사람은 애자일(Agile) 방법론을 싫어했다.

뭐랄까 나도 좀 사기성이 있다고 생각했는데. 중소규모 프로젝트에는 그럭저럭 넘어갈 수 있을지 몰라도 대규모 프로젝트에는 거의 안 맞는다.


특히 자기 입으로 Visual Basic 칭찬할때는 뭐랄까

아무리 MS 출신이라지만 너무 뻔뻔하지 않나 ㅋㅋ 싶었는데



하여튼

틀린 얘기는 안 하는 아저씨였음.

다소 지루하긴 하지만.




목차

1. SW 구축의 핵심 원리

2. 지난 10년간 최악의 구축 아이디어 10개

3. 지난 10년간 최고의 구축 아이디어 10개

4. 현대 SW 구축의 10가지 현실





1. SW 구축의 핵심 원리

"No Silver Bullets"   생산성을 10~20%, 2~3배 높이는 방법은 있어도, 10배씩 높이는 방법은 없다. 만능 방법론은 없다.

본질적인 어려움 vs. 부수적인 어려움   사소한 어려움을 해소하기 위해 본질적인 어려움을 키우면 안된다. 본질적인 어려움에 집중하라.

복잡함 vs. 단순함   우리의 머리는 한계가 있다. 한 번에 생각할 단위를 줄여라.

복잡성 관리   가장 중요하다. 간단하고 명백하게 작성하라.

가독성: 쓰기 편리하게(X) -> 읽기 편리하게(O)   쓰는 건 한 번이지만 읽는 건 수십 번이다. 코드로 다른 사람과 커뮤니케이션하라.

인터페이스   인터페이스에 '맞추어' 작성(X) -> 인터페이스를 '통해서' 작성(O)

단어 통일   똑같은 의미의 단어는 통일해서 사용하라. 약자도 통일하라.

품질에 집중하라   개발 초기부터 품질 테스트를 해서 결함을 조기에 제거하라. 안정화 기간이 짧아진다.



2. 1990년대 최악의 구축 아이디어

code & fix   일단 코딩부터 시작, 고쳐가며 만들기

all design up front   모든 설계를 처음에 다 하기

컴포넌트 만능 주의

자동 프로그래밍   3~4년마다 논문이 나오지만 항상 실패

폭포수 모델의 잘못된 사용



3. 2000년대 최악의 구축 아이디어

no design up front   처음에 디자인을 전혀 안 하기

리팩터링의 지나친 신뢰

해외 아웃소싱 만능주의

XP(eXtreme Programming)의 잘못된 사용

모든 Agile 방법론



4. 지난 10년간 최고의 구축 아이디어 10개

설계가 중요해짐   (UML)

일단위 빌드, 간략 테스트   개발에 따라 시스템이 커져도 버그가 따라 급격히 증가하지 않는다.

표준 라이브러리   (Win32, MFC, java.*)

Visual Basic   (4GL Tool)

오픈 소스   학생들도 실제 기업 규모의 소스를 학습할 수 있다.

웹   게시판, 검색엔진으로 자료를 찾기 쉬워졌다.

점층적 개발   조그만 프로그램부터 시작해서 조금씩 추가해가며 큰 프로그램을 만든다.

테스트 우선 개발   TestCase (JUnit), 일단위 빌드/테스트

리팩터링   문제가 생길때마다 앞단까지 바로바로 고친다.

컴퓨터가 빨라짐   OOP 등 다소 컴퓨팅 파워를 소모하며 개발 생산성을 높이는 방법이 대중화되었다. (예) Python은 C++보다 100배 이상 느리지만 4배 이상 코드 짧아짐.



5. 현대 SW 구축의 10가지 현실

"구축"은 여전히 다룰만한 주제다

개인차가 확실하다   연구에 따라 10배에서 28배까지 차이난다. 숙련자의 특징- 디자인(UML), 요구사항 준수, 코딩(변수명, 형식, 주석), 코드 읽기, 통합, 디버깅, 테스팅, 팀워크, 툴 사용

개인 수련이 중요하다   팀워크도 중요하지만 개인의 열정,용기가 더욱 중요하다.

복잡함보다는 간단함에 집중하라

결함 비용은 여전히 증가하고 있다   Agile 방법론도 결함 비용을 줄이진 못한다. 결함은 방법론과 상관없이 관리해야 한다.

설계가 중요하다   산출물을 너무 많이 만들어도 안 좋고, 아예 없어도 안 좋다. 필요한 만큼 만들면 된다.

기술 흐름이 영향을 준다   기술도입 초기, 성숙기, 후기에 따라 접근방법이 달라진다.

점층적 접근이 최고다   폭포수 모델보다 나선형 모델이 효과적이다. 모든 프로젝트는 어떤 형태로던 반복적이다.

공구상자 비유가 현혹한다   여러 방법론이 있지만, 어디까지나 망치, 드라이버, 스패너처럼 특정한 범위에서만 동작하는 공구상자일 뿐이다. 지나치게 신뢰하지 말 것.

SW의 핵심 긴장은 여전하다

   꽉 짜여진 플랜 vs. 자유로운 개발

   창의성 vs. 구조적 접근

   양 vs. 질

   프로세스에 집중 vs. 제품에 집중

   이런 긴장은 여전하다. 균형을 잘 잡아라.

http://xacdo.net/tt/rserver.php?mode=tb&sl=1778

  • Harry 09/09/26 04:44  덧글 수정/삭제
    직접 강연을 들어 본 적은 없지만 책을 읽으면서 굉장히 재밌는 아저씨라고 생각했는데 말이죠...;; 중간 중간 위트나, 비유 같은 것들..
이름
비밀번호
홈페이지 (없어도 됩니다)

비밀글로 등록
작도닷넷은 당신을 사랑합니다.

[이전 목록]   [1] ... [208][209][210][211][212][213][214][215][216] ... [671]   [다음 목록]

최근 글

이웃로그 관리자 옛날 작도닷넷 태터툴즈 ©현경우(xacdo) since 2001