BookReview [The Clean Coder]

읽은 기록

The Clean Coder

단순 기술자에서 진저한 소프트웨어 장인이 되기까지

브릿지라는 게임개발 동아리에서 개설하게 된 북클럽 3회차 책이다.

싸이클

총 274쪽 분량, 14장으로 구성

2주에 약 120쪽 분량을 읽을 예정

총 3싸이클, 6주 소요 예정

3회차는 책이 짧기도 하고 기술이 아닌 소프트스킬내용이라 2주에 120쪽씩 읽기로 했다.

그래서 3싸이클로 진행하게 되었는데 가벼운 책이라 참여자 두분 다 완주하실 것 같다..!

좋은 책이기도 하고, 추천을 받은 책이라 진행했는데 비슷한 내용을 클린코드에서도 보고, 리팩터링, 프로그래머의 길 멘토에게 묻다, 실리콘 밸리의 팀장 들 등..

이제는 좀 책을 읽어서 그런지 겹치는 내용들이 나와서 다시한번 기억을 상기하기에 좋았던 것 같다. (겹친다면 중요한 내용이니)

자신이 어떤 프로그래머가 되고 싶은지 명확하게 하고 싶다면 한번 읽어보는 걸 추천!

CleanCoder(preface)

들어가며에 나온 로켓의 사례에선 관리자와 기술자의 입장차이를 보여주고 있다.

O링에 관한 사실과 같이 이 사례뿐만 아니라 사회에서도 많이 보이는 현상이다.

한 가지 사례는 이미 우리 일상속에 깊숙이 들어와 있지만 아직까지도 대다수의 사람들이 외면중이다.

바로 지구 온난화이다.

최근에는 지구 온난화라는 말을 개정하여 earth boiling라고 한다.

많은 과학자, 기술자들이 지금이라도 당장 이산화탄소 배출을 급격하게 줄여야 한다고 주장하지만 정치인들은 이를 무시하고 있다.

이와 같이 서로의 일, 그리고 입장 차이에선 정말 다양한 해석이 가능하다.

역사는 반복되고 있고, 이를 통해 우리는 무엇을 배워야 할까?

기술은 발전하지만, 사람은 그대로

소프트웨어 개발자로 이 사례를 본다면 어떤 생각을 해야할까?

이 책에서 다루는 내용

이 책은 북클럽 3회차 책으로 개인적으로 내가 선정한 책이다.

2회차에서 혼자 남게되어 선정하게 되었다.

좋은 동료? 책을 읽는 친구, 팀원을 만들기 위해 스터디 진행에 대한 회고를 통해 책을 선정하게 되었다.

• 회고록

이 책은 개발자 마인드 셋에 관한 내용으로 내가 처음 개발 책을 읽어야겠다는 마음가짐을 가지게 한 책도 개발자 마인드 셋에 관한 책이었다.

프로그래머의 길, 멘토에게 묻다라는 책이다.

스스로 왜 개발을 하고 있는지, 성장하기 위해선 뭘 해야하는지, 나는 어떤 개발자가 되고 싶은지에 대한 의문이 든다면 이런 책을 읽는 것은 상당히 도움이 된다.

스스로와 대화를 통해 얻을 수도 있고, 나보다 몇십년을 더 개발해본 숙련자와 책을 통해 대화를 할 수도 있다.

이런 마인드 셋과 같이 기술서적이 아닌 책을 같이 읽게 되면 다양한 주관적인 이야기를 나눌 수 있지 않을까? 라는 생각도 들고 내가 시작한 것 처럼 다른 사람도 한 책을 끝내보고 시작해봤으면 좋겠다.

• 소프트웨어 프로란 무엇인가?
• 프로는 어떻게 행동해야 하는가?
• 프로는 어떻게 사람들 사이의 대립, 빡빡한 일정, 불합리한 관리자를 감당해 내는가?
• 프로는 언제, 어떻게, ‘아니요’라고 말해야 하는가?
• 프로는 어떻게 주위의 압박을 처리하는가?

이 책의 충고를 따르다 보면 힘든 상황도 돌파할 수 있는 마음가짐을 배우게 된다.

정직, 명예, 자기존중, 긍지가 바로 그 마음이다.

기술 장인이 되겠다는 막중한 책임을 짊어지겠다는 의지다.

하지만 책임지는 일은 항상 무서운 일이다.

기술자라면 시스템과 프로젝트에 대해 관리자가 알기 힘든 깊은 지식을 알아야 한다.

그 지식을 가지고 행동으로 옮겨야 할 책임이 있다.

관리자라고 해서 기술자가 아는 세세한 내용까지 다 알아야 한다고 생각하면 안된다. 그 직책은 그에 맞는 일이 있는 것이고 서로를 이해해야 한다.

책을 읽기 앞서

이런 책을 읽기전 이 책은 상당히 오래된 고전책으로 이를 인지하고 읽어야 한다.

가장 무섭다는 사람이 책을 한권만 읽은 사람으로 책을 읽을 땐 자신과 생각과 비교해가며 비판적인 사고로 읽는 것이 좋다.

특히, 이쪽 분야는 더더욱 그렇다. (발전이 빠르기 때문에)

따라서 다른 책과 달리 좀 더 개인적인 생각에 대해 정리해 나갈 생각이다.

미리 읽어두기

안 읽고 넘어가지 마세요. 나중에 필요합니다?!

이 책에선 프로 프로그래머에 대한 정의를 내리고자 한다.

태도, 원칙, 행동이 프로의 핵심이라 생각한다.

저자는 스스로 잘못한 일의 목록을 솔직하게 기록하였다.

모든 사례에서 코드를 잘 짜는 것이 좋은 프로그래머가 아니라는 점을 기억하자.

1장 프로의 마음가짐

그냥 웃어, 커틴 이 친구야. 신이 대단한 장난을 친 거야. 아니면 운명이거나 자연의 섭리인거지.
모든 좋을대로 생각해. 하지만 누가 됐든 유머 감각은 있구만 하하.

• 하워드, <시에라 마드레의="" 황금="">

숙련공, 프로에 대한 판단은 주관적인 부분과 객관적인 부분이 섞여있다.

언젠간 스스로 프로라고 말할 수 있는 날이 올까?

함부로 바라지 마라

프로페셔널리즘(professionalism)은 명예와 긍지의 상징이기도 하지만, 동시에 책임과 의무를 나타내기도 한다.

노블리스 오블리제

물론 두 가지는 뗄레야 땔 수 없다.

책임지지도 못할 일에서 명예와 긍지를 얻을 수는 없다.

읽다보니 몰입과 프로는 상당한 연관관계가 있다고 생각된다.

프로는 자신의 일에 책임을 져야하고 대부분의 편하게 살고 싶어하는 즉, 적당히는 자신이 정해놓은 선이 있다고 생각한다.

물론 후자로 사는게 당장은 편하다고 생각되지만, 자아실현의 욕구 그리고 하루의 3분의 1을 인생 전체에서 의미없는 시간으로 보낸다는 건 개인적으로 끔찍하다.

책임을 지더라도 주도적, 적극적으로 일을 하는 것이 더욱 행복하다고 생각한다.

책임감을 가져라

책임을 져보지 못한 사람은 평생을 회피하며 살아간다고 생각한다.

실로 얼마나 끔찍한가..

사례와 같이 실시간 서비스되는 애플리케이션의 경우는 더욱 그렇다.

책임이란, 어찌보면 불편한 어감이 느껴지기도 한다.

한국 사회가 책임에 대한 무게감을 부정적으로 둬서 그런건지, 스스로 무겁다고 느껴서 그런건지..

어떤 일에 책임을 질 수 있다는 것은 역설적으로 해당 일에 대한 주도권을 가지고 있다고 해석할 수 있다.

어떤 이는 책임질 일도 없을 수 있다.

따라서 개발자로써 책임질 부분이 있다는 것은 나름 프로페셔널리즘을 가지고 있다고 해석할 수 있다.

무엇보다 해를 끼치지 마라

소프트웨어 개발자는 기능과 구조 양쪽에 해를 끼친다.

기능에 해를 끼치지 마라

프로그래머가 매력적인 이유는 잘 돌아가는 소프트웨어를 만들었을 때의 쾌감에 나름 중독되기 때문일 것이다.

하지만 모든 소프트웨어가 그렇듯 완벽할 순 없다.

프로그래머는 당장에 최선을 다할 뿐 프로그램 자체가 버그가 1도 없는 완벽한 프로그램을 만들 순 없기 때문이다.

그렇다는 것은 완벽하지 않다는 사실에 책임을 져야 한다는 것이다.

프로라면 모든 오류에 책임을 져야 한다.

QA는 아무것도 찾지 못해야 한다

프로라면 QA가 아무것도 찾지 못하게 해야 한다.

제대로 작동하는지 아닌지 알아야 한다

코드가 잘 돌아가는지 알려면 어떻게 해야 할까?

간단하다 테스트하고 또 테스트하라

역시.. TDD의 창시자..

얼마만큼의 코드를 자동화한 단위 테스트로 테스트해야 할까? 대답할 필요조차 없다. 모조리 다 해야 한다. 모조리!!

자동화된 QA

데브옵스, CI/CD에 관한 내용으로 정리된다.

구조에 해를 끼치지 마라

전체 구조를 희생하면서까지 기능을 추가하는 일이 헛수고라는 사실은 프로라면 당연히 알고 있다.

구조가 좋아야 코드가 유연해진다.

구조가 위태로우면 미래도 위태롭다.

소프트웨어는 변한다는 생각은 모든 소프트웨어 프로젝트의 기본 가정이다.

요구사항에 따라 도메인이 변경되는 것은 당연한 일로 생각되어야 한다.

한마디로 변경을 할 때 비용을 치르지 않고 변경할 수 있어야 한다.

이해를 돕기 위한 게임 구조 자료를 첨부한다.

• Unity Architecture: Spaghetti Pattern

싱글톤 패턴의 구조를 가져가는 것에 대한 내용으로 작업 시간을 체크했을 때 토이프로젝트의 경우라도 feature가 늘어남에 따라 작업 시간, 버그 시간이 기하급수로 늘어날 수 있다.

이 책에서는 구조에 관한 기술적인 내용을 다루진 않겠지만 클린 코드나 리팩터링을 참고하면 좋을 것 같다.

돌아가서 바꾸기 쉽게 위해선 테스트 코드가 작성 되어 있어야 하고, 거버넌스/커플링이 적어야하고, 객체지향적으러 섥계되어 있어야 한다.

직업 윤리

자신의 경력은 자신이 책임져야 한다.

실무에서 통할 능력을 갖추는 일은 회사의 책임이 아니다.

자기 경력을 회사에 맡기는 개발자에게 재난이 있으라..!

한번 경력에 따라 개발자의 비율이 역 피라미드 형태로 많이 존재하는 이유에 대해 생각해보면 좋을 것 같다.

대부분 개발자는 3~4년차에 이직을 준비한다고 하는데, 이후에 이직을 준비할 때는 자신의 포토폴리어는 텅 비어있다고 말한다.

스스로의 경력을 관리하지 않기 때문에, 이직을 10년차까지 반복하다 보면 회사에선 10년차 개발자에게 다른 능력을 요구하게 된다.(프로젝트 매니저, 관리자 등등)

사실 그때는 늦을 수 있다.

자신의 여가 시간을 전부 바치라는 말이 아니다.

주에 5시간 만이라도 자기 개발을 꾸준하게 한다면 문제가 되지 않는다.

흔한 잘 작성된 테크 블로그의 마지막 post날짜가 취업 그 사람의 취업 날짜로 보면 쉽다.

전산 분야 지식을 익혀라

과거를 기억하지 못하는 자, 그 과거를 반복하는 저주를 받을지니..

전산 분야 지식보다는 새로운 기술을 익혀라가 더 적합해 보인다.

자신이 사용하는 도구와 다른 도구의 차이점, 장점을 비교해가며 계속 생각해야 한다.

이 분야에서 뒤쳐지는 것은 한 순간이다.

책에서 나오는 예시에서도 변하지 않는 고전은 존재한다.

디자인 패턴, SOLID, 방법론, 원칙등이 있지만 계속 발전하는 도구는 2023년 기준으로 사용하지 않는 부분이 더 많다.

즉, 개념적인 부분은 지금까지 형태를 유지하지만 기술은 계속 발전하기에 도구는 의심해야 한다.

회사에 들어갔는데 팀장이 강제적으로 git bash만 써야한다고 하면 그거 나름대로 끔찍할 것

끊임없이 배우기

IT는 미친듯이 바뀌기 때문에 어마어마하게 공부해도 간신히 따라잡는다.

개인적으로 정말 잘 생각해야 한다.

자신이 잘 할 수 있는 것, 하고 싶은 것, 당장 필요한 것을 잘 생각해서 학습해야 한다.

이때 부터는 학습하는 시간도 비용이기 때문에 무식하게 공부하는 것은 정말 비효율적이다.

과거에 매일 무식하게 공부했던 것 같다.

컨퍼런스에 끊임없이 참여하고, 새로운 언어를 익히고, 새로운 도구를 배워라.

연습

프로는 연습한다.

일상 업무를 연습이라고 부르면 안된다. 일상 업무는 연습이라기보다 공연이다.

이 부분은 함께 자라기의 의도적 학습을 참고하면 도움이 될 것 같다.

미하이 칙센트미하이의 몰입 그래프로 난이도와 실력의 2차원 그래프의 형태에서 스스로 몰입 채널에 들어갈 수 있도록 계속 노력해야 한다.

개인적으로 작성했던 글을 첨부한다.

• 당신이 제자리 걸음인 이유

함께 일하기

이 책을 다른 사람과 같이 읽듯이 소프트웨어 개발은 혼자할 수 없는 일이다.

혼자서 하는 일, 학습보다 같이 하는 일, 학습이 더 효율적이고 성장에도 더욱 좋은 영향이 간다.

사람의 대부분의 넘어야 하지만 쉽게 넘지 못하는 벽으로 남이 잘되면 배아프거나, 자신의 지식을 나누려 하지 않는 경우가 많다.

나도 과거에는 그랬기 때문에 왜 그런지 잘 알지만, 정말 짧게 보고 있다고 생각된다.

당장 비교를 주위 사람밖에 하지 못하는 시각과 더 먼 미래를 보지 못하는 시야는 전혀 도움이 되지 않는다.

멘토링

배우기에 가장 좋은 방법은 가르치는 것이다.

쓸모 있는 내용을 머릿속에 가장 빠르고 강하게 넣는 방법은 자신이 책임지고 담당하는 사람들과 이야기를 주고 받는 일이다.

가르치고 배울 때 더 큰 이득을 보는 사람은 선생쪽이다.

매우 동의..

그래서 만든 스터디가 브릿지 아카이브라는 스터디로 자신이 공부하고자 하는 내용을 남에게 쉽게 설명할 수 있는 글로 적는 아주 좋은..

업무 지식을 익혀라

프로 소프트웨어 개발자는 자신이 프로그래밍하는 제품의 업무 분야 지식을 알아야 한다.

즉, 요구사항과 도메인에 빠삭해야 한다.

비기능적인 부분을 스스로 Q/A를 통해 알아내고 예외를 처리해야 하기 때문이다.

자신이 뭘 만드는지도 모르고 코딩하는 것만큼 끔찍한 일도 없을 것..

공장의 부품과 다를 게 없다.

회사와 고객에 동질감을 가져라

회사의 문제가 자신의 문제다.

문제가 무엇인지 이해하고 최선의 해결책을 만들기 위해 일해야 한다.

겸손

프로그래밍은 창조 행위다.

다른 곳에도 많이 적었지만 프로그래밍은 단순 기술이 아닌 기예에 가깝다.

언제든지 틀릴 수 있기 때문에 프로그래밍 자체가 매우 오만한 행위다.

프로는 자신이 극도로 오만하다는 사실과 언젠가 불운이 닥쳐 목표가 무너질지도 모른다는 사실을 안다.(경험적)

목표가 무너졌을 때, 가장 좋은 방법은 그냥 웃어. 이 친구야

느낀점

확실히 오래된 책이라고 느끼는 부분도 있고, 고전책은 고전책으로 남는 이유도 있다고 생각된다.

그동안 개인적으로 생각했던 부분도 책과 비교해 가면서 정리하기 좋았던 것 같다.

논의사항

• 자신의 현재에 가장 공감갔던 내용은 뭔가요?

저는 개인적으로 배우기, 연습, 멘토링 이 부분인 것 같습니다.

소프트웨어 개발자로써, 프로를 목표로 하기 때문에 평생 가져가고 싶기 때문에 지금이라도 저런 부분을 습관화하고 싶습니다.

재능이나 특출난 능력이 없기 때문에 항상 의도적으로 꾸준하게 해볼려고 하는 생각이 있어서 그런 것 같습니다..

혼자 하는 것 보다 남들과 같이 하는 게 좋다는 걸 알아서 몇년을 개발, 공부할 텐데 같이 꾸준히 나아갈 동료 한 두명만 있어도 성공했다고 판단될 것 같네요!

2장 아니라고 말하기

“한다. 하지 않는다 둘 뿐이야. 해본다는 말은 없어.”

요다(yoda)

프로라면 권위에 맞서 진실을 말해야 한다.

프로는 관리자에게 아니라고 말하는 용기를 가져야 한다.

노예들에겐 아니라는 말이 허락되지 않는다. 단순 일꾼들은 아니라고 말하길 꺼린다.

하지만 프로는 아니라고 말해야 마땅하다.

사실 좋은 관리자라면 아니라고 말하는 배짱을 가진 사람을 꼭 가지고 싶어한다.

아니라고 말하는 일이야 말로 맡은 작업을 완료하는 유일한 길이다.

나도 프로젝트를 진행하며 느낀점이 있다면 느리게 가는 길이 가장 빠른 길이라는 것이다.

대부분 프로젝트를 진행하다 공모전 마감이나, 제출 전에 크런치를 통해서 개발을 급하게 만들어 가는 경우가 있다.

크런치가 이뤄지는 밤에는 정상적인 결과물이 나오지 않는다.

기획에게 결과물을 보여주기 위한 엉망친창인 코드, 대충 그린 아트, 급하게 기획한 기획문서들..

해당 작품들은 당장의 게임프로젝트가 동작하게 움직일 순 있지만, 이후에 레거시가 되어 작업한 몇배만큼의 시간을 빼앗아 간다.

대부분의 프로젝트는 크런치 몇 번으로 망가져서 쉽게 번 아웃이 오곤 한다.

그래서 지금 진행중인 프로젝트는 내가 PM이기 때문에 더욱 경계하고 있다.

시험기간이라고 쉬는 것도 없고, 크런치도 절대 없다. 공모전이 코 앞이라고 빠르게 달리는 일도 없을 것이다.

진짜 개발은 기한에 맞춰하는 것이 아닌, 팀원들과 계속 맞춰가며 불확실성에 대응하는 것이다.

나도 좋은 관리자일지 모르겠지만, 아니라고 말하는 팀원이 있으면 좋겠다.

반대하는 역할

대립관계가 없는 팀이 존재하는가?

서로에게 상처주기 싫어서, 불필요한 언쟁이라 생각하여 대립을 회피한다면 결과는 뻔하다.

관리자와 작업자는 계속 대립하며 합의점을 계속 찾아야 한다.

이를 작업자가 방어한다고 책에서 표현하는데 작업자 스스로 불가능하다고 판단된다면 아니라고 말할 수 있어야 한다.

왜 그런지가 중요한가?

관리자의 성격이나 해당 대화의 본질을 봐야 한다.

폴라가 로그인 페이지를 만드는데 2주가 걸린다는 사실보다 대화를 통해 합의점을 찾아낸 사실이다.

이해관계가 높을 때

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

이는 당연한 말이다. 프로젝트로 따지면 해당 프로젝트의 애정도, 실패하면 손해가 커서 본인에게도 영향이 있을 경우이다.

팀 플레이어

이야기에서 진짜 팀 플레이어는 누구일까?

단호하게 최대한의 능력을 말한 폴라, 자신의 능력을 믿고 해내도록하는 능력을 가져 조율을 한 마이크

노력해보기

노력해보겠다는 의미는 ‘추가로 힘을 쏟는다’라는 의미를 가지며 이는 이전에는 최선을 다하지 않았고, 예비로 힘을 남겨뒀다는 의미다.

음.. 개인적으론 누구나 최선을 다하진 않는다고 본다. 개개인의 최선의 한도도 다르다고 믿기 때문이다..

오히려 앞서 말한 최선을 다하게 되어 원래 페이스에서 무너져 번아웃이 오거나 좋지 못한 결과물이 나온다고 생각한다.

수동적 공격성, 두고 보자는 심보

진짜 대화문만 읽어도 숨이 턱 막힌다..

예라고 말하는 비용

사실 우리는 언제나 예라고 말하고 싶어한다.

건강한 팀은 오히려 예라고 말할 수 있는 방법을 찾으려 애쓴다.

관리자와 개발자들은 서로 만족할 수 있는 계획이 나올 때까지 협상한다.

존 블랑코의 글이다.
“회사가 나를 떠받들고 거리행진을 나가 ‘동서고금을 통틀어 가장 위대한 개발자’라는 명예를 안겨주는 모습을 상상하기 시작했다.”

코드 임파서블

앞선 일화에서 “훌룡한 코드는 불가능한가?” 라는 말보다 사실은 “프로 답게 사는 것은 불가능한가?”라고 묻는 것이다.

단순 개발자의 입장에선 일화에 등장한 이사들에게 돌을 던질 순 있지만 한 발자국 떨어져서 바라보면 각자의 일에 최선을 다한 것 뿐이다.

객관적으로 바라보면 존은 스스로 할수있다고 믿었고 그 책임, 화풀이를 회사에게 맡긴 것 뿐이다.

2주 기한을 받은 것도 존, php서버가 필요하다는 요구사항을 받아들인 것도 존

이후에 대금을 지금하지 않았다면 문제가 되지만 그렇지 않다.

프로가 영웅이 될 때는 업무를 충실히, 제 시간에, 예산 안에서 완수했을 때다.

구세주라는 명예를 얻기 위해 존은 프로답지 못한 행동을 했다.

느낀점

저번 논의때 나온 해당 프로젝트가 자신에게 직접적인 연관이 있으면 태도가 달라진다고 했는데, 실제로 사례가 나와서 반가웠다..

이번 장은 특히 대화문이 많았는데 대부분 숨이 턱 막히는.. 정말 최고의 복지는 마음에 맞는 팀, 좋은 팀이 아닐까..?

논의사항

• 아니라고 말하지 못했다가 후회한 경험이 있으신가요?

저는 첫 프로젝트때 아니라고 의견을 내지 못해서 너무 아쉬웠던 경험이 있습니다.

정말 좋은 팀이였는데 서로에게 상처주기 싫어서 아니라는 말을 삼키다 결국 팀원 모두가 지친것 같아요

실제로 팀 인터뷰에서 한번도 싸워보지 못한 팀은 좋은 팀이 아니다라고 말씀해주신게 생각나네요

3장 예라고 말하기

음성 메일을 개발한 사람이 저자라니?

“감사합니다. 러스 사장님. 약속드릴 수 있을 것 같아요… 아마도요”

약속을 뜻하는 말

말하고 진심을 담고 실행하라

약속을 하는 행동은 세 부분으로 나뉜다.

• 하겠다고 말한다.
• 진심을 담는다.
• 실제로 실행한다.

하지만 세상엔 이 3단계를 거치지 않는 사람들이 너무 많다.

과연 나는?

말할 때, 진심을 담은 후 실제로 완료해 내는 사람은 매우 드물다.

몇몇은 말은 진심이지만 절대 행동으로 옮기지 않는다.

아예 약속에 진심을 담지 않는 사람은 훨씬 더 많다.

약속이 부족함을 알아차리기

뭔가를 하겠다고 약속할 때 사용하는 언어는 실제 일어날 일을 알려주는 표시이므로 잘 살펴봐야 한다.

사실 이것은 말에 특정 단어가 있는지 찾아보는 이상의 의미를 지닌다.

이런 마법의 단어가 없다면, 진심이 아니거나 말하는 본인조차 실현 가능성이 낮다고 믿고 있을 확률이 높다.

• 약속이 아님을 알려주는 단어나 문구
  • 필요/해야 한다
    • 이걸 끝내야 해, 살 좀 빼야 할 필요가 있어, 누군가는 해야해
  • 희망/바람
    • 내일까지 끝나면 좋겠는데, 언젠가 다시 만나길 바라, 시간이 좀 더 있었으면 좋겠어, 컴퓨터가 더 빨랐으면 좋겠어
  • 하자
    • 언제 한번 만나자, 이거 끝내자

일단 이런 단어를 신경 쓰기 시작하면, 주변 어디서나 이 단어가 들릴 뿐 아니라 자신이 다른 사람에게 말할 때도 이 단어를 사용한다는 사실을 인식하게 된다.

우리는 아무 책임도 지짖 않으려 아주 바쁜 척 하는 경향이 있다.

그리고 자신이나 다른 사람이 업무를 볼 때 그 약속을 믿고 의지하는 일은 바람직하지 않다.

겨우 첫걸음을 내디뎠으니, 이제 주변뿐만 아니라 스스로도 약속이 부족하다는 사실을 알아차리기 시작한다.

즉, 위의 말을 믿고 의지하는 것은 바람직하지 않다.

약속을 뜻하는 말은 어떤 말인가?

앞선 문장에서 공통된 부분은 ‘내’손을 벗어난 일이라는 표현이거나 개인적으로 책임을 지지 않으려는 표현이다.

이 경우 사람들은 업무를 통제하려 하지 않고 오히려 상황 때문에 피해자가 된 것처럼 행동한다.

진심으로 하는 약속인지 아닌지 구별하는 비법은 문장에서 “나는 언제까지 할 것이다.”라는 말을 찾아보는 것이다.

이 문장의 핵심은 명확한 마감 시간을 언급하고 그 시간까지 무언가를 하겠다는 사실을 서술한 점이다.

스스로에 대한 이야기만 하고 다른 사람 이야기는 꺼내지도 않았다.

뭔가를 하겠다는 행동을 표현했다. (완수하려는 의지를 담았다.)

이 구두 약속을 피할 방도는 없다 처리하겠다고 했으니 결과는 하거나 하지 못하거나 두 가지 경우뿐이다.

그리고 적어도 한 명 이상이 지켜보는 앞에서 어떤 일에 완전한 책임을 져야 한다.

거울이나 컴퓨터 화면 앞에 서 있는 것과는 전혀 다르다.

사람 대 사람으로 다른 사람에게 바로 자신이 해내겠다고 말하는 일이다.

그것이 진심을 담은 약속의 시작이다.

뭔가를 해야만 하는 상황으로 자신을 밀어 넣어야 한다.

이 일을 끝내려면 어떤 사람 X가 꼭 필요하기 때문에 안 될 거야

자신이 모든 상황을 제어할 수 있을 때만 약속을 해야 한다.

의존성이 있는 작업이라도 해당 상황을 본인이 제어할 수 있는지 판단해야 한다.

목표 달성을 위해 구체적으로 어떤 일을 하겠다는 약속을 해야 한다.

어떻게 해야 할지 방법을 모르기 때문에 안 될 거야

어떻게 할지 몰라도, 목표를 달성하기 위해 어떤 행동을 취하겠다는 약속은 할 수 있다. (방법을 찾아내겠다고 약속하는 길도 있다.)

출시 전 남은 오류 25개를 모두 고치겠다고 약속을 하는 대신, 목적을 달성하기 위해 다음처럼 노력하겠다고 약속한다.

• 25개 오류를 모두 조사하고 재현해본다.
• 각 오류를 발견한 OA와 함께 오류를 재현해본다.
• 이번 주에는 오류를 재현해본다.
• 이번 주에는 오류 수정에만 전념한다.

가끔은 어쩔 도리가 없을 때도 있어서 안 될 거야

그럴 때도 있다. 살다 보면 예상치 못한 일이 일어나기도 한다.

그래도 예상했던 목표를 맞추고 싶다면, 지금 당장 예상치를 바꿔야 한다.

삶은 불확실성의 연속이다. 이런 불확실성에 누구는 무너지고 누구는 유연하게 대처하곤 한다.

핵심은 문제가 될지도 모르는 사실을 다른 사람에게 즉시 알리는 것이다.

알리지 않으면, 약속을 완수하는 데 필요한 도움을 얻을 기회를 스스로 뺏게 된다.

요약

약속의 뜻을 담은 언어의 사용은 얼핏 두려워 보이지만, 오늘날 프로그래머들이 맞닥뜨리는 여러 의사소통 문제들, 즉 추정, 마감일, 마주보고 하는 대화에서 생기는 사고를 해결하는 데 도움이된다.

내뱉은 말은 지키는 진지한 개발자로 인정받게 되고, 이는 이 업계에서 개발자들이 바라는 최고의 일이다.

예라고 말하는 법 익히기

예, 아니요도 중요하지만 개인적인 생각은 자신의 생각을 솔직하게 말하는게 가장 중요하다.

프로젝트에 흥미가 없다면 없다고 말하는게 멀리 본다면 본인에게도 프로젝트에도 이득이다.

당장 해야하는 방법을 모르겠다면 같이 이야기하여 해결점을 찾으면 된다.

예, 아니오가 아닌, 솔직한 생각을 전달하는 것 (사실 그렇게 하기 위해선 관계가 중요하다.)

노력의 또 다른 면

피터는 과연 뭘 피하고 싶었던 걸까?

애매모호한 답변을 한 이유는?

간단하다. 해당 작업에 대해서 어떻게 해야하는지, 어떻게 할것인지 진지하게 고민을 해본적이 없기 때문이다.

때문에 일단 미루고 보는 것..

원칙을 가지고 의사소통하기

이 대화의 예시는 크런치, 마감이 있는 개발이 넘어지는 이유에 대한 좋은 사례이다.

앞 장에서 여러번, 개인적인 블로그나 생각에도 많이 언급했지만 개발에 있어서 크런치는 매우 위험한 행동이다.

원칙을 어기고 싶어지는 매우 달콤한 유혹이 존재하기 때문이다..

결론

프로는 모든 업무 요청에 예라고 대답할 필요가 없다.

하지만 예라고 대답할 수 있는 창의적인 방법을 찾는 데 고심해야 한다.

프로가 예라고 대답할 때는 약속을 뜻하는 언어를 사용해서 내뱉은 말에 모호한 부분이 없도록 해야 한다.

느낀점

다른 책에서도 비슷한 내용을 다루는 경우가 많아서 때에 따라 생각이 달라지곤 하는데 요즘엔 예, 아니오를 쉽게 말할 수 있는 사람은 흔하지 않은 것 같다.

물론 나도 본인에게, 남들에게 얼마나 솔직한지 잘 모르겠다.

2년사이에 스스로 많이 솔직해졌다고 생각하지만..

사람과 대화를 통해 변화시켜서 솔직한 사람과 일을 하는 것과 처음부터 솔직한 사람과 일을 하는 것은 매우 다르다..

논의사항

• 스스로 답변을 모호하게 했을 때, 할 때 왜 그렇게 말했는지 이야기 해보면 좋을 것 같습니다.

저는 글에 적었지만, 해당 Task에 대해서 진지하게 고민해보지 않고, 진지하게 고민해보지 않은 저의 잘못을 숨기기 위해 “해봐야 알 것 같네요.” 이런 식으로 처리한 것 같다..

4장 코딩

클린 코드에서 깔끔한 코드의 구조와 성질에 대해 많은 이야기를 했다.

개발자의 고전 서적.. 좋은 내용이 많다.

다양한 서적에 등장하는 감각적인 부분, 흔히 오류 감각, 코드 감각으로 많이 설명하는데 이는 프로그래머로써의 자질? 재능의 영역으로 해석된다.

실제로 코딩하다 보면 비슷한 패턴에서 몸으로 먼저 느끼는 감각적인 부분이 분명하게 존재한다.

이번 장에선 코드를 짤 때 행동과 기분, 태도에 관한 규칙과 원칙이다.

클린 코드는 코드 자체에 관한 레벨이라면 여기선 인간에 포커스를 맞춘다.

코드 작성에 대한 정신 상태, 윤리, 정서적 흐름을 설명한다.

4장 내용의 일부는 동의하지 않을지도 모른다.
굉장히 개인적인 내용이기 때문에 솔직히 말해 몇몇 태도와 원칙에는 동의하지 않는 정도가 아니라 격렬하게 반대할지도 모른다.

준비된 자세

코딩은 어려운 데다 사람을 지치게 하는 지적 활동이다.

과연 코딩이 재밌다는 사람이 몇이나 될까? 처음 배울 땐 재밌을지 몰라도 이게 일이 된다면 당연하게 흥미는 수직하락..

• 첫째, 코드는 반드시 동작해야 한다.
  • 풀고자 하는 문제가 어떤 문제며 어떻게 풀어야 하는지 확실히 이해해야 한다.
  • 해결법을 나타낸 코드에 믿음이 가는지 확인해야 한다.
  • 해결법의 언어, 플랫폼, 현재 아키텍처, 시스템의 모든 결점까지 구석구석 지속적으로 관리해야한다.
• 코드는 고객이 제시한 문제를 반드시 풀어야 한다.
  • 간혹 알고 보니 고객의 요구사항이 고객의 문제를 해결하는 데 도움이 안 되는 경우도 있다.
  • 이런 상황을 파악하고 고객과 협상해 고객의 진정한 필요를 충족시키는 일은 당신에게 달렸다.
• 코드는 기존 시스템에 잘 녹아들어야 한다.
  • 기존 시스템의 경직성, 취약함, 불투명도를 높이면 안 된다.
  • 의존성도 잘 관리해야 한다. 한 마디로 코드는 견고한 객체지향 원칙을 따라야 한다.
• 코드는 다른 프로그래머가 읽기 쉬워야 한다.
  • 주석을 잘 쓰라는 단순한 조언이 아니다.
  • 만든 사람의 의도가 잘 드러나도록 코드를 잘 다듬어야 한다는 뜻이다.
  • 이는 어려운 작업으로 사실 프로그래머가 가장 통달하기 어려운 일이다.

이러한 여러 관심사항을 한 번에 교모히 다루기는 힘들다.

하지만 위 사항에 집중하지 못하면 잘못된 코드를 만들게 된다.

노력하고 또 노력하고, 노력하라

지치거나 주의력이 흩어졌다면 코드를 만들지 마라.

해봤자 결국 재작업해야 한다. (오히려 비효율적이다.)

새벽 3시에 짠 코드

좋은 반면교사가 내게도 있다.

크런치작업 때문에 급하게 작성한 코드를 제대로 소화시키지 못한채로 작업을 이어간 경험이 넘치게 있기 때문에..

근심이 담긴 코드

코드를 작성하더라도 우리는 온전히 코드에 쉽게 집중하지 못한다.

백드라운드 프로세스가 돌아가고 있기 때문이다. (컴퓨터와 같이..)

친구와 싸우거나, 팀원과 갈등이 있는 상태의 코드의 질은 당연히 떨어진다.

나도 저자와 같이 프로세스가 돌아갈 때 스스로를 몰아붙여 코딩을 하기보다 원인을 해결하고 작업하는게 효율적이라 판단된다.

몰입 영역

나왔다.. 몰입..!

몰입으로 알려진 극도로 생산적인 상태에 대한 글이 많다.

개인적으로 가장 이해가 잘 되고 정리를 했던 글이 내용이 있어서 첨부한다.

몰입영역에 관한 글

이에 대한 설명은 아직 몰입을 많이 경험해보지 못해서 쉽게 동의하지 못하겠다.

저자는 몰입에 대해 코딩에 있어서는 부정적인 시각으로 보는 것 같다.

아무래도 단순 코드만 짜서 퀄리티를 올리는 것이 아닌 리팩터링, 구조화 등의 작업은 급하고 빠르게 처리한다고 도움이 되지 않기에 영역에 대한 시선을 부정적으로 보는 것 같다.

음악

유튜브 개발할 때 듣는 음악…

어떤 책인지 기억은 나지 않지만 분명 코딩할 때는 노래를 들으라고 들었던 기억이 있어서 이에 대한 판단도 개인의 몫인 것 같다.

외부 방해

코딩할 때의 자신의 모습에서 외부 방해가 일어났을 때 모습을 상상해봐라

짝 프로그래밍이 두번이나 나와 잠깐 이야기 해보자면 경험상 정말 좋은 경험이였다.

이를 온라인에서 비슷하게 처리하기 위한 형태가 아마 코드리뷰의 형태일 것이다.

이 부분도 마찬가지로 기본 마인드셋? 성격 차이인 것 같다는 생각..

진퇴양난에 빠진 글쟁이

어떤 때는 그저 코드가 안 나오기도 한다.

이럴 땐 종종 다른 일을 한다.(메일을 보거나, 관련 글을 보는 등..)

저자에게 있어서 코드를 짜지 못하는 상황(진퇴양난)의 원인은 수면이라고 한다.(나머지는 걱정, 불안, 우울증)

자신의 가장 큰 진퇴양난과 그에 대한 해결법을 잘 찾아내는게 중요..!

나는 흥미를 잃어버리는 것이 가장 큰 진퇴양난이고 이를 해결하기 위한 방법으로 가끔 인디게임 켠왕을 한다.

창의적인 입력

막힘을 방지하는 다른 방법도 있다.

창의적인 출력은 창의적인 입력에 의존한다는 사실

나의 창의적인 입력은.. 다양한 외부 정보의 수집이다.

레딧이나 미디엄을 통해 현재 개발 트렌드를 파악하려고 하고, 책을 통해 고전 지식을 습득한다.

좀 더 창의적인 레벨은 사실 유튜브나 인터넷을 통해 많이 접하는 것 같다.

디버깅

밥 아저씨의 디버깅이력.. 지금이야 1분이면 처리할 수 있는 일에 있어서 이렇게 큰 차이가 생기는 것 까진 생각해보지 못한 것 같다.

기술은 끊임없이 발전하지만 사람은 그대로라는 말 처럼 해당 오류가 현대에 있더라고 해결했다고 보장할 수 있을까?

디버깅 시간

개발자는 디버깅 시간을 코딩 시간으로 여기지 않는다. 디버깅 시간은 자연스런 생리 현상, 당연하게 치러야 할 무언가로 본다.

디버깅 시간도 비용이기 때문에 줄이기는 것이 좋다.

이를 해결하기 위한 방법으로 테스트 코드, TDD등을 활용할 수 있다.

디버깅 시간을 가능한 한 0에 가깝게 줄이는 일은 프로가 짊어진 의무다.

속도 조절

소프트웨어 개발은 마라톤이지 단거리 질주가 아니다.

언제 걸어 나가야 할지 알기

풀고 있는 문제를 다 풀기 전에는 집에 못 간다고? 아니다. 가도 된다.

창의성과 총명함은 지속되지 않고 스쳐 지나가는 정신의 상태이다.

피곤하면 창의성과 총명함이 사라진다. (즉, 소모품이다.)

곤경에 빠졌을 때나 피곤할 때는 잠시 자리를 떠나라.

창의적인 잠재의식이 문제를 깨뜨리도록 두어라.

사실 코딩의 대부분은 코드를 읽는 시간에 할애된다.

문제를 해결하기 위해선 머리속에 있는 알고리즘을 옮겨적는 과정이 빠르게 이뤄지기 때문에 샤워할 때나, 자기전에 해당 문제에 대해서 생각하다 보면 해결법이 생각나기도 한다. (적어도 나는)

집까지 운전하기

나의 문제해결 장소는 항상 침대였다.

자기 전까지 코드를 짜다 누워서 좀 더 좋은 구조를 생각하다 보면 항상 더 좋은 구조가 생각났다.

샤워

샤워도 마찬가지..

일정을 못 지키다

언젠가는 마감을 못 지키는 날이 온다.

최고 실력자에게도 오고 가장 헌신적인 사람에게도 온다.

그저 추정을 망쳐서 일정을 못 지키는 처지가 되기도 한다.

스스로 추정치를 대비해야 한다 모든 불확실성을 컨트롤할 수 없기 때문에.

희망

열흘안에 끝내리란 희망을 갖지 마라!

희망은 프로젝트 살해자다. 희망은 일정을 파괴하고 자신의 평판을 망가뜨린다.

희망 때문에 깊은 문제에 빠지게 된다.

질주

솔직히 확신하지는 못하겠다.

내가 마감, 요구사항에 쫓겨서 인생에서 몇번은 질주를 할 것 같다는 생각이다.

물론 좋지 않다는 것도 알고 그것이 프로가 아니라는 것도 알지만, 이해관계자들이나 보이지 않는 부분까지 내가 덮을 수 있을지 모르겠다.

코딩을 더 빨리 하게 할 수 없긴 하지만, 해당 팀의 성격에 맞춰야 하지 않을까..?

초과 근무

초과 근무는 잘 될 때도 있고, 가끔은 필요하다.

하지만 20%를 더 일한다고 작업이 20%가 더 완료되지 않는다.

가짜 출시

프로그래머가 저지르는 가장 프로답지 못한 행동은 끝내지도 않았는데 끝냈다고 말하는 짓이다.

명백한 거짓말이고 아주 나쁜 짓이다.

스스로를 설득하고 완료의 뜻을 재정의 하는 등 자신의 양심, 대외적인 이미지를 생각하여 꾸며내는 행위..

이 행동은 전염성이 있는 행동이라 한 집단에서 완료의 정의를 확장하게 된다면 이후에 개개인마다 다른 기준을 가지게 된다.

‘완료’ 정의

완료를 정의하자면 테스터가 자동화된 인수 테스트를 만들어 완료했다고 말하는 것.

도움

프로그래밍은 어렵다.

프로그래밍은 수많은 if와 while 문장의 덩어리다.

하지만 경험을 쌓다 보면 어떤 식으로 if와 while 문장을 결합하는지가 결정적으로 중요하다는 사실을 깨닫기 시작한다.

두 문장을 듬뿍 끼얹어 놓고 최고가 되기를 바라면 안 된다. 그보다는 시스템을 작고 알기 쉬운 단위로 주의깊게 쪼개야 한다.

그 단위는 가능한 서로 간섭이 적도록 만들어야 하는데, 이 부분이 어렵다.

개발은 혼자서 하는 것이 아니다.

다른 사람 돕기

이런 이유로 서로를 돕는 것은 프로그래머의 의무이다.

사무실 칸막이에 틀어박히거나 다른 사람의 질문을 거부하는 일은 프로가 갖출 윤리 위반이다.

혼자만의 시간이 필요 없다는 말이 아니다. 당연히 혼자만의 시간도 필요하다.

도움 받기

다른 이가 나를 도울 때는 감사해야 한다.

고맙게 그리고 기꺼이 도움을 받아들여라.

영역을 지키는 듯한 행동은 하지 마라.

몸시 바빠 정신이 없다는 이유로 도움을 거부하지 마라.

명예를 걸고 타인을 도와야 하듯이 명예를 걸고 도움을 받아야 함을 기억하라.

프로그래머는 오만하고 자신에게만 열중하는 내향적인 경향이 있다.

멘토링

경험이 적은 프로그래머를 훈련시키는 일은 경험이 더 많은 프로그래머의 의무다.
교육 강의 과정은 해낼 수 없다.
책도 해낼 수 없다.
선배가 주는 효과적인 멘토링 말고는 본인의 노력 이상으로 더 빨리 젊은 소프트웨어 개발자가 제대로 일하게 만들 수 있는 방법은 없다.

반대로 젊은 프로그래머는 선배에게 멘토링을 구하는 일이 프로로서의 의무다.

멘토링은 개발 서적에서 많이 강조되는 내용으로 멘토라는 말은 소프트웨어 개발쪽에서 많이 활용된다.

단순 수학, 언어를 뛰어넘는 다양한 능력을 개발자로서 요구하기 때문에 교육과정에서 배울 수 없기 때문이다.

느낀점

이번 장이 가장 재밌게 읽은 것 같다.

내가 생각한 개발자의 자세와 책에서 말하는 부분과 공통점과 차이점을 비교할 수 있었고, 생각하지 못한 부분도 있었기 때문이다.

이렇게 내가 생각한 부분을 정리하는 과정이 너무 재밌기도 하고, 읽으면서 팀원에게 말하는 상황이나 다른 상황에 대해 혼자 시뮬레이션 해보기도 한다.

내가 스스로 얼마나 솔직한지도 판단하기 좋은 내용

논의사항

• 스스로 진퇴양난에 빠진다면 어떤 방법으로 해결하시나요?

저는 글에 적었지만 게임하는 것보다 게임을 만드는 것을 좋아해서 인디게임하나를 하루에 끝까지 플레이하고 엔딩을 보는 것을 좋아합니다.

끝나고 나면 나는 뭐하는거지..? 이런 의지에 불타게 되는..ㅎ

5장 테스트 주도 개발

TDD가 무언인지 이해하려면 먼저 테스트 코드를 이해하는 것이 좋은데, 여기서 모든 내용을 설명하기 보다 직접 읽어보는 걸 추천

또 다시 등장한 켄트 벡 선생님..

기억하기론 자바 유닛 테스트 코드 프레임 워크를 비행기에서 만드신 분? 으로 기억한다.

코드를 짜면서 자동으로 테스트 코드를 돌리며 리팩터링과 구현을 같이 가져간다면 확실히 효과적일 것 이라는 생각이다.

배심원 등장

• 배심원 등장
• 논란은 끝났다.
• GOTO는 해롭다.
• TDD는 잘 돌아간다.

TDD에 관한 논쟁은 지금도 뜨거운 감자인데, TDD 신봉자분들이 많아서 쉽게 말하지 못하겠지만, 해본적도 없어서 내가 뭘 말할 수가 없다.

하지만 하나는 명확하게 말할 수 있다.

어떠한 개발 방법론도 정답이 아니다.

당시 시대와 환경에 맞춰 유행에 불과할 뿐 개발의 본질은 크게 변하지 않으며 계속 변해간다.

몇 십년 뒤에 등장한 새로운 개발 방식에 대해서 시도해보지도 않고 TDD가 맞아! 하는 포지션보다 직접 해보고 장점과 단점을 비교하고 뭐가 더 유리한지 판단하는 것이 더 중요하다.

쉽게 확증편향, 교조주의 풀어서 책 한권만 읽은 사람이 제일 무섭다라는 말로 해석할 수 있다.

반대로 TDD가 이렇게 사랑받는 이유는 분명히 존재할 것 이므로..

TDD의 세 가지 법칙

1. 실패한 단위 테스트를 만들기 전에는 제품 코드를 만들지 않는다.
2. 컴파일이 안 되거나 실패한 단위 테스트가 있으면 더 이상의 단위 테스트를 만들지 않는다.
3. 실패한 단위 테스트를 통과하는 이상의 제품 코드는 만들지 않는다.

이 세 가지 법칙을 지키면 반복 주기는 대략 30초 길이를 유지한다.

처음에는 작은 단위 테스트를 만들며 진행한다.

하지만 몇 초가 지나지 않아 아직 만들지도 않은 클래스나 함수의 이름을 써야 하고, 그 때문에 단위 테스트는 컴파일 되지 않는다.

따라서 테스트가 컴파일되도록 제품 코드를 만들어야 한다.

하지만 그 이상의 제품 코드를 만들면 안 되기 때문에 단위 테스트를 더 만들기 시작한다.

거듭해서 주기를 반복한다.

테스트를 조금 추가한다.

제품 코드도 추가한다.

두 가지 흐름이 동시에 자라나 상호 보완하는 컴포넌트가 된다.

항체와 항원처럼 테스트와 제품 코드가 딱 들어맞는다.

사실 이런 능력까지 가기 위해선 단위 테스트 코드를 많이 짜봐야 하고 객체지향적 사고가 충분해야 역으로 설계가 가능하다.

단순 창발성을 고려하여 미로에서 탈출 경로를 짜는 DFS알고리즘의 형태를 머리로 그리기 위해선 당연히 설계를 할 줄 알아야 한다고 생각한다.

수많은 혜택

확신

TDD는 프로다운 규칙으로 받아들이면 테스트를 하루에 십여 개, 일주일에 수백 개, 일 년에 수천 개를 만든다.

게임으로 따지자면 확보된 시야로 자신이 걸어가는 길에 와드를 박아두어 자신의 백그라운드에 확신을 심어주는 것이다.

결함 주입 비율

테스트가 확보되면 시간이 기하급수적으로 줄어든다.

테스트만 통과하면 출시할 수 있을 정도이다.

용기

왜 나쁜 코드를 봐도 고치지 않을까?

1장에 나왔지만, 건드리는 순간 책임을 져야하기 때문이 아닐까?

아니면 내가 생각한 애정 자체가 없거나.. 스스로 프로라고 생각하지 않아서?

하지만 말끔히 정리해도 해당 기능을 망가뜨리지 않을 수 있다는 확신이 생긴다면? 테스트 코드..!

이런 믿음이 프로그래머의 개발 속도에 엄청난 영향을 준다.

문서화

테스트 코드만큼 완벽한 문서화는 없다.

해당 기능을 동작하기 위한 테스트이기 때문에 프로그래머에게 인수인계를 할 때 글을 주저리 적는 것 보다 테스트 코드 자체를 이해하는 것이 더 효율적이다.

설계

세 가지 법칙에 따라 테스트를 먼저 만들다 보면 딜레마에 빠진다.

어떤 코드를 만들어야 하는지 정확히 아는 데 불구하고, 법칙을 따르려다 보니 제품 코드가 없어 실패하는 단위 테스트를 먼저 만들어야 한다.

이는 만들려는 코드를 반드시 테스트해야 한다는 뜻이다.

테스트 코드를 만들려면 코드의 의존관계를 고립시켜야 한다는 어려움이 있다.

다른 함수를 호출하는 함수는 테스트하기 어려운 경우가 많다.

이 경우 테스트를 만들려면 다른 부분에서 떨어뜨리는 방법을 찾아야 한다.

다른 말로 테스트를 먼저 만들기 위해서는 좋은 설계를 고민해야 한다.

프로다운 선택

최종 결론은 TDD는 프로다운 선택이라는 사실이다.

TDD는 확신, 용기, 오류 감소, 문서화, 설계를 향상시키는 원칙이다.

TDD와 관련 없는 사실

TDD는 마법이 아니다. (은총알이 아니다.)

느낀점

테스트코드의 중요성은 사실 작은 프로젝트에선 보기 힘들다.

엔트로피가 증가함에 따라 기하급수로 증가하는 버그나 투자 시간을 경험해보면 절실해지는 것 같다.

TDD는 좋은 선택이라는 것도 잘 알지만, 지금 내 수준에선 테스트 코드에 대한 경험이 먼저라고 판단된다.

논의사항

• 나쁜 코드라고 생각하고 지나치신 경험이 있다면 이유가 무엇인가요?

저는.. 이제는 그렇지 않겠지만 당시에는 feature를 빠르게 보여주기 위해서 넘어갔던 것 같습니다.

결국엔 다시 저에게 레거시로 돌아와 그만큼을 넘는 시간을 투자해야 했지만..

6장 연습

모든 프로는 기술 연마 훈련을 통해 그들의 기예를 갈고 닦는다.

연습의 배경지식

main()
{
    printf("Hello World!\n");
}

코딩에서 연습이란 무슨 의미일까?

0이 22개

저자가 산 맥북 프로는 과연 지금과 얼마나 차이가 날까..?

기술의 발전이 이토록 빠른데 과연 10년 뒤에는 내가 무슨 사양의 노트북을 쓰고 어떤 툴로 게임을 개발하고 있을지?

새로운 언어와 툴을 등장으로 갈아타게 되면서 새로운 특이점이 올까?

변해버린 시대

이미 변해버린 시대에 살고 있는 우리는 이 시대에 녹아들면 안된다.

항상 경계하고 새로운 학습에 열려 있어야 한다.

물론 견습공과 숙련자는 새로운 학습에 대해 시선을 달리 하겠지만.

프로그래머는 더욱 경계해야 한다..!

연습에 관해서는 함께 자라기 책을 추천한다.

코딩 도장

저자의 첫 품새는 볼링 게임 TDD과정이라고 한다.

관련 글

품새

무술에서 품새라고 쓰이고 소프트웨어에서도 품새라고 쓰이는 지 몰랐다.

나는 패턴정도로 쓰이는 줄 알았다.(디자인 패턴이 아닌, 스스로 적용한 패턴)

한국에선 이런 품새를 학습? 하기 위해 알고리즘 품새를 따고 취직전 품새 겨루기(코딩 테스트)를 통해 취업하는 모습을 상상하니 생각보다 재밌다.

합 맞추기

단위 테스트를 서로 짜주는 방식은 생각보다 흥미로워서 적용해볼만 할 것 같다.

상대방이 생각하지 못한 부분의 테스트 코드라면 도움이 될 것

대련

합 맞추기나 대련이 짝 프로그래밍, 코드리뷰로 확장될 수 있을 것 같다.

경험의 폭 넓히기

회사가 업무에 필수인 단 하나의 언어, 플랫폼, 도메인을 강요하는 경우가 많다.

영향력을 넓히지 못하면 자신의 경력과 사고 방식이 해로울 정도로 좁아진다.

예를 들어 자체엔진의 메이플?(메이플을 비하는 것은 아니다. 개발자로서 성장이 제한되지 않을까? 라는 생각)

오픈소스

변화의 물결을 따라잡는 한 가지 방법은 의사나 변호사처럼 하는 것이다.

오픈소스 프로젝트에 기여해 공익에 봉사하라.

오픈소스는 수없이 많으며 다른 사람들이 관심을 가지는 일에 적극적으로 뛰어드는 행동은 자신의 기술 목록을 다양화하는 최고의 방법이다.

C++을 제대로 공부해서 Godot엔진 오픈소스에 기여를 꼭 해보고 싶다.

연습에 관한 윤리

프로 프로그래머는 개인 시간에 연습한다.

취업한 프로그래머를 구분해내는 방법은 간단하다. 그 사람의 깃허브를 보면 토, 일에 잔디가 심어져 있지 않다면 그 사람은 취업한 사람이다.(ㅋㅋ..)

결론

모든 프로는 어떤 식으로든 연습한다.

느낀점

내가 과연 취업을 한다면, 꾸준하게 책을 읽거나 기술에 대해서 공부를 할까?

지금은 한다고 말할 수 있지만..(이미 습관화 되어버린?) 과연 할까?

논의사항

• 진행중인 품새?가 있다면 알려주세요!

저는 북클럽도 일종의 품새라고 생각합니다.. 품새보단 지속가능한 연습, 공부에 가깝네요

7장 인수 테스트

개발은 물론이고 의사소통 또한 프로 개발자의 업무이다.

입력이 형편없으면 출력도 형편없다.

GPT에게는 해당되지 않는 말.. 입력 맨날 똥으로 주는데 출력이 엄청나다;;

요구사항 관련 의사소통

프로그래머로서 단순 코딩만 하고 싶다면 당장 1인개발을 하는게 좋다.

내 기준 프로그래머로써 가장 중요하다고 생각되는 역량이 커뮤니케이션이다.

프로그래머와 사업부 사이에 가장 흔한 의사소통 쟁점은 요구사항이다.

사업부는 자신들이 필요하다고 생각했던 바를 나름대로 표현하면, 프로그래머들은 사업부에서 이런 식으로 서술했다고 믿는 바를 나름대로 구현한다.

그러나 현실에서는 요구사항 관련 의사소통은 엄청나게 어렵고, 그 과정에는 오류가 가득하다.

시기상조의 정밀도

사업부와 프로그래머는 모두 시기상조의 정밀도라는 함정에 빠지기 쉽다.

사업부는 프로젝트를 승인하기 전에 일이 어떻게 진행될지 정확히 알고 싶어한다.

개발자들이 프로젝트를 추정하기 전에 어떤 제품을 만들어야 할지 정확히 알고 싶어한다.

한마디로 말해 양쪽이 원하는 정밀도는 불가능하고, 그런 정밀도를 얻기 위해 예산을 낭비하는 일도 많다.

불확실성의 원칙

리뷰하며 많이 다룬 말이지만, 불확실성은 정말 중요하다.

불확실성은 매번 등장하고 유연하게 대처하는 것이 중요하다.

이는 개발에 관한 영역에서 동 떨어져 있어서 쉽게 패닉이 오곤 하는데, 이때 지쳐서 번 아웃이 오기도 한다.

불안한 추정

개발자 또한 정밀도 함정에 빠진다.

개발자는 시스템 구현을 추정해야 한다.

그리고 시스템 추정에 정밀도가 필요하다고 생각하지만, 그렇지 않다.

첫째로 완벽한 정보로 추정을 한다 해도 추정에는 큰 편차가 생기고야 만다.

둘째로 불확실성 원칙이 초기 정밀도를 엉망으로 만든다.

요구사항은 반드시 바뀌기 때문에 초기 정밀도는 고려할 가치가 없다.

프로개발자는 정밀도가 낮은 요구사항을 바탕으로 추정해야할 때가 많고, 그런 추정이 말 그대로 추정이라는 사실을 잘 안다.

프로 개발자는 이를 보강하려고 항상 추정에 오차범위를 추가해 사업부에서 불확실성을 이해하게 만든다.

때늦은 모호함

시기상조의 정밀도를 해결하려면 가능한 정밀도를 늦추면 된다.

프로 개발자들은 개발 직전까지도 요구사항에 살을 붙이지 않는다.

하지만 이러다 보면 또 다른 병폐인 때늦은 모호함으로 이어지게 된다.

이해당사자들은 의견이 어긋나는 경우가 잦다.

그런 경우 의견 불일치를 해결하기보다는 매끄러운 말 쏨시로 우회하는 게 더 쉽다는 것을 알게 된다.

실제로 분쟁을 해결하지 않고, 모두가 동의하도록 요구사항의 표현을 바꾸는 방법을 찾아낸다.

요구사항 문서의 모호함은 이해당사자들 간의 논쟁을 대변한다.

반대로 이해당사자가 보기엔 완벽하게 분명한 일도 그걸 판독하는 프로그래머에게는 뭔가 완전히 다른 의미가 되기도 한다.

인수 테스트

꼭 인수 테스트가 아니더라도 같은 작업자 끼리의 용어는 통일하는 것이 좋다.

‘완료’에 대한 정의

앞 장에서 나온 이야기지만 완료라는 정의를 작업자끼리 통일하는 것이 좋다.

프로개발자에게 완료에 대한 정의는 하나 뿐이다.

완료란 다 됐다는 뜻이다.

모든 코드를 다 작성했고, 모든 테스트를 통과했고, QA와 이해당사자들에게 이를 인수했다는 것

의사소통

인수 테스트의 목적은 소통, 명확성 및 정밀성이다.

개발자, 이해당사자 및 테스트 모두 동의함으로써 시스템 행동을 위한 계획을 이해한다.

자동화

인수 테스트는 언제나 자동화해야 한다.

소프트웨어 생명주기에 수작업 테스트과정이 있지만, 인수 테스트는 결코 수작업이 되어서는 안된다.

그 이유는 단순하다. 비용 때문이다.

추가 작업

테스트 자체를 추가 작업으로 보지 말고 많은 시간과 비용에 대한 절약으로 볼 수 있다.

이를 한번 더 자동화를 한다면 작업자가 한명 줄어든 셈..

누가, 언제 인수 테스트를 작성하는가?

테스트를 작성하는 개발자들은 테스트를 거친 기능을 실행하는 개발자들과는 같지 않다는 점을 유의해야 한다.

인수 테스트는 ‘늦은 정밀성’의 원칙에 따라 보통 기능 구현 며칠 전에 가능한 늦게 작성해야 한다.

애자일 프로젝트에서 테스트는 다음 반복 주기나 전력질주에서 구현할 기능을 선정한 후에 작성한다.

최초의 몇몇 인수 테스트는 반복 주기의 첫째 날에 준비가 되어야 한다.

매일 더 많은 인수 테스트를 완성해서 반복 주기의 중간 지점에는 모든 인수 테스트가 준비돼야 한다.

개발자의 역할

기능 구현 작업은 그 기능의 인수 테스트가 준비되면 시작한다.

개발자는 새 기능에 대한 인수 테스트를 실행해서 오류 과정을 살핀다.

그런 다음 인수 테스트를 시스템에 연결하는 작업을 하고 원하는 기능을 실행해 테스트 통과 과정을 시작한다.

요점은 시스템에 인수 테스트를 연결한 다음 테스트를 통과시키는 것은 개발자의 몫이라는 점이다.

테스트 협상과 수동적 공격성

테스트를 만든 사람도 인간이므로 실수를 한다.

때때로 작성된 테스트를 실행 시켰을 때 너무 복잡하고 서툴러서 제대로 되지 않는 경우가 있다.

잘못된 가정을 했거나 그냥 틀린 경우도 있다.

이것은 테스트를 통과시키려는 개발자에게 매우 당혹스러운 일이다.

명심해야 할 일은 가능한 최상의 소프트웨어를 만드는 데 도움을 주는 것이 프로의 일이라는 것이다.

이는 모든 이가 오류와 실수를 살펴서 그것들을 함께 바로 잡는 것이 필요하다는 뜻이다.

인수 테스트와 단위 테스트

인수 테스트는 단위 테스트가 아니다.

단위 테스트는 프로그래머가 프로그래머를 위해 만든다.

단위 테스트는 코드의 최하위 구조와 행동을 설명하는 공식 디자인 문서이다.

단위 테스트를 읽는 사람은 사업부가 아니라 프로그래머다.

인수 테스트는 사업부를 위해 사업부가 작성한다.

테스트를 두 가지나 만드는 일은 불필요하다고 가정함으로써 ‘추가 작업’을 없애는 일이 달콤해 보일지도 모른다.

단위 및 인수 테스트가 똑같은 사항을 테스트하는 것이 사실이지만, 불필요한 일과는 거리가 멀다.

같은 내용을 테스트할지라도, 다른 메커니즘과 경로를 통해서 테스트한다.

GUI 및 다른 문제점

GUI는 제대로 명세하기 어렵다.

할 수는 있지만 잘 하기가 쉽지 않다.

그 이유는 미학이라는 게 주관적이어서 논란의 여지가 있기 때문이다.

그래서 GUI에 대한 인수 테스트 작성이 어렵다.

묘안은 GUI가 일련의 버튼, 슬라이더, 그리드 및 메뉴라기보다는 API인 것처럼 GUI를 만들도록 시스템을 설계하는 것이다.

단일 책임 원칙(SRP)이라는 디자인 원칙이 있듯이 이 원칙이 다른 이유로 바뀌는 것들은 분리하고 같은 이유로 바뀌는 것들은 함께 모아야 한다는 내용을 나타낸다. GUI도 같다.

올바른 인터페이스를 통한 테스트

더 나은 방법은 GUI를 통하는 것보다 실제 API를 통해서 기본 시스템의 기능을 불러오는 테스트를 작성하는 것이다.

이 API는 GUI가 사용하는 API와 같아야 한다.

새로운 내용이 아니다.

설계 전문가들은 수십 년 동안 업무 규칙과 GUI를 분리하라고 말해왔다.

GUI 테스트를 최소한으로 유지하라.

테스트들은 GUI의 취약성으로 깨지기 쉽다.

지속적 통합

CI/CD는 개발자 한명을 덜 쓰는 것과 같다.

출시를 멈춰라

테스트가 통과되지 않는다면 출시를 멈춰라.

결론

세부사항에 대한 의사소통은 어렵다.

특히 애플리케이션의 세부사항에 대해 의사소통 해야 하는 프로그래머와 이해당사자에게 들어맞는 말이다.

서로에게 말없이 손만 흔든 다음 상대방이 이해했을 거라 가정해 버리면 일은 너무 쉬워진다.

느끼점

의사소통은 매번 말하지면 솔직해야 하는 것 같다..

인수테스트와 단위 테스트에 대한 구별이 확실하게 되는 내용이라 따로 검색해보면서 더 알아봤다.

논의사항

• 테스트 코드에 대한 이해도가 가장 높아진 제목이 뭔가요?

다들 알고리즘을 풀 때 푼 내용이 해당 알고리즘의 테스트 코드를 통과한다 라는 느낌을 아실까요? 대학생레벨에서 테스트 코드를 짜고 공부하기는 쉽지 않아서 실제로 회사에서 많이 배운다고 하더라구요 (안짜는 회사도 많다고 합니다.)

8장 테스트 전략

테스트는 단순히 단위 테스트나 인수 테스트 작성만으로 끝나는 문제가 아니다.

단위 테스트나 인수 테스트 작성은 훌륭한 일이긴 하지만 결코 충분하지 않다.

프로 개발팀이라면 훌륭한 테스트 전략이 필요하다.

QA는 오류를 찾지 못해야 한다

앞 장에서 나온 이야기지만 회사에 QA가 있더라도 개발팀은 QA가 잘못된 점을 찾지 못하는 상태를 목표로 삼아야 한다.

이 이야기는 사실 다른 개발책에서 하는 말과 같은 맥락인 이상적인 목표에 가깝다.

완벽한 코드는 없지만, 완벽한 코드를 추구해야 한다.(프로젝트에 맞는 코드를 추구해야 한다.)

마찬가지로 QA는 무조건 버그를 찾아내겠지만, 개발팀은 QA가 버그를 찾지 못하도록 노력해야 한다.

QA는 같은 팀이다

QA와 개발자는 시스템 품질 향상을 위해 힘을 합쳐야 한다.

팀원으로서 QA의 가장 중요한 역할은 명세서술과 특징 묘사다.

QA의 명세서술

QA의 역할은 사업부와 함께 자동화된 인수 테스트를 만드는 일이다.

그렇게 만든 인수 테스트는 시스템에 대한 진정한 명세서이자 요구사항 문서다.

QA의 특징 묘사

QA는 탐색 테스트를 수행해 작동 중인 시스템의 실제 동작을 묘사하고 이 동작을 개발팀과 사업부에 보고하는 일이다.

시스템의 실제 동작을 식별하는 일을 맡는다.

테스트 자동화 피라미드

QA가 오류를 찾지 못하리라는 확신을 가지려면 상위 계층 테스트 또한 필요하다.(컴포넌트)

단위 테스트

테스트 자동화 프라미드는 지금 내가 하고 있는 XUnit(유니티는 NUnit) 단위 테스트가 가장 아래에 위치해 있다.

단위테스트는 프로그래머에 의해, 프로그래머를 위해 시스템 프로그래밍 언어로 만든 테스트다.

이 테스트는 시스템 최하위 계층을 명세하려는 의도로 만든다.

테스트 코드는 지속적 통합(CI)의 일부로 실행되어 프로그래머가 의도한 바를 지켜낸다.

단위 테스트의 커버리지는 최대한 100%애 가까워야 한다.

즉, 모든 함수와 모든 분기에 대해 테스트를 작성해야 한다.

컴포넌트 테스트

컴포넌트 테스트는 피라미드 아래에서 두번째에 위치한다.

인수테스트의 일종으로 컴포넌트 테스트의 대상은 시스템의 독립 컴포넌트이다.

컴포넌트 테스트는 컴포넌트를 감싸고 있으며, 컴포넌트에 입력 데이터를 넣고 출력 값을 받아 모은다.

입력 값에 대해 출력 값이 올바른지 테스트한다.

유니티에서 이 컴포넌트 테스트는 한 컴포넌트 단위로 이해해도 좋을 듯 하다.

즉, 하나의 MonoBehaviour를 가지고 있는 컴포넌트 C# 클래스를 테스트하는 것이다.

NSubstitute를 이용해 Mocking하여 흉내내는 객체를 만들어서 테스트 더블이 필요한 경우에는 이를 이용하면 된다.

하지만 유니티에선 이런 테스트 더블이 필요한 경우가 많지 않다.

플레이 모드에 대한 테스트가 가능하기 때문에 (실제로 열어서 보면 씬 하나를 만들어서 직접 Play레벨에서 테스트가 가능하다.)

따라서 디바이스에 한정되는 것이 아니라면 테스트를 PlayMode에서 목킹을 만들지 않고 실제 객체로 테스트하는 것이 효율적이라는 것

통합 테스트

통합 테스트는 피라미드 아래에서 세번째에 위치한다.

통합 테스트는 여러 컴포넌트로 이뤄진 큰 시스템에서만 의미가 있다.

이 테스트또한 유니티에선 PlayMode에서 UnityTest애트리뷰트로 설정하여 좀 복잡할 수 있지만 컴포넌트끼리의 관계를 설명하기 위한 통합 테스트작성이 가능하다.

시스템 테스트

시스템 테스트는 피라미드 아래에서 네번째에 위치한다.

시스템 테스트는 통합한 시스템 전체를 대상으로 하는 자동화 테스트다.

다시 말해 궁극적인 통합 테스트다.

게임에서 이 레벨까지 가능 경우는 보지 못했기 때문에,, 만약 본인이 좋은 회사에 들어간다면 볼지도 모르겠다.

수동 탐색 테스트

이 테스트는 피라미드 가장 위에 위치한다.

게임으로 따지면 실제 QA분들이 게임을 플레이하면서 버그를 찾아내는 것이다.

일부러 오류를 찾기 위해 노력하며, 게임에서는 비슷한 형태로 유저에게 이 역할을 맡기기도 한다.(테스트 서버)

결론

TDD는 강력한 원칙이며 인수 테스트는 요구사항을 표현하고 강화하는 가치있는 방법이다.

느낀점

최근에 계속 테스트 코드를 작성하며 느끼는 점이지만, 테스트 코드는 프로젝트가 장기적일 수록 당연히 중요하지만 개인적 성장에도 매우 큰 도움을 준다는 느낌이다.

TDD는 조금 먼 미래(설계를 제대로 할 줄 알아야 가능)이지만, 단위 테스트 코드는 당장 추천해주고 싶다.

객체지향적으로 코딩하는 새로운 지평이 열리기 때문이다.(실제로 다른 책에서도 언급)

테스트 코드를 항상 생각하고 코드를 짜게 되면 결합도는 낮고 응집도는 높은 코드를 작성하게 된다.

논의사항

• 스스로 작성하신 코드가 테스트 코드가 작성 가능한 레벨인가요? 작성 해보셨나요?

느낀점의 연장이지만, 스스로 테스트 코드작성 가능한 코드를 작성중이신지 궁금합니다.

논외로 한명의 프로그래머로써 테스트 코드의 중요성을 이해하지만 게임업계에서 잘 쓰이는 지는 확신하지 못하겠습니다.

물론 대기업의 경우 쓴다고 100% 생각합니다. (만약 작성하지 않는 다면 다른 방식으로도 테스트코드와 같은 검사체계를 만들어 놨을 것)

9장 시간 관리

8시간은 정말 짧은 시간이다. 480분 혹은 28,800초밖에 되지 않는다.

프로라면 시간을 효율적으로 써야하고, 아까운 시간을 낭비하지 않아야 한다.

자신이 스스로 하루에 대해 스케줄링 하고 그것을 잘 지키는 지 확인해보자.

나의 경우 아래와 같은 스케줄을 짜고 있다.

githun action을 통해 하루 Todo를 생성하고, 해당 Todo에 미리 생각해놓은 일정을 집어 넣어 하루에 대한 스케줄을 짜고 있다.

이 글을 작성중인 23년 11월 14일의 Todo는 다음과 같다.

나도 매일 잘 지킨다고 말하긴 어렵지만 최대한 지키려고 노력하고 있다.

점점 좋아진다는 느낌도 받고 있어서 자신만의 일정을 관리하는 것은 중요하다.

좀 더 이야기 한다면 Project로 일정 전체를 관리하기에 효율적이다. 미리 2주정도의 계획을 잡아두고 불확실성이 강한 일정의 경우 해당 이슈의 코멘트로 관리하기 때문에 편리하다.

최근에는 여기에 옵시디언까지 활용하여 메모또한 분리했다.

회의

회의는 참석자마다 시간당 약 20만원의 비용이 든다.

회의에 대한 두 가지 진실은 다음과 같다.

• 회의는 필요하다.
• 회의는 엄청난 시간 낭비다.

매우 동의한다.

거부하기

요청을 받았다는 이유로 모든 회의에 참석할 필요는 없다.(프로의 경우다 프로, 신입의 경우는 다르다.)

개발자는 시간을 영리하게 사용해야 한다.

그러므로 신중하게 참석할 회의와 거절할 회의를 골라야 한다.

빠져 나오기

회의는 계획대로 흘러가지 않을 때가 많다.

저자의 규칙의 경우 회의가 지루하다고 느낄 땐 바로 빠져나오는 것이다.(한국에서 가능?)

하지만 내가 운영하는 팀에서 이렇게 정신을 차릴 수 있는 찬물을 부워주면 좋겠다..

회의 자체가 길어지는 경우가 종종 있는데, 이럴 땐 회의를 그냥 중단하고 환기하는 것이 더 좋다고 생각하긴 한다.

의제와 목표를 정하라

비용이 비싼 회의를 감내하는 이유는 특정 목표 달성을 서로 도우려면 정말로 참석자들이 한 방에 모여야 하기 때문이다.

참석자들의 시간을 현명하게 사용하려면, 회의에는 명확한 의제가 필요하며 주제별로 시간과 목표를 명확히 정해야 한다.

개인적으로 참석자도 어느정도는 회의에 대해 생각하고 와야겠지만, 가장 중요한건 회의를 만든이가 의제를 명확하게 하고, 회의에 대한 전반적인 생각을 하고 참석하는 것이라고 생각한다.

일일 회의

일일 회의는 애자일 개발의 규범 중 하나다.

일일 회의의 또다른 말은 스탠드 업 미팅이다.

각 참석자들이 매일 자기 차례에 다음과 같은 질문에 대답한다.

• 어제는 뭘 했는지?
• 오늘은 뭘 할 건지?
• 방해요소는 없나?

이게 전부며 모든 답변은 20초를 넘지 않아야 한다.

즉 10명이 모여도 10분이 채 걸리지 않는다.

반복 계획 회의

반복 계획 회의는 애자일 개발의 규범 중에서 가장 잘 해내기 어려운 일이다.

이 것도 또한 스크럼 회의라고도 한다.

반복 주기를 설정하고 미리 다음 일정에 대한 추정이 끝나야 함..

실제 진행중인 프로젝트에서도 적용중인데 아직까지도 잘 안되고 있다.

반복 회고와 시연

반복 회고와 시연은 각 반복 주기가 끝날 때마다 시행한다.

팀원들은 무엇이 잘 됐고 무엇이 잘못됐는지 토론한다.

이해관계자들은 새로 작업한 기능의 시연을 본다.

이 회의는 아주 나쁘게 흘러가거나 엄청난 시간을 소모하기 쉬우므로, 반복 주기의 마지막 날 업무 종료시간으로 잡는다.

내가 운용하는 팀은 이를 정기 회의시간에 같이 진행한다.

회고는 2주에 한번 진행하고 시연은 완성된 결과물을 1주에 한번씩 직접 빌드하여 시연한다.

논쟁/의견 차이

어떤 논쟁이든 5분 안에 해결되지 않으면 논쟁으로는 해결할 수 없다.

켄트 벡

논쟁이 길어지는 이유는 양쪽 모두 근거가 되는 명백한 증거가 없기 때문이다.

기술적인 면에서 나타나는 의견 차이는 보통 대기권을 돌파하는 경우가 많다.

양측은 자기 입장을 끝없이 정당화하지만 실제 데이터를 가진 경우는 드물다.

성깔로 논쟁을 이기려는 부류도 있다.

하지만 성깔로는 논쟁을 마무리짓지 못한다.

데이터가 꼭 필요하다.

어디 잘 되나 보자는 심보인 수동적 공격성을 가진 부류도 있다.

논쟁을 끝내기 위해 동의를 하긴 하지만 해결안에 참여하기를 거부하는 식으로 결과에 찬물을 끼얹는다.

이런 부류는 “이 방식은 다른 사람들이 원한 방식이야. 어디 한번 원하는 대로 해보라지.”라고 스스로에게 말한다.

이런 행동은 프로답지 못한 행동중에도 프로답지 못한 행동이다.

일단 동의했다면, 반드시 참여해야 한다.

이런 수동적 공격성을 지닌 인물과 작업을 해본적이 있다. 처음엔 답답했지만 뒤에 가선 불쌍했다. 회피할 생각만 하고 자신의 의견을 쉽게 꺼내지도 못하는..

자신이 있다면 말했을 것 스스로도 부족한 걸 알아서 그랬다고 생각한다.

의견 차이를 해소하기 위한 데이터는 일단 해보는 것이다. 동전을 던지든 하나를 선택하든 결과에 같이 책임을 지고 해보는 것이다.

만약 일이 잘 돌아간다면 쓸 만한 길을 선택했다는 것

집중력 마나

프로그래밍은 지적인 행위로 긴 시간 정신을 모아 집중해야 한다.

집중력은 소중한 자원으로 마나와 비슷하다. (다 쓰면 집중을 통해 회복해야 한다.)

프로 개발자는 이를 인지하고 자신의 집중력을 잘 관리해야 한다.

수면

수면은 아무리 강조해도 지나치지 않다.

다른 책에서 읽은 말로 평생 1인개발을 할 것이 아니라면 저녁에 자고 아침에 작업해야 한다.

자신은 저녁에 집중이 잘 되기 때문에 새벽 작업을 한다?

그렇다면 아침 작업이 가능하도록 다시 몸을 세팅해야 한다.

나도 최근에는 잠을 자는 시간을 오전 3시를 절대 넘기지 않으려고 한다.

오전 3시도 많이 늦어서 1시까지 당길 예정..

카페인

카페인을 섭취하면 집중력 마나를 더 효율적으로 쓸 수 있다는 사실은 당연하다.

하지만 카페인은 내성이 생길 수 있다.

자신의 몸을 객관적으로 다시 한번 바라볼 필요가 있다.

재충전

집중을 풀면 마나가 일부 회복되기도 한다.

기분좋은 산책, 친구와 대화, 잠시 창 밖을 바라보기 등 스스로 안정감을 느끼고 풍요로움을 느끼는 순간을 찾아라.

나는 개인적으로 드라마 한편 보기..

근육 집중

근육또한 코딩에 필요한 집중과는 다르지만 집중력을 향상시키는데 도움이 된다.

나는 아침에 정말 간단한 운동을 하고 있다.

최소한의 양심으로..

입력 vs 출력

집중에 필요한 다른 한 가지는 적절한 입력과 출력의 균형을 맞추는 것이다.

창의적인 생각을 하기 위해선 창의적인 입력이 필요하다.

그 사람의 모든 생활 출력은 그 사람이 살아온 환경을 알 수 있듯이, 자신이 원하고 끌어당기는 것은 스스로 많이 접하는 것과 관련이 있을 것이다.

나는 드라마나 영화, 책을 많이 보기 때문에 이런쪽에 영향을 많이 받은 듯 하다.

타임박스와 토마토

시간관리와 집중을 관리하기 위해 뽀모도로라는 매우 효율적이고 유명한 기법이 있다.

소프트 스킬, 개발자 마인드셋 관련 책을 많이 읽다보니 항상 이런 비슷한 이야기들이 나온다.

그중에서 뽀모도로도 포함이 되는데 나도 항상 사용중이다.

책에선 25분 집중 5분 휴식을 한 싸이클로 4번 이후에 30분정도 길게 휴식한다.

나는 조금 익숙해져서 50분 집중 10분 휴식 4번 이후 30분 휴식을 한다.

아직 나는 숙련자는 아니지만 많이 사용한 사람과 대화했을 때 놀란 점은 모든 자신의 업무를 뽀모라는 단위로 관리한다는 것이다.

예를 들어 이번 주 Feature A에 대해 3뽀모정도로 예측하고 실제로 그렇게 행동하는 것이다.

개인적으로 느낀 가장 좋은 점은 자기가 집중한 시간에 대해 객관화가 가능하다는 것이다.

하루를 끝낼 때 내가 정확하게 집중만 한 시간에 대해 메타인지가 가능해지면서 스스로를 과대 평가하지 않고 일정을 적절하게 배분한다는 점이다.

대부분, 아니 거의 사람들은 자신을 과대평가하는 경향이 있다. 그래서 항상 계획이 실패한다.

피하기

어떤 때는 그저 일이 손에 잡히지 않기도 한다.

해야할 일이 무섭거나 불편하거나 지루해서 그럴지도 모른다.

아마 빠져나올 수 없는 구멍으로 끌려들어가는 느낌일 것이다.

아니면 단순히 하기 싫어서 그럴지도 모른다.

우선순위 뒤집기

이유가 뭐든 간에 눈 앞의 업무를 피하는 길을 찾아볼 때가 있다.

일보다 다른 일이 더 급하다고 스스로를 설득하기도 한다.

이런 이를 우선순위 뒤집기라고 부른다.

다른 업무의 우선순위를 높여 정말 중요한 일을 뒤로 미룬다.

우선순위 뒤집기는 스스로에게 하는 거짓말이다.

정말 끝나야 하는 업무를 마주할 수 없어서, 다른 업무가 더 중요하다고 자신을 설득한다.

아니라는 사실을 알면서 스스로에게 거짓말을 한다.

정확히 말하면 거짓말이 아니다. 실은 다른 사람이 뭘 하는지 왜 그 일을 하는지 물을 때를 대비해 거짓말을 준비하는 것이다.

사람은 정말 이중적인 존재다.

당연히 프로답지 못한 행동이고.

프로는 개인적인 두려움과 바람은 제쳐두고 각 업무의 우선순위를 검토하고 우선순위에 따라 순서대로 업무를 진행한다.

우선순위관련해서 다른 책에서 읽은 좋은 방법이 있어서 적어본다.

자신의 일정의 중요도를 우선순위 큐 형태로 관리하여 항상 우선순위를 먼저 처리하는 형태로 진행하는 방법이다.

막다른 길

막다른 길은 모든 소프트웨어 장인들이 피할 수 없는 삶의 현실이다.

가끔은 의사결정 후 기술의 오솔길을 따라 이리저리 돌아다녀 보지만 아무 곳에도 도착하지 못한다.

결정이 확고할수록 황무지에서 헤매는 시간이 길어진다.

프로로서의 명성이 걸린 일이라면 영원히 헤매게 된다.

신중함과 경험으로 특정 막다른 길은 피할 수 있지만, 전부 피할 순 없다.

따라서 정말 필요한 기술은 막다른 길에 도달했을 때 재빨리 알아채고 뒤로 물러날 용기를 가지는 일이다. 이를 구덩이의 법칙이라 부르기도 한다.

막다른 길이면 그만 파라

내용이 조금 추상적일 수 있어도 막다른 길은 다들 한 번씩 만났을 꺼라 생각한다.

진흙탕, 늪, 수렁, 기타 엉망진창

진흙탕은 막다른 길보다 더 나쁘다.

진흙탕은 굼뜨게 만들지만 길을 막지는 않는다. 하지만 오히려 더 나쁘다.

차라리 털고 나와서 다른 평탄한 길을 찾는 것이 더 좋다.

그렇다고 진흙탕에 안빠지는 것이 아닌 개발과정에서 항상 마주하게 되는 함정이다.

진흙탕에 빠지는 일은 자신도 모르게 일어난다.

처음에는 간단한 문제에 대한 해결책을 만들고, 코드를 주의깊게 관리해 단순하고 깔끔하게 만든다.

문제의 범위와 복잡도가 커지면서 기반 코드를 확장하고 최선을 다해 깔끔하게 만든다.

하지만 어느 순간 처음부터 설계가 잘못됐고 코드가 요구사항이 움직이는 방향으로 뻗어나가지 못한다는 사실을 깨닫게 된다.

이때가 변곡점이다.

뒤로 물러나서 설계를 고칠 수 있다. (리팩터링이 필요한 이유다.)

반대로 계속 앞으로 나아갈 수도 있다.

되돌아가는 것은 기존 코드를 재작업해야 하기 때문에 비용이 비싸 보이지만, 이때야말로 되돌아가기 가장 쉬운 지점이다.

앞으로 나아가면 시스템을 늪으로 끌고 들어가 절대 빠져 나오지 못하게 된다.

멀리 갈수록 가장 빠른 길이다. 그리고 급하면 넘어진다.

결론

프로 소프트웨어 개발자는 부지런히 시간과 집중력을 관리한다.

우선순위를 뒤집고 싶은 유혹을 이해하고, 이 유혹에 명예를 걸고 저항한다.

다른 여러 해결책에 마음을 열어 선택지를 넓힌다.

하나의 해결책을 포기하지 못할 정도로 너무 깊이 빠져들지 않는다.

진흙탕이 점점 커지는 것을 언제나 경계하고, 눈치채는 즉시 최대한 빨리 깨끗이 정리한다.

느낀점

이번 장은 다른 책에서 읽은 내용의 합성이라 느꼈다.

애자일 방법론과 자기 개발(소프트 스킬)부분이고 시간관리에 있어서 가장 강조하고 싶은 부분은 (경험상..) 자신을 과대 평가하지 말라는 것

나 자신에게도 항상 해주고 싶은 말이라 절대로 과신하지 말것!

과거에 읽고 정리한 글이 있는데 박종천개발자님의 GPAM이라는 방법이다.

글 첨부

논의사항

진흙탕 부분이 제일 재밌다고 생각되서 질문입니다..

• 진흙탕에 빠져보신 경험이 있나요? 그 때의 경험을 알려주세요

저는 첫 프로젝트에서 진흙탕에 빠졌지만 계속 전진했던 경험이 있습니다..

(약 1년전..?)

당시에 객체지향의 ㄱ자도 모르던 시절이라 구조적 프로그래밍만 반복하다.

프로그래밍 패턴을 알게 되고 FSM모델을 억지로 적용했다가 힘들게 작업했던 기억이…

지금은 좋은 반면교사로 남아서 좋긴 합니다.

만약 진흙탕에서 이미 많이 들어가버렸다면.. 그게 라이브 서비스, 개발 막바지가 아니라면 무조건 돌아가는게 좋다고 생각합니다.

10장 추정

추정은 프로 개발자가 접하는 일 중 가장 단순하면서도 가장 두려운 행위다.

추정이란 무엇인가?

문제는 추정을 서로 다른방향에서 바라본다는 점이다.

사업부는 추정을 약속으로 보길 좋아한다. 개발자는 추정을 어림짐작으로 보고 싶어한다. 어마어마한 차이가 있다.

PM과 개발자의 사이에 있다보면 추정에 대한 생각이 계속 변화한다. PM으로썬 프로젝트의 확실함을 보장해야 하고 개발자로선 좋은 구조를 위해 1보 후퇴가 필요할 때가 많다.

약속

약속은 꼭 지켜야 한다.

특정 날짜까지 끝내겠다고 약속했다면 그냥 그 날까지 끝내야 한다.

약속은 확실함에 관한 문제다. 다른 사람들은 나의 약속을 받아들이고 거기에 기반하여 계획을 짠다.

추정하기

추정은 어림짐작이다.

약속은 포함되지 않는다. 아무런 약속도 하지 않는다.

추정이 빗나가는 일은 전혀 불명예가 아니다. (추정 자체가 얼마나 걸릴지 모르기 때문)

추정은 숫자가 아니다. 추정은 분포다.

엉겹결에 해버린 약속

프로는 추정과 약속 사이에 명확한 선을 그어 구분짓는다.

프로는 확실히 성공한다는 사실을 알기 전에는 약속하지 않는다. 프로는 넌지시 암시된 약속도 하지 않도록 주의를 기울인다.

의사소통할 때는 추정의 확률 분포에 대해 가능한 선명히 밝혀 관리자가 적절한 계획을 세울 수 있도록 한다.

업무 추정

추정에 사용하는 자원 중 가장 중요한 자원은 주변 사람들이다.

주변 사람들은 본인이 보지 못하는 것을 본다.

주변 사람들은 혼자서 추정하는 것보다 더 정확하게 추정할 수 있도록 도와준다.

광대역 델파이

1970년 광대역 델파이라고 불리는 추정 기법이 등장했다.

세월이 흐르며 많은 변형이 일어났지만, 모두 하나의 공통점이 있다.

바로 의견일치다.

방법은 간단하다 팀을 꾸리고, 업무에 대해 토론하고, 추정하고, 합의에 도달할 때까지 토론과 추정을 반복한다.

날아다니는 손가락

모두가 한 탁자에 둘러 앉는다. 한 번에 하나의 업무에 대해서만 토론한다.

각 업무마다 필요한 것은 무엇인지, 혹시 곤란하거나 복잡하게 만들 일은 없는지, 어떻게 구현할지에 대해 토론한다.

그후 참석자는 얼마나 걸릴지 생각해서 탁자 밑에서 손가락으로 0~5까지의 숫자를 정한다.

이후 진행에 따라 손가락을 동시에 내민다.

모든 의견이 일치했다면 다음 업무로 넘어간다. 만장일치가 아니라면 어째서 의견이 엇갈렸는지 계속 토론한다. 의견 일치를 볼 때까지 반복한다.

계획 포커

날아다니는 손가락에서 손가락을 카드로 바꾼 것이다.

실제로 애자일 팀에서는 계획 포커를 사용한다. (스토리 포인트)

가장 해보고 싶은 방법

관계 추정

모든 업무를 카드에 적되 추정 값은 적지 않는다.

추정에 참여한 사람들은 카드가 흩어진 탁자나 벽 주위에 흩어져 선다.

참여자는 말을 하지 않고, 그저 카드를 상대적으로 비교해 정렬한다.

더 긴 시간이 필요한 업무는 오른쪽으로 옮긴다. 작은 업무는 왼쪽으로 옮긴다.

3방 추정

앞서 언급했던 방법으로 (적지는 않았다.) 세 추정 값으로 확률 분포를 만드는 게 목적이다.

큰수의 법칙

추정에는 오류가 가득하다.

그렇기 때문에 추정이라고 부른다.

오류를 다루는 방법 중 하나로 큰 수의 법칙을 따라 이득을 보는 방법이 있다.

큰 업무를 여러 개의 작은 업무로 쪼개 따로따로 추정하면, 하나의 큰 업무 추정 값보다 작은 업무들의 추정 값의 합이 정확해지는 게 이 법칙의 의미다.

더 정확해지는 이유는 작은 업무에 포함된 오류는 합쳐서 사라지는 경향이 있기 때문이다.

인생도 그렇고 OOP도 그렇듯 모든 항목에 있어서 세분화하는 것이 매우 중요하다.

문제를 좀 더 나눠서 볼 수 있는 센스, 시각이 개발자에게 있어서 매우 중요한 능력이라고 생각한다.

결론

프로 소프트웨어 개발자는 사업부가 계획을 짜는 데 실용적인 추정 값을 사업부에 전달해야 한다.

프로 개발자는 지킬 수 없는 약속은 하지 않으며, 달성할 수 있다는 확신이 없는 일은 약속하지 않는다.

프로가 약속을 할 때는 확실한 숫자를 제공하며 그 숫자를 지킨다. 하지만 프로라도 약속을 지키지 못할 때가 많다.

사실 프로가 말하는 숫자는 예상 완료 시간과 가능성 분산을 나타내는 가능성의 추정 값일 뿐이다.

느낀점

숙련된 개발자가 아닐수록 즉, 초급 개발자일수록 추정치는 매우 불안정해지고 해당 추정치를 지키기 위해 무리하다 결국 늪지대를 만드느게 아닐까라는 추측을 해본다.

프로젝트를 처음할 때도 대부분 추정치에 맞춰 일정을 짜고 팀원과 약속을 하기 때문에 해당 Feature를 개발하기 위해 거짓된 코드를 양산하기 때문에 결국 뒤에가서 그 빛을 갚게되는 것 같다.

적다보니 경험담이란 생각이..

스스로 얼마나 솔직해질 수 있는지가 관건이라는 생각이 든다.

논의사항

• 스스로 추정을 했을 때 발생한 오류의 빈도가 어느정도 인가요?
  • ex) 3일이라고 생각했지만 그 이상 걸린 경우의 비율

저는 약 40% 이상 빗나가는 것 같습니다.

추정도 물론 경험에 의해서 정교화될 수 있지만, 항상 오류나 기능의 부가적인 이유로 인해 추정치가 빗나가는 경우가 많은 것 같습니다.

그런 추정이 빗나간 상황에 대해 솔직하게 말할 수 있으면 좋겠네요!

11장 압박

프로 개발자는 압박감을 느껴도 침착하고 결단력있게 행동한다.

압박감이 커질수록 훈련과 규율을 따르는데, 이 방식이 압박의 주체인 마감일과 약속을 지키는 최선의 방법임을 알기 때문이다.

압박 피하기

압박을 받을 때 침착함을 유지할 수 있는 가장 좋은 방법은 압박감을 일으키는 상황을 피하는 것이다.

상황 회피는 압박을 완전히 사라지게 하지는 않지만 높은 압박을 받는 기간을 상당히 줄이고 최소화한다.

약속

10장에서 나왔듯이 확신이 없는 마감일 약속은 하지 않는다.

사업부는 위험을 없애기 위해 항상 약속을 원한다.

우리가 해야 할 일은 위험의 크기를 확실히 측정하고 적절히 관리할 수 있음을 사업부에게 알리는 것이다.

비현실적인 약속을 받아들이는 일은 이 목표 달성에 해를 끼치고 양쪽 모두 피해를 입힌다.

깔금하게 유지

마감일을 지키면서 빠르게 움직이는 방법은 언제나 깔끔한 상태를 유지하는 것이다.

프로는 빨리 움직이려고 마구잡이로 어지르고 싶은 유혹에 굴하지 않는다.

시스템, 코드, 설계를 가능한 한 깔끔하게 유지함으로써 압박을 피할 수 있다.

난장판은 우리를 느리게 만들고 날짜를 놓치고 약속을 지키지 못하게 한다.

따라서 최선을 다 해 일하고 만든것은 가능한 한 깔끔히 유지해야 한다.

위기는 규율이다

위기에 처했을 때의 모습을 관찰하면 어떤 믿음을 가지고 있는지 알게 된다.

위기에 처했을 때 훈련과 규율을 따른다면 진정으로 그 규율을 믿는다는 뜻이다.

반대로 위기 때 행동이 바뀐다면 평소 행동을 진심으로 믿지 않는다는 뜻이다.

보통 때는 TDD를 따르지만 위기가 닥쳤을 때 포기한다면, 마음 속 깊은 곳에서는 TDD를 믿지 않는다는 뜻이다.

평소에는 코드를 깔끔히 관리하다가도 위기가 닥쳤을 때 코드가 엉망이 된다면 마음 속 깊은 곳에서는 엉망진창 코드가 발목을 잡아 더 느리게 만든다는 사실을 믿지 않는다는 뜻이다.

압박 다루기

압박을 사전방지, 완화, 제거하는 행동들도 모두 좋지만, 아무리 주의를 기울이고 조심해도 압박은 찾아온다.

어떤 때는 단지 프로젝트가 조금 길어질 뿐이지만, 어떤 때는 초기 설계가 잘못돼 새로 작업해야 할 수도 있다.

당황하지 말자

스트레스를 관리하자.

잠 못 드는 밤은 빠른 일 처리에 도움이 되지 않는다. 불안해 하는 것도 마찬가지다.

최악의 행동은 급히 서두르는 것이다.

어떤 값을 치르더라도 이 유혹에 저항하라. 서두르면 빠진 구멍이 더 깊어질뿐이다.

서두르지 말고 속도를 늦춰라. 문제를 곰곰이 고민하자.

가능한 최선의 결과로 가능 길을 짜고 이성적이고 꾸준한 속도로 진행하자.

의사소통

어려움에 빠졌다면 어려움에 빠진 사실을 팀 동료와 상사에게 알려야 한다.

어려움에서 벗어나는 최선의 계획을 짜서 다른 이들에게 알려라. 도움과 가르침을 부탁하라.

규율에 의지하자

상황이 힘들어지면 규율을 믿어라.

애초에 규율을 세운 이유는 압박이 심해질때 길잡이로 삼기 위해서다.

이런 때야말로 자신이 가진 모든 규율에 특별히 주의를 기울여야 한다.

규율을 의심하거나 포기해야 할 때란 없다.

현재 내가 만든 팀의 기본 개발 규율은 테스트 코드와 코드리뷰이다.

도움받기

짝 프로그래밍을 하자! 본격적으로 업무를 해야할 때는 자신과 짝을 이뤄줄 조력자를 찾자.

일이 더 빨리 끝나고 결함이 더 적어진다.

결론

압박을 다루는 요령은 피할 수 있으면 피하고 피할 수 없을 땐 극복하는 것이다.

바람은 계산하는 것이 아니라 극복하는 것이다.

남이 <최종병기 활="">

피하는 법은 주의 깊게 약속하고, 규율을 따르고, 깔끔하게 유지하는 것이다.

극복하는 법은 당황하지 않고, 의사소통하고, 규율을 따르고, 도움을 받는 것이다.

느낀점

압박은 프로젝트를 하며 따라오는 것 같은데, 책에서 말하듯이 규율이 가장 중요한 것 같습니다.

스스로 실제 위기상황에서 어떻게 행동하는지에 따라 거짓된 모습인지 진실된 모습인지 알 수 있다는 것이 인상깊었습니다.

논의사항

• 압박 피하기와 압박 다루기의 비율이 어떻게 되시나요?

저는 약.. 7 : 3정도 나오는 것 같습니다.

12장 함께 일하기

소프트웨어는 대부분 팀 단위로 만든다.

팀원들이 프로답게 힘을 모을 때 팀은 가장 효율적이다.

독불작운이나 은둔자는 프로답지 못한 사람이다.

프로그래머 vs 보통 사람들

우리는 사람들과 같이 일하는 게 좋아서 프로그래머가 된 게 아니다.

일반적으로 사람들 사이의 관계는 뒤죽박죽이고 예측하기 힘들다.

우리는 프로그래밍한 기계가 깔끔하고 예측 가능하도록 운직일 때가 즐겁다.

제일 행복한 때는 홀로 방 안에서 흥미로운 문제에 몇 시간이고 완전하게 집중할 때다.

일반화라고 하지만 대부분의 프로그래머는 비슷할 것 같다. 코딩을 좋아하는 것이 아닌 결과물과 그 과정을 좋아하는 것 같다.

하지만 평균적으로 보면 홀로 집중하기 좋아하는 경향이 있다.

프로그래머 vs 회사

오류는 흥미로운게 아냐, 오류는 고쳐야 하는 거야!

프로 프로그래머의 첫 번째 책임은 회사가 필요로 하는 일을 처리하는 것이다.

이는 관리자, 사업 분석가, 테스터, 팀 동료와 힘을 합쳐 사업 목표를 속속들이 이해해야 한다는 뜻이다.

사업 공부를 하라는 것이 아닌, 그 코드로부터 회사가 어떤 이득을 얻을지 알아야 한다는 뜻이다.

프로 프로그래머가 절대 피해야 할 일은 기술더미에 파 묻혀 정신을 못 차려 주변에서 사업이 무너지고 있다는 사실을 알아채지 못하는 것이다.

우리 업무는 사업이 순조롭게 나아가도록 만드는 일이다.

따라서 프로 프로그래머는 사업을 이해하는 데 시간을 투자한다. 소프트웨어 사용자들과 소프트웨어에 대해서 이야기하고, 영업부, 마케팅부 사람들과 해결해야 할 문제에 대해 대화한다.

팀의 장단기 목표를 이해하기 위해 관리자와 대화한다.

프로그래머 vs 프로그래머

코드 소유

삐걱대는 팀의 모습 중 가장 나쁜 모습은 각 프로그래머가 자신의 코드에 벽을 두르고 다른 프로그래머가 건드리지 못하게 하는 행동이다.

심지어 자기 코드를 다른 사람이 보는 것조차 거부하는 곳도 경험했다.

이는 재앙으로 가는 지름길이다.

내가 경험한 최악은 자기가 회사 제출용 코드이기에 보지 말아달라고 요청했던 일이 가장 최악의 협업이라 생각한다.

공동 소유

코드 소유권의 벽을 무너뜨리고 팀 전체가 모든 코드의 소유권을 가지는 편이 낫다.

모든 팀원은 어떤 모듈이라도 체크아웃할 수 있으며 적절하다고 생각하는 대로 수정도 할 수 있는 편이 좋다.

프로 개발자는 다른 사람의 코드 작업을 막지 않는다.

함께 일하며 시스템에 대해서 최대한 많이 알아가며 서로 배우고 가르친다.

짝 프로그래밍

짝 프로그래밍이 위급 상황을 풀어내는 가장 효과적인 방법이라면, 위급 상황이 되기 전 문제발생 단계에서도 가장 효과적이지 않을까?

이는 코드를 검토(Review)하는 최고의 방법이기 때문이다.

다른 프로그래머가 검토하지 않는 코드가 시스템에 있으면 안 된다.

소뇌

프로는 함께 일한다. 헤드폰을 쓴 채 구석에 앉아서는 함께 일하지 못한다.

하나의 묶음이 되어 의사소통해야 한다.

아마 혼자 일할 때 더 잘한다고 생각하는 사람도 있을 것이다.

개인으로 보면 그럴지 모르지만, 팀 전체가 더 잘한다는 뜻은 아니다.

그리고 솔직히 말해 혼자 일할 때 더 잘 할 가능성은 그리 높지 않다.

혼자 일하는 것이 적절할 때는 어떤 문제를 긴 시간 깊게 고민해야 할 때이다.

결론

좋은 팀과 좋은 사람을 만나는 것도 운이다.

프로그래밍은 온전히 다른 사람과 함게 일하는 것에 관한 업무다.

트리플 모니터, 좋은 키보드 사방이 막혀있는 나만의 공간은 현실이 아니다.

정말로 프로그래밍을 하며 일과 시간을 보내고 싶다면, 사람과 함께 일해야 한다.

느낀점

노련한 개발자분들의 말을 들어보면 항상 실력보다 중요시 되는게 커뮤니케이션 능력이라고 한다.

컨퍼런스나 연사, 멘토링을 받다보면 항상 나오는 말인데, 그만한 이유가 있다고 생각..

1년차 개발자와 3년차 개발자의 실력은 엄청나게 차이가 나겠지만, 13년차 개발자와 15년차 개발자의 실력은 그리 차이가 나지 않을 것이다.

나도 커뮤니케이션, 솔직함이 정말 중요한 요소라고 생각되며, 나중에 정말 그런 팀에 들어간다면? 개인적 성장에는 큰 도움이 될 것 같다.

코드 소유 내용은 과거 좋은 코드 나쁜 코드라는 책에서 읽었던 경험이 있다. (살짝 다른 내용이였던 것 같은데..)

논의사항

• 조금 벗어난 이야기지만, 어떤 프로그래머가 되고 싶으신가요?

13장 팀과 프로젝트

작은 프로젝트를 여러 개 끝내야 한다면 어떨까?

어떤 식으로 프로젝트를 프로그래머에게 할당해야 할까?

정말 거대한 프로젝트 하나를 끝내야 한다면 어떨까?

갈아서 만들었나요?

이름이 상당히 폭력적이다.

절반의 사람이란 없다.

프로그래머에게 절반의 시간에는 프로젝트 A에 전념하고 나머지 시간에는 프로젝트 B에 전념하라는 말은 터무니없는 소리다.

특히 두 프로젝트를 서로 다른 프로젝트 관리자, 다른 사업분석가, 다른 프로그래머, 다른 테스터가 맡아 한다면 더욱 말이 안 된다.

그것은 팀이 아니라 믹서기로 갈아 만든 잡탕이다.

이걸 깨닫고 나서야 프로젝트를 한번에 여러 프로젝트를 진행하지 않는다.

과거에는 4개를 한번에 진행한 적도 있지만, 그게 좋지 않다는 것을 깨닫는데 오래 걸리지 않았다.

한 덩어리로 뭉친 팀

팀이 만들어지는 데는 시간이 걸린다. 팀 구성원들은 관계를 만들기 시작한다.

서로 어떻게 협력하는지 배운다.

서로의 버릇, 약점, 강점을 알게 되고, 결국 한 덩어리가 되기 시작한다.

한 덩어리가 된 팀은 일하며 기적을 만든다.

서로의 요구를 미리 알아내 처리하고 보호하며 서로 돕고 서로의 최선을 요구한다. 뭔가를 이뤄낸다.

한 덩어리가 된 팀은 약 12명 정도로 이뤄진다. (최적)

프로젝트 관리자는 팀의 진행 상황을 추적하고 팀이 일정과 우선순위를 이해하도록 만든다.

숙성

팀원들이 각자 차이점을 극복하고 서로를 받아들이고 진정한 한 덩어리가 되기에는 시간이 걸린다.

6개월이나 1년이 걸리기도 한다.

하지만 덩어리가 되면 그것은 마법이다. 한 덩어리가 된 팀은 같이 계획을 세우고, 같이 문제를 풀고 맞선다.

일단 한 덩어리가 되면 프로젝트가 끝났다고 팀을 해체하는 일은 우스운 짓이다.

팀원을 한 데 모아 프로젝트를 던져 주는 것이 최선이다.

팀이 먼저인가 프로젝트가 먼저인가?

팀이 먼저다.

비슷한 프로젝트의 경험이 있다고 해서 비슷한 인원끼리 모아 팀을 만들어 프로젝트를 배정하지 않고, 팀 단위로 배정한다.

이미 잘 맞는, 한 덩어리의 팀이라면 감당할 수 있고, 팀의 선택, 기술, 능력에 따라 분해한다.

하지만 어떻게 관리하지?

팀에는 저마다의 속도가 있다.

속도란 단순히 정해진 기간 동안에 끝낼 수 있는 일의 양이다.

어떤 팀은 한 주에 처리하는 점수로 속도를 측정하는데, 점수는 일이 얼마나 복잡한지를 표시하는 단위다. (스토리 포인트)

속도는 통계적 측정 값이다.

프로젝트 소유자의 딜레마

프로젝트 소유자가 권력과 안정확보를 잃을 수 있기에 불안감을 느낀다.

팀을 해체하는 일은 비싼 작업이기에 사업부가 단기적으로 팀을 없애지 않는다는 사실을 안다.

하지만 프로젝트를 한 덩어리 팀에게 맡기고, 그 팀이 동시에 여러 프로젝트를 맡고 있다면, 사업부는 내키는 대로 자유롭게 우선순위를 바꾼다. (사업부 시점에 따라)

이 때문에 불안을 느낀다.

하지만 사업부는 말 그대로 사업부이기에, 팀을 만들고 해체하는 인위적인 어려움에 손을 묶여선 안된다.

사업부에서 어떤 프로젝트가 다른 프로젝트보다 더 중요하다고 판단했다면 자원의 재배치가 재빨리 이루어져야 한다.

자신의 프로젝트를 더 유리하게 만드는 일이 프로젝트 소유자의 책임이다.

결론

팀은 프로젝트보다 만들기 더 어렵다.

그러므로 영구적인 팀을 만들어 이 프로젝트에서 저 프로젝트로 움직이게 하고 한 번에 여러 프로젝트를 맡기는 게 낫다.

팀을 만드는 목적은 한 덩어리로 뭉칠 시간을 충분히 줘서 여러 프로젝트를 완수할 원동력을 제공하는 것이다.

느낀점

요즘 PM이라는 직군을 맡게 되면서 좋은 프로젝트, 좋은 팀, 좋은 구조등에 고민이 많았었다.

그래서 PM관련 컨퍼런스와 과거에 읽었던 책도 다시 읽어봤다.

책에서 한번 더 강조해서 읽으니 좋은 팀을 만들고 싶고, 만나고 싶다.

좋은 팀은 정말 만나기 어렵고, 운이 좋아야 한다고 생각한다.

논의사항

• 프로젝트 개수에 대해서 어떻게 생각하시나요?
  • 취업 후 개인 프로젝트를 진행한다고 할 때

모두에게 다 피해를 주는 것 같다고 생각합니다..

장기적인 취업이라면 지속될 악영향을 본인, 회사 팀, 개인프로젝트 팀 모두에게 피해를 줄 수 있다고 생각합니다..

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

소프트웨어학과, 컴퓨터 공학과에서는 진정한 프로그래밍이 무엇인지 가르쳐주지 않는다.

실패의 정도

책에선 조금 과거의 이야기라 공감이 잘 되진 않지만, 개인적인 생각으로 대학교에선 현업에서 사용될 만한 기술을 가르쳐 주지 않는다.

물론 현업의 입사 면접, 코테도 똑같은 방식이라 생각한다.

야생에서 배우는 야생학습에서 학교에서 배운 CS, 알고리즘, OPP가 도움이 되긴 하지만 그 본질에 대해서는 많이 부족하다고 느꼈다. (나는)

물론 대학교에서 현업에서 사용될 만한 것을 가르친다면 그건 그냥 취업학교가 되어버릴 것이다.

따라서 학문에 초점을 맞춰서 가르치는 것은 당연하다고 생각되나, 부족한 부분도 있다고 생각된다.

왜 프로그래밍을 배워야 하는지에 대한 교육이 아쉽다.

회사 입장에선 신입을 뽑을 때 사실 신입이기 때문에 처음부터 다 다시 가르쳐 줄 생각으로 뽑는다. (모든게 아닌 해당 직무에 대해)

그렇다면 좋은 사람을 뽑기 위한 기준은 학교 생활을 생각할 수 밖에 없으니 코테를 통해 기본적 소양을 확인하고, 면접을 통해 인성을 확인하는 것이 당연하다.

이후에 기술면접에서도 해당 분야의 관심도, 기본적 지식을 물어보며 판단정도를 한다고 생각한다.

나름 준비해야 한다고 생각하는 점은 해당 직무에 대한 이해도와 전문성이라고 생각한다.

스승과 제자

프로그래밍 과정을 어떻게 배우는가?

내 첫 번째 컴퓨터 DIGI-COMP I

어지럽다. 3비트의 유한상태 기기

프로그래밍 분야에서 나름 권위자인 밥 아저씨의 첫 프로그래밍 장면이라니..

내가 처음 만든 프로그램은 무엇이었을까? (아마 C로 짠 Hello World가 아닐까 싶다.)

고교시절의 ECP-18

나는 한 비트 한 비트씩 (말장난 아님)
진짜 한 비트 한 비트임 ㅋㅋ

저자의 첫 멘토링 현장이다..

멘토링에 관한 이야기겠지만, 앞 장에서 나온 것 처럼 멘토링은 매우매우 중요하다고 생각한다.

비관습적 멘토링

앞의 두 이야기는 매우 다른 종류의 멘토링을 설명하기 위해서다.

두 경우 모두 일반적으로 멘토링이라는 단어가 의미하는 바와는 거리가 멀다.

첫 번째 사례에서는 아주 잘 만들어진 메뉴얼을 보면서 배웠고, 두 번째 사례에서는 저자를 거들떠 보지 않았던 사람들을 보면서 배웠다.

역경

스스로가 역사이기 때문에 당시 선배나 멘토가 없어서 많은 역경이 있었지만, 저자는 과거 멘토 한명이 있었다면 더 좋은 결과가 있었을 것이라고 생각한다.

수습기간

의사의 경우 수습기간이 3년이라고 한다. (이 과정 자체가 멘토링)

인턴은 롤모델이 되는 스승과 함께 일하며 배워간다.

그런 다음에야 시험을 치를 자격을 얻고 의사가 된다.

소프트웨어 견습기간

그렇다면 소프트웨어 직업은 어떻게 젊은 졸업생들을 전문적 대열로 유도해야 하는가?

그들이 따라야 하는 단계들은 무엇인가? 그들이 해결해야 할 과제들은 무엇인가?

어떤 목표를 달성해야 하는가?

장인들

장인은 한 가지 이상의 중요 소프트웨어 프로젝트를 주도했던 프로그래머들이다.

그들은 전형적으로 10년 이상의 경력을 가지고 여러 다른 시스템, 언어 및 운영시스템 작업을 해왔다.

그들은 복수의 팀들을 주도하고 조정하는 법을 알며, 능숙한 디자이너와 건축가들이며, 힘들이지 않고 다른 모든 이들을 위해 코드를 처리할 수 있다.

숙련공

숙련공은 훈련을 받은, 능숙한, 그리고 열정적인 프로그래머들이다.

이 과정을 통해 팀 내에서 일을 배워서 팀의 리더가 된다.

그들은 현재의 기술을 알고 있지만, 한 시스템, 한 플랫폼에서만 익숙해서 보통은 수많은 다양한 시스템에 대한 경험은 부족하다.

그러나 아직은 더 많이 배우는 과정이다. (약 5년차)

견습생/인턴

졸업생들은 견습생으로 시작한다.

견습 프로그래머들에게는 자주성이 없이 숙련된 프로그래머의 밀착 지도를 받는다.

처음에는 과제를 부여하지 않고 숙련된 프로그래머의 옆에서 돕는다.

숙련된 프로그래머들은 견습 프로그래머들이 설계 원칙, 디자인 패턴, 규율, 절차들을 숙지하도록 돕는 선생들이다.

현실

이 모든 이야기는 이상적인 가정에 불과하다.

“잘하는 사람이 오래 살아남는 것이 아닌, 오래 살아남는 사람이 잘하는 것”

현실은 위 견습기간과정과 매우 다르다.

쉽게 말해서 1~2년 코딩하고 다른 일을 할 것 같이 살아간다.

오늘날 업계에서 벌어지는 일과 이상적인 견습기간 간의 차이는 기술 훈련, 교육, 감독 및 검토 등에 대한 초점이다.

장인 정신

장인 정신이라는 단어를 정의해보자.

우선 장인은 일을 빠르게 처리하며 합리적인 평가를 제공하고 임무를 처리하는 사람이다.

그들은 “아니요”라고 말을 할 때를 알지만 “예”라고 대답하려고 노력한다.

장인은 프로다.

장인 정신은 장인들이 지니고 있는 사고방식으로써 가치, 규율, 기술, 자세 및 답변을 포함하는 밈이다.

장인 정신은 사람을 통해 전해진다.

선배들이 후배들을 가르치고 동료들 사이에서 교류가 된다.

선배들이 후배들을 관찰하면서 재학습이 이뤄진다.

장인 정신은 감염되는 일종의 정신적 바이러스다.

타인들을 관찰하고 그 밈이 자리잡도록 함으로써 얻을 수 있는 것이다.

확신 심어주기

사람들에게 장인이 될 수 있도록 확신을 줄 수는 없다.

사람들이 장인 정신 밈을 수용하도록 확신시키는 것도 어려운 일이다.

논쟁은 비효율적이며 데이터는 중요하지 않으며 사례 연구는 의미가 크지 않다.

밈은 감염성이 있지만 관찰할 때만 가능한 것이다.

우선 장인이 된 다음 자신의 장인 정신을 보여주도록 하라.

결론

학교에서는 프로그래밍의 이론을 가르치지만, 장인의 규율, 실태와 장인이 되는 기술을 가리치지 않는다.

느낀점

앞서 말한 학교에서 가르치지 않는 장인 정신은 매우 중요하다.

나는 따라가고 싶고, 따라가고 있다.

누구에게는 멘토가 누구에게는 멘티가 되고 싶다.

하지만 현실에서 느낀점은 장인 정신을 거부하는 사람도 많다는 것이다.

이 업계나 프로그래밍에 대해 흥미가 없지만, 단순 업무로서 살아가는 사람들이 많다. (내 생각엔 절반 이상)

그들에게 강요하기 보다 스스로 알을 깨려는 사람에게 손을 내미는 것이 더 중요할 것 같다.

논의사항

• 스스로 장인이 되고 싶으신가요?