실용주의 프로그래머 TIP 4/4

실용주의 프로그래머 TIP 4/4

55. 생각의 틀을 벗어나지 말고, 틀을 찾아라.

해결이 불가능해 보이는 문제와 마주쳤을 때, 진짜 제약 조건을 찾아라. 스스로에게 이렇게 물어보라. ‘정말로 반드시 이런 방식으로 해야 하는 일인가? 꼭 해야만 하는 일이긴 한 건가?’

56. 준비가 되었을 때 시작하라.

여러분은 살아오면서 경험을 쌓아왔다. 자꾸 거슬리는 의혹을 무시하지 말라.

57. 어떤 일들은 설명하기보다 실제로 하는 것이 더 쉽다.

명세의 나선에 빠지지 말라. 언젠가는 코딩을 시작해야 한다.

58. 형식적 방법의 노예가 되지 마랄.

여러분의 개발 실천방법과 개발 능력의 맥락 안에 넣어보지 않고, 맹목적으로 어떤 기법을 채택하지 말라.

59. 비싼 도구가 더 좋은 설계를 낳지는 않는다.

벤더들의 과장, 어떤 분야의 도그마 그리고 가격표의 휘광에 넘어가지 말라. 도구 자체의 장점만 갖고 판단하라.

60. 팀을 기능 중심으로 조직하라.

설계자와 코더를, 테스트 담당자와 데이터 모델 담당자를 분리시키지 말라. 코드를 만드는 방식에 맞춰 팀을 만들어라.

61. 수작업 절차를 사용하지 말라.

쉘 스크립트나 배치 파일은 똑같은 명령을, 똑같은 순서로, 어느 때라도 반복해서 실행해준다.

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

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

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

뭐 더 할 말 있나?

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

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

65. 코드 커버리지보다 상태 커버리지를 테스트하라.

중요한 프로그램 상태들을 파악해서 테스트 하라. 단지 많은 코드 줄 수를 테스트 범위안에 넣는 것만으로는 충분하지 않다.

66. 버그는 한 번만 잡아라.

인간 테스터가 버그를 찾아내면, 그 때가 인간 테스터가 그 버그를 찾는 마지막 순간이 되어야 한다. 그 순간 이후부터는 자동화된 테스트가 그 버그를 담당하도록 만든다.

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

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

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

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

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

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

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

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