개발 중 아래 설명하는 기본적인 원리들을 유념하면

더 좋은, 더 빠른, 더 강력한 코드를 작성할 수 있을것이라 이야기한다.

📌 Topic8 - 좋은 설계의 핵심

좋은 설계는 나쁜 설계보다 바꾸기 쉽다

🚀 ETC 원칙은 규칙이 아니라 가치

아무 실마리가 없을 경우!

1. 코드를 교체하기 쉽게 만들도록 노력하기
2. 직관을 발전시키는 기회!

📌 Topic9 - DRY(Don’t Repeat Yourself) 중복의 해악

지식은 고정적이지 않다.

유지보수

유지 보수란 버그를 고치고 기능을 개선하는 것이 아니다. 늘 유지보수 모드이다.

DRY 원칙 모든 지식은 시스템 내에서 단 한번만, 애매하지 않고, 권위 있게 표현되어야 한다.

DRY를 따르지 않으면

중복된 코드를 기억하느냐 마느냐의 문제가 아니라,

언제 잊어버릴가 하는 문제다.

DRY는 코드 밖에서도

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

• 기본적으로는 코드에서의 중복
  • 모든 코드 중복이 지식의 중복은 아니다!
• 문서화 중복
  • 코드 + 주석
• 데이터의 DRY 위반
• 표현상의 중복
  • 중복을 피할 수는 없지만 완화할 수 있다.
  • 내부 API에서 생기는 중복
    • API 명세가 가능한 도구를 이용
  • 외부 API에서 생기는 중복
    • OenAPI 형식으로 공개
  • 데이터 저장소와의 중복
    • 스키마 분석 기능
    • 외부 데이터를 고정된 구조 대신 키—값 데이터 구조에 밀어 넣는 것
  • 개발자 간의 중복
    • 의사소통 및 유대가 돈독한 팀을 만들 것
    • 일일 스크럼 스텐드업 미팅
    • 공통 소통 공간 만들기
    • 프로젝트 사서로 임명
    • 일상적인 코드 리뷰

📌 Topic10 - 직교성(Orthogonality)

설계와 빌드, 테스트, 확장이 쉬운 시스템을 만드는데 매우 중요한 개념

직교성 이란

결합도 줄이기를 의미한다.

하나를 바꾸더라도 나머지에 어떠한 영향도 주지 않으면 서로 직교한다고 표현한다.

비-직교적인 시스템

모든 변경 하나하나가 나머지 모든 입력에 영향을 주는 시스템.

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

직교성의 장점

독립된 컴포넌트는 외부 인터페이스를 바꾸지 않는 한 전체 시스템으로 퍼져가는 문제를 일으키지 않는다.

• 생산성 향상
  • 테스트 시간의 축소
  • 재사용 촉진
  • 각기 다른 컴포넌트의 장점을 결합하여 더 많은 기능을 얻을 수 있음.
• 리스크 감소
  • 잘못 작성된 코드를 도려내고 새로 작성하기 편함
  • 수정한 코드의 문제가 생기더라도 문제점이 생긴 부분은 수정한 부분 한곳으로 한정될 것.
  • 테스트 설계 및 실행이 쉬워 테스트 작성에 용이하다.
  • 특정 비지니스 로직에 덜 종속 될 수 있다.

설계

계층 구조

추상화

유연성

• 설계가 직교적인지 확인하는 방법 Q: 특정 기능에 대한 요구 사항을 대폭 변경해야 하는 경우 몇 개의 모듈이 영향을 받는가

자신의 힘으로 제어할 수 없는 속성에 의존하지 말라

툴킷과 라이브러리

외부 라이브러리나 툴킷을 도입할 때 직교성을 해치지 않는지 고민하고 현명하게 선택하라.

코딩

• 코드의 결합도를 줄여라
  • 불필요한 것은 다른 모듈에 보여주지 않는 부끄럼쟁이 코드를 작성하라.
• 전역 데이터를 피하라
  • 전역 데이터를 공유하는 다른 컴포넌트와 묶이면 불필요한 결합을 만들 수 있다
• 유사한 함수를 피하라

비판적으로 보는 습관을 길러 기회가 있을 때마다 코드의 구조와 직교성을 개선하기 위해 노력하라.

테스트

직교적으로 설계한 시스템은 테스트하기 쉽다.

문서화

정말 직교적인 문서라면 내용 변화 없이 모양새를 완전히 바꿀 수 있다.

내용의 이동이나 수정 없이 꾸밀수 있다는 이야기.

직교적으로 살아가기

📌 Topic11 - 가역성(Reversibility)

알고 있는 해결책은 언젠가는 변할 것이다.

가역성

결정은 돌에 새겨진 것이 아니라 바닷가의 모래 위에 쓰인 글씨다.

최종 결정이란 없다.

유연한 아키텍쳐

아키텍쳐가 자주 바뀌는 변덕스러운 환경에서는 계획을 세울 수 없다.

할 수 있는 방법은 바꾸기 쉽게 만드는 것이다.

유형을 좇지 말라.

📌 Topic12 - 예광탄

일반 탄환들 사이에 일정한 간격으로 끼워있는 예광탄처럼

우리 프로젝트에서도 실제 조건하에서 즉각적인 피드백을 받아야 한다.

어둠 속에서 빛을 내는 코드

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

최종 시스템까지의 일부분까지 빨리, 눈에 보이게, 반복적으로 도달할 무언가(예광탄)를 찾아야한다.

• 시스템을 정의하는 중요한 요구 사항을 찾아라.
• 의문이 드는 부분이나 가장 위험이 커 보이는 곳을 찾아라.
• 위험 부분이 가장 커 보이는 코드를 가장 먼저 작성하도록 우선순위를 정하라.

예광탄 코드의 장점

• 사용자가 뭔가 작동하는 것을 일찍부터 보게 된다.
• 개발자가 들어가서 일할 수 있는 구조를 얻는다
• 통합 작업을 수행할 기반이 생긴다
• 보여줄 것이 생긴다
• 진행 상황에 대해 더 정확하게 감을 잡을 수 있다.

예광탄이 언제나 목표물을 맞히는 것은 아니다

예광탄이 맞히고 있는게 ‘무엇인지’ 보여주는 것이지 ‘목표물’이라는 보장은 없다.

핵심은 목표물에 맞을 때까지 조준을 옮기는 것 이다.

예광탄 코드 대 프로토타이핑

• 프로토 타입
  • 목표: 최종 시스템의 어떤 특정한 측면을 탐사해 보는 것
  • 어떤 경우든 결정을 내리고 나면 다시 처음부터 최종 목표 환경에서 코드를 작성한다.
• 예광탄 코드
  • 목표: 애플리케이션 전체적으로 구현체를 구현하며, 사용자에게 상호 작용을 보여주는 것, 개발자에게는 전체적인 아키텍쳐 골격을 제시하는 것
• 차이점
  • 프로토타입: 나중에 버리는 코드를 만드는 것
  • 예광탄 코드: 기능은 별로 없지만 완결된 코드이며 최종 시스템 골격 중 일부가 되는 것.

📌 Topic13 - 프로토타입과 포스트잇

프로토 타입의 목적은 위험 요소를 분석하고 노출시킨 후, 이를 아주 저렴한 비용으로 바로잡을 기회를 마련하는 것

세부 사항을 포기할 수 없는 환경이라면 프로토 타입보다는 예광탄 방식의 개발이 더 적절할 것.

프로토 타이핑 대상

• 위험을 수반하는 모든 것
  • 이전에 해 본 적이 없는 것
  • 최종 시스템에 매우 중요한 것
  • 증명이 되지 않은 것
  • 실험적인 것
  • 의심이 가는 것
  • 마음이 편하지 않은 것

프로토 타이핑은 학습 경험이며 해당 가치는 코드에 있는게 아니라 프로토 타이핑을 통해 배우는 교훈에 있다.

프로토 타이핑으로 학습하라

프로토 타입을 어떻게 사용할 것인가

• 무시해도 좋은 세부 사항
  • 정확성
  • 완전성
  • 안정성
  • 스타일

아키텍쳐 프로토 타이핑

프로토 타이핑의 목적은 전체 시스템이 어떻게 동작할 지 감을 잡는 것

코드 이외에 간단하게 포스트잇이나 화이트보드로 설계해도 좋다.

프로토타입 코드를 사용하지 않도록 하려면

코드가 폐기될 것이고, 불완전하며, 완성될 수 없다는 사실을 분명히 사람들에게 알려야 한다.

작업환경이나 문화에서 프로토타입 코드의 목적이 잘못 해석될 가능성이 크다면 예광탄 접근 방식이 나을것

📌 Topic14 - 도메인 언어

문제 도메인에 가깝게 프로그래밍하라.

내부 언어

실행시키는 코드 내부로 들어가는 코드

도메인 언어(내부 언어)가 원래 코드의 어휘를 진짜로 확장시키는 것

외부 언어

별도의 코드가 외부 언어를 읽어 들여서 사용할 수 있는 형태로 바꾸는 것.

내부 - 외부 언어의 장단점

• 내부 언어
  • 장점
    • 호스트 언어의 기능을 쓸 수 있음
    • 도메인 언어를 추가 리소스 없이 강력하게 만들 수 있는 점
  • 단점
    • 호스트 언어의 문법과 의미론을 따라야만 한다.
    • 원하는 언어와 구현할 수 있는 언어 사이에서 어느 정도 타엽해야 함
    • 궁극적으로 어떤 형태로 만들더라도 호스트 언어의 문법을 벗어날 수 없음
• 외부 언어
  • 장점
    • 내부 언어의 단점이 없다

결론

• 절약하는 것보다 더 많은 시간을 쏟지 말라.
• 기본적으로 가능하다면 YAML, JSON, CSV와 같은 널리 통용되는 언어를 사용하라.
• 그게 아니라면 내부 언어를 고려하라
• 외부 언어는 애플리케이션의 사용자가 직접 도메인 언어로 코드를 작성하는 경우에만 추천한다.

📌 Topic15 - 추정

추정으로 놀람을 피하라

얼마나 정확해야 충분히 정확한가

답변이 사용될 상황이 무엇인지 생각해보라

• 매우 높은 정확도의 답을 요구하는가.
• 단순히 큰 그림만을 요구하는가.

전달하려는 정확도를 고려하여 답변의 단위를 선택하라.

추정치는 어디에서 나오는가

경험자에게 조언을 구하라

모델 작성에 너무 시간을 많이 쏟기 전에 비슷한 상황에 처했던 경험자에게 조언을 구한다면

그 경험을 바탕으로 성공적인 추정치를 낼 수 있을것

• 무엇을 묻고 있는지 이해하라
  • 정확도뿐 아니라 도메인에 존재하는 조건에 대해서도 알아야한다.
  • 추정하기 전에 미리 어떤 조건이 있을지 생각하는 습관을 길러라.
• 시스템의 모델을 만들어라
  • 기본적인 것만 갖춘 개략적인 모델을 만들어보라.
    • 전체 시스템에 사용할 발판이 되고, 어떻게 구현해야 할지에 대한 배경이 될것이다.
• 모델을 컴포넌트로 나눠라
  • 각 컴포넌트가 어떻게 전체 모델에 기여하는지 나타내는 매개 변수를 찾아라.
• 각 매개 변수에 값을 할당하라
  • 약간의 오차가 발생할 수 있다.
    • 결과에 가장 큰 영향을 미치는 매개 변수를 찾아 해당 매개 변수의 값을 최대한 정확하게 산출하라
  • 매개 변수를 계산할 때는 근거가 있어야 한다.
• 답을 계산하라
  • 주요 매개 변수들의 값을 변경시켜 가면서 여러 번 계산해 모델에 가장 잘 들어맞는지 찾아라.
• 여러분의 추정 실력을 기록하라
  • 이전의 추정치를 기록하고 실제 결과와 비교하여 얼마나 정확했는지 평가하라.
  • 추정치가 틀렸더라면 원인을 찾아 회고하라

프로젝트 일정 추적하기

• 미사일에 페인트 칠하기

  • 낙관적 추정치, 가장 가능성이 높은 추정치, 비관적 추정치를 계산하여 전체 프로젝트 예상 최소 ~ 최대 소요 시간을 계산하는 방법

• 코끼리 먹기

  코드와 함께 일정도 반복하며 조정하라

  • 초기 기능의 구현과 테스트를 마친 후, 이를 첫 번째 반복주기로 삼아라
  • 이 후 무엇을 할지에 대한 추측을 다듬어라
  • 각 반복 주기가 끝날 때마다 추측을 다듬다보면 일정에 대한 확신이 들것이다.

• 더 정확한 일정을 추정하는 것을 각 반복 주기의 일부로 삼았을 때, 구성원이 추정할 수 있는 가장 정확한 일정을 경영진에게 건넬 수 있을 것.

이 책은 더 효과적이고 생산성 높은 프로그래머가 되고 싶은 사람들을 위해 썼다고 말한다.

무엇이 실용주의 프로그래머를 만드는가.

실용주의 프로그래머들의 공유하는 특징

• 얼리 어댑터 또는 새로운 것에 빨리 적응하는 사람
• 호기심 많은 사람
• 비판적인 사고의 소유자
• 현실주의자
• 다방면에 능숙한 사람

실용주의 프로그래머들의 공통적인 특징

• 자신의 기예에 관심을 갖는 사람
  • 소프트웨어 개발을 잘하는 것에 관심이 없다면, 이 일을 하는 의미가 없다고 생각함.
• 자기 일에 대해 생각하는 사람
  • 기계적으로 일하지 않고, 동시에 생각하며, 자기 일을 비평한다.

큰 팀에서의 실용주의 프로그래머

어떤 사람은

큰 팀이나 복잡한 프로젝트에서 개인이 개성을 발휘하면 기본적인 프로그래밍 규율이 무너질 것 이다.

라고 표현하지만, 글쓴이는 반대의 입장을 이야기 한다.

프로젝트 전체 구조 속에 각자의 개성과 장인 정신을 발휘한다면 멋진 대성당이 완성될 것이라고.

끊임없는 과정

매일같이 기술을 다듬고, 새로운 기술 목록에 새로운 기술들을 추가해 관리해야한다.

1장 - 실용주의 철학

📌 Topic1 - 당신의 인생이다

모두에게 스스로 행동을 직접 결정할 수 있는 힘이 있다고 말한다.

• 업무 환경이 엉망인가?
• 하는 일이 지루한가?

문제를 고치기 위해 노력하기를 당부하며

‘당신은 당신의 조직을 바꾸거나, 당신의 조직을 바꿀 수 있다’ - 마틴 파울러

위 말을 인용하며 공부하고, 주도적으로 행동하기를 권장하고 있다.

📌 Topic2 - 고양이가 내 소스 코드를 삼켰어요

1. 팀 내 신뢰

신뢰에 바탕을 둔 건강한 환경에서는 팀원들과 안전하게 의견을 주고 받을수 있다고 말한다.

2. 책임지기

어설픈 변명 말고 대안을 제시하라.

다른 사람 혹은 다른 무언가를 비난하거나 변명을 만들어 내지 말라고 이야기한다.

모든 문제를 외부 업체나 프로그래밍 언어, 경영진, 동료 때문이라고 떠넘기지 말고,

이들 모두가 한몫씩 했을 수 있겠지만 변명이 아니라, 해결책을 찾아내야 한다.

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

도움이 필요한 부분이 있다면 부탁을 어려워 하지 말고 도움이 필요하다는 사실을 인정하고 구하라.

📌 Topic3 - 소프트웨어 엔트로피

엔트로피는 시스템 내의 ‘무질서’한 정도를 가르키는 물리학 용어

이를 우리는 기술부채라고 부르기도 한다.

깨진 창문

심리학자들은 절망감이 전염된다는 연구 발표를 했다.

건물의 깨진 창문 한개가 새로운 깨진 창문을 야기하고, 사람들이 쓰래기를 함부로 버리기시작하는 계기가 된다.

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

나쁜 설계, 잘못된 결정, 형편없는 코드 등 모두를 깨진창문이라 비유한다.

관리 되고 있는 범위임을 명확하게 인지할 수 있도록 코드를 작성하라고 말한다.

우선, 망가트리지 말라.

무슨일이 있더라도 깨진 창문은 하나로도 충분하다. 부가적인 피해를 일으키지 말라.

깨진 창문 한개는 내리막길로 가는 첫걸음이다.

📌 Topic4 - 돌멩이 수프와 삶은 개구리

변화의 촉매가 되라.

조그마한 것으로 시작할 수 있도록 유도하라.

그 조그마한 것으로 사람들을 설득하고, 더 많은 것을 만들어낼 기회를 마련하라.

큰 그림을 기억하라

당장 하고 있는 일에만 정신을 쏟지 말고, 주변에 무슨 일이 벌어지는지 늘 살펴보고 주의를 가져라.

📌 Topic5 - 적당히 괜찮은 소프트웨어

사용자나 미래의 유지 보수 담당자 혹은 자기 자신이 마음의 평화를 유지하기에 적당한 소프트웨어를 만들어라.

주의 할것!!!!

→ ‘적당히 괜찮은’은 너덜너덜하거나 형편없는 코드를 의미하지 않는다.

기본적인 부분은 만족하며, 적당히 괜찮게 사용자의 요구를 충족하는 것을 뜻한다.

타협 과정에 사용자를 참여시켜라

많은 사용자는 멋지고 휘황찬란한 버전을 위해 1년을 기다리기보다 차라리 오늘 당장 좀 불편한 소프트 웨어를 사용하고 싶어한다.

멈춰야 할 때를 알라

완펵을 기하느라 프로그램을 과도하게 장식하거나 지나치게 다듬느라 망치지 말라.

완벽하지 않더라도 괜찮다. 완벽이란 불가능하다.

📌 Topic2 - 지식 포트폴리오

스스로 무엇이든 한 번 해본 다음, 습관을 들여 따라 할 절차를 만들고, 뇌에 각인될 때까지 반복하라.

포트폴리오 만들기

• 주기적인 투자
  • 방해받지 않을 수 있는 시간과 장소를 마련하여 계획을 마련하라.
• 다각화
  • 컴퓨터 분야의 지식은 빠르게 변화한다.
  • 더 많은 기술에 익숙하다면 변화에 더 잘 적을할 수 있다.
  • 기술외의 분야도 포함하여 필요한 다른 역량도 잊지 말고 투자하라.
• 리스크 관리
  • 다양한 스팩트럼을 관리하라.
  • 기술 달걀을 모두 한바구니에 담지 말라.
• 싸게 사서 비싸게 팔기
  • 새롭게 떠오르는 기술에 관심을 기울여라.
• 검토 및 재조정
  • 지난달에 인기있었던 기술이 한 달 만에 인기없는 기술이 되어있을 수 있다.

목표

• 매년 새로운 언어를 최소 하나는 배워라
  • 몇 가지 서로 다른 접근법을 알면 사고를 확장하고 판에 박힌 사고에 갇히는 걸 예방할 수 있다.
• 기술 서적을 한 달에 한 권씩 읽어라.
  • 깊이 있는 지식을 원한다면 긴 글 형식의 책을 읽어라.
• 기술 서적이 아닌 책도 읽어라
  • 사람을 대할 때는 완전히 다른 종류의 기술이 필요하다.
• 수업을 들어라
• 지역 사용자 단체나 모임에 참여하라
• 다른 환경에서 실험해 보라
• 요즘 흐름을 놓치지 말라

학습의 기회

늘 읽을 거리를 준비하고, 새로운 지식을 탐하라.

어떤 질문이던 스스로 답을 찾지 못한다면 찾아줄 누군가를 찾아라.

비판적 사고

상업주의의 힘을 절대 과소평가하지 말라.

검색 엔진의 첫머리 결과, 서점에서 특별하게 취급하는 책 등 그것은 정확한 - 인기있는 무엇이 아닐 수 있다.

• 왜냐고 다섯번 묻기
• 누구에게 이익이 되는지 생각하기
• 어떤 맥락인지 파악해보기.
• 언제 혹은 어디서 효과가 있을지 생각해보기
• 왜 이것이 문제인지 되짚어보기

📌 Topic7 - 소통하라

효과적인 소통 없이는 아무리 훌륭한 아이디어라도 고립된다.

1. 청중을 알라

그들이 무엇을 궁금해하는지, 좋아하는지 이해하고 소통하라.

2. 말하고 싶은게 무엇인지 알라

무엇을 말할지 미리 계획하고 개요를 작성하라.

그리고 계속 다듬으며 어떻게 사람들에게 내 이야기를 잘 표현할 수 있을지 생각하라.

3. 때를 골라라

말하는 내용이 중요한것도 사실이지만, 듣는 사람이 필요한 시점도 적절하게 하는것이 중요하다.

4. 스타일을 골라라

듣는이가 어떤 스타일인지 어울리는 표현으로 전달하라.

5. 멋져 보이게 하라

기본적인 맞춤법을 확인하고, 눈부신 출력물을 만들어 전달하라.

문서의 내용도 중요하지만 어떻게 보이는지도 중요하다.

6. 청중을 참여시켜라

청중의 피드백으로 그들의 머릿속을 도용하라.

7. 경청하라

말하는 이가 다른 사람들의 말을 귀 기울여 듣지 않는다면 그들 역시 말하는 이의 말을 듣지 않을 것이다.

8. 응답하라

간단한 응답이 소통이 되고 그 소통이 더 효과적일수록 많은 영향력을 갖게 될 것이다.

9. 문서화

문서를 늘 손에 닿는 가까운 코드에 작성하라.

반복되고, 자주수정되는 문서화의 중복작업을 최소화 하라

코드 작성을 마무리한 후 오늘 ‘오늘 아주 잘했어!’라고 말할수 있는지.

많은 이가 찝찝한 기분으로 하루를 마무리한다.

조악한 품질은 피할 수 없다고, 빠른 속도를 위해 어쩔 수 없다고 느끼며, 너무 많은 이가 생산성과 품질이 반비례한다고 생각한다.

🧸 - 내 갈비뼈 한 120개는 부서진듯...

이 책에서는 훌륭하게 일하는 법, 일을 잘 해내는 법을 다루며

모든 프로그래머가 빠르게 일하고, 생선적이 되고, 매일 쓰는 코드에 자부심을 갖기 위해 알아야 하는 규율과 실천 방법을 설명한다.

장인 정신(Craftsmanship)

이 책에서는 비행기의 발전과, 프로그래밍의 발전을 비교하며 장인 정신에 대해 설명하고 있다.

두 기술의 진보는 갑작스러운 100~200년내에 진행되었다.

비행기의 발전

비행기의 발전은 부력의 발견, 엔진의 발명 등 여러 기술의 진보에 따라 비행기의 성능은 좋아졌다.

그럼에도 수 많은 사람이 비행기를 조종하며 목숨을 잃었고,

비행 기술의 발전으로 점차 안전하게 비행기를 만들고 띄우는 방법에 대해 배우게 되었다.

프로그래밍의 발전

인류는 숫자를 세기 위해 손가락, 나뭇가지 등을 사용했고, 기억 장치와 연산 장치의 발명을 하기 시작했다.

여러 개념들이 정리되고, 발전되어가며 새로운 기술을 사용한 기계장치들이 발명되었다.

지금보다 50년 전인 1970년대에 프로그래밍을 학습하고, 사용하는 사람들은 매우 적은수였다.

2000년대에 와서는 어마어마한 하드웨어의 발전이 있었고, 많은 프로그래머들이 양산되어 ‘프로그래머’로써 일하고 있다.

비교해보면

이 책에서는 2가지의 분야를 비교하며 물어본다.

비행 기술의 장인처럼, 항공 조종사들만큼 자기가 사용하는 기술을 깊이 이해하는 프로그래머를 양성했는지.

프로그래밍에 장인은 필요한것은 분명하나 현재 우리에게 장인은 있는것인지.

1부 - 규율(The Disciplines)

규율(規律) - 명사

規 - 법 규 / 律 - 규칙 률

질서를 유지하기 위하여 정해 놓은, 행위의 준칙이 되는 본보기.

책에서는 일련의 규칙들을 규율이라 표현하며, 두가지로 구성된다고 말한다.

본질적인 규칙

규율의 권위를 부여하는 규칙

애초에 규율이 존재하는 이유에 해당함

임의적인 규칙

형태와 실체를 부여하는 규칙

임의적인 부분 없이는 규율이 존재할 수 없음.

책에서는…

소프트웨어 장인 정신의 5가지 규율을 탐구한다.

읽다보면 거부감이 드는 규율이 있을것이다.

→ 규율의 본질적인 요소 때문인지, 임의적인 요소 때문인지 판단해 보길

→ 임의적인 요소 때문에 잘못된 판단을 하지 않도록 주의

→ 각 규율의 본질적인 요소를 보면 임의적인 형태는 중요한 것이 아니게 됨

익스트림 프로그래밍

익스트림 프로그래밍의 실천 방법을 보여주는 그림.

책에서 다루는 주제

1. 테스트 주도 개발(Test-Driven Development - TDD)
2. 리펙터링(Refactoring)
3. 단순한 설계(Simple Design)
4. 짝 프로그래밍(Pairing)
5. 인수 테스트(Acceptance Test)
   • 익스트림 프로그래밍의 비지니스 실천 방법 중 가장 기술적이고 엔지니어링에 초점을 둔 실천 방법.

위 5가지의 실천 방법이 소프트웨어 장인 정신의 기본 규율에 속한다고 말한다.

1. 테스트 주도 개발(TDD)

일 하는 방식을 초단위로 통제하는 규율.

핵심 규율이며, 테스트 주도 개발 없이 다른 규율은 지키기 어렵거나 지켜 봐야 의미가 없다.

핵심

• 작은 순환 주기를 따르고 테스트를 우선한다는 것.
• 모든 일에서 테스트가 우선
• 테스트를 먼저 쓰고 테스트를 먼저 정리
• 모든 활동에서 테스트가 먼저
• 모든 활동을 가장 작은 순환 주기로 쪼개는 것.

테스트 주도 개발의 목표는 전적으로 신뢰하는 테스트 묶음을 만드는 것.

• 테스트 묶음을 통과한 코드는 마음 편히 배포할 수 있어야 함.

테스트 주도 개발은 익히기 어렵지만 헤아릴 수 없는 가치가 있는 정교하고 복잡한 기술.

2. 리펙터링(Refactoring)

깨끗한 코드를 쓰도록 하는 규율.

테스트 주도 개발이 없다면 리펙터링은 어렵가나 아예 불가능할 수도 있음.

• 깨끗한 코드를 쓰는 것도 마찬가지로 어렵거나 불가능함.

리펙터링은 동작을 바꾸지 않으면서 형편없는 구조를 가진 코드를 더 나은 구조의 코드로 고치는 규율.

동작을 바꾸지 않는다는 점이 중요!!!

동작을 바꾸지 않는다는 게 보장되면 구조를 개선해도 ‘안전’하다고 보장할 수 있다.

개선사항이 동작에 영향을 주지 않는다고 어떻게 보장할 수 있나

→ 테스트 주도 개발로 만든 테스트가 있다면 가능.

리펙터링은 복잡한 규율임.

→ 형편없는 구조를 만드는 방법이 많다 보니 깨끗한 코드로 바꾸는 전략도 많은 탓.

3. 단순한 설계(Simple Design)

프로그램이나 시스템, 어플리케이션의 더 큰 구조에 잘 들어맞도록 단순하고 아주 작은 단위로 설계하는 규율

테스트 주도 개발이나 리펙터링과는 다르게 정의가 느슨한 규율.

→ 판단과 경험에 의존함.

단순한 설계를 잘할 수 있다면 시니어로써 한 단계 올라섰다는 첫 신호가 될 것.

4. 짝 프로그래밍(Pairing)

책에서는 공동 프로그래밍이라 표현한다.

소프트웨어 팀에서 함께 일하는 규율

짝 프로그래밍, 몹 프로그래밍, 코드 리뷰, 브레인 스토밍 같은 하부 규율이 포함되는 규율임.

부서에 상관없이 모든 팀원이 참여하여 지식을 공유하고, 일관성을 보장하며, 팀을 한 몸으로 작동하도록 묶는 주요 수단이다.

다른 규율에 비해 공동 프로그래밍은 제일 기술적이지도 않고 지시 사항도 제일 적다.

그럼에도 가장 중요할 수 있다.

→ 효과적인 팀을 꾸리는 일은 흔히 경험할 수 없고 소중한 일이다.

5. 인수 테스트(Acceptance Test)

소프트웨어 개발 팀을 사업과 묶어 주는 규율

시스템이 동작해야 하는 방식을 사업 목표로 명시함.

사업 부서는 인수 테스트를 쓰고 읽고 통과하는 것을 확인함으로써 소프트웨어가 무엇을 하는지,

그리고 사업 부서에 필요한 일을 하는지 알 수 있다.

추가 공부 (책에 언급은 되었으나, 설명되어있지 않은 내용.)

이 글은 36기 세션 중 하나인 34기가 36기에게를 준비하며 쓴 대본을 정리한 내용입니다. 욕심넘치게 열심히 짤도 준비하고,, 농담도 준비하고 했는데,, 정작 발표에서 발발발발 떨어 참... 아쉬운 기억이다.

7월 27일 발표

안녕하세요 저는 34기 프론트 엔드 개발자 3살 서한샘입니다!

다들 저녁 늦게까지 코드카타 하랴, 인스타그램 만들랴 고생이 많으셔요 ㅎㅎ

내일 목요일이니까 맥주한잔 할 생각으로 오늘 잘 버텨봐요!!!!

본격적으로 발표 시작해볼게요!

저는 이번 발표에서 크게 3가지 주제에 대해서 이야기 할 계획이에요

왜 ( 개발자의 길을 걷는가 )

무엇을 ( 궁금해 해야 하는것인가 )

어떻게 ( 시간을 보낼 것 인가 )

왜 부터 이야기를 시작해보겠습니다.

개발자의 길을 걷는 이유에 대해

궁금증. 호기심.시작

→ 개발자(開發者) - 개척하여 유용하게 만드는 사람

개발자라는 단어의 뜻을 생각해본적이 있는가.

개발이라는 사전 정의를 아시나요

개발자는 무엇일까요!

대학교에서 체크무늬 입고다니는 공대생, 회사에 자주 출몰하는 노숙인의 정체 등등..

오해아닌 오해로 가득찬 개발자들이에요 ㅎㅎ..

개발이란 개척하며 유용하게 만드는 것.

개발자란 개척하며 유용하게 만드는 사람을 말해요.

복잡하게 말하면 어떠한 사건이나 현상에 대해 논리적으로 생각하며,

이를 수식화 하는 사람… 어려운말이죠 ㅋㅋㅋㅋ

→ 왜 저사람은 저렇게 비효율적으로 일을 하는것인가

아니시에이팅 개발의 시작.

개발자의 의문은 모두가 공감 할 그런 내용에서 시작됩니다.

저걸 왜 저렇게 하지? 아 그거 그렇게 하는거 아닌데… 아니!!!!

사람보다 월등히 빠른 멍청한 컴퓨터에 대해 조금만 생각하고 조금만 공부하면 삶이 윤택해질텐데

조금 더 공부하고, 깨닫고, 생각하다보면 우린 모두 이런 생각에 빠지게 됩니다.

→ 저 사람이 필요한가.

저 사람은 도대체 왜 있는거지?

저 사람이 손수 작성하는 저 시간을 없앨 수 있지 않을까?

열사람이 할 일을 한 사람이 할 수 있게 능률을 높일 수 있지 않을까?

이러한 생각이 같이 일하는 옆사람에게 향하게 된다면 이런식으로도 변할 수 있어요.

같은 시간을 주고 같은 돈 혹은 나보다 더~ 많은 것을 누리며 사는 사람이 이런것도 못해..?

와 같은 생각을 가지게되는 불신의 시대를 살게 될 거에요.

앞으로의 시대는

→ 무서운 시대의 시작.

우리는 지독하리만큼 경쟁한 시간을 보냈지만 또 다시 시험대에 오르게 될 거에요.

뒤쳐지면 사라지는 직업들의 틈새에 내가 있을 수 있어요.

눈 깜빡하면 사라지는 그런 환경에 말이에요

겁만 준거같네요 하하

개발자. 라는 단어가 가지는 의미

→ 모든 직군( 법, 의료, 금융 등 )을 포괄하여 사람을 줄이는 사람

→ 사람이 있고 개발이 있다.

개발자 라는 단어가 가지는 의미에 대해 다시한번 말씀드리고 다음 주제로 넘어갈거에요.

개발자란 모든 직군 .. 법, 금융, 의료, 생활 등 모든 방면을 포괄해서 결론적으로 사람을 줄이는 직업이에요.

이런 시대에 우리가 가져야 할 생각은

사람이 있고 개발이 있다는 거에요.

우리가 이곳 부트캠프에 오게된 계기 또한 그래야 한다고 생각해요.

직업이 사라지고, 경쟁하고, 시험하고… 듣기만해도 너무 피곤하잖아요.

→ 개발 직군의 특이점

• 커뮤니티의 확장

제가 강조하고, 드리고 싶은 말은 이거에요. 우리.

제가 말한 직업적인 위기, 경쟁, 시험...

이 모든부분을 잠시 내려놓아보는거에요.

왜 이곳 부트캠프에 왔는가.

내가 얻고자 하는것이 무엇인가.

이것에 포커스를 맞추고, 같이 걸어가는 사람들이 되기를 바래요.

혼자 걷기에 너무 지치는 길이에요.

저는 커뮤니티를 얻기위해 이곳에 왔어요.

혼자 일하고, 혼자 공부하고, 혼자 노력했어요.

분명한 한계가 보이더라구요.

그래서 드리는 말씀이에요.

여러분들도 당장에 아침 인사 안녕하세요!! 건내는 인사말로 시작해봐요,

머리 쥐어싸매고있으면,

내가 모르더라도 무슨일이세요!!

질문한번… 이 한마디가 어떠한 사람에게는 큰 위로가 될거에요.

위코드에서 왜 이곳에 내가 왔는가

정체성을 찾고 즐거운 여행길에 같이 갈 수 있는 사람이.. 개발자가 되어보아여

무엇을 궁금해 해야 하는것인지.

다음으로 말씀드릴 것은 그럼 우리 개발자들은 무엇을 궁금해 해야 하는가!

localhost와 port를 아시나요

→ npm start를 실행 했을 때 크롬 브라우저의 주소를 기억하시나요

사소한 궁금증에서 개발은 시작됩니다.

여러분들 혹시 npm start 라는 커맨드를 실행시켜보셨는지 모르겠네요..

어떤 사이트에 접속하려면 브라우저 상단에 주소 입력하시죠??

naver.com 같은 주소 말이에요

프론트던 백이던 상관없이 보게될 localhost라는 부분이 있어요

그리고 나오게되는 포트 3000 혹은 8000…

왜 localhost인거지??

왜 프론트엔드는 3000인데 백엔드는 8000이지?

라는 의문을 가져봐요.

localhost를 깊게 깊게 파서 왜 localhost라고 쓰는지 사전을 찾고 나무위키찾으라는 소리가 아니에요.

논문을 쓰라는 의미도 더더욱이 아니구요.

정말 사소하게 넘기는 부분에 의문을 가져봐요.

3000번인데… 3001로 쓸수는 없을까…?

오만사천삼백이십일번 포트를 쓸수는 없는건가?

전공자들조차 사소하게 지나치는 이런 기초적인 부분을 궁금해 하셔야 해요.

호기심, 탐구욕이 우리를 발전시켜요.

끊임없이 조그마한것이라도 넘기지 말고 궁금해 해봐요. 그게 무엇이 되었든 얻는게 있을거에요.

단! 너무 깊게 알려하지마세요. 주의점이에요.

우리는 개발자에요.

연구하고, 학문하고, 발견하고… 그건 나중에 해도 상관없고

도라에몽 같은 학자들이 할거에요.

우린 가져다 사용하는 진구가 되면 됩니다.

T자! 항상 기억하세요!

넓은 지식을 알게 되면

내가 지금 당장에 특정 지식을 파지 않아도 알게되는 순간이 올거에요

그리고 어느정도 관심이 생기는 분야가 생긴다면 그곳에 집중하세요.

모든 지식을 아는 개발자는 없어요.

욕심을 버리고 욕망을 가지세요. 꿈꾸시면 됩니다! 꾸는 꿈을 현실로 만드세요.

Domain을 아시나요

→ 여러분이 꿈꾸는 무대는 어디인가

전문적인 지식을 궁금해해야 한다

그럼에 말씀드리는 말이에요

도메인을 아시나요. 여러분이 꿈꾸는 무대는 어디인가요?

나는 개발만 잘 할거야, 개발만 하면 알아서 잘 되겠지.

라는 생각은 욕심이에요.

내가 근무하는

혹은 근무하고자 하는 생태계를 알아야 살아남을수 있어요.

적응하고 근무하는 곳의 전문 지식을 궁금해해야 해요

그곳에서 내가 무엇을 이루고 싶은지

무엇을 할 수 있는지 찾으세요.

개발은… 코드는 도구에요

그 무엇보다 사람이 우선시 되어야 해요.

내가 만드는 프로그램이 우리 사는 이 공간을 어떻게 바꾸고 싶은지 생각해보세요.

무엇을 편리하게 만들 수 있는지 생각해보세요.

그러기 위해서 내가 지금 만드는 것이 무엇인지 정확하게 배경을 아는 개발자가 되시기를 바래요.

당신의 꿈을 아시나요

→ 당신의 목표는 어디인가요

→ 지금의 MVP는 무엇인가요

다음은 여러분은 꿈이 있나요?

대통령, 우주인, 외계인, 공룡이 되고싶었던 3살의 우리는

어느덧 성숙해지고 나이들었어요.

다시한번 곰곰히 생각해보세요

여러분은 꿈이 있나요?

지금의 여러분의 목표가 어디에 있나요?

지금 코드한줄 두줄치면서 이게 맞나 하는 고민보다

더욱더 근본적인 질문이에요.

더욱더 중요해요.

방향잃은 배는 정처없이 떠돌다가 침몰해요.

목표 잃은 개발자는 무기력해지고 나태해지고.. 한없이 약해져요..

당장의 목표를 잡기는 힘들 수 있어요.

꿈을 찾기에 늦은 나이이다? 이건 변명이구요

차근차근 해봐요

MVP(Minimum Viable Product) 최소 기능 제품이라는 뜻이에요.

자동차를 만들어야 해!

라고한다면 보통의 사람들은

바퀴를 만들어요, 차대를만들고, 부속품을 만들겠죠.

하지만 완성된 자동차의 모양은 우리가 생각하지 못한 괴물이 되어있을 수 있어요.

저는 자동차를 만들고자 한다면

보드를 먼저 만들어볼거에요.

다음에는 핸들이 달린 퀵보드를 만들고

조금더 편안한 기능을 넣어 자전거

그다음 오토바이

그리고 마지막으로 자동차를 만들거에요.

MVP는 이렇게 제품을 만드는 상황에 자주 사용되는 단어에요.

하지만 전 목표에 자주 대입해 많이 말하고 다녀요.

제가 이번 주제에 대해 처음 던진 질문은

당신은 꿈이 있나요 ?

라는 질문이였습니다.

다시 질문드릴게요

여러분의 인생의 지금 MVP는 무엇인가요.

많은 고민을 해보시기 바래요.

어떻게 시간을 보낼것인지

마지막 주제에요

어떻게 시간을 보낼것인지.

시간 버리기로 소문난 사람이 있어요. 바로 그게 나에요

하릴없이 보낸 시간에 대한 후회

→ 버린시간에 대한 후회로 가득한 후회로만 가득한 날

정말 많은 시간을 버리고 허비하고 펑펑 썼어요.

All is well!! 모든게 잘 될거야

케세라세라!! 될대로 대라

제 인생단어였는데 잘되지 않았고 되고싶은대로 되지 못했어요.

계속된 자기비하,

자존감의 하락

매일 후회로 가득했어요.

공부안한 내가 잘못한거야.

그때 조금만 더 신경쓸껄.

후회로만 가득한 생각을 가지면 우울해지기 시작해요

우울증 그거 되게 무서운 병이더라구요.

후회가 아닌 회고

→ 지금의 데이터를 기반으로 예측이나 결정을 이끌어낸다.

그때 정말 좋은 인생 동료를 만났어요.

저에게 소중한 사람이라고 말해주는

저에게 정말 잘 살고있다고 한마디 해주는 사람을 만났어요.

그사람 남자에요 ㅎㅎ 전 여자 좋아해요 환장합니다. 오해하지 마세요 ㅎㅎ

무튼

다시 되돌아 봤어요.

내 인생 정~~말 보잘것 없는

모서리에 쌓인 먼지들만 골라골라

보석처럼 소중하게 다루면서 매일을 후회하던 저는

제가 잘 할수 있는것이 무엇인지 찾아보고있어요.

지금까지 내가 해왔던게 부질없는 날개짓이라고 생각하지 않고

비상하기위한 멋진 준비기간이라고 생각해요.

인공지능이 지금까지의 데이터를 기반으로 예측이나 결정을 이끌어내는 기술이에요.

인공지능이 아닌 지능을 가진 사람으로써도 분명히 할 수 있는 일이에요.

지금까지 보낸 시간을 회고해보세요.

하루하루를 되돌아보면서

다음 걸어갈 앞을 보세요.

분명히 멋진 날개짓을 하실수 있으실거에요

개발자 연봉 6000만원의 시작

→ 의사, 변호사, 그리고 개발자

의사, 변호사만큼 공부해라.

개발자 초봉 6000만원!!! 뭔가 엄청나게 개발자가되면 부자가 될 것만 같은 그런단어에요.

의사 변호사 등등이 초봉이 6000정도더라구요

우리도 다 원하잖아요 돈 많이 버는거!

간~단해요! 할수있어요!

그사람들만큼만 공부하세요. ㅎㅎ

말은 참 쉽져 ㅎㅎ

앞으로의 나. 그리고 우리

그래서 진짜 마지막으로 드리는 말씀이에요.

인생 누가 대신 살아주지 않아요.

원하기만 하지마세요.

나를 조금 더 돌아보세요.

내가 어떻게 살지 정하고

능동적으로 움직이세요.

의사 변호사 처럼 공부하는게

쉽지는 않을거에요 …

혼자하면…

같이 하세요.

옆에 둘러보시고 손에 손잡고 같이가세요!

동기사랑 나라사랑!

그렇다면 여러분도 분명히 해적왕이 될 수 있을거에요.

아니지 여러분도 분명히 빛나는 개발자가 될 수 있을거에요. 반짝반짝✨✨✨

긴 얘기 듣느라 고생하셨습니다

이상 34기 프론트앤드 개발자 3살 서한샘이였습니다.

감사합니다!