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

* 실용주의 프로그래머 Tip

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

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

: 언제나 생각하고, 언제나 일하면서 동시에 자신의 일을 비평하고 분석하라

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

: 실용주의 철학의 초석 중 하나는 경력 향상, 프로젝트, 일상 업무의 면에서 자신과 자신의 행동에 대해 책임을 지는 것이다

: 실용주의 프로그래머는 경력에 대해 책임을 지고, 자신의 무지나 실수를 인정하기를 두려워하지 않는다

: 실수를 저지르거나 잘못된 판단을 내렸다면, 정직하게 인정하고 다른 방안을 제안하도록 노력하라

: 안 된다고 하지 말고 상황을 개선하기 위해 무엇을 할 수 있는지 설명하라

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

: '깨진 창문' (나쁜 설계, 잘못된 결정, 혹은 형편없는 코드) 을 고치지 않은 채로 내버려 두지 말라. 발견하자마자 바로 고쳐라

: 불쾌한 코드를 주석처리 하거나, "Not Implemented" 라는 메시지를 표시하거나 Dummy 데이터로 대치해 놓거나 하라

: 깨끗하고 잘 기능하는 시스템들이 일단 창문이 개지기시작하면급속도로 악화되는 것을 많이 보아 왔다

5. 변화의 촉매가 되라

: 큰 무리 없이 요구할 수 있을 만한 것을 찾아내라. 그리고 그걸 잘 개발해라. 일단 되면, 사람들에게보여 주고, 그들이 경탄하게 하라.

6. 큰 그림을 기억하라

: 개인적으로 무엇을 하고 있는가에만 정신을 쏟지 말고, 주변에서 무슨 일이 벌어지는지 지속적으로 살펴보라

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

: 어느 정도면 괜찮은지를 결정하는 과정에 사용자가 참가할 기회를 가져야 한다

: 단순히 프로그램에 새 기능을 추가하거나 코드를 한 번 더 다듬는다던가 하기 위해서 사용자의 요구사항을 무시하는 것은 전문가답지
    못한 것이다.

: 불가능한 시간 약속을 하거나 데드라인에 맞추기 위해 기본적인걸 빼버리거나 하는 것 역시 똑같이 전문가답지 못하다

: 완벽하게 훌륭한 프로그램을 과도하게 장식하거나 지나칠 정도로 다듬느라 망치지 말라.

그냥 넘어가고 코드가 현재 상태에서 한동안은 그대로 있도록 놓아두라. 완벽하지 않을 수도 있다. 걱정하지 마라. 완벽해지기란 불가능하다

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

: 매년 새로운 언어를 최소 하나는 배워라

- 다른 언어는 동일한 문제를 다르게 푼다. 몇 개의 서로 다른 접근법을 알면 사고를 확장하고 판에 박힌 사고에 갇히는 걸 예방하는 데에
    도움이 된다

: 기술 서적을 분기마다 한 권씩 읽어라

- 습관이 들면, 한 달에 한 권씩 읽어라. 현재 사용하는 기술을 완전히 익혔다면, 가지치기를 해서 지금 하는 프로젝트와 관련 없는 분야까지
    공부 범위를 넓혀라

: 비 기술 서적도 읽어라

- 컴퓨터를 사용하는 것은 사람. 우리는 바로 이 사람들을 만족시키려고 노력하고 있다

: 수업을 들어라

: 지역 사용자 모임에 참여하라

: 다른 환경에서 실험해보라

- 윈도우에서만 일을 해 왔다면, 집에서는 유닉스를 갖고 놀아보라. 만약 makefile과 에디터만 사용하고 있다면 IDE를 시도해보라

: 요즘 흐름을 놓치지 마라

: 인터넷을 이용하라

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

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

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

: 최고의 아이디어, 최상의 코드 혹은 가장 실용주의적인 사고 등이 있다고 해도 다른 사람들과 소통할 수 없다면 그것들은 궁극적으로 아무
    효용이 없다

: 말하고 싶은게 무엇지 알아라

: 청중을 알아라 (WISDOM)

- 무엇(What)을 배우길 원하는가?

-  말하려는 것에서 그들이 관심(Interest) 있어 하는 건 무엇인가?

-  얼마나 소양(Sophisticated)이 있는가?

- 어느 정도의 구체적인(Detail) 내용을 원하는가?

- 누가 정보를 소유(Owe)하길 원하는가?

- 그들이 경청하도록 동기(Motive)를 주려면 어떻게 해야 할까?

: 때를 골라라

- 타이밍을 잘 선택 해야한다

: 스타일을 골라라

- 간단하거나 사실만을 전달하거나 스타일에 맞게 골라야 한다

: 멋져 보이게 하라

: 청중을 참여시켜라

: 청자가 되어라

: 응답하라

11. DRY - Don't Repeat Yourself (반복하지 마라)

: 모든 지식은 시스템 내에서 단일하고, 애매하지 않고, 정말로 믿을만한 표현 양식을 가져야 한다

: 강요된 중복

- 개발자들은 다른 선택이 없다고 느낀다. 환경이 중복을 요구하는 것처럼 보인다

: 부주의한 중복

- 개발자들은 자신들이 정보를 중복하고 있다는 것을 깨닫지 못한다

: 참을성 없는 중복

- 중복이 쉬워 보이기 때문에 개발자들이 게을러져서 중복을 하게 된다

: 개발자간의 중복

- 한 팀에 있는(혹은 다른 팀에 있는) 여러 사람들이 동일한 정보를 중복한다

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

: 재사용에 실패한다면 지식 중복의 위험을 각오 해야한다

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

: 컴포넌트들이 각기 격리되어 있으면 어느 하나를 바꿀때 나머지 것들을 걱정하지 않아도 된다

: 직교적인 시스템을 작성하면 두 가지의 큰 장점이 있다

- 생산성 향상

: 변화가 줄어 개발 시간과 테스트 시간이 줄어든다

: 상대적으로 작고, 자족적인 컴포넌를 작성하는 거이 하나의 커다란 코드 덩어리를 만드는 것보다 더 쉽다

: 새로운 코드를 추가할 때마다 기존의 코드를 계속 바꾸어야할 필요가 없다

: 재사용을 촉진한다

: 컴포넌트들에 명확하고 잘 정의된 책임이 할당되어 있다면 애초의 구현자들이 미처 생각하지 못했던 방식으로 새로운 컴포넌트와
    결합할 수 있다

- 리스크 감소

: 감연된 코드는 격리된다

: 시스템이 잘 깨지지 않는다

: 더 많은 테스트를 하게 된다

: 특정 벤더나 제품, 플랫폼에 덜 종속될 것이다

: 프로젝트 팀

- 팀 내 업무가 겹치는 영역이 많다면 뭘 하나 바꾸려고 해도 그들 중 누구라도 영향을 받을 수 있기 때문에 전체 팀원이 모여야 한다

- 주된 인프라 컴포넌트마다 서브팀을 할당한다

: 설계

- 각 모듈은 다른 부분과 독립적인 기능을 구현해야 한다

: 코딩

- 코드의 결합도를 줄여라 

: Shy code 를 작성하라

- 전역 데이터를 피하라

: Singleton 은 불필요한 링크를 유도한다 (Use Your Singletons Wisely)

- 유사한함수를 피하라

14. 최종 결정이란 없다

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

: 사용자들은 뭔가 작동되는 것을 일찍부터 보게 된다

: 개발자들은 들어가서 일할 수 있는 구조를 얻는다

: 통합 작업을 수행할 기반이 생긴다

: 보여줄 것이 생긴다

: 진전 상황에 대해 더 정확하게 감을 잡을 수 있다

: 예광탄은 지금 맞추고 있는 것이 무엇인지 보여준다. 그러나 그것이 꼭 목표물이라는 보장이 없다. 그럴 경우 목표물이 맞을 때까지 조준을
    옮겨야 한다. 이것이 핵심이다

- 코드의 크기가 작으면 관성 역시 약하므로 빠르고 쉽게 바꿀 수 있다