[리뷰] 실용주의 프로그래머

읽은거 | 2011. 11. 9. 20:37

우리는 우연에 맡기는 프로그래밍, 곧 행운과 어쩌다 오는 성공에 의존하는 프로그래밍을 하지 말아야한다.

대신 의도적으로 프로그래밍(Programming deliverately)해야한다.

코드를 조금 작성해서 테스트해보고 잘되기 때문에 다시 코드를 작성하고 테스트 하다가 에러가 발생하고 작동하지 않게되면

코드를 살펴보고 수많은 시간을 쏟아도 고칠 가능성은 희박하다. 어떤 시도를 해봐도, 코드는 제대로 돌아가지 않는다.

이유는 코드가 처음부터 왜 잘 돌아가는지도 몰랐기 때문이다. 한정된 테스트를 했을때 코드가 잘 돌아가는 것처럼 보였지만,

그것은 단지 그때 운이 좋았을 뿐이다. 근거가 없는 확신을 가지고 계속 진행했기때문에 실패를 맛본것이다.

자신을 위해 만들어진 코드를 정말로 이해하지 못하는 한, 자기 자신을 속이는 것이다. 우연에 맡기는 프로그래밍을 하고 있다.

마법사는 평범한 개발자의 애플리케이션에 통합되어 뗄레야 뗄 수 없는 부분이 되는 코드를 생성한다.

마법사 코드는 깔끔한 인터페이스 뒤로 옮겨놓을 수 없다. 마법사가 생성한 코드는 평범한 개발자가

작성하는 기능과 줄 단위로 섞인다. 결과적으로 그 코드는 마법사의 코드이기를 관두고 평범한 개발자 자신의 코드가 되기 시작한다.

그리고 누구도 자신이 완전히 이해하지 못하는 코드를 내놓아서는 안 된다.

풀리지 않는 문제와 마주쳤다면, 생각해 볼 수 있는 모든 가능한 해결 경로를 눈앞에 나열해보라.
아무리 쓸모없고 바보같이 보이는 경로라도 절대 버리지 말라. 이제 목록을 하나씩 점검하면서 왜 그 경로를 따라갈 수 없는지 설명해 보라.
정말 확신하는가? 증멸할 수 있는가?
제약들을 범주별로 나누고 우선순위를 매겨라. 목공은 어떤 일을 시작할 때 그일에서 필요한 가장 긴 조각을 먼저 자르고, 남은 나무에서
작은 조각들을 잘라낸다. 비슷한 방식으로, 우리도 제일 구속이 심한 제약들로부터 파악해 내고 나머지 제약들을 그 안에서 맞춰보아야 한다.
불가능한 문제 대문에 일정이 늦어질 수 있다.
- 더 쉬운 방법이 존재하는가?
- 왜 이것이 문제인가?
- 진짜 문제를 풀려고 노력하고 있나. 그렇지 않다면 중요하지 않은 기술적 문제에 정신이 팔려 있는것인가?
- 문제를 이렇게 풀기 어렵게 만드는 것이 무엇인가?
- 반드시 이 방법으로 해야 하는가?
- 반드시 해야 하는 일이긴 한가?

팀이 하나로서 의사소통하게 도와주는 간단한 마케팅 비결이 있다. 프로젝트를 시작할 때 이름을 지어주는 것이다. 유별난 이름이라면 더 좋겠다.
30분정도 투자해서 멍텅구리 로고를 만들어 메모나 보고서 등에 사용하라.
사람들과 대화를 할때에 자신의 팀 이름을 거리낌 없이 사용하라.
바보같이 들리지만, 팀은 정체성 확립의 기반을 얻을 것이고, 세상은 여러분의 작업과 관련되어서 기억할 만한 뭔가를 얻게 될 것이다.

소스코드 주석에 나오지 말아야 할 것들의 목록

소스파일에 나타나야만 하는 가장 중요한 정보

서명하라.

여러분의 서명이 품질의 보증 수표로 인식되게 해야한다. 사람들이 코드에 붙여진 여러분의 이름을 보고
그것이 튼튼하고 잘 작성되고 제대로 테스트되었으며 또 훌륭히 문서화되었을 것이라고 기대하도록 만들자.
진정한 프로페셔널한 일. 진정한 프로페셔널이 작성한.

이 글은 스프링노트에서 작성되었습니다.

awesome programming