글 쓰는 시간

15장 정리

애플리케이션을 설계하다 보면 과거에 경험하고 해결했던 방법을 다시 사용하는 경우가 있다.
이렇게 소프트웨어 설계에서 반복적으로 발생하는 문제에 대해 반복적으로 적용할 수 있는 방법을 디자인 패턴이라고 한다.
디자인 패턴의 목적은 설계를 재사용하기 위함이다.
프레임워크는 설계와 코드를 함께 재사용하기 위한 것이다.
디자인 패턴과 프레임워크 모두 일관성 있는 협력과 관련이 있다.
디자인 패턴은 특정한 변경을 일관성 있게 다루는 협력 템플릿을 제공하고,
프레임워크는 특정한 변경을 일관성 있게 다룰 수 있는 확장 가능한 코드 템플릿을 제공한다.

디자인 패턴과 설계 재사용

소프트웨어 패턴

패턴은 한 컨텍스트에서 유용한 동시에 다른 컨텍스트에서도 유용한 아이디어다.
패턴이 지닌 가장 큰 가치는 경험을 통해 축적된 실무 지식을 효과적으로 요약하고 전달할 수 있다는 점이다.
패턴은 경험의 산물이기 때문에 초보자라고 하더라도 패턴을 익히고 반복적으로 적용하는 과정 속에서 유연하고 품질 높은 소프트웨어를 개발하는 방법을 익힐 수 있다.
패턴은 '이름'을 통해 지식 전달과 커뮤니케이션의 순단으로 사용할 수 있기 때문에 이름 짓기가 중요하다.

패턴과 책임-주도 설계

패턴은 공통으로 사용할 수 있는 역할, 책임, 협력의 템플릿이다.
적절한 패턴을 따르면 특정한 상황에 적용할 수 있는 설계를 쉽고 빠르게 떠올릴 수 있다.
하지만 디자인 패턴을 따른다는건 역할, 책임, 협력의 관점에서 유사성을 공유하는것이지 특정한 구현 방식을 강제하는 것은 아니다.
대부분의 디자인 패턴의 목적은 특정한 변경을 캡슐화함으로써 유연하고 일관성 있는 협력을 설계할 수 있는 경험을 공유하는 것이다.
따라서 디자인 패턴에서 중요한 것은 디자인 패턴의 구현 방법이나 구조가 아니라 어떤 변경을 캡슐화하는지를 이해하는 것이 중요하다.

패턴은 출발점이다.

대부분의 패턴 입문자는 패턴을 적용하는 컨텍스트의 적절성을 무시한 채 맹목적으로 패턴의 구조에만 초점을 맞추기 쉽다.
따라서 부적절한 상황에서 부적절하게 사용된 패턴으로 인해 유지보수 하기 어려운 시스템을 만드는 것을 주의해야 한다.
패턴을 남용하지 않기 위해서는 다양한 트레이드오프 관계 속에서 패턴을 적용하고 사용해 본 경험이 필요하다.
정당한 이유 없이 사용된 모든 패턴은 설계를 복잡하게 만드는 장애물이다.
패턴을 적용할 때는 항상 설계를 좀 더 단순하고 명확하게 만들 수 잇는 방법이 없는지를 고민해야 한다.
또한 코드를 공유하는 모든 사람들이 적용된 패턴을 알고 있어야 한다.
패턴을 적용할 때는 함께 작업하는 사람들이 패턴에 익숙한지 여부를 확인하고, 그렇지 않다면 설계에 대한 지식과 더불어 패턴에 대한 지식도 함께 공유하는 것이 필요하다.
패턴을 가장 효과적으로 적용하는 방법은 패턴을 지향하거나 패턴을 목표로 리팩터링하는 것일 수 있다.

프레임워크와 코드 재사용

프레임워크란 '추상 클래스나 인터페이스를 정의하고 인스턴스 사이의 상호작용을 통해 시스템 전체 혹은 일부를 구현해 놓은 재사용 가능한 설계' 또는 '애플리케이션 개발자가 현재의 요구사항에 맞게 커스터마이징 할 수 있는 애플리케이션의 골격'을 의미한다.

제어 역전 원리

의존성 역전 원리를 따르는 설계는 변경에 유연하게 대처할 수 있다.
이런 의존성 역전 원리는 프레임워크의 가장 기본적인 설계 메커니즘이다.
의존성 역전은 의존성의 방향 뿐만 아니라 제어 흐름의 주체 역시 역전시킨다.
협력을 제어하는 것은 프레임워크이고, 우리는 프레임워크가 적절한 시점에 실해할 것으로 예상되는 코드를 작성한다.

인상깊었던 점

"정당한 이유 없이 사용되는 패턴은 유지보수를 어렵게 만드는 장애물이 된다."
이 부분이 이번 장에서는 인상깊었다.
디자인 패턴을 공부하고서 의욕이 넘쳐서 이리저리 써봤지만 결국 적용하고 보니 과한 설계였던 경험들이 있었다.
이 경험들이 떠오르면서 정당한 이유 없이 사용되는 패턴은 유지보수를 어렵게 만드는 장애물이 된다는 부분이 더 와닿았다.

자라기

1. 야생형 개발자가 되라.

공부법에는 학자형 공부법과 야생형 공부법이 있다.

둘 중 뭐가 우위다 하는건 아니고 두 학습법 모두 적합한 상황에 적용해야 한다.

• 학자형 학습법은 차근차근 순차적으로 기초를 쌓아올라가는 방법이다.
• 불확실성과 변동이 적은 분야는 학자형 공부법이 어울린다.
• 야생형은 비순차적으로 필요에 따라 지식을 습득한다.
• 불확실성이 높고 변동이 많은 분야일수록 야생형 공부법이 필요하다.

사람들은 불확실성이 높은 분야에서도 학교에서 공부하던 방법대로 공부하려는 경향이 있다.

졸업한 시점에서는 결국 학자형으로만 공부해서는 안된다.

아무 생각없이 고수가 시키는대로, 고수가 해왔던대로 하다보면 고수가 된다는 판타지를 버려야한다.

2. 의도적 수련을 하라.

생각없이 오랜 시간을 투자해봤자 일정 수준 이상 실력이 오르지 않고 효율도 나쁘다.

중요한건 의도적 수련이다. 짧은 주기로 피드백을 반복하면서 공부의 목적과 어디에 쓸 수 있을지 의식해야 한다.

또한 나를 되돌아보는 시간을 자주 가져서 변화한 실력에 맞는 적절한 난이도를 수시로 조정해야 한다.

3. 자신이 이미 갖고 있는 것부터 잘 활용하라.

올해 책 몇권을 읽었다고 자랑하지 말고, 배운것을 얼마나 활용했는지 생각해야한다.

이미 갖고 있는 지식을 촘촘히 연결하고 새로 배운 지식을 기존 지식과 충돌시키며 자신의 것으로 만들어야한다.

4. 실행 프레임을 만들지 말라.

무언가를 하면 어떤걸 얻을 수 있다는 보상심리로 공부하는건 좋지 않다.

또한 어떠한 이유 때문에 무언가를 할 수 없다는 생각도 좋지않다.

"부트 캠프를 수료하면 취업할 수 있겠지", "내 환경이 이래서 할 수 없었다" 같은 생각을 버려야 한다.

어차피 과거를 되돌릴 수는 없는 일이므로 동일한 환경 속에서도 성장의 기회를 찾아야 한다.

5. 능률을 올려주는 도구와 환경을 점진적으로 만들어라.

처음부터 완벽한 환경을 구성하고 시작할 생각을 하지 말고 점진적으로 개선할 생각을 해야한다.

결국 완벽한 환경이라는건 성립할 수 없고 결국 아쉬운 부분이 생긴다. 그러므로 당장 실행하고 점진적으로 개선하자.

6.튜토리얼을 읽어도 뭘 만들지 생각하며 읽어라.

그냥 배우는 데서 끝내면 결국 쉽게 잊어버리고 학습 속도도 느리다.

배운걸로 간단한거라도 만들어보는게 가장 빨리 배우는 길이다.

7. 새로운 언어를 배울 때는 표준 라이브러리 소스 코드를  읽어라.

새로운 언어를 배울 때는 당장은 잘 와닿지 않는다. 결국 사용을 해봐야 그 언어에 대한 스타일을 습득할 수 있는데

이럴 때 표준 라이브러리 소스코드를 보면 해당 언어의 숙어와 패턴, 스타일을 배우기 좋다.

8. "전문가에게 전문성을 효과적으로 뽑아내는" 전문가가 되라.

전문가에게 배움을 구할 때 그 비결 자체를 물어보는 화법은 원하는걸 많이 얻지 못할 수 있다.

전문가 본인도 잘 설명하고 싶어도 대본까지 완벽하게 준비해온게 아닌 이상 모든걸 말 할 수는 없다.

따라서 구체적인 사건에 대해 말하도록 유도하는 화법을 사용해야 원하는걸 많이 얻을 수 있다.

또한 모르는 문제에 대해 질문할 때도 어떻게 생각하면서 문제에 접근 했는지 과정을 설명하는 습관을 들이면

듣는 사람의 입장에서도 메타 인지에 도움이 되고 더 많은걸 알려줄 수 있다.

함께

1. 커뮤니케이션과 협력의 중요성

짝 프로그래밍은 대화를 통해 서로의 생각을 공유하면서 추상화와 구체화 과정을 반복한다.

그 결과 혼자서는 생각하지 못했던 영역까지 사고를 확장시킨다.

뛰어난 프로그래머 일수록 커뮤니케이션을 통해 구성원들의 협력을 잘 이끌어내고 이는 곧 생산성과 이어진다.

직관이라는 것은 생각보다 틀릴 때가 많다. 함께함으로써 이 직관의 허점을 줄일 수 있다.

함께라면 확률이 AND 에서 OR 로 바뀐다. 만약 팀원이 n명이고 개개인의 버그 발생 확률이 10% 라면

팀원끼리 단절된 독립적인 팀의 버그 발생하지 않을 확률은 0.9^n  이다. (모두 버그 발생하지 않은 경우)

하지만 함께 소통하는 팀의 버그가 발생하지 않을 확률은 1 - 0.1^n 이다. (1 - 모두가 버그가 발생할 확률)

2. 팀장이면 새로운 아이디어 전파가 쉬울거란 생각은 환상이다.

새로운 아이디어를 전파하기 위해서는 구성원들을 설득하는 과정이 필요하다.

구성원 각각의 이해의 수준과 성향이 판이하므로 그 사람에 맞는 대화법을 통한 설득이 필요하다.

3. 커뮤니케이션을 할 수록 신뢰가 깨지는 사람이 되지 말자.

신뢰는 사회적 자본이고 신뢰가 깨진 상태에서는 좋은 의도로 한 말이나 행동도 악의적으로 보인다.

결국 새로운 기술을 도입하고 제대로 정착시키기 위해서는 구성원들의 협력이 필요하다.

아무리 논리적이고 타당한 제안일지라도 구성원들간의 신뢰가 깨진 상태에서 구성원들을 설득하는것은 쉽지 않다.

상대방을 설득할 때는 논리성과 객관성에 대한 환상을 버려야 한다. 인간은 그리 합리적인 동물이 아니다.

4. 실수는 예방하는게 아니라 관리하는 것이다.

상대방을 압박하는 말투는 그 사람을 위축시키고 할 수 있는 일도 못하게 만드는 수가 있다.

결국 그 사람은 실수를 숨기고 질문을 안하는 경향을 띠게 될것이고 이는 조직에 큰 피해를 주는 결과로 이어질 수 있다.

상대방을 비난하는 대화 보다는 그 사람의 사고 과정과 전략을 이해하고 조언을 하는 사람이 되라.

더 나아가 행동을 유도하는 대화를 하라.

실수를 어떻게 막을지 생각하기 보단 실수를 빠르게 처리하는 방법을 생각하라.

애자일

1. 앞에서 말한 "함께"와 "자라기" 가 애자일의 핵심

애자일은 불확실성이 높은 프로젝트를 위해 생겨난 개념이다.

"자라기" 에서의 짧은 주기의 피드백을 통해 방향성을 수시로 재조정하고 필요한것을 학습하며 점진적으로 발전시킨다.

"함께" 에서의 협력과 커뮤니케이션을 통해 안좋은 일이 일어날 확률을 줄이고 좋은 일이 일어날 확률을 올린다.

2. 고객에게 가치를 전하라.

여기서 고객이란 돈주고 프로젝트를 맡긴 사람 뿐 아닌 프로젝트와 관련된 모든 이해 관계자를 말한다.

고객에게 가치를 전하면 신뢰가 쌓이면서 고객의 협력을 얻기 쉬워진다.

이로써 고객의 의사소통이 명확하고 구체화 되고 고객이 원하는 결과물에 더 가까워질 수 있다.

3. 두려워도 중요하다면 미루지 말고 시도해라.

결국 사람과의 소통이 가장 어렵기 때문에 고객의 협력을 얻는 것을 주저할 수 있다.

코드 공유 또한 개발자를 설득해야 하므로 이 또한 꺼려질 수 있다.

하지만 소통의 중요성을 알고 있다면 두려워도 미루지 말고 시도해야한다.

4. 누구나 애자일 코치가 될 수 있다.

애자일 코치는 팀장, 사장, 팀원 중 그 누구도 될 수 있다. 중요한건 애자일 코치가 되자고 결심하는 것이다.

"함께" 와 "자라기" 를 하고자 하는 사람이라면 누구든 애자일 코치가 될 수 있다.

5. 애자일을 애자일스럽게

애자일은 불확실성이 높은 프로젝트를 진행하기 위해 생겨난 개념이지 정해진 형식이 아니다.

변화에 대응하는 방식은 프로젝트마다 모두 다르다.

성공한 애자일 사례들로 나온 애자일 실천 방법들도 변화에 대응하는 한 때의 스냅샷이다.

느낀점

이 책을 보고 공부의 방향성과 커뮤니케이션 측면에서 깨달은 점이 많다.

나는 불확실성이 높은 프로그래밍이에서 학교에서 공부하던 방법대로 공부했던것 같다.

개발을 잘 하는 사람이 했던 순서대로 따라하다 보면 고수가 될거라고 생각했다.

아직도 옛날에 공부하던 습관을 버리지 못했나보다. 학자형 공부법을 쓰기에는 프로그래밍의 분야는 너무 넓다.

백년 천년 공부만 할게 아니라면 결국 개발을 진행하면서 생긴, 필요에 따른 공부가 필요하다.

또한 "함께" 파트를 읽으면서 저번에 했던 팀 프로젝트에 대해서도 생각해볼게 많다. 

최대한 신경쓴다고 했던 부분이지만 결국 커뮤니케이션과 협력 부분에서 미흡했던 부분이 많이 떠오른다.

커뮤니케이션과 협력의 가치를 생각하면서 함께 자랄 수 있는 방법 을 생각해야지.

더 나아가 나부터 애자일 코치가 되도록 스스로를 변화해나가야겠다.