Clean Coders 책 챕터 1 - Professionalism 좋은 문장들
프로는 믿음직스러워야한다
“이 사람은 진짜 프로야”, 라고 표현되는 사람은 어떤 특징을 가지고 있을까?
‘프로’라는건 아무래도 신뢰의 상징인 것 같다.
내가 돈을 내서라도 이 사람의 서비스를 받고싶다, 그만큼 이 사람의 서비스는 좋고 안정적이여야한다는 것이다.
하지만 아무래도 소프트웨어는 수정하기가 쉽다보니, 비-프로의 세계에서는 이 ‘신뢰’가 상당히 가볍게 여겨지는 것 같다.
책에서는 프로의 신뢰를 의사에 비교할 정도로 중요한 가치라고 이야기한다.
프로그래머가 ‘내가 이 프로그램을 X월 XX일까지, 무조건적으로 네가 원하는대로 완벽하게 만들어줄게’ 라고 말할 수 있고 또 그걸 지킬 수 있다는 것이, 바로 비-프로와 프로를 가르는 경계이지 않을까 생각이 든다.
“맞아요, 소프트웨어를 버그 없이 만드는건 불가능할정도로 복잡한 일입니다.
하지만 그렇다고 당신이 버그가 있는 소프트웨어를 만들어도 된다는 면죄부를 받는건 아니에요.
사람의 몸도 전부 이해하는건 불가능하지만, 의사들은 환자를 무조건 좋은 방향으로 치료하기 위해 선서를 하잖아요?”“프로가 되기 위해서 첫번째로 할 일은 ‘사과하는걸 연습하는 것’이에요.
무언가를 잘못했을 때 우리는 사과를 하지만, 사과 하나로 모든게 다 해결되지는 않잖아요.
같은 실수를 계속 반복하면 안될거잖아요.
당신이 프로가 되면서 이러한 ‘사과하는 행동’은 0으로 수렴해야해요.”
내 버그는 내가 제일 잘 알아야한다
프로그래머에 대한 신뢰는 ‘다 된다고 내놨는데 버그가 나올 때’ 깨지게 된다.
아무 베이스도 없으면서 ‘아 내가 코드 좀 잘 짜는데요, 다 잘 될겁니다’ 라는 느낌으로 다 된다고 이야기한거면, 그건 그냥 (당연하게도) 100% 오만이지 않을까 생각한다.
‘내 코드는 A라는 시나리오에서 잘 작동합니다. B 라는 시나리오에서는 작동하지 못합니다’ 라고 명확하게 기능과 한계점을 찝어줄 수 있어야 한다.
그리고 작동/비작동의 여부를 알기 위해서는 코드를 무조건 테스트 목적을 가지고 돌려봐야한다.
“당신의 코드가 작동하는건지 어떻게 알까요? 정답은 간단합니다. 테스트를 하세요. 또 테스트 하세요. 위 아래로 테스트하고, 월화수목금토일 테스트하세요.”
“하루 종일 테스트만 하고 있다면 코드를 짤 시간이 없겠죠? 맞는 말씀이십니다. 그러니까 테스트를 자동화하세요!”
“착각하실까봐 말씀드리는건데, 코드 테스팅은 ‘추천하는 행동’이 아니에요.
이건 필수에요.
당신이 짠 코드는 한줄한줄 전부 다 책임지고 테스트 하세요.”“테스트 코드 작성이 어렵다구요?
그건 테스트 하기 어렵게 당신이 짰기 때문이에요.”
유연한 코드를 가지기 위해서는
산업공학을 전공하면서 배운 것 중 하나는, ‘시작 단계의 고객 요구사항은 항상 불완전하며, 끝 단계의 고객 요구사항은 이미 과거의 것이다’ 라는 것이다.
즉, 고객 요구사항은 계속 바뀌게 된다 (제조업이 그래서 어려웠다 ㅜㅜ)
소프트웨어는 다행히도 코드만 바꾸면 고객 요구사항에 맞춰서 금방 따라갈 수 있다.
하지만 유연하지 못한 코드를 짜게 된다면, 하드웨어 생산보다도 더 경직된 유연성을 가지게 된다.
고객 만족도를 최상을 높이는 ‘프로’가 되기 위해서는, 무조건 유연한 코드를 만들어야한다.
책에서는 유연한 코드륾 만들기 위해서는 1. 좋은 아키텍처, 2. 코드를 항상 깔끔하게 유지하려는 마음, 3. 테스트 가 필요하다고 한다.
“당신의 코드가 유연하려면 우선 코드 구조가 유연해야합니다.
구조를 대충 짜는 행위는 당신의 미래를 희생하는 거에요.”“무자비하게 리팩토링하세요 (merciless refactoring).
당신이 어떤 코드를 보기 전과 후를 비교했을 때, 그 결과물은 이전보다 더 깔끔해야합니다.”“소프트웨어가 바뀌지 않고 있을 때가 가장 위험한겁니다”
“개발자들은 왜 소프트웨어를 바꾸는걸 무서워할까요?
아마 본인들이 무언가를 잘못 수정해서 코드가 작동하지 않을까봐 일겁니다.
왜 코드가 작동하지 않을 것을 무서워할까요? 코드를 테스트되지 않았기 때문입니다.
코드를 테스트하면 코드가 작동할 것을 확신할 수 있습니다.”
프로의 마음가짐
소프트웨어 업계는 빠르게 변한다.
새로운 프로그래밍 언어나 프레임워크는 매년 소개가 되고 있고, 새로운 논문은 매일 몇개씩 쏟아져나온다.
구글 검색 몇번이면 새 지식을 쉽게 접할 수 있다보니 세상도 함께 빠르게 변한다.
2015년만해도 AI 개발자 포지션은 찾기 어려운 수준이였지만, 2018년에는 사람이 없어서 못 뽑았다.
2020년에 NeRF 논문이 공개되었고, 2022년 컴퓨터 비전 컨퍼런스에서는 어딜가나 NeRF 논문이 보인다.
개인 사정 때문에, 아이를 돌보기 위해, 이직을 준비하느라, 여행을 하고 싶어서 - 어떠한 이유에서든 1-2년만 쉬어도 순식간에 뒤쳐질 수 있다.
그리고 나 자신에게 질문을 해보자 - ‘뒤쳐진 개발자에게 돈을 주고 일을 맡기고 싶을까?’
“당신의 커리어는 당신이 책임져야합니다.
당신의 고용주가 당신을 트레이닝 시켜주고, 테크 컨퍼런스에 보내주고, 프로그래밍 책을 사줄 이유는 단 1도 없어요.
당신의 고용주가 이미 이런 것들을 제공해주고 있다면, 이런 부분들을 ‘당연히 고용주가 제공해야하는 것’이라고 착각하지 마십시오.”“고용주는 당신의 실력이 좋아지는 걸 기다려줄 책임이 없습니다.”
“개발자라면 매주 60시간은 일 해야합니다.
40시간은 당신의 고용주를 위해, 20시간은 당신을 위해. 20시간은 약 하루에 3시간 정도입니다.
점심시간에 책을 읽어도 좋고, 출퇴근 시간에 팟캐스트를 들어도 좋고, 하루 2시간 새로운 언어를 배워도 좋습니다.”“1주일은 168 시간입니다.
고용주에게 40시간과 자신을 위한 20시간을 빼면 108시간이 남습니다.
매일 8시간 수면을 취해 56시간을 빼면, 나머지 시간은 52시간이 남습니다.
충분히 가족과 시간을 보낼 수 있고, 개인 시간을 가질 수 있습니다”“프로는 본인의 커리어에 시간과 노력을 쏟을 줄 알아야합니다”
“자신을 위한 20시간 동안에는 고용주를 위해 일하면 안됩니다.
당신 자신의 커리어를 위해 일해야합니다.”“코딩을 그만둔 아키텍트들은 곧 업무에서 본인이 쓸모없음을 느낄겁니다.
새로운 프로그래밍 언어를 습득하지 않는 프로그래머는 곧 본인이 업계에서 밀려남을 느낄겁니다.
새로운 소프트웨어 방법론과 기술을 익히지 않는 개발자들은 곧 본인의 동료들이 승진할 때 본인의 가치는 내려감을 느낄 겁니다”“의학 논문을 읽지 않는 의사에게 진단을 받고 싶으신가요?
최신 법률을 따라가지 못하는 변호사에게 상담을 받고싶나요?”
전문지식을 익히자
프로그래머에게 비용을 주며 개발을 맡기는 이유는 돈으로 프로그래머의 개발 능력과 개발 시간을 산다고 볼 수 있다.
여기서 프로그래머가 가진 지식의 수준이 얕다면, 50%는 빈 쭉정이인게 아닐까?
진짜 ‘프로’는 빈 쭉정이 같은 소리를 듣지 않는다.
“Nassi-Schneiderman 차트가 무엇인지 아십니까? 모른다면, 왜 모르나요?
Mealy state machine과 Moore state machine의 차이를 아시나요? 알아야합니다.
Quick sort를 인터넷 안 보고 바로 짤 수 있나요?
Transform analysis가 무엇인가요?
Data flow diagram에 기능 분해를 하실 수 있나요?
Tramp data란 무엇일까요? Conascene이라는 단어를 들어본적이 있나요?
파르나스 테이블이 무엇인가요?”“지난 50년간 소프트웨어 분야에는 다양한 지식들이 축적되어 왔습니다.
그에 비해 현대 소프트웨어 기술은 굉장히 빠르게 발전하고 있습니다.
하지만 그렇다고해서 옛 것의 지식을 익히지 않을 이유가 되지 않습니다.
과거에 만들어진 대부분의 개념들은 현대에서 사용하는 개념들에 그대로 계승되었기 때문입니다”“역사를 기억하지 못하는 자는, 같은 실수를 반복하기 마련입니다”
“제가 개인적으로 생각하는 ‘프로라면 갖춰야할 지식들’ 입니다”
- 디자인 패턴
- GOF 책에 있는 24개의 패턴을 전부 설명할 수 있음
- POSA 책에 나오는 많은 패턴들을 설명할 수 있음.
- 디자인 방침
- SOLID principle을 이해함
- 개발 방법론
- XP, Scrum, Lean, Kanban, Waterfall, Structured analysis, Structured design
- 소프트웨어 방법론
- TDD, Object-Oriented design, Structured programming, Continuous integration, Pair Programming
- 산출물
- UML, DFD, Structure chart, Petri Nets, State Transition Diagrams, flow chart, decision table
Continuous learning
Practice
“피아니스트, 바이올리니스트 들이 어떻게 아름다운 선율을 만들 수 있을까요? 수많은 연습으로써 만들어진 결과물입니다. 수많은 스케일과 에튀드를 통해 손가락을 단련시킵니다. 무대에 자주 올라가서가 아닙니다.”
“소프트웨어 개발자들도 연습을 해야합니다. 저는 이 연습을 kata라고 불러요. 저는 하루에 kata를 하나에서 두개 정도 합니다.”
“아침에 10분 kata를 통해 웜업을, 저녁에 10분 kata를 통해 쿨다운을 하시죠”
Mentoring
“가장 빠르게 공부하는 방법은 가르치는 겁니다. 당신이 책임져야하는 학생들에게 정보를 정확하게 전달하기 위해서는 누구보다 빠르고 정확하게 공부해야합니다. 그러니 가르치는 행위는, 사실 선생님에게 가장 큰 이득이 돌아가는 학습 방법입니다.”
“프로들이 주니어들을 멘토링을 책임져야합니다”
Know your domain
“개발자는 본인이 프로그래밍하고 있는 분야에 대한 이해도가 있어야합니다.”
“도메인 전문가가 되라는건 아닙니다. 하지만 적어도 프로젝트를 시작할 때, 해당 분야에 대한 책 한두권 정도는 읽으세요”
“가장 안 좋은건, 비즈니스가 어떻게 굴러가는지 단 1도 이해하지 못한 채 코드만 치는겁니다”.
Identify with your employer / customer
“당신의 고용주의 문제가 곧 당신의 문제입니다”
“절대 어떠한 상황에서도 ‘당신 vs 고용주’ 형태로 문제를 끌고가지 마세요. 프로들은 어떠한 대가를 치뤄서라도 이런 구도를 피합니다.”
Humility
“연차가 쌓이고 실력이 쌓이면서, 어느정도 리스크를 가지고 계산된 행동을 할 수 있습니다. 하지만 연차와 실력에 관계없이 누구나 실수는 합니다.”
“진짜 프로는 실수를 했을 때 가장 먼저 웃을 수 있는 사람입니다.”
“프로는 다른 사람이 실수 했을 때 비난하지 않습니다. 왜냐면 언제든지 자기 자신도 실수할 수 있기 때문입니다”