DEVOCEAN

안녕하세요 DEVOCEAN YOUNG 2기 구해줘의 나건주 입니다!

저희는 책읽기 컨텐츠로 클린 코더를 선택하게 되었습니다.

전문가 분들이 추천해주신 목록을 바탕으로 하나의 분야에 치중되지 않고 가장 기본적인 자세를 다루는 책을 선택하게 되었습니다!!

목차

1. 책 선정 이유

2. 책 컨텐츠

3. 이 책을 읽은 후기

책 선정 이유

클린 코드, 클린 아키텍처 등 다양한 클린으로 시작하는 책들이 있고 많은 사람들이 읽은 것으로 알고 있었습니다.

저희 팀원 모두가 코드를 잘 짜는 사람들은 무엇일까? 라는 고민을 하게 되었고 그렇기 때문에 클린 코더를 선택하게 되었습니다.

1장. 프로의 마음가짐

1장을 한 줄로 요약하자면, 프로페셔널리즘의 핵심은 “책임”이라는 것입니다.

1. 프로는 ‘무엇보다도 해를 끼치지 말라’는 마음가짐을 가집니다. 여기서 해를 끼치지 않는다는 것은 다음과 같습니다. :

   1. 오류에 책임을 져야한다는 것

   2. 오류가 명백하지 않더라도 돌아가는 상황을 밝히기

   3. 같은 오류를 반복하면 안 됨.

   4. QA가 아무런 오류를 찾지 못하도록 마음 가지기

   5. 제대로 돌아가는지 100% 테스트 커버리지를 ‘요구’

2. 프로는 ‘직업윤리’를 가집니다. 직업윤리를 갖춘다는 것은 다음과 같습니다. :

   1. 직업을 돌보기 위해 공부를 게을리하지 않기

   2. 전산 분야 지식을 익히는 것

   3. 끊임없이 배우기

   4. 끊임없이 연습하기

   5. 함께 일하기 / 멘토링 / 업무지식을 익히기

   6. 그리고 겸손하기

2장. 아니라고 말하기

2장을 한 줄로 요약하자면, 아니라고 말하는 것은 “될 수 있는 것을 정확하게 말하는 것입니다.”

1. 반대하는 역할은

   1. 상호 합의하에 해결책을 만들 수 있어야 한다는 것입니다.

   2. 위를 통해, 상황을 파악하고 현실을 받아들이는 데 도움이 되도록 하는 것입니다.

2. 이해관계가 높을 때

   1. 이해관계가 높을 때는 아니라고 말할 가장 중요한 순간입니다.

3. 팀 플레이어는

   1. 항상 “네”라고 말하지 않습니다.

   2. 노력하겠다는 말에 책임을 져야합니다.

      노력하겠다는 약속은 계획을 바꾼다는 약속이기 때문입니다.

3장. 예라고 말하기

3장을 한 줄로 요약하자면, 모든 업무 요청에 “예”라고 말할 필요는 없지만, “예”라고 말할 창의적인 방법을 찾는 데 고심해야 한다는 것입니다.

1. 약속은 ‘하겠음’ / ‘진심을 담기’ / ‘실제로 실행’을 뜻하는 것입니다.

2. ‘약속을 하겠다’는 것은 다음 3가지와 같습니다.

   1. 명확한 시점을 서술한다는 것입니다.

   2. 구체적인 약속을 하는 것입니다.

   3. 문제가 될지도 모르는 사실을 즉시 알려야 합니다.

4장. 코딩

4장에서는 코드를 짜는 행위와 그 행위 주변 상황에 대해 이야기합니다.

1. 코드는 반드시 동작해야 한다.

2. 코드는 고객이 제시한 문제를 반드시 풀어야 한다.

3. 코드는 기존 시스템에 잘 녹아들어야 한다.

4. 코드는 다른 프로그래머가 읽기 쉬워야 한다.

이러한 관심사항을 모두 충족시키기는 어렵지만, 다음과 같은 태도를 제시합니다.

1. 지쳤을 때는 코드를 만들지 말 것 (충분한 휴식과 잠을 취할 것)

2. 근심있는 상태로 코딩을 하지 말 것 (사적인 걱정거리를 코드에 담지 말 것)

3. 몰입에 빠지지 말 것 ( 영역에 빠져 큰 그림을 놓칠 수 있다.)

4. 음악은 집중에 도움이 되지 않는다.

5. 외부 방해를 없앨 것.

6. 속도를 조절할 것

7. 디버깅 시간을 줄일 것

이 외에도, 여러 이야기를 담고 있지만, ‘도움’에 대해 더욱 더 강조하고 있습니다.

프로그래밍은 너무 어려워서 한 사람의 능력으로 잘 해내기 어렵기에,

아무리 기술이 뛰어난 프로그래머라도 반드시 다른 프로그래머의 생각과 아이디어에서 도움을 받아야 한다고 이야기합니다.

또한, 다른 이가 나를 도울 때는 감사한 마음을 가지고, 서로를 도울 준비를 하는 일 또한 프로그래머의 의무라고 이야기합니다.

5장. 테스트 주도 개발

TDD에 대한 논쟁은 블로그나 기사를 통해 수년간 계속되고 있습니다.

TDD의 세가지 법칙

1. 실패한 단위 테스트를 만들기 전에는 제품 코드를 만들지 않는다.

2. 컴파일이 안 되거나 실패한 단위 테스트가 있으면 더 이상의 단위 테스트를 만들지 않는다.

3. 실패한 단위 테스트를 통과하는 이상의 제품 코드는 만들지 않는다.

TDD의 혜택을 이 책의 저자는 이렇게 이야기합니다.

1. 테스트 코드를 통과한 제품에 대한 확신

2. 결함 주입 비율이 매우 낮다

3. 코드 변경을 두려워하지 않게 된다.

4. 의존성이 낮은 좋은 설계를 만드는 힘이 된다.

위를 이유로 TDD는 프로다운 선택이라 이야기합니다. TDD는 확신,용기, 오류 감소, 문서화, 설계를 향상시키는 원칙입니다.

6장. 연습

프로그래머들이 기술을 연마하는 방법에 대해 다룹니다.

로렌트 보사빗과 엠마누엘 갤리엇이 진행하는 코딩 도장이라는 강의에서 ‘실용주의’ 데이브 토마스의 말을 빌려,

TDD를 사용해 콘웨이의 인생 게임을 코딩한 시연을 ‘품새’라고 불렀다고 합니다.

많은 프로그래머들은 무술 연마의 비유를 받아들이고, 코딩 도장이라는 이름으로 굳어졌다고 합니다.

1. 품새 : 격투 중인 한 사람을 가상해 일련의 잘 짜인 동작들을 모은 것.

   1. 프로그래밍에서 품새란 어떤 문제 풀이를 가상해 만든 키 누름과 마우스 조작을 정교하게 짜 모은 것.

   2. 프로그래머는 무술가처러 다른 품새를 익히고 규칙적으로 연습해 기억에서 멀어지지 않도록 해야한다.

   3. https://katas.softwarecraftsmanship.org/ 품새 모음 사이트

2. 합 맞추기 : 프로그래머들을 <핑퐁>이라 부르는 비슷한 방식으로 연습한다.

   1. 두 명이 짝을 이뤄 품새나 간단한 문제를 고르고, 한 프로그래머는 단위테스트를 다른 프로그래머는 그 테스트를 통과하는 코드를 짠다.

그 외에도, 오픈 소스에 기여하는 등 연습의 중요성을 강조하고 있습니다.

7장. 인수 테스트

소통이 중요하다는 것을 강력히 어필하고 있습니다.

개발자와 사업부(기획부) 사이의 가장 흔한 의사소통 쟁점은 요구사항 이라고 합니다.

사업부에서 서류로 자신들이 필요하다고 생각하는 바를 넘기면, 개발자들은 사업부에서 이런식으로 의도하고 있다고 자체적으로 판단하여 나름대로 구현하는 케이스가 많다고 합니다.

이런 상황 중, ‘정밀도’와 ‘모호함’의 함정에 빠지기 쉽다고 합니다.

초기에 너무 정확하게 하려고 하면 ‘시기상조의 정밀도’에 빠지기 쉽다고 합니다. 양쪽이 원하는 정밀도는 사실 불가능합니다.

사업부와 개발부서의 활발한 소통으로 중간을 잘 찾아야 합니다.

또한 요구사항이 실제 동작하는 모습을 보고 나면 더 나은 생각이 떠오르는데, 개발 과정을 지켜보면 계속 새로운 시각으로 제품을 바라보게 되고,

결국 초기 기획 요구사항과 최종 구현된 시스템은 크게 벌어지게 됩니다. 이를 ‘불확실성의 원칙’이라고 합니다.

따라서 초기 기획을 아무리 정밀도 있게 하더라도 실제 구현되는 과정에서 여러가지 노이즈가 있기 때문에, 최종 구현체는 언제나 불확실 합니다.

따라서 시기상조의 정밀도의 정도를 잘 생각해야 합니다.

시기상조의 정밀도를 해결하려면 정밀도를 늦추면 되지만, 모호함이 생깁니다. 요구사항의 모호함은 이해당사자들 간의 논쟁을 대변합니다.

요구사항이 언제 "완료"되는지를 정의하기 위해 이해당사자와 프로그래머들이 힘들 모아 작성하는 테스트를 바로 인수 테스트 라고 합니다.

흔히 QA라고 부르는 인수테스트는 단순히 개발자 입장에서의 ‘완료’라고 정의하면 안된다고 합니다.

개발자에게 완료란 코딩이 다 끝났다, 오류가 안난다, 배포가 가능하다 와 같은 의미로 쓰이고, 사업부에게 완료란 서류 작성 및 결제가 완료를 의미할 수 있습니다.

따라서 사업부와 QA담당자가 기능 구현 및 배포를 하는 과정 내내 소통이 중요하다고 강조하고 있습니다.

8장. 테스트 전략

개발자 입장에서 QA는 오류를 찾지 못해야 합니다.

QA는 하나의 같은팀이며, QA팀의 가장 중요한 역할은 명세서술과 특징 묘사라고 합니다.

적대적이여도 안되고, 웃으면서 넘어가는 그런 관계여서도 안됩니다. 적절한 관계를 유지하며 오류를 없애기 위해 소통해야 합니다.

목표를 달성하기 위해 개발팀과 QA팀이 협업하여 테스트 계층을 만들고, 테스트를 자주 실행하여 오류가 없는 완벽한 상태에 도달할 수 있도록 노력해야 한다고 강조하고 있습니다.

9장. 시간 관리

효율적인 시간 관리를 위한 회의 계획 세우기, 적절한 수면, 우선순위 등과 같은 방법들을 제시하고 있습니다.

해당 장에서 가장 인상 깊었던 내용은 바로 ‘거부하기’ 입니다.

자신과 이해관계가 있긴 하지만, 당장 필요하지 않은 회의가 있을 수 있습니다.

그런 회의로 시간을 허비하지 않아야 한다고 강조하고 있습니다.

팀원에게 실례를 범하지 않는 선에서 적절한 멘트로 거부하는 능력이, 프로다운 개발자라고 말합니다.

10장. 추정

저자는 추정을 ‘약속’을 언급하며 자세히 설명하고 있습니다.

사업부에서 개발자에게 ‘몇 일 정도 걸릴거 같냐’ 라는 질문에 ‘3~4일 정도 걸립니다’라고 추정해서 답변하는 경우가 있다고 하겠습니다.

개발자는 자신의 머리속에서 3~4일 정도에 끝낼 가능성이 가장 높다고 추정하여 ‘약속’을 하였고,

사업부는 해당 기간에 맞춰 일정을 계획하고 있습니다. 만약 3~4일이 지나도 일이 끝나지 않는다면,

개발자의 추정은 틀린것이며, 전체 일정이 큰 차질이 발생합니다.

위와 같이 추정은 가장 단순하면서도 가장 두려운 행위라고 정의하면서, 관계를 어긋나게 하는 불신의 원인이라고 저자는 말합니다.

11장. 압박

11장은 주로 데드라인에 따른 압박에 대한 내용이었습니다.

프로 개발자는 침착해야하며 결단력이 있어야 하는데 마감일과 약속을 지키는 최선의 방법은 훈련과 규율이 필연적이라고 합니다.

기초가 약하면, 데드라인 시연은 통과하더라도 그 이후 단계가 힘들기 때문입니다.

즉 이러한 압박을 피하기 위해

1. 리스크를 줄이기 위한 약속

2. 시스템, 코드, 설계를 깔끔하게 유지하기

3. 위기 상황에도 규율 유지하기 입니다.

특히 위기 상황에도 규율을 유지하는 것은 평소에 TDD를 유지하더라도 위기 때는 건너뛰는 일이 없어야 한다는 것을 의미합니다.

압박을 다루기 위해서는

1. 당황하지 말고 (유혹에 빠지지 말고 스트레스 관리하기)

2. 어려움이 있을 때는 의사소통을 반드시 하고

3. 규율을 따르며

4. 도움을 받기를 권장했습니다. (짝 프로그래밍)

12장. 함께 일하기

프로그래머로써 보통 사람들과 일하는 법에 대해 소개했습니다.

1. 프로그래머 vs 회사

   프로그래머는 회사가 필요로 하는 일을 처리하는 것이다.

   → 반드시 사업 목표를 이해해야 한다. (여러 다른 부서 동료들과 함께)

   → 기술에만 집착하면 안된다.

2. 프로그래머 vs 프로그래머

   자신의 코드에 벽을 두르지 말자.

   어떤 모듈이라도 수정할 수 있는 것이 좋다. (팀 단위 코드 소유)

   시스템의 여러 다른 부분을 배우자.

   이를 위해 짝 프로그래밍을 통해 코드를 검토하자.

13장. 팀과 프로젝트

프로젝트에서 업무를 맡는 것에 대해 팀의 구조에 대한 소개를 했습니다.

절반은 프로젝트 A, 절반은 프로젝트 B를 맡는 것은 하나의 팀이 아니라 잡탕이다.

하나의 팀을 만드는 것은 오래 걸리지만 서로 보호하고 최선을 요구하는 것이며 12명의 팀이라면 7명의 프로그래머, 2명의 테스터, 2명의 분석가, 1명의 관리자가 좋은 비율이라고 합니다.

분석가는 사업 가치에, 테스터는 정확함에 집중하여 테스트를 하고 더 나은 프로젝트를 진행합니다.

이러한 구성이 되기 위해서는 6개월의 시간 이상 걸린다고 합니다.

하지만 프로젝트를 위한 팀을 보통 만들기 때문에 이를 관리하는 것이 중요하다고 합니다.

14장. 스승과 제자 그리고 장인 정신

잘 만들어진 메뉴얼을 배운 것과 자신에게 관심 없는 사람들을 보며 배우는 것 또한 멘토링이 될 수 있다.

여기서 중요한 것은 역경을 극복할 자세를 가져야 하며 이를 위해 수습기간이 존재한다.

이상적으로는 장인, 숙련공, 견습생이 있지만 현실적으로 불가능하다.

그렇지만 견습생은 기술에, 숙련공은 팀의 리더로 장인들은 기술에 대한 책임을 배우는 것이 좋다.

장인은 그들의 사고방식으로 다른 사람에게 확인을 심어주고 후배를 가르친다.

그렇기 때문에 장인이 된다면 롤모델로써 자신의 장인 정신을 보여줘야 한다.

이 책을 읽은 후기

나건주

프로젝트를 하면서 항상 실행만 되는 코드 작성, 리팩토링 없는 프로젝트, 누군가의 일정 주도와 역할 분배가 되지 않는 경우가 많았습니다.

하지만 이번 책을 읽고 할 수 있는 것과 없는 것을 말할 수 있는 책임감과 팀이 잘 굴러갈 수 있도록 하는 자세, 프로그래머로써 올바르게 코드를 작성하는 법을 배울 수 있었습니다.

특히 여러 사례들을 통해 이런 상황에서 나는 어떻게 할까? 를 고민할 수 있었던 책이어서 더 와닿았던 것 같습니다.

좋은 책을 읽게 해주셔서 정말 감사합니다!

육하영

개발자로서 가져야할 태도를 책을 통해 배우게 되었습니다. 특히, ‘책임’을 지는 태도에 대해 정확히 무엇인지 정의할 수 있었습니다.

“할 수 있는 것과 할 수 없는 것을 구분하며 정확한 기간 내에 말에 대한 책임을 가지는 것”이 가장 중요함을 느끼게 되었습니다.

앞으로도 수 많은 개발 프로젝트와, 취업 준비 속에서 책임감을 가질 수 있는 개발자로 성장하도록 노력하겠습니다.

좋은 책을 통해 ’책임감’을 가지는 마인드를 확고히 가지는 사람으로 성장하게 해주셔서 감사합니다!

박민지

개발자를 생각하였을 때, 자연스레 불규칙하고 늦게 자는 이미지를 떠올리곤 하였는데, 책을 읽으며 규칙적인 생활과 충분한 휴식, 스트레스 관리까지 더욱 더 중요함을 깨달았던 시간이였습니다.

또한, 코딩의 연습 방법들을 몇가지 제안해주셨는데, 볼링 게임이라는 유명하고 재미있을 것 같은 문제를 첨부해주셔서 오늘 한번 풀어보고 자려합니다.

나중에 기회가 되면 데보션 여러분들과 페어 프로그래밍 꼭 해보고 싶습니다 ! 감사합니다.

김진호

흔히 생각하는 개발자는 ‘혼자’ 묵묵히 코드를 뜯어보고 ‘혼자’ 고민하는 독립적인 존재가 될 수 있다는 이미지가 있습니다.

하지만 이 책에서 개발자가 항상 ‘소통’을 통해 사업부와 접점을 찾는 연결고리와, 자기계발을 통한 전문가가 될 수 있는 진정한 ‘프로’가 되는 방법을 강조하고 있습니다.

맡은 분야에 최선을 다하고 소통하는 자세로 업무를 수행하는 것이 프로가 되기 위한 첫 발걸음이라고 생각합니다.

‘클린 코더’를 통해 기술적인 부분의 프로보단, 사람과 사람 관계에서의 프로도 중요하다는 것을 배울 수 있었습니다.

좋은 책을 읽을 수 있는 기회를 마련해주셔서 진심으로 감사드립니다 :)