최상단 광고

2012년 7월 9일 월요일

실용주의 프로그램 - 1편


1. 자신의 기술에 관심과 애정을 가져라

 기술에 관심과 애정이 없다면 이미 일을 하고 있는것에 아무런 의미가 없다. 
 의미없는 일은 곧 지루함을 말하는 것이기에 목표가 없다는 말이기도 하다

2. 자신의 일에 대해 생각하면서 일하라

 일에 대해 생각하며 시간을 보낸다면 소중한 시간을 잡아먹는 것일 수도 있지만
 이러한 생각을 함으로써 받는 보상은 더 많을 것이다. (발전을 느끼는데서 오는 희열 등)


3. 어설픈 변명을 만들지 말고 대안을 제시하라

 고양이가 내 소스코드를 삼켰어요 라고 상사에게 말하는건 이미 도움이 안되며
 그 대신에 상황을 개선하기 위해 무엇을 할 수 있는지 대안을 제시한다

4. 깨진 창문을 내버려 두지 말라

 깨진창문(잘못된결정, 나쁜 설계, 형편없는 코드)을 고치지 않은 채 내버려 두지 말고  
 발견하자마자 바로 고친다. 시간이 안되면 코드를 주석처리를 해서라도 메시지를 표시한다
 조치를 취하고 현 상황을 언제나 잘 관리하고 있다는것을 보여준다

5. 변화의 촉매가 되라

 군인들이 하나의 촉매로 작용해서 마을사람들 스스로 재료를 모아 돌멩이 수프를 만들었던 것 처럼
 시너지의 결과로 모든 사람이 승리 할 수 있다는 걸 보여준다.
 팀원들에게 미래를 살짝이라도 보여준다면 팀원들은 원조를 위해 집결할 것이다
 계속되는 성공에 합류하는건 쉬운 것이다 

6. 커다란 그림을 기억하라

 물을 서서히 데우면 온도가 오르는걸 감지 못하고 삶아져 죽는 개구리가 되지 않는다.
 무엇을 하고 있는가에만 집중하지 말고  큰 그림에 늘 주의를 기울이며 주위의 변화를 지속적으로 살핀다. 

7. 품질을 요구사항으로 만들어라

 사용자들은 멀티미디어 버전을 위해 1년을 기다리느니 지금당장 좀 불편한 소프트웨어를 사용하고 싶어한다
 사용자들에게 뭔가 직접 만져 볼수 있는것을 일찍 준다면 그들은 자연스레 품질을 요구사항으로 변경하게 되어
 더 나은 솔루션으로 도달 하는 길이 될 것이다

8. 지식 포트 폴리오에 주기적으로 투자하라

 비록 소량일지라도 습관 자체가 금액의 합계만큼이나 중요하며 많이 알수록 자신의 가치는 더욱 높아진다
 게다가 컴퓨터 분야는 매우 변화가 빠르므로 더많은 기술에 익숙하다면 그만큼 변화에 적응하기는 쉬울 것이다
 또한, 새로운 것도 빨리 습득하려는 습관을 들이게 되면 얼리어답터들 처럼 많은 이득도 챙기며 
그 분야에 꼭대기에 서게 되는 기초가 될것이다
 (매년 새로운 언어를 최소 하나는 배워라기술서적을 분기마다 한권씩 읽어라. 비 기술서적도 읽어라. 수업을 들어라
  지역 사용자 모임에 참여하라. 다른 환경에서 실험해보라)

9. 읽고 듣는 것을 비판적으로 분석하라

 자신의 포트폴리오에 있는 지식이 정확하고, 벤더나 매체의 과대광고에 흔들림이 없도록 확실히 주의해야 할 것이다

10. 무엇을 말하는가와 어떻게 말하는가 모두 중요하다

 진공속에서 작업하지 않는 이상 의사소통을 해야한다. 그 소통이 효과적일 수록 많은 영향력을 갖게 될 것이다

11. DRY (Don't Repeat Yourself)

 모든 지식은 시스템 내에서 단일하고, 애매하지 않으며 믿을만한 표현 양식을 가져야 한다. 
 소프트웨어를 신뢰성 높게 개발하고, 개발을 이해하여 유지보수가 쉽게 만드는 길일 것이다.

12. 재사용하기 쉽게 만들라

 직접 만드는 것이 아닌 기존의 것을 찾아내고, 또 재사용하기 쉬운 환경을 조성해야 한다.
 그게 쉽지 않다면 사람들은 하지 않을것이며 그렇게 되면 지식 중복의 위험을 각오해야 한다

13. 관련 없는 것들 간에 서로 영향이 없도록하라

 독립적이며, 단일하고 잘 정의된 목적을 가진 컴포넌트를 설계한다.
 이렇게 직교적으로 시스템을 만들게 되면 생산성 향상과 리스크 감소라는 커다란 장점이 있다

14. 최종 결정이란 없다

 의사결정들은 해변가의 모래 위에 쓰인 글씨라 생각한다.
 언제든지 큰 파도가 글씨를 지워버릴 수 있다. 이것을 염두해 두고 하는것과 그렇지 않은것은
 분명 커다란 차이가 있을 것이다

15. 목표물을 찾기 위해 예광탄을 써라

 탄창의 일반탄환들 사이에 일정한 간격으로 끼어 총알을 맞은것과 총 사이에 빛의 궤적을 남기는 예광탄은
 좋은 예이다. 동일한 환경과 제약조건에서 발사되고 날아가며, 목표물에 도달하는 시간이 짧기 때문에
 즉각적인 반응을 얻을 수 있어 비용이 적게 드는 방법이다.
 즉, 코딩에서도 요구사항으로부터 최종시스템의 일부 측면에까지. 빨리. 눈에 보이게 반복적으로 도달해줄
 무언가를 만드는 것이 좋다


16. 프로토 타입을 통해 학습하라

 프로토타이밍은 학습 경험이며, 프로토타입의 가치는 생성된 코드에 있는 것이 아니라
 이를 통해 배우는 교훈에 이다. 이 핵심을 잘 생각하고 만든다면 커다란 도움이 될 것이다
 코드로 작성할 필요는 없다. 화이트보드도 좋고 노트도 좋다. 
 인터페이스만 그려도 그것은 좋은 프로토 타입이다

17. 문제 도메인에 가깝게 프로그래밍 하라

 현재 자신이 쓰고 있는 언어에 가깝게 프로그래밍 한다.
 같은 문제라도 Lisp으로 코딩할때와 C로 코딩할때는 엄연히 다른 해결책이 나오는 것과 같다
 도메인 언어에 가깝게 프로그래밍 한다면 사소한 구현의 세부사항 문제를 신경쓰지 않아도 될 것이다

18. 추정을 통해 놀람을 피하라

 추정에 대한 지식을 배운 후 경험을 통해 추정능력을 계발한다면
 무언가의 가능성을 가늠할 수 잇는 능력을 발휘하게 될 것이다. 
 그렇게 되면 직관적으로 문제가 가능한지 안한지 판단 할 수 있게 된다
    
19. 코드와 함께 일정도 반복하며 조성하라

 추정을 통해 필요한 일정등을 알았다면 당연히 코드는 물론 일정도 반복하며 조성해야 할 것이다
 이 것 또한 팀의 생산성의 높은 영향력을 미칠 것이다

20. 지식을 일반 텍스트로 저장하라

 당연히 코딩을 할때는 기계와 친해져야 하겠지만 지식을 저장할때는
 일반 텍스트로 저장해야 한다. 비 구조적이어야 하는 것만은 아니며
 XML, HTML 등은 잘 정의된 구조를 가진 좋은 일반텍스트의 예이다

21. 명령어 셸의 힘을 사용하라

 셸에 익숙해지는데는 시간이 걸리겠지만 익숙해진다면 프로젝트 생산성은 급 상승 할 것이다.

22. 하나의 에디터를 잘 사용하라

 에디터 하나를 골라서 완전히 마스터하고, 모든 편집 작업에 해당 에디터를 사용한다
 ( 텍스트를 조작하고 멈출때 필요한 키 입력은 이젠 거의 반사운동 수준이 될 것이다)

23. 언제나 소스코드 관리 시스템을 사용하라
    
 SVN,CVS같은 소스코드 관리 시스템은 프로젝트를 진행하는데 많은 도움을 준다
 한주짜리 프로젝트를 진행할지라도 소스코드 관리 아래있으면
 각종문서, 메모, 빌드 과정을 처리하는데 있어서도 안전하게 코드들은 보관될 것이다

24. 비난대신 문제를 해결하라

 버그가 내 잘못인지 남 잘못인지는 이미 중요한게 아니다.
 어쨋거나 그 버그는 우리들의 문제로 남을 것이다.

25. 디버깅을 할떄 당황하지마라

 버그 보고를 받고서 "그건 불가능해"라는 말은 틀렸다
 그런 일은 실제 일어났으며 일어날 가능성은 충분히 있다. 
 또한 증상만이 아닌 원인을 고쳐야 할 것이다

26. "select"는 망가지지않았다

 직접적이건 간접적이건 간에 코드를 수정했고 시스템이 작동을 멈춘다면 한가지 뭔가 책임이 있는 것이다

27.  가정하지 마라. 증명하라

 불가능해 라고 말하는 시점에서 이미 지금까지 알고 있는 진실들을 재평가해야한다.
 놀라운 실패를 대면했을대 불가능하다는 생각 이전에 내가 세운 가정들에 대해서 잘못되었다는 것을
 깨닫고 그것을 맥락 안에 해당 데이터로 증명하는 것이 중요하다

28. 텍스트 처리 언어를 하나 익혀라

 간단한 스크립트 언어들을 펄(Perl)같은 언어로 간단히 만들어 쓰게 된다면 생산성 향상에 크게 도움이 된다
 이러한 언어들은 재빨리 유틸리티를 만들어 낼 수 있고, 아이디어를 프로토타이핑 해볼수 있기 때문이다.
 (루비. 스몰토크. 펄) 등이 있다

29.  코드를 작성하는 코드를 작성하라

 목공이 지그를 만드는데에 시간을 투자하느것처럼 코드생성기를 만들기만 하면 프로젝트 기간 내내
 아무런 비용 없이 사용할 수 있을 것이다

30. 완벽한 소프트웨어는 만들수 없다

 길지않은 컴퓨터 역사속에 그 누구도 완벽한 소프트웨어는 만들지 못했다. 이후도 그렇다
 남을 믿지 않는 방어적 코딩을 해가면서 한 걸음 더 나아가 내 자신 역시 믿지 않게 되면
 자신의 실수에 대비해 방어적으로 코드를 짜게 될 것이다.

31. 계약에 따른 설계를 하라

 계약에 부응하지 못하는 것이 버그가 된다면 그그것은 이미 치명적이다..
 내가 계약에 부응하지 못하는 코드를 만든다면 그 역시 계약 불이행이나 마찬가지이다

32. 일찍 작동을 멈추게 하라

  가능한 빨리 문제를 발견하게 되면 좀 더 일찍 시스템을 멈추는것이 최선일 때가 많다
  자바언어와 라이브러리도 이러한 철학을 기반으로 RuntimeException을 던지게 설계했다

33. Assert를 사용해서 불가능한 상황을 미리 예방하라

 물론 일어나지 않을거야 라는 생각이 들어도 그걸 확인하는 코드를 추가 하는것이 좋다
 이것을 가장 간단하게 할 수 있는것이 Assert이다

34. 예외는 예외적인 문제에 사용하라

 에러와 예외는 엄연한 차이가 있다.
 예외는 엄연히 예외적인 일만 처리를 해야 할 것이며, 수습이 불가능한 것은 에러처리를 해야 할 것이다

35. 시작한 것은 끝내라

 리소스를 할당하는 루틴이나 객체가 리소스를 해제하는 책임 역시 져야 한다는 의미이다
 해당 루틴에서 모든 리소스나 포인터를 책임지고 있다면, 해당 루틴에서 모든것을 끝낼 수 있다
 또한 , 예외 상황도 처리를 확실하게 해야 한다
 DRY 원칙이 깨지지 않도록 리소스 사용의 균형을 잡아야 한다 
 ( ex 동적할당을 하는 그 순간 예외처리를 여러개 해야하지만 객체로 처리하면 객체의 자동 파괴를 C++에 맡길수 있다
       그게 힘들다면 리소스 자체를 다른 클래스로감싸서 처리 하는 방식도 있다