실용주의적 프로그래머 Summary

Open jbee37142 opened this issue 6 years ago • 0 comments

[책] 실용주의적 프로그래머

자신의 기술에 관심과 애정을 가져라
자신의 일에 대해 생각하면서 일하라

모든 개발 과정에서 매일 자신이 내리는 모든 결정을 지속적이고 비판적으로 평가해 보는 것

어설픈 변명을 만들지 말고 대안을 제시하라
깨진 창문을 내버려 두지 말라

‘깨진 창문’이란 나쁜 설계, 잘못된 결정, 혹은 형편없는 코드를 말한다. 이 깨진 창문을 고치지 않은 채로 내버려 두지 마라. 발견하자마자 바로 고쳐야 한다. 깨끗하고 잘 기능하는 다른 시스템들이 하나의 창문이 깨지기 시작하면서 급속도로 악화된다.

변화의 촉매가 되라. 큰 무리없이 요구할 수 있을 만한 것을 찾아내고 그것을 잘 개발하자. 그리고 그걸 사람들에게 보여주고 그들이 좋아하게 한다. 그리고 만약…를 추가하면 더 좋아지지 않을까여? 한다.
큰 그림을 기억하라 무엇을 하고 있느낙에만 정신을 쏟지 말고 주변에서 무슨 일이 벌어지는지 지속적으로 살펴보자.
품질을 요구사항으로 만든다. 시스템의 범위와 품질은 해당 시스템 요구사항의 일부로 명기되어야 한다
지식 포트폴리오에 주기적으로 투자하라 주기적으로, 다각화하여 투자한다. 보수적인 투자, 위험성이 큰 투자, 보상이 높은 투자에서 균형을 맞춘다. 포트폴리오는 주기적으로 재검토하고 재조정해야 한다.

매년 새로운 언어를 최소 하나는 배워라
기술 서적을 분기마다 한 권씩 읽어라
비 기술 서적도 읽어라
수업을 들어라
지역 사용자 모임에 참여하라
다른 환경에서도 실험해보라
트렌드를 놓치지 마라
인터넷을 이용하라

자신이 배훈 교훈들을 현재 프로젝트에 적용하도록 노력하라

읽고 듣는 것을 비판적으로 분석하라
무엇을 말하는가와 어떻게 말하는가 모두 중요하다
반복하지 말 것 (Don’t Repeat Yourself) 프로그래머는 늘 유지보수 모드에 있다.
재사용하기 쉽게 만들라.
관련 없는 것들 간에 서로 영향이 없도록 하라
최종 결정이란 없다.
목표물을 찾기 위해 예광탄을 쏴라
프로토타입을 통해 학습하라
문제 도메인에 가깝게 생각하라
추정을 통해 놀람을 피하라

추정의 단위

1-15일 : 일
3-8주: 주
8-30주: 달
30주 이상: 추정치를 말하기 전에 다시 한번 생각하자

코드와 함께 일정도 반복하며 조정하라
지식을 일반 텍스트로 저장하라
명령어 셸의 힘을 사용하라
하나의 에디터를 잘 사용하라
언제나 소스코드 관리 시스템을 사용하라
비난 대신 문제를 해결하라

디버깅 사고 방식 - 가장 속이기 쉬운 사람은 자기 자신이다.

디버깅할 때 당황하지 마라.
select는 망가지지 않았다.

React는 잘 동작한다.

가정하지 말고 증명하라.
텍스트 처리 언어를 하나 익혀라
코드를 작성하는 코드를 작성하라
완벽한 소프트웨어는 만들 수 없다.
계약에 의한 설계를 하라.

자신이 하는 일이라고 주장하는 것보다 많거나 적지도 않게 딱 그만큼만 하는 프로그램 선행조건 - 제대로 된 데이터를 전달하는 것은 호출하는 쪽의 책임이다. 후행조건 - 종국에는 종료될 것을 암시한다.

일찍 작동을 멈추게 하라
단정문을 사용해서 불가능한 상황을 예방하라 디버깅행위가 디버깅되는 시스템의 행동을 바꿔버리는 하이젠버그적인 문제(하이젠베르크에서 유래)
예외는 예외적인 문제에 사용하라
시작한 것은 끝내라
모듈간의 결합도를 최소화하라

가능한 느슨하고 유연한 코드를 작성하기 위해 노력해야 한다. 가능한 적은 양의 코드를 작성하는 것이다. Shy code: 자신을 남에게 속속들이 드러내지 말고 너무 많은 사람과 상호작용하지 말라 디미터 법칙) 한 객체가 제공하는 메소드에 접근하기 위해 또 다른 객체들을 통하는 것을 허용하지 않는다.

통합하지 말고 설정하라

세부 사항을 코드에서 몰아내라
Configurable(설정 가능하게)하면 변화에 쉽게 적응할 수 있게 된다.
메타데이터란 데이터에 관한 데이터
- 좀 더 넓은 의미로는 애플리케이션을 기술하는 모든 데이터

코드에는 추상화를 메타데이터에는 세부 내용을

가능한 많은 메타 데이터를 사용하여 애플리케이션을 설정하고 실행시켜라 설정 메타데이터는 일반 텍스트로 표현하길 권장한다.

똑은 딱보다 먼저 일어나야 한다.

작업흐름 분석을 통해 동시성을 개선하라
서비스를 사용해서 설계하라
언제나 동시성을 고려해 설계하라
모델에서 뷰를 분리하라
칠판을 사용해 작업흐름을 조율하라
우연에 맡기는 프로그래밍을 하지 말라

정말로 제대로 돌아가는 것이 아닐지도 모른다

알고리즘의 차수를 추정하라
추정을 테스트하라.

성급한 최적화를 조심하라(premature optimization)

어떤 것이든 ‘잘못’되었다고 생각될 때, 그것을 변경하는 일을 주저하면 안 된다. 언제나 바로 지금이 최적기다. 고통관리(pain management) 리팩터링이 필요한 코드는 종양이다.

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

리팩터링의 본질은 재설계다.
리팩터링해야 할 것들의 면단을 만들고 유지하라.
코드를 사용하는 사람들이 코드가 조만간 리팩터링될 것이라는 사실과 그 사실이 그들의 코드에 어떤 영향을 주게 될지 인지하도록 만들어야 한다.
리팩토링과 새로운 기능 추가를 동시에 하지 말라
든든한 테스트 집합이 있는지 먼저 확인하고 자주 테스트를 돌려본다
단계를 나누어 신중하게 작업한다.
단위테스트란 어떤 모듈에게 이것 저것을 시켜보는 코드를 말한다.
인위적인 환경을 구축한 다음, 모듈의 루틴들을 호출한다.
반환된 결과들을 이미 알고 있는 값과 비교해보거나 똑같은 테스트를 이전에 돌렸을 때 나온 값과 같은지 비교한다. (회귀 테스트)

테스트를 염두에 두고 설계하라
자신이 이해하지 못하는, 마법사가 만들어준 코드는 사용하지 말라.

마법사가 생성한 코드는 평범한 개발자가 작성하는 기능과 줄 단위 로 섞인다. 마법사의 코드이기를 관두고 평범한 개발자 자신의 코드가 되기 시작한다. 그 누구도 자신이 완전히 이해하지 못하는 코드를 내놓아서는 안 된다.

요구사항을 수집하지 말고 채굴하라.
사용자처럼 생각하기 위해 사용자와 함께 일하라.
구체적인 것보다 추상적인 것이 오래 간다.
프로젝트 용어사전을 사용하라.
생각의 틀을 벗어나지 말고 틀을 찾아라.

더 쉬운 방법이 존재하는가?
진짜 문제를 풀려고 노력하고 있나. 기술적인 문제에 정신이 팔려 있는 것은 아닌가?
왜 이것이 문제인가
문제를 이렇게 풀기 어렵게 만드는 것이 무엇인가
반드시 이 방법으로 해야 하는가
반드시 해야 하는 일이긴 한가?

준비가 되었을 때 시작하라.
어떤 일들은 설명하기보다 실제로 하는 것이 더 쉽다.
형식적인 방법의 노예가 되지 말라.
비싼 도구가 더 좋은 설계를 낳지는 않는다.
팀을 기능 중심으로 조직하라
수작업 절차를 사용하지 말라
일찍 테스트하고 자주 테스트하고 자동으로 테스트하라
모든 테스트가 통과하기 전엔 코딩이 다 된게 아니다.
파괴자를 써서 테스트를 테스트하라

버그가 의도적으로 생기도록 한 다음 테스트가 불평을 해대는지 확인하라

코드 커버리지보다 상태 커버리지를 테스트하라
버그는 한 번만 잡아라

아무리 흐린 먹물이라도 가장 훌륭한 기억력보다 낫다. 문서화를 전체 개발 프로세스의 필요불가결한 부분으로 포용한다.

한국어도 하나의 프로그래밍 언어인 것처럼 다루라.
문서가 애초부터 전체의 일부가 되게 하고 나중에 집어넣으려 하지 말라

너무 많은 것은 너무 적은 것만큼이나 좋지 않다.
의미없는 이름보다 더 고약한 것은 오해를 불러일으키는 이름

사용자의 기대에 부드럽게 넘어서라
자신의 작품에 서명하라

개발자는 넓은 범위에 걸친 여러 전문 분야의 기술들을 사용해서 소프트웨어를 개발하는 사람. 단순한 프로그래머 이상이면서, 기술을 갖추되 컴퓨터 과학자보다 초점은 더 넓고 팀 기반 환경에서 개발하기 위해 필요한 팀 및 사회적 기술을 갖춘 사람.

Mar 11 '19 12:03 jbee37142