이응기역

스콧 로젠버그, 황대산 옮김, 드리밍 인 코드:천국과 지옥을 넘나드는 소프트웨어 개발 이야기, 에이콘, 2009년, 서울


소프트웨어 개발에 대한 온갖 생각이 소개된 책이다. 저자는 챈들러 프로젝트를 유려하게 기록하기 위해 썼을지도 모른다. 하지만, 나는 소프트웨어가 왜 실패하는지, 프로젝트가 왜 어려운지에 대해 갑론을박을 하는 토론의 대 향연으로 보인다.

다행히 챈들러 프로젝트는 계속되고 있다.

30여년 전 프레데릭 브룩스는 이런 말을 했다. "소프트웨어 개발에 있어 가장 어려운 일은 개발 그 자체가 아니라, 무엇을 개발하지를 결정하는 일이다"(47)

2004년 11월에는 영국의 국민연금 시스템 전체가 다운됐다.(69)

인간이 현실과 소통하기 위해 사용하는 패턴 인식의 원칙을 이용해 소프트웨어를 개발하면 어떨까?(351)

 

그냥 최대한 빨리 이슈 추적 시스템을 사용하세요.(49)

참고 사이트
CVS http://www.cvshome.org (<-- 현재 제대로 운영되지 않고 있다. http://www.nongnu.org/cvs/ 대신 이곳을 보라)

서브버전 http://subversion.tigris.org


참고 도서
"Mastering Regular Expressions", Jeffrey Friedl


"실용주의 프로그래머를 위한 버전관리 using  CVS", 데이비드 토머스, 앤드류 헌트 공저, 인사이트

* 코드가 어떻게 동작하는가 이해해야 하지만, 꼭 그 내용에 전문가가 될 필요는 없다...

* 팀원 가운데 한 사람이 코드가 너무 어려워서 다른 사람은 이해할 수 없다고 말한다면, 누구라도(원저자를 포함해서) 유지 보수하기가 힘들것이다. 단순화하라.

* 이해하지 않은 상태에고 코드를 고쳐서 못 쓰게 만들지 말라. 땜질식 수정 증후군은 처음엔 아주 천진난만하게 시작하지만 급격히 알아볼 수 없는 쓰레기가 된다. 증상이 아니라 문제를 고쳐라.

* 대부분의 복잡한시스템은 너무나 난해해서 한 사람이 시스템 전체를 이해하기 어렵다. 작업 중인 특정 부분에 대해 더 깊이 이해하는 것 외에도, 시스템의 각 부분이 서로 어떻게 상호작용하는 지 알기 위해 시스템의 대부분에 대하여 상당한 수준으로 이해할 필요가 있다.(44-45)

     매 주 팀원 중 한 명에게 토의를 이끌게 하자. 토의를 이끄는 사람은 개념을 제시하거나 툴 사용법을 보여주고, 그렇지 않더라도 팀의 관심을 끄는 것이면 무엇이든지 소개할 것이다. 여러분은 책 한 권을 골라서 그 책에서 특정 단원이나 항목, 실천방법들을 수행해 볼 수도 있다....

  그 주의 회의 주관자가 15 분 정도 얘기하는 것으로 시작하자....모두가 자신의 아이디어를 제안하고 프로젝트에 그 주제가 어떻게 연관되는지 토의할 수 있다.(64)

     다운로드해 얻을 수 있는 프로그램을 새로 만들지 말라. 환상적인 것을 만들고 있다면 ..., 정신 차리고 잘못하고 있음을 깨달아라. 코딩을 적게 할 수록 유지보수할 양이 적다.
     ..."객체 관계 매핑(Object Relational Mapping) 은 컴퓨터 과학의 베트남이다." 라고 테드 뉴워드(Ted Neward) 가 말한 것을 기억하라. 자신의 애플리케이션을 만드는 데 필요한 것만, 즉 도메인이나 애플리케이션에 국한된 프로그램을 만드는 데 더 많은 시간과 노력을 들여야 한다.(94)

프로젝트를 항상 릴리스 가능하게 하라.
프로젝트를 항상 컴파일할 수 있고, 실행할 수 있으며, 테스트하고 당장에 배치할 수 있게 하자.(99)
 
* 고객이 피드백들 주고 프로젝트를 조정하는데 데모의 목적이 있다.  기능이나 안정성이 부족해서 고객을 동요시키거나 화나게 해서는 안된다, 안정성이 없으면 보여주지 말라.(114)

   코드를 시험하는 단위테스트를 미리 작성하기 때문에 , 코드를 수정하거나 리팩터링할 땨마다 코드를 체크인 하기 전에 테스트 케이스를 시험한다.(141)

* 코드가 무슨 일을 하는지 주석을 다는 것은 그다지 유용하지 않다. 그러나 코드가 왜 그렇게 하느지 주석을 다는 것은 유용하다.(171)

* 문제를 문서화하는 것보다 해결하는데 더 많은 시간을 보내야 한다. 문제를 문서화하는 일을 가볍고 간단하게 유지하자. 출판할 정도로 문서화 하지 않아도 된다.

* 이전 해결책을 찾는 것이 중요하다. 따라서 필요하 때 목록을 찾는데 도움이 되도록 많은 키워드를 사용하자.(201)

모든 예외를 처리하거나 전달하라.
예외를 덮어 두지 말자. 임시로라도 말이다. 코드가 실패할 수 있다고 생각하며 작성하자.(213).

* 어떤 사람도 홀로 설계하게 하지 마라. 특히 여러분 자신이 혼자서 설계해서는 안된다.(233)

코드 리뷰...아래의 최소 목록으로 시작해야 한다.
* 코드를 읽고 이해할 수 있는가?
* 명백한 에러는 없는가?
* 코드가 애플리케이션의 다른 부분에 바람직하지 않은 영향을 끼치는가?
*(코드 자체의 배부 섹션이나 시스템의 다른 부분과) 코드 중복이 있는가?
* 코드를 개선시키는 적당한 개선이나 리팩터링이 있는가?
(250)

.. 개발 기반(infrasctructure) 환경을 .. 도입해야 한다.....
* 버전관리
* 단위테스트
* 빌드 자동화
(259)

자료
여러분의 코드는 왜 형편없을가? (Why Your Code Sucks)
http://www.artima.com/weblogs/viewpost.jsp?thread=71730

이 책의 한국어 사이트
http://insightbook.springnote.com/pages/335290

영어판 참고 사이트
 http://www.pragmaticprogrammer.com

정신병원에서 뛰쳐나온 디자인

말로만 들었던 고전, 피플웨어. 고전이라고 하기에는 아직도 너무 적실하게 IT 회사안의 사정을 잘 얘기해주고 있다. 매경 에서 나와서 경영자들도 읽을 수 있는 기회가 더 많이 생긴 것 같다. 그런데 내가 알고 있는 경영자 중에 이 책을 언급하는 이는 아무도 없었다.

발췌

사람들이 업무의 인간적인 측면보다 기술적인 측면에 주로 매달리는 가장 큰 이유는 기술적인 부분이 더욱 중요하기 때문이 아니라 거기에 매달리는 것이 훨씬 더 쉽기 때문이다.(21)

사람들이 회사에서 일하다 보니 '병'이 날 지경이라고 말하면 그 말은 신체의 병을 말하고 있는 것이 아니다. 그 말 뜻은 자신의 정신적 건강을 돌보지 않고 일해야 하는 곳에서 일하고 있다는 것이다. 이것과 관련하여 가장 중요한 것은 '자아존중'이라는 원칙이다. 자아를 존종할 수 없게 만드는 일터는 그 자체로 이미 '병든' 것이다.(227)

팀이라는 구조는 상호 평등한 네트워크이지 위계적인 것은 아니다....팀이라는 측면에서 보면 리더십은 그다지 필요하지 않다.(246-7)

사람들이 초과 근무를 하는 이유는 과제를 주어진 시간 안에 끝마치기 위해서라기보다는, 일을 정해진 기간까지 끝마치지 못했을 때 비난받게 될 것을 우려해 자신을 보호하기 위함이다.(284)

 야마모토 케이지 지음, 이지연 옮김, 인사이트

람들을 잘 협력하게끔 하는 사람이다. 프로젝트 관리에 대한 마음가짐의 중요성을 더 일깨워준다. 언제나 소프트웨어는 피플웨어인가 보다.

아래는 발췌
아키텍트 주도로 비기능 요구사항을 정리한다 (64)
문제의 해결책을 제시한다...위험요소를..해결한다(68)
의도를 전달하는 것이 중요하다(83)
(비기술자에게 의견을 전달할 때는 ).. 필요한 정보를 간략하게 전달해야 한다(181)
아키텍트는 ...기술자와 비즈니스 관계자들이 서로 협조할 수 있도록 조정자 역할을 한다(215)

웹 2.0을 이끄는 방탄웹 책에 실린 소스 출처는 http://acornpub.co.kr/book/webstandard-set