의견 1

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

=> 눈에 뜨일 때마다 나쁜 설계, 잘못된 결정, 좋지 않은 코드를 고쳐라

 

2.   큰 그림을 기억하라.

    => 주변에 무슨 일이 일어나는지 점검하는 일을 잊어버릴 정도로 세부사항에 빠지지 말라.

 

3.    DRY( Don’t Repeat Yourself) – 반복하지 마라.

=> 어떤 지식 한 조각도 하나의 시스템 안에서는 모호하지 않고, 권위 있고, 단 하나뿐인 표현을 가져야 한

   다.

 

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

    => 재사용하기 쉽다면, 사람들이 재사용할 것이다. 재사용을 촉진하는 환경을 만들라.

 

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

    => 컴포넌트를 자족적이고, 독립적이며, 단 하나의 잘 정의된 목적만 갖도록 설계하라.

 

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

    => 예광탄은 이것저것을 시도해보고 그것들이 목표와 얼마나 가까운 데 떨어지는지 보는 방법으로 목표를 정

       확히 맞추게 해준다.

 

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

    => 프로토타이핑은 배움의 경험이다. 프로토타이핑의 가치는 만들어낸 코드에 있지 않고, 여러분이 배운 교

       훈에 있다.

 

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

    => 그래픽 사용자 인터페이스로는 할 수 없는 일에 셸을 이용하라.

 

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

    => 진짜 데이터와 경계 조건이 있는 실제 환경에서 여러분이 내렸던 가정들을 증명하라.

 

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

    => 코드가 실제로 하기로 한 것을 문서화하고 검증하기 위해 계약을 사용하라.

 

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

    => 보통은 죽은 프로그램이 절름발이 프로그램보다 해를 훨씬 덜 끼친다.

 

12.   단정문을 사용해서 불가능한 상황을 예방하라.

    => 단정은 여러분이 세운 가정을 검증해준다. 확실한 것이 없는 세상에서 여러분이 코드를 보호하려면 단정

       문을 사용하라.

 

13.   시작한 것은 끝내라.

    => 가능하다면, 리소스를 할당한 루틴이나 객체가 해제도 책임져야 한다.

 

14.   모듈간의 결합도를 최소화하라.

    => 디미터 법칙을 적용하고 부끄럼 타는 코드를 작성해서 결합이 생기는 일을 피하라. 코드에는 추상화를,

       메타데이터에는 세부 내용을 프로그램은 최대한 일반화해서 만들고, 세부사항들은 가능하면 컴파일된 코

       드 기반 바깥으로 빼라.

 

16.   서비스를 사용해서 설계하라.

    => 서비스, 곧 잘 정의되고 일관성 있는 인터페이스를 통해 의사소통하는 독립적이고 동시성 있는 객체들의

       관점에서 설계하라.

 

17.   모델에서 뷰를 분리하라.

    => 애플리케이션을 모델과 뷰의 관점으로 설계해서 적은 비용만 들이고도 유연함을 얻어내라.

 

18.   우연에 맡기는 프로그래밍을 하지 마라.

    => 정말 믿을 만한 것만 믿어야 한다. 우발적인 복잡함을 조심하고, 우연한 행운을 목적의식을 가지고 만든

       계획과 착각하지 말라.

 

19.   일찍 리팩터링하고, 자주 리팩터링 하라.

    => 정원의 잡초를 뽑고 식물 배치를 조정하는 것과 똑같이, 코드도 필요할 때면 언제라도 다시 작성하고 다

       시 작업하고 다시 아키텍처를 만들라. 문제의 근원을 해결하라.

 

20.   소프트웨어를 테스트하라. 그렇지 않으면 사용자가 테스트하게 될 것이다.

    => 가차 없이 테스트하라. 사용자가 여러분을 위해 버그를 찾게 만들지 말라.

 

21.   요구사항을 수집하지 말고 채굴하라.

    => 요구사항이 지면에 놓여져 있는 경우는 퍽 드물다. 보통은 가정과 오해, 정치의 지층들 속 깊이 묻혀 있

       다.

 

22.   사용자처럼 생각하기 위해 사용자와 함께 일하라.

    => 시스템이 정말로 어떻게 사용될지 통찰력을 얻을 수 있는 가장 좋은 방법이다.

 

23.   구체적인 것보다 추상적이 것이 더 오래간다.

    => 구현 말고 추상에 투자하라. 추상은 서로 다른 구현이나 새로운 기술의 출현 때문에 빗발치듯 생기는 변

       화를 견뎌내고 살아남을 수 있다.

 

24.   일찍 테스트하고, 자주 테스트하라. 자동으로 테스트 하라.

    => 매번 빌드할 때마다 실행되는 테스트가 책꽂이의 테스트 계획보다 훨씬 효과적이다.

 

25.   모든 테스트가 통과하기 전엔 코딩이 다 된 게 아니다.

    => 뭐 더 할 말 있나?

 

26.   파괴자를 써서 테스트를 테스트하라.

    => 코드의 별도 복사본을 만들고, 그 복사본에 고의로 버그를 넣은 다음 테스트가 잡아내는 지 검증하라.

 

27.   한국어도 하나의 프로그래밍 언어인 것처럼 다루라.

    => 코드를 작성하는 것처럼 문서도 작성하라. DRY 원칙을 존중하고, 메타데이터를 사용하고, MVC 모델을 쓰

       고, 자동 생성을 이용하고 등등.

 

28.   문서가 애초부터 전체의 일부가 되게 하고, 나중에 집어 넣으려고 하지 말라.

    => 코드와 떨어져서 만든 문서가 정확하거나 최신 정보를 반영하기는 더 힘들다.

 

29.   사용자의 기대를 부드럽게 넘어서라.

    => 사용자들이 무엇을 기대하는 이해한 다음, 그것보다 약간 더 좋은 것을 제공하라.

 

30.   자신의 작품에 서명하라.

    => 옛날 장인들은 자신의 작업 결과물에 서명하는 일을 자랑스럽게 여겼다. 여러분도 마찬가지여야 한다.

[출처] 실용주의 프로그래밍 팁 - I ( Pragmatic Programming Tips )|작성자 Hermet