이책을 언제쯤 제대로 볼수있을까...

이렇게 정리된 내용만 대충 훅 훝어 보는구나 

1장. 클린 코드

궁극적으로 코드는 요구사항을 표현하는 언어라는 사실을 명심한다.

우리 모두는 자신이 짠 쓰레기 코드를 쳐다보며 나중에 손보겠다고 생각한 경험이 있다. 다시 돌아와서 나중에 정리하겠다고 다짐했었다. 물론 그 때 그 시절 우리는 르블랑의 법칙을 몰랐다. “나중은 결코 오지 않는다”

시간을 들여서 클린 코드를 만들려는 노력이 비용을 절감하는 방법일 뿐 아니라 전문가로서 살아남는 길이라는 사실을 인정하리라.

일정에 쫓기더라도 대다수 관리자는 좋은 코드를 원한다. 그들이 일정과 요구사항을 강력하게 밀어붙이는 이유는 그것이 그들의 책임이기 때문이다. 좋은 코드를 사수하는 일은 바로 우리 프로그래머들의 책임이다.

기한을 맞추는 유일한 방법은, 그러니까 빨리 가는 유일한 방법은, 언제나 코드를 최대한 깨끗하게 유지하는 습관이다.

그림을 보면 좋은 그림인지 나쁜 그림인지 구분이 간다. 그렇지만 좋은 그림을 구분할 줄 안다고 좋은 화가라는 뜻은 아니다. 다시 말해, 클린 코드와 나쁜 코드를 구분할 줄 안다고 클린 코드를 작성할 줄 안다는 뜻은 아니다.

클린 코드는 ‘보기에 즐거운’ 코드다.

나쁜 코드는 너무 많이 하려고 애쓰다가 의도가 뒤섞이고 목적이 흐려진다. 클린 코드는 한가지에 ‘집중’한다.

테스트 케이스가 없는 코드는 클린 코드가 아니다. 아무리 코드가 우아해도, 아무리 가독성이 높아도, 테스트 케이스가 없으면 깨끗하지 못하다.

클린 코드는 주의깊게 작성한 코드다. 누군가 시간을 들여 깔끔하고 단정하게 정리한 코드다.

코드가 그 문제를 풀기 위한 언어처럼 보인다면 아름다운 코드라 말한다.

이 논리에서 빠져나갈 방법은 없다. 주변 코드를 읽지 않으면 새 코드를 짜지 못한다. 주변 코드를 읽기 쉬우면 새 코드를 짜기도 쉽다. 주변 코드를 읽기 어려우면 새 코드를 짜기도 어렵다. 그러므로 급하다면, 서둘러 끝내려면, 쉽게 짜려면, 읽기 쉽게 만들면 된다.

시간이 지날수록 코드가 좋아지는 프로젝트에서 작업한다고 상상해보라. 전문가라면 너무도 당연하지 않은가?

이 책을 읽는다고 우수한 프로그래머가 된다는 보장은 없다. 단지 우수한 프로그래머가 생각하는 방식과 그들이 사용하는 기술과 기교와 도구를 소개할 뿐이다.

2장. 의미있는 이름

좋은 이름을 지으려면 시간이 걸리지만 좋은 이름으로 절약하는 시간이 훨씬 더 많다.

따로 주석이 필요하다면 의도를 분명히 드러내지 못했다는 소리다.

발음하기 쉬운 이름은 중요하다. 프로그래밍은 사회적 활동이기 때문이다.

똑똑한 프로그래머와 전문가 프로그래머 사이에서 다른 점 하나를 들자면, 전문가 프로그래머는 명료함이 최고라는 사실을 이해한다.

프로그래머는 코드를 최대한 이해하기 쉽도록 짜야한다. 집중적인 탐구가 필요한 코드가 아니라 대충 훑어봐도 이해할 코드가 목표다. 의미를 해독할 책임이 독자에게 있는 논문 모델이 아니라 의도를 밝힐 책임이 저자에게 있는 잡지 모델이 바람직하다.

3장. 함수

함수를 만드는 첫 번째 규칙은 ‘작게!’다. 함수를 만드는 두 번때 규칙은 ‘더 작게!’다.

각 함수가 너무도 명백했다. 각 함수가 이야기 하나를 표현했다. 각 함수가 너무도 멋지게 다음 무대를 준비했다. 바로 이것이 답이다.

함수는 한 가지를 해야 한다. 그 한 가지를 잘 해야 한다. 그 한 가지만 해야 한다.

단순히 다른 표현이 아니라 의미 있는 이름으로 다른 함수를 추출할 수 있다면 그 함수는 여러 가지 작업을 하는 셈이다.

근본 개념과 세부 사항을 뒤섞기 시작하면, 깨어진 창문처럼, 사람들이 함수에 세부 사항을 점점 더 많이 추가한다.

함수로 부울값을 넘기는 관례는 정말로 끔직하다. 왜냐고? 함수가 한꺼번에 여러 가지를 처리한다고 대놓고 공표하는 셈이니까!

함수는 뭔가를 수행하거나 뭔가에 답하거나 둘 중 하나만 해야 한다. 둘 다 하면 안된다.

어쩌면 중복은 소프트웨어에서 모든 악의 근원이다.

소프트웨어를 짜는 행위는 여느 글짓기와 비슷하다. 논문이나 기사를 쓸 때는 먼저 생각을 기록한 후 읽기 좋게 다듬는다. 초안은 대개 서투르고 어수선하므로 원하는 대로 읽힐 때까지 말을 다듬고 문장을 고치고 문단을 정리한다. 처음부터 탁 짜내지 않는다. 그게 가능한 사람은 없으리라.

4장. 주석

우리는 코드로 의도를 표현하지 못해, 그러니까 실패를 만회하기 위해 주석을 사용한다.

부정확한 주석은 아예 없는 주석보다 훨씬 더 나쁘다.

진실은 한 곳에만 존재한다. 바로 코드다. 코드만이 자기가 하는 일을 진실하게 말한다. 코드만이 정확한 정보를 제공하는 유일한 출처다. 그러므로 우리는 (간혹 필요할지라도) 주석을 가능한 줄이도록 꾸준히 노력해야 한다.

주석으로 처리된 코드는 다른 사람들이 지우기를 주저한다. 이유가 있어 남겨놓았으리라고 중요하니까 지우면 안 된다고 생각한다. 그래서 질 나쁜 와인병 바닥에 앙금이 쌓이듯 쓸모없는 코드가 점차 쌓여간다.

6장. 객체와 자료 구조

변수를 private으로 선언하더라도 각 값마다 get과 set 함수를 제공한다면 구현을 외부로 노출하는 셈이다.

객체가 포함하는 자료를 표현할 가장 좋은 방법을 심각하게 고민해야 한다. 아무 생각 없이 조회/설정 함수를 추가하는 방법이 가장 나쁘다.

객체 지향 코드에서 어려운 변경은 절차적 코드에서 쉬우며, 절차적 코드에서 어려운 변경은 객체 지향 코드에서 쉽다!

8장. 경계

외부 코드를 익히기는 어렵다. 외부 코드를 통합하기도 어렵다. 두 가지를 동시에 하기는 두 배나 어렵다. 다르게 접근하면 어떨까? 곧바로 우리 쪽 코드를 작성해 외부 코드를 호출하는 대신 먼저 간단한 테스트 케이스를 작성해 외부 코드를 익히면 어떨까? 이를 학습 테스트라 부른다.

학습 테스트는 이해를 높여주는 정확한 실험이다. 공짜 이상이다. 투자하는 노력보다 얻어지는 성과가 더 크다.

외부 패키지를 호출하는 코드를 가능한 줄여 경계를 관리하자.

9장. 단위 테스트

애자일과 TDD 덕택에 단위 테스트를 자동화하는 프로그래머들이 이미 많아졌으며 점점 더 늘어나는 추세다. 하지만 우리 분야에 테스트를 추가하려고 급하게 서두르는 와중에 많은 프로그래머들이 제대로 된 테스트 케이스를 작성해야 한다는 좀더 미묘하고 더 중요한 사실을 놓쳐버렸다.

코드에 유연성, 유지 보수성, 재사용성을 제공하는 버팀목이 바로 단위 테스트다. 이유는 단순하다. 테스트 케이스가 있으면 변경이 두렵지 않으니까! 테스트 케이스가 없다면 모든 변경이 잠정적인 버그다. 아키텍처가 아무리 유연하더라도, 설계를 아무리 잘 나누었더라도, 테스트 케이스가 없으면 개발자는 변경을 주저한다. 버그가 숨어들까 두렵기 때문이다.

클린 테스트 코드를 만들려면? 세가지가 필요하다. 가독성, 가독성, 가독성.

테스트 함수마다 assert 하나만 사용하기 보다는 개념 하나만 테스트하라.

클린 테스트 5가지 규칙(FIRST). 빠르게, 독립적으로, 반복 가능하게, 자가 검증하는, 적시에.

Fast, Independent, Repeatable, Self-validation, Timely.

테스트 코드가 방치되어 망가지면 실제 코드도 망가진다. 테스트 코드를 깨끗하게 유지하자.

10장. 클래스

클래스를 만들 때 첫 번째 규칙은 크기다. 클래스는 작아야 한다. 두 번째 규칙도 크기다. 더 작아야 한다.

함수는 물리적인 행 수로 크기를 측정했었다. 클래스는 다른 척도를 사용한다. 클래스가 맡은 책임을 센다.

간결한 이름이 떠오르지 않는다면 분명 클래스 크기가 너무 커서 그렇다.

도구 상자를 어떻게 관리하고 싶은가? 작은 서랍을 많이 두고서 기능과 이름이 명확한 컴포넌트를 나눠 넣고 싶은가? 아니면 큰 서랍 몇 개를 두고서 모두를 던져 넣고 싶은가?

큰 클래스 몇 개가 아니라 작은 클래스 여럿으로 이뤄진 시스템이 더 바람직하다. 작은 클래스는 각각 책임이 하나이며, 변경할 이유가 하나이며, 다른 작은 클래스와 협력해 시스템에 필요한 동작을 수행한다.

“함수를 작게, 매개변수 목록을 짧게”라는 전략을 따르다 보면 때때로 몇몇 메소드만이 사용하는 인스턴스 변수가 아주 많아진다. 이때가 십중팔구 새로운 클래스로 쪼개야 한다는 신호다.

11장. 시스템

‘처음부터 올바르게’ 시스템을 만들 수 있다는 믿음은 미신이다. 대신에 우리는 오늘 주어진 사용자 스토리에 맞춰 시스템을 구현해야 한다. 내일은 새로운 스토리에 맞춰 시스템을 조정하고 확장하면 된다. 이것이 반복적이고 점진적인 애자일 방식의 핵심이다.

12장. 창발성

켄트 백이 제시한 간단한 설계 규칙 4가지.

모든 테스트를 실행한다. 중복은 없앤다. 프로그래머 의도를 표현한다. 클래스와 메소드 수를 최소로 줄인다.

코드를 정리하면서 시스템이 깨질까 걱정할 필요가 없다. 테스트 케이스가 있으니까!

작은 재사용을 제대로 익혀야 큰 재사용이 가능하다.

자신의 작품을 조금 더 자랑하자. 함수와 클래스에 조금 더 시간을 투자하자. 더 나은 이름을 선택하고, 큰 함수를 작은 함수 여럿으로 나누고, 자신의 작품에 조금만 더 주의를 기울이자. 주의는 대단한 재능이다.

경험을 대신할 단순한 개발 기법이 있을까? 당연히 없다.

13장. 동시성

동시성은 결합을 없애는 전략이다. 즉, 무엇과 언제를 분리하는 전략이다.

독립적인 스레드로, 가능하면 다른 프로세서로 돌려도 괘찮도록 자료를 독립적인 단위로 분할하라.

각 알고리즘을 공부하고 해법을 직접 구현해보라. 그러면 나중에 실전 문제에 부닥쳤을 때 해결이 쉬워지리라.

임계영역 개수를 줄인답시고 거대한 임계영역 하나로 구현하는 순진한 프로그래머도 있다.

‘일회성’ 문제를 계속 무시한다면 잘못된 코드 위에 코드가 계속 쌓인다.

14장. 점진적인 개선

여러분이 깨끗하고 우아한 프로그램을 한 방에 뚝딱 내놓으리라 기대하지 않는다. 지난 수십 여 년 동안 쌓아온 경험에서 얻은 교훈이라면, 프로그래밍은 과학보다 공계에 가깝다는 사실이다. 클린 코드를 짜려면 먼저 지저분한 코드를 짠 뒤에 정리해야 한다는 의미다.

프로그램을 망치는 가장 좋은 방법 중 하나가 개선이라는 이름 아래 구조를 크게 뒤집는 행위다.

TDD는 시스템을 망가뜨리는 변경을 허용하지 않는다. 변경을 가한 후에도 시스템이 변경 전과 똑같이 돌아가야 한다는 소리다.

리팩토링은 루빅 큐브 맞추기와 비슷하다. 큰 목표 하나를 이루기 위해 자잘한 단계를 수없이 거친다. 각 단계를 거쳐야 다음 단계가 가능하다.

단순히 돌아가는 코드에 만족하는 프로그래머는 전문가 정신이 부족하다. 나쁜 코드보다 더 오랫동안 더 심각하게 개발 프로젝트에 악영향을 미치는 요인도 없다. 나쁜 일정은 다시 짜면 된다. 나쁜 요구사항은 다시 정의하면 된다. 나쁜 팀 역학은 복구하면 된다. 하지만 나쁜 코드는 썩어 문드러진다.

참 다양한 이야기들을 들려준다. 이야기가 97개나 있으니 좋은 이야기도 있고 공감이 잘 안되는 이야기도 있다. 그런데 신기하게도 97 가지의 이야기를 찬찬히 듣다보면 그들이 하는 얘기중에 무언가 공통된 점을 발견하게 된다.

바로 개발자가 가져야하는 마음가짐이다.

지속적인 학습

완벽한 코드를 작성하겠다는 장인정신

모두를 위한 배려

훌륭한 프로그래머가 되겠다는 마음

집필에 참여한 많은 사람들이 이렇게 쓰자고 미리 정한 것도 아닐텐데 말이다. 결국 Expert로서 후배들에게 이야기해주고 싶은 내용을 꼽으라면 비슷한 내용이 나온다는 얘기다. 이것이 이 책에서 내가 생각하는 가장 중요한 포인트다.

“소프트웨어 회사에서의 다년간의 경험으로, 저는 적당한 프로그래머와 훌륭한 프로그래머 사이의 진짜 차이의 대한 결론을 내렸습니다. 바로 마음가짐입니다”

차이를 만드는 것은 마음가짐이다. 능력이 아니다.

초보 프로그래머라면 좋고 나쁘고를 판단하기 전에 먼저 이러한 마음가짐을 한번 가져보자. 한창 배우는 중인 견습 프로그래머라면 바쁜 일정과 여러가지 변명들로 마음 한구석에 쟁여놓았던 마음가짐을 다시 한번 꺼내보자. 전문가라면 이 마음가짐을 주변사람들에게 스물스물 전파해보자.

미약하나마 이 책을 통해 이러한 일들이 벌어진다면 참 좋겠다.

한줄 요약과 함께 마음에 드는 글은 추천(★)표시를 해두었으니 시간이 없으신 분들은 추천글만이라도 꼭 읽어보시길!

참고로 원문은 모두 공개 되어있다.

1. Act with Prudence by Seb Rose

- 기술적 부채를 가능한한 빨리 갚을것. 안그러면 이자가 엄청날 것임.

2. Apply Functional Programming Principles by Edward Garson

- 함수형 프로그래밍의 맥락을 깊이 이해하라.

3. Ask “What Would the User Do?” (You Are not the User) by Giles Colborne

- 사용자를 관찰해보자. 그들이 어떻게 생각하는지 알게 될 것이다.

4. Automate Your Coding Standard by Filip van Laenen

- 코드는 혼자만의 것이 아니다. 우리 모두의 코드이기 때문에 코딩표준이 필요하다. 자동화하지 않으면 녹아들기 힘듬.

5. Beauty Is in Simplicity by Jørn Ølmheim

- 단순한 코드가 아름답다. 간단한 코드가 우아하다.

6. ★ Before You Refactor by Rajith Attapattu

- 리팩토링은 좋은 것이지만 하기전에 한번 생각해보자.

- “코드의 스타일과 구조가 여러분의 개인적 선호도를 충족시키지 못한다는 것은 리팩토링의 정당한 사유가 될 수 없습니다”

7. Beware the Share by Udi Dahan

- 코드를 공용화할때 맥락을 고려해야 한다. 즉 의존성이 높아진다면 안하느니만 못하다.

- “제가 만든 공용 라이브러리들은 한 발의 신발끈을 다른 발에 묶어 놓은 것과 같이 서로에 대한 의존도가 높았습니다”

8. ★ The Boy Scout Rule by Uncle Bob

- 체크아웃할 때 보다 더 개선해서 체크인! Clean Code!

9. Check Your Code First before Looking to Blame Others by Allan Kelly

- 아니 이게 무슨소리오. 당신 코드는 완벽하고 컴파일러가 문제라니.

10. Choose Your Tools with Care by Giovanni Asproni

- 툴을 사용하자. 좋은거 많다. 선택은 주의해서.

11. ★ Code in the Language of the Domain by Dan North

- 암묵적 규칙을 남발하지 말고 도메인 용어. 즉 알아들을 수 있는 용어로 코딩하라.

12. Code Is Design by Ryan Brush

- 설계가 중요하다.

13. Code Layout Matters by Steve Freeman

- 코드 레이아웃은 생각보다 훨씬 중요하다.

- “우선 팀원들로 하여금 기본적인 자동 포맷터를 사용하지 않도록 해야합니다. 그리고 여러분 또한 도구의 도움을 받지 않고 스스로 레이아웃을 구성할 수 있어야 합니다”

14. ★ Code Reviews by Mattias Karlsson

- 코드리뷰는 반드시 해야한다. 지식공유를 위해. 어떻게? 상냥하게. 거부감 없이 편하고 재미있게. 비판적이기보다는 건설적으로.

15. Coding with Reason by Yechiel Kimchi

- 코딩할때 주의해야할 것들.

16. A Comment on Comments by Cal Evans

- 주석도 쓸모있을 때가 있다. 그치만 주석이 없을정도로 읽기쉽게 코딩하는게 낫다.

17. ★ Comment Only What the Code Cannot Say by Kevlin Henney

- 주석을 코드처럼 다뤄야 한다. 따라서 당연히 코드와 중복되면 안된다. 즉 코드가 말하지 않는 것을 주석으로 설명해야 한다.

18. ★ ★ Continuous Learning by Clint Shank

- 지속적인 배움은 스스로에게 달려있다. 강추.

19. Convenience Is not an -ility by Gregor Hohpe

- API를 구현할때의 편의성보다는 API를 사용할때의 편의성이 더 중요하다.

20. Deploy Early and Often by Steve Berczuk

- 릴리즈와 설치 프로세스도 미리미리 신경쓰자.

21. Distinguish Business Exceptions from Technical by Dan Bergh Johnsson

- 기술적인 예외와 비지니스 로직에 의한 예외를 따로 처리하자.

22. ★ Do Lots of Deliberate Practice by Jon Jagger

- 수련은 의도적인 반복이다. 수련의 목적은 능력 향상이다.

- “전문성을 개발하기 위한 핵심은 단순히 무엇인가를 반복하는 것이 아니라 여러분의 능력을 넘어서는 일에 도전하고, 그 일을 열심히 하고, 그 일을 계속하면서 성과를 계속 분석해 보고 실수를 고쳐 나가는 것”

23. Domain-Specific Languages by Michael Hunger

- DSL 이란게 있다.

24. ★ Don’t Be Afraid to Break Things by Mike Lewis

- 오믈렛을 만들때 달갈깨는 것을 두려워하지 마라. 리팩토링으로 인해 코드가 잠시 불안정해지는것을 두려워하지 마라.

- “숙련된 외과의사는 수술을 위해 절개가 필요하지만, 이것은 일시적이며 곧 봉합되어 회복될 것이라는 사실을 알고 있습니다. 여러분의 코드를 수술하는 것을 두려워하지 마십시오”

25. Don’t Be Cute with Your Test Data by Rod Begbie

- 장난삼아 넣어놓은 임시 데이터를 고객이 본다면?

26. Don’t Ignore that Error! by Pete Goodliffe

- 에러는 보일때 잡자. 안그러면 후회한다.

- “여러분이 에러를 무시했다면, 여러분은 장님이 되는 것입니다. 더 나쁜일이 일어나지 않을 것이라고 스스로를 속이는 것과 같은 것입니다”

27. Don’t Just Learn the Language, Understand its Culture by Anders Norås

- 새로운 언어의 사고방식을 배우자.

28. Don’t Nail Your Program into the Upright Position by Verity Stob

- 너무 많은 예외처리로 예외를 먹어버리지 말자.

29. Don’t Rely on “Magic Happens Here” by AlanGriffiths

- 프로젝트에는 다양한 역할이 필요하다. 역할 하나를 없애고 잘 돌아가길 기대하는건 기적을 바라는거다.

30. ★ Don’t Repeat Yourself by Steve Smith

- 프로세스도 중복을 피하자. DRY, OCP, SRP

31. Don’t Touch that Code! by Cal Evans

- 운영서버에 직접 코드를 고지치마라.

32. Encapsulate Behavior, not Just State by Einar Landre

- 객체지향 모델링의 장점을 활용해서 캡슐화를 제대로 하자.

33. Floating-point Numbers Aren’t Real by Chuck Allison

- 부동소수점은 정확하지 않다. 조심해서 사용하자.

34. Fulfill Your Ambitions with Open Source by Richard Monson-Haefel

- 회사에서 채워지지 않는 개발욕망이 있다면 오픈소스로 채워보자.

- “일로써 소프트웨어를 개발하는 것이 아니라 열망하기 때문에 소프트웨어를 개발할 수 있다면 참 좋을 것 같습니다”

35. The Golden Rule of API Design by Michael Feathers

- API를 설계할때 그 API를 사용하는 코드를 테스트할 방법도 고려해서 설계하자

36. The Guru Myth by Ryan Brush

- 구루도 사람이다. 다 알꺼라는 생각은 버리자.

37. ★ Hard Work Does not Pay Off by Olve Maudal

- 끝없는 잔업으로 일만한다고 해서 절대 성과가 나오지 않는다. 왜냐하면 프로그래밍과 소프트웨어 개발 작업에는 지속적인 학습이 수반되어야 하기 때문이다.

- “전문 프로그래밍은 길 끝에 도달해야만 목표 지점을 볼 수 있는 달리기와는 다릅니다. 대개의 소프트웨어 프로젝트는 어두운 곳에서 대략 그려진 지도만을 가지고 정해진 길을 찾아가야 하는 장거리 오리엔티어링 마라톤과 더 비슷합니다”

38. How to Use a Bug Tracker by Matt Doar

- 버그 리포트는 최대한 상세하게 적자. 버그는 작업의 표준 단위가 아니다.

39. Improve Code by Removing It by Pete Goodliffe

- 필요없는 부가적인 코드는 제거하자.

40. Install Me by Marcus Baker

- 쉬운 설치, 간결한 사용법은 생각보다 중요하다.

41. Inter-Process Communication Affects Application Response Time by Randy Stafford

- 느리다 싶으면 IPC부터 점검해보자

42. Keep the Build Clean by Johannes Brodwall

- Warning도 보일때마다 잡아야한다.

43. Know How to Use Command-line Tools by Carroll Robinson

- IDE말고도 커맨드라인 명령어로 다 할 수 있다. 특히 자동화에서는 필수.

44. ★ Know Well More than Two Programming Languages by Russel Winder

- 다양한 언어의 패러다임을 익히자. 상호 교류는 전문 지식의 핵심.

45. Know Your IDE by Heinz Kabutz

- IDE의 기능을 최대한 활용하자

46. Know Your Limits by Greg Colvin

- 소프트웨어가 뛰어넘기 힘든 현실의 한계가 있다.

47. Know Your Next Commit by Dan Bergh Johnsson

- 업무를 작은 보폭으로 짧게짧게 나누어라. divide and conquer.

48. Large Interconnected Data Belongs to a Database by Diomidis Spinellis

- RDBMS 사용을 두려워하지 말자. 많이 발전했고 장점도 많으며 계속 발전중이다.

49. ★ Learn Foreign Languages by Klaus Marquardt

- 도메인 언어든 제2외국어든 사람과 대화할 때 사용하는 진짜 언어를 하나 더 익히자.

- “제가 알고있는 최고의 프로그래머들은 모국어뿐 아니라 다른 언에도 능통합니다. 언어를 유창하게 하면 또한 문제점을 추상화하는 명확한 사고를 이끌어 낼 수 있습니다. 그리고 이런 것이 프로그래밍입니다” - “다른 언어를 안다는 것은 다른 영혼을 소유하게 되는 것”

50. ★ Learn to Estimate by Giovanni Asproni

- 추정하는 능력이 필요하다. 잘하기 위해서는 역시나 좋은 방법을 배운 후 꾸준한 연습뿐.

51. Learn to Say “Hello, World” by Thomas Guest

- 함수 하나도 충분히 독립적으로 실행할 수 있다는 사실. 단위 테스트를 작성하는 개발자라면 당연히 알테지만.

52. Let Your Project Speak for Itself by Daniel Lindner

- 지속적인 통합을 적용한 다음 문제가 생겼을때 이메일 노티 대신 싸이렌이 울리도록 해보자. 절대 무시할 수 없을 것이다. 재밌기도 하고. Extreme Feedback Device (XFD) 라 한다.

53. The Linker Is not a Magical Program by Walter Bright

- 링크하는 과정도 알아야한다.

54. The Longevity of Interim Solutions by Klaus Marquardt

- 임시 해결책을 적용해야하는 상황이 있다. 임시 해결책은 글자그대로 임시일 뿐이다.

- “여러분이 변화시킬 수 없는 것을 그대로 용납하는 평안을 누리고, 변화시킬 수 있는 것을 바꾸는 용기를 얻고, 그 차이를 아는 지혜를 얻기를 바랍니다”

55. Make Interfaces Easy to Use Correctly and Hard to Use Incorrectly by Scott Meyers

- 인터페이스 설계를 잘못사용할수 없도록 잘 설계하자. GUI 포함해서.

56. Make the Invisible More Visible by Jon Jagger

- 눈에 보이지 않는 것은 해결하기도 어렵다. 장애요소는 무엇이든 빨리드러나도록 하자.

- “프로젝트가 정상적인 개발 일정에 맞춰 진행되고 있었는데, 1주일후에 6개월이 지연되야 한다고 알려진다면, 프로젝트에는 문제가 있는 것입니다. 가장 큰 문제는 6개월의 지연이 아니라 6개월 지연을 감출 정도로 강력한 비가시성입니다”

57. Message Passing Leads to Better Scalability in Parallel Systems by Russel Winder

- 복잡한 병렬 문제를 해결하는 방법은 서로 독립적인 환경이 되도록 공유 메모리를 사용하지 않는 것이다. 대신 메시지 전달방식을 써보자. like Erlang.

58. ★ A Message to the Future by Linda Rising

- 지금 내가 작성하는 코드는 미래의 누군가에게 보내는 메세지이다.

- 읽기 쉬운 코드 = 완벽하고 아름다운 코드 = 잊혀지지 않는 멜로디 같은 코드 = 아름다운 세상을 만드는 코드

59. Missing Opportunities for Polymorphism by Kirk Pepperdine

- if-then-else 대신 다형성을 활용하자.

- “물론 if-then-else 구문을 사용하는 것이 더 실용적인 경우도 있겠지만 대부분 다형성을 적용한 코드가 더 적은 양으로도 가독성 높으며 견고한 코드를 만들 수 있습니다”

60. News of the Weird: Testers Are Your Friends by Burk Hufnagel

- 테스트를 해주는 테스터를 미워하지 말고 고마워해야한다.

61. One Binary by Steve Freeman

- 커스텀 바이너리 여러개 생성하지말고 딱 하나만 생성하자.

62. ★ Only the Code Tells the Truth by Peter Sommerlad

- 각종 문서, 주석 등은 모두 거짓일 수 있다. 가장 정확한 것은 바로 코드이다. 따라서 진실을 명확하게 말해주는 코드를 작성할 수 있도록 신경을 써야한다.

- “프로그램이 무엇을 하는지 알고자 한다면 소스코드를 살펴보는 것이 가장 확실한 방법입니다”

63. Own (and Refactor) the Build by Steve Berczuk

- 빌드는 개발과정의 필수 부분이다. 따라서 빌드 스크립트도 코드만큼 중요한 것이다.

64. Pair Program and Feel the Flow by Gudny Hauknes, Ann Katrin Gagnat, and Kari Røssland

- 짝 프로그래밍 좋아요. 장점이 이렇게나 많다구요. 하지만 어렵자나!

- “작업을 다른 짝에게 넘기기 위해 도중에 인터럽트를 거는 것이 납득이 잘 안될 수도 있지만, 우리는 이것이 문제없다는 것을 발견했습니다”

65. Prefer Domain-Specific Types to Primitive Types by Einar Landre

- 기본 타입보다 지금의 맥락에 맞는 타입을 따로 정의해서 사용하는게 더 낫다.

66. Prevent Errors by Giles Colborne

- 에러가 발생할 여지를 막아버리면 당연히 에러가 발생하지 않는다.

67. ★ ★ The Professional Programmer by Uncle Bob

- 전문 프로그래머란?

- 지속적인 학습을 통해 자신의 경력을 책임진다 + 완벽한 코드를 작성하려는 자세 + 팀 플레이어 + 버그는 절대 용납하지 않는다 + 대충대충하면서 엉망으로 만들지 않는다

- “만약 여러분이 유체 이탈을 해 의사가 여러분의 심장 절개 수술을 진행하는 장면을 지켜보고 있다고 상상해 보십시오. 그 의사가 전형적인 소프트웨어 개발자처럼 서두르면서 엉망으로 진행하기를 원하나요? 의사가 수술을 마치고 나서 ‘다시 돌아와서 나중에 고쳐도 될까요?’ 라고 말하기를 원하십니까?”

68. Put Everything Under Version Control by Diomidis Spinellis

- 코드뿐만 아니라 프로젝트와 관련된 모든 것들을 Repository 에 밀어넣고 관리하자. 논리적인 변경을 각각 별도로 커밋하자. 한꺼번에 하면 구분하기가 어렵다.

69. Put the Mouse Down and Step Away from the Keyboard by Burk Hufnagel

- 전체 맥락을 다시 생각해보기 위해서는 잠시 두뇌를 환기시키는게 좋다. 뽀모도로에서 의도적으로 5분을 쉬는것도 역시나 같은 이유때문이다.

70. Read Code by Karianne Berg

- 책도 좋다. 코드를 설명해놓은 문서도 좋다. 하지만 더 좋은 건 코드를 직접 읽어보는 것이다.

71. Read the Humanities by Keith Braithwaite

- 소프트웨어가 동작하는 방식과 소프트웨어를 개발하는 방식은 사실 사람들이 서로 돕고 함께 살아가는 이 세상과 닮아있다. 따라서 먼저 이 세상을 이해해보는건 어떨까?

72. ★ Reinvent the Wheel Often by Jason P Sage

- 이미 잘 쓰고있는 바퀴를 의도적인 학습을 목표로 다시 만들어보자. 분명히 값진 경험이 될 것이다.

- “항해와 관련된 영화를 보는 것과 직접 항해를 하는 것은 다르다”

73. Resist the Temptation of the Singleton Pattern by Sam Saariste

- 싱글톤에는 단점이 많다. 사용전에 꼭 필요한지 다시한번 생각하자. 특히 단위테스트가 어렵다는 단점이 가장 맘에 안든다.

74. The Road to Performance Is Littered with Dirty Code Bombs by Kirk Pepperdine

- 코드의 복잡성과 의존성을 파악하는 도구를 활용해서 미리미리 코드의 폭탄을 제거해놓자. 안그러면 성능개선을 위해서든 뭐든 코드변경이 필요할때 폭탄이 터져버릴것이다.

75. Simplicity Comes from Reduction by Paul W. Homer

- 코드를 간단하게 유지하자. 그럴려면 잘 돌아가는 기존의 코드도 간결하게 리팩토링할 의지와 용기가 있어야한다.

76. ★ The Single Responsibility Principle by Uncle Bob

- SRP. 단일 책임의 원칙. 하나의 서브시스템, 모듈, 클래스, 함수에는 한 가지 이상의 변경 이유가 있어서는 안된다.

77. Start from Yes by Alex Miller

- 긍정적인 마인드로 접근하면 긍정적인 면이 보이고 부정적인 마인드로 접근하면 부정적인 면만 보인다.

78. ★ Step Back and Automate, Automate, Automate by Cay Horstmann

- 한번 이상 반복될거라 생각되면 자동화해버리자. 일단 자동화가 되면 생각보다 편하게 실행할 수 있고 평소보다 훨씬 더 많이 실행할것이며 그에 따라 얻는 이득이 분명 있을 것이다.

79. Take Advantage of Code Analysis Tools by Sarah Mount

- 정적 코드 분석 툴을 활용하자. 분명히 문제인데도 툴이 잡아내지 못한다면 자신만의 분석툴을 만들어보자.

80. Test for Required Behavior, not Incidental Behavior by Kevlin Henney

- 코드가 구현되어있는대로 테스트하기 보다는 기대하는 동작대로 테스트를 작성하자.

- “코드로부터 무엇을 하는지를 명백하게 알 수 있음에도 이를 그저 반복해 확인하는 것은 가치 있는 일이 아니며 잘못된 진척률과 안도감을 줄 수 있습니다. false sense of progress.

81. Test Precisely and Concretely by Kevlin Henney

- 테스트를 작성할때는 기대하는 값에 대해서 정확히 검증하도록 하자. 어설프게 검증하면 구멍이 생긴다.

- “소프트웨어를 설계하는 방법에는 두 가지가 있다 : 한 방법은 설계를 아주 단순하게 해서 명백하게 결함이 존재하지 않게 하는 것이고, 다른 방법은 설계를 아주 정교하게 해서 명백한 결함이 존재하지 않게 하는 것이다”

82. Test While You Sleep (and over Weekends) by Rajith Attapattu

- 내가 일하고 있지 않는 시간에도 테스트는 돌아가게 해놓자. 어차피 그시간에 컴터는 논다. 회사 전기세를 걱정하지 않아도 되잖냐. 특히 시간이 오래걸리는 테스트라면 딱이다.

83. Testing Is the Engineering Rigor of Software Development by Neal Ford

- 테스트는 이제 소프트웨어 개발에서 엄격히 지켜야하는 규칙이다.

- “교량 건설자는 결코 상사로부터 ‘건물의 구조를 분석하느라 애쓰지 마. 우리 마감일은 빠듯하니까’ 라는 말을 듣지는 않을 것입니다”

84. Thinking in States by Niclas Nilsson

- 상태를 명확히 구분해야하는 시나리오라면 State Machine 을 사용하자.

85. Two Heads Are Often Better than One by Adrian Wible

- 짝 프로그래밍으로 배울 수 있는게 많다.

86. Two Wrongs Can Make a Right (and Are Difficult to Fix) by Allan Kelly

- 버그 두개가 서로 영향을 주어서 둘다 드러나지 않는 경우가 있다. 버그를 알아차리기도 힘들지만 수정하기는 더 힘들다. 그래서 어떻게해야한다? 잘 찾아서 고치자.

87. Ubuntu Coding for Your Friends by Aslam Khan

- 깨진 창문을 내버려 두지 말자. 코드는 너 혼자만의 것이 아니다. 당신이 작성한 나쁜 코드로 스트레스받을 동료 개발자를 생각하자.

- “사람은 다른 사람이 있기에 사람이다. 개발자는 다른 개발자가 있기에 개발자다. 코드는 다른 코드가 있기에 코드다”

88. The Unix Tools Are Your Friends by Diomidis Spinellis

- 유닉스 툴은 참 유용하다.

89. Use the Right Algorithm and Data Structure by JC van Winkel

- 알고리즘과 자료구조에 대해서는 기본적으로 잘 알아야한다. 그래야 효율적인 코드를 작성할 수 있다. 아니 문제있는 코드 작성을 피할 수 있다.

90. Verbose Logging Will Disturb Your Sleep by Johannes Brodwall

- 필요없는 로그 말고 필요한 로그만 적어보자.

91. WET Dilutes Performance Bottlenecks by Kirk Pepperdine

- Write Every Time. 동일한 코드가 중복되는 현상은 좋지 않다. 성능 개선을 위해 분석할때도 당연히 안좋다. 중복이 좋은게 뭐가 있겠나. 무조건 DRY 다.

92. When Programmers and Testers Collaborate by Janet Gregory

- 개발자와 검증자는 적이 되기 쉽다. 하지만 서로에게 배울 점이 분명히 있으며 서로 도움이 되는 부분도 분명히 존재한다. 너무 미워하지 말자.

93. Write Code as If You Had to Support It for the Rest of Your Life by Yuriy Zubarev

- 코드를 대하는 자세는 어때야 할까? 결혼 상대자를 찾는 것처럼 진중한 마음이어야 한다. 잠깐의 Enjoy 마인드는 안된다.

94. Write Small Functions Using Examples by Keith Braithwaite

- 도메인을 생각하면 고려해야하는 세계가 작아지고 훨씬 문제가 쉬워진다.

95. ★ Write Tests for People by Gerard Meszaros

- 테스트는 코드를 어떻게 사용해야하는가와 이 코드가 무슨일을 하는지를 설명해준다. 결국 테스트를 작성하는 것은 나를 위해서가 아닌 것을. 테스트의 장점은 수도없이 많다. 작성하자. 테스트. 두번 작성하자.

96. ★ You Gotta Care about the Code by Pete Goodliffe

- 프로그래밍을 함에 있어서 가장 중요한 것은 마음가짐이다. 아니 무슨일이든 마찬가지 일 것이다.

- “소프트웨어 회사에서의 다년간의 경험으로, 저는 적당한 프로그래머와 훌륭한 프로그래머 사이의 진짜 차이의 대한 결론을 내렸습니다. 바로 마음가짐입니다. 좋은 프로그래밍은 소프트웨어 회사의 현실적인 제약과 압력 속에서도 전문적인 접근 방법을 사용하려 하고, 여러분이 할 수 있는 최상의 소프트웨어를 작성하기를 원할 때 만들어집니다”

97. Your Customers Do not Mean What They Say by Nate Jackson

- 고객은 그들이 무엇을 원하는지 잘 모른다. 개발자도 모른다. 그러면 코드도 뭘하는지 모르게 된다. 고객을 자주 만나서 소통하자.

모든 관리 행동은 정치적인 행동이다. 모든 관리 행동은 어떤 방식으로든 권력을 재분배하거나 강화한다는 뜻이다. - 리차드 파손

의욕있고 야심찬 사람들은 본능적으로 정치적인 행동을 한다. 즉, 일을 성사시킬 권한이 있는 사람을 움직여서 원하는 바를 얻으려고 한다.

정치를 이끄는 힘은 권력이다. 즉, 권력은 다른 사람을 통제하는 개인의 능력이다. 

권력을 가진 사람 = 상사 가 아니라 

적절한 인물을 설득해서 난국을 풀어나가는 힘을 가진 사람이 권력이 크다고 할수있다.

그래서 상사가 아닌 그냥 일반 개인이 이런 권력을 획득할수있기 때문에 정치 구도는 더욱 복잡해 질수있는것이다.

우리는 최소한 정치 시스템이 어떻게 동작하는지 알고 있어야 한다. 그래야 조금이라도 긍정적인 효과를 얻을수있다.

이 장에서는 “ 응용 프로젝트 정치학 “ 이라는 핵심 교훈을 제시한다. 

내가 속한 그룹에서 정치적 형세를 파악하는 법 

흔히 발생하는 상황

그 상황이 발생하는 이유

정치과 권력 문제를 해결하는 방법 

—————————————————

정치적 인간으로 다시 태어난 날

권력의 근원

권력 오용

정치적인 문제를 푸는 방법

정치판 알기

——————————————————————————

정치적 인간으로 다시 태어난 날 - 

프로젝트가 제대로 돌아가지 않자 조직정치에 불신을 갖게 되며 정치는 사악하고 나약하고 이기주의적인 인간이 행하는 일이라고 믿음

크리스존스와 면담 중에 크리스는 자신의 관점에서 현재의 상황을 설명해주고, 합리적인 해결책도 제시해 줌 그리고 의견을 물어봐 주고 나의 논리와 관점을 피력할 기회를 줌

—> 앗!! 정치란 어려워도 한참 어려운 기술이구나 

정치는 더러운 단어가 아니구나

- 정치는 사람과 조직을 다루는 기술입니다. 비윤리적이거나 비열한 방식에 의존하지 않고서도 효과적인 정치를 펼칠수있습니다.

모든 리더는 정치적 제약과 권력 제약이 있구나

- 미합중국 대통령은 어마어마한 권력이 있다고 믿기 쉽지만, 사실은 대통령의 공식적인 행위중에 다수는 거부되거나 기각될수있으며 아래 부처에서 점검하고 균형을 맞춥니다.

자신보다 권력이 많은 사람이라고 해서 전능하다고 가정해서는 안됩니다. 

책임 대 권력 비율은 상수이구나

- 권력이 커질수록 책임감과 스트레스와 도전도 커집니다. 그러므로 권력이 커진다고 해서 일이 더 쉬워지지 않습니다.

정치는 일종의 문제해결이구나

또한 비난하지말자. 남탓 하지 말자 

비난한다고 해서 상대가 덜 멍청하거나 덜 비효율적이 되지는 않는다

————————————————

권력의 근원

권력 : 일을 하거나 행동하는 능력, 무엇인가를 하거나 달성하는 수완

정치를 이해하려면 권력의 기본을 이해해야 한다.

우리 조직에서 어떻게 결정을 내리는지 생각해보자

- 힘든 결정을 내려야 한다면 누가 내리는가?

- 이를 토론하는 회의에는 누가 참석하는가?

- 사람들이 누구 의견을 가장 귀담아 듣는가?

—> 바로 이들이 권력을 가진 사람들이다.

제도적 권력 : 직책이나 근속 연수로 부터 옴,  거의 항상 권력이 더 큰 직위에 있는 사람으로 부터 부여받음

절차적 권력 : 명성과 능력으로 부터 옴, 하지만 이는 주관적이므로 누가 절차적 권력을 가질지는 참여자 개개인이 결정함

예를 들어 한 조직의 선임관리자가 다른 조직의 신참 직원을 높이 사기도 한다.

결정 분야에 따라, 회의 참석자에 따라, 참석자의 권력에 따라 결과는 달라진다.

군력은 누가 휘두르지 전까지 명백하게 드러나지 않습니다. 그래서 누구에게 어떤 권력이 있는지 잘못 판단하기 쉽습니다.

그럼 이제부터 우리 조직에서 누가 권력을 쥐고 있으며, 그들이 어떻게 권력을 사용하는지 생각해 봅시다.

포상 : 보너스를 주거나, 연봉을 인상하거나, 맛있는 음식을 내놓는 등 눈에 보이는 유익한 포상을 제공하는 권력

강압 : 처벌 체계를 관리하고 징벌 조치를 취하는 권한  (다른 사람들 앞에서 개인을 비웃거나 모욕하는 권력도 포함)

지식 : 특정 분야에 전문 지식이 있거나 결정에 영향을 미치는 정보가 있다면, 권력이 생김

단순 - 똑똑하게 굴거나  자신의 분야에서 문제를 잘 해결하는 경우 권력이 생김

복잡 - 다른 사람, 팀, 경향, 회의에 대한 정보를 확보하면 이또한 권력이 생김 - 스티브 잡스 (지각력 왜곡)

준거 : 권력자와 우호관계에 있거나 친분이 있는 사람에게도 권력이 생김 

영향력 : 의사소통 능력, 자신감, 감정적인 인지력, 관찰 능력등이 뛰어나서 생기는 권력 

상대가 지닌 지식을 존경해서, 상대를 신뢰해서, 혹은 상대가 매력적이고 똑똑하고 재미나기 때문에 상대가 영향력을 발휘할 수도 있습니다.

——————————————————

권력 오용

정치가 나쁘다고 말할때는 보통 권력 오용을 의미함

프로젝트와 프로젝트 참여자에게 큰 이익을 주지 못하는 부정적인 행위 전부 : 권력 오용

개인이 자신의 이익을 추구할 때 생김

개인적인 동기는 프로젝트와 보조를 맞춰야 한다 

보조를 맞추지 못할 수록 정치적인 행동 양식이 더 파괴적으로 변한다.

때로는 권력에 대한 분쟁이 이타주의적인 이유로도 발생할 수 있다.

순수하게 사적인 동기를 가려내려면 관련자에 대한 지식, 명확한 프로젝트목표, 우수한 의사소통/토론/논쟁구조가 필요하다.

이익이 분산될 수록 권력을 오용할 확률은 높아진다. 

절차로 인한 권력오용 : 팀이나 조직을 잘못구성한 탓 일종의 관리 실패/리더십 실패

훨씬 위험 왜냐면, 특정 개인의 행동에만 국한하지 않고 조직 전반에 존재

- 의사 결정의 불투명한 절차 —> 의사결정자는 결정을 내리는 방식, 결정에 참여하는 사람들, 결정에 사용할 조건을 모두에게 명확히 밝혀야 한다. 

- 의사소통 오해 : 의사소통이 나쁠수록 권력 오용은 증가 —> 해결 정보를 전달하기에 그치지 않고, 이해했는지 그리고 가능하다면 동의하는 지까지 확인해야 한다.

- 불투명한 자원분배 : 사람들은 모든 전술을 동원해서 자원을 확보하려 들것이다. —> 자원을 분배하는 과정, 기준을 팀에게 분명하게 밝혀야 한다. 

- 책임감 부족 : 책임을 지지 않는 분위기에서는 정치가 불가피, 신뢰가 없으면 사람들은 각자 권력을 동원하여 자신을 보호 하려 함 

- 미약하거나 무력한 목표 : 십중팔구 권력이 오용됨 

프로젝트 목표에 중심이 없다면, 모든 사항이 논쟁거리가 되고 제각각 해석될수밖에 없음  —> 팀리더는 적극적으로 목표를 보호하고 정확하게 유지해야 함

동기로 인한 권력 오용 : 개인적인 필요와 욕구로 생김 

- 다른 사람을 보호하려는 마음 

- 사리사욕 : 승진 진급 자부심을 얻기 원함

- 자아 : 내가 얼마나 똑똑한지 증명하겠다

- 증오/복수 : 누군가와 일하기 싫다. 

위의 동기도 제어하는 책임은 관리자의 몫이다. 남에게 상처입히지 않는 범위에서는 또다들 추진력이 될수있다. 

관리자는 프로젝트에 저항하는 쪽이 아닌 돕는 방향으로 위의 동기를 이끌어야 한다.

대부분은 복합적

권력 오용 방지

: 최선의 방법 —> 프로젝트 목표 강조해서 권력 사용을 조종

- 이번주/달/프로젝트 목표가 무엇입니까

- 전체 팀 목표 또는 하위 팀 목표가 충돌을 일으킵니까? 이문제를 어떻게 관리하거나 해결합니까?

- 이결정은 어떻게 그리고 누가 내렸습니까?

- 이결정이 프로젝트에 최선인지 판단하는 기준은 무엇입니까?

- 목표에 기여하고 팀을 지원하는 방향으로 권력을 사용하고 있습니까?

- 자원을 어떻게 사용하면 성공 확률이 가장 높아집니까? 어떻게 하면 이렇게 만들수 있습니까?

목표가 아주 오개되었거나 개인별 혹은 팀별로 크게 다르다면, 권력 오용은 반드시 일어난다

목표가 다르거나 상충하는 개개인을 그래로 방치하면 각자는 자신의 목적을 위해 정치력을 사용하려고 합니다.

때로는 관리자가 고의적으로 팀을 서로 경쟁하게 만들기도 하는데 이를 위해서는 더욱 강력하고 적극적인 리더가 필요하다. 그렇지 않으면 조직을 더 정치색이 강하게 취약하게 만든다. 

—————————

정치적인 문제를 푸는 방법

가정

1. 프로젝트에는 잘 정의한 목표가 있다

2. 프로젝트 목표가 달성하려는 업무에 동기를 부여한다.

(중요한 사안일 경우 유용한 방법임)

무엇이 필요합니까?

자원/ 결정/ 목표 조정 / 조언/ 전문지식/ 지원 등 필요한 사항을 명확하게 정의한 후 어떻게 얻어낼 것인지 계획을 세워야 함 —> 상사 관리하기

- 상사관리하기

관리층에게 필요한 바를 명확하게 말하는 것

관리자가 내게 해주어야 할 일은 무엇인지, 관리자가 관여했으면 하는 수준은 어느정도인지, 목표를 달성하기 위해 필요한 자원은 무엇인지를 관리자에게 이야기 해야 한다.

만약에 관리자가 미적거리거나, 에매하거나, 방어적인 태도로 요청에 책임지려 하지 않는다면… 이는 경고신호로 받아드려야 한다. 

누구에게 권력이 있는가?

- 실제 권력이 누구에게 있는가? 반드시 조직구조도를 따르지는 않는다. 특정 사안에는 중간급 직원이 상사보다 권한이 클수있다.

-상대방 입장 이해하기

권력을 쥐고 있는 사람의 목표가 무엇인지 파악하고 그안에서 내가 필요한 사항을 끌어내자. (권력을 쥐고 있는 사람의 목표는 프로젝트 목표와 거의 일치함)

그들은 누구를 신뢰하고 존경합니까?

권력을 쥐고있는 사람을 찾았으면, 누가 그에게 영향을 미치는지 찾아야함

그래서 내 주장에 설득력을 더하기 위해 이들의 영향력을 활용하는 방법을 고민해라

하지만.. 사람을 조종하거나 거짓말 하거나 미심쩍은 행동을 해서는 안된다.

그룹권력

때로는 필요한 권력을 그룹이 쥐고있는 듯 보일수도 있다.  하지만 절대로 그룹에 초점을 맞추지 말자

재미난것

사실 회의에서 무언가를 결정하는 경우는 거의 없다

대게 사람들은 강력한 의견과 동맹군을 준비해서 토론에 참석한다.

그리고 회의는 미리 정해진 각본대로 진행된다.

풋내기에게는 회의가 역동적이고도 활발해 보이겟지만 최고 권력을 보유한 사람은 논쟁 대부분의 시작과 끝을 전적으로 예측한다.

사전에 철저히 준비했으며 논쟁을 끝낼 훌륭한 반박까지 준비헀다.

프로젝트에 가장 이익이 된다고 생각하는 방향을 이들에게 납득시킬 논리, 영향력, 의사소통 기술이 있다고 확신하는 경우에만 맹목적으로 그룹에게 아이디어를 제시하십시오

상황판단

권력에 영향을 미치는 전술

- 상황을 판단했다면 행동할 차례

직접 요청 : 권력을 달라고 직접 요청

대화 : 직접요청을 협력적인 형태로 변형한 전술

강한 리더나 관리자는 이런 행동을 장려하는데 이런 행동이 활성화 되면 리더나 곤리자가 관여할 필요성이 줄어들기 때문

영향력 활용 : 팀에서 A에게 영향력이 큰 사람들을 주의 깊게 선발 하십시오 

다단계 영향력 활용 : 

간접적인 영향력 활용 다른 사람의 도움을 받아서 그 사람이 대신 요청하게 

그룹회의 : 그룹회의는 예측 불가능

자기 생각이라고 여기게 만들어라 : 자기가 항상 옳다고 생각하는 상사에게 종종 효과가있음

정치판 알기

자신만의 정치판 알기

PM은 정치판을 통제할 권력이 있다. 또한 팀 내부로 권력을 분배하는 방법도 통제한다 

자신의 정치판을 안전하고 공정한 곳으로 만들어 똑똑한 사람이 제대로 일하도록 만들어야 한다.

훌륭한 관리자는 팀을 보호한다.

팀원들이 일하기 편한 세상을 만들어주기 위해 팀원을 대신해서 뛰어다닌다.

상사가 나를 형편없이 대한다고 해서 부하직원을 똑같이 대하지는 말자

결국 자신의 영향권 내에서 발휘하는 적극적인 리더십은 자신의 권력을 키우는 최고의 수단

아래의 5가지의 구결은 비즈니스 문서의 품격에 관한 좋은 가이드가 될 것이다. 이것 역시 IT업계에 종사하는 전문인은 항시 외울 것을 권하고 싶다. 외울 수 없다면, 전천후로 판단 기준을 상기할 수 없을 것이다. 

첫째, 결론부터 말하라. 많은 문서는 결론을 문서의 마지막에 제시한다. 비즈니스 문서는 신속한 의사결정을 위하여 본문의 결론을 한 페이지로 요약하여 표지 다음으로 위치시키는 것이 좋다. 바쁜 의사결정권자가 설명 중에 떠나더라도, 그 표지 한 장으로도 키 메시지를 이해시켜야 한다. 젊은 작성자들은 대개 요약문(Executive Summary)과 개요(Overview)를 구별하지 못하는 경우가 많은데, 요약문은 어떤 의사결정을 하게 되면 어떤 경영적 이점이 달성된다는 메시지가 분명히 기재되어야 한다. 

둘째, 구조화하고 시각화하라. 장황한 설명보다는 주요 메시지가 눈에 잘 들어오도록 시각화하고, 구조화시켜야 독자들이 짧은 시간에 이해할 수 있게 된다. 특히 동일 레벨의 메시지가 5개~8개를 넘어가게 된다면, 2개의 상위레벨로 하위레벨을 분리하여 종속시키는 것이 원칙이다. 

셋째, 추상화레벨을 맞추어라. 독자나 청중의 수준에 맞추어 메시지의 심도가 달라야 한다. 경영자에게는 추상화 레벨을 높이고, 실무자에게는 추상화 레벨을 심화시키는 것이 좋으며, 각 장의 수준은 동일한 추상화레벨을 유지하는 것이 좋고, 추상화레벨이 더욱 심화된 것은 별첨으로 옮기는 것이 효과적이다. 직원들이 “추상화레벨”이라는 용어를 잘 이해하고 사용하는 경우는 의사소통문화가 진일보하는 증거가 되기도 한다. 

넷째, 논리적 연관성을 유지하라. 작성자들은 각각의 장에 해당 메시지만을 포함시키는 우를 범하여, 결정적인 의사결정을 유도하는 논리적 설명을 요하는 페이지를 누락시키는 경우가 많이 있다. 특히, “요건-제안기능-효과”를 각 장에서 별도로 설명했어도 이들 내용의 논리적 연관성을 설명하는 매칭 테이블이 포함된다면, 이것이 키 메시지가 될 것이다. 

다섯째, 장기적 비전 혹은 남겨진 과제를 제시하라. 요청자가 1차적인 과제에 대한 해답만을 요구하였다 하더라도, 제안자가 1차 과제 이후에 발생할 과제까지 예측하여 제시하여 준다면, 요청자는 제안자의 식견에 경의를 표할 것이고 만약 그와 같은 예측 상황이 실제로 발생하게 된다면, 1차 과제의 제안자를 먼저 초대하게 될 것이다. 대다수의 실무자가 근시안적 관점으로 이러한 미래기회를 미리 확보하지 못하는 과오를 범하고 있다. 당신이 미래의 비전이나 과제를 제시할 능력이 있다면, 당신은 사회적 성공을 기대할 자질을 가지고 있는 사람이다.

필자의 경험으로 훈련을 많이 받은 직원들이 많이 놓치는 것이 네 번째와 다섯 번째 원칙이다. 구결은 단순하지만, 2~3년 훈련 받지 않으면 활용하기 힘든 구결이다.@