Clean Coders 책 챕터 4 - Coding 좋은 문장들

“당신이 어떤 에러를 만들었는지 느끼는건 정말로 중요합니다”

Preparedness

“코딩이 어렵고 힘든 이유는, 해결해야할 문제가 여러가지로 복잡하게 얽혀있기 때문입니다.”

“첫째로, 당신의 코드는 무조건 작동해야합니다. 당신의 코드는 당신이 풀려고 하는 문제를 정확하게 풀어내야합니다.”

“둘째, 고객이 요구하는 문제를 풀어야합니다. 고객이 풀려고 하는 ‘문제’와 고객의 ‘요구사항’은 종종 다를 수 있습니다. 당신은 고객의 요구사항을 맞추는 코드를 작성하는게 아니라, 궁극적으로 고객의 문제를 풀어줘야합니다.”

“셋째, 당신의 코드는 기존의 시스템에서도 잘 작동해야합니다. 당신의 코드가 새로 적용됨으로써 기존의 시스템에 더 복잡해지면 안됩니다. 이를 위해서 당신의 코드는 여러 엔지니어링 패턴들을 잘 따라야합니다.”

“넷째, 다른 프로그래머들이 당신의 코드를 읽을 수 있어야합니다.”

“당신이 충분히 집중을 하지 못할 때, 코드에는 버그가 생기고 잘못된 구조가 나타납니다. 이렇게 되면 당신의 코드는 고객이 풀려고 하는 문제를 풀 수 없게 됩니다. 그러니 피곤하거나 집중을 하지 못할 때는 그냥 코드를 짜지 마세요.”

 

3AM Code

“그건 진짜로 잘못된 솔루션이였어요. 하지만 새벽 3시에 짠 코드는 다 겁나 멋져보입니다.”

“당연하죠. 18시간이나 연속으로 코딩을 했으니, 그런 퀄리티가 그 당시의 저의 최선일 수 밖에 없습니다.”

“몇시간동안 개발을 했는지는 중요하지 않습니다.. 당신의 코드는 진정성있게 고객의 문제를 해결해주나요? 당신의 코드는 프로페셔널 수준의 퀄리티를 가지고 있나요? 자신있게 고객에게 보여줄 수 있는 코드인가요? 좋은 코드를 짜고 싶다면, 우선 충분히 잠은 자고 있는지, 건강한 생활패턴을 가지고 있는지부터 확인하세요. 그렇지 않고서는 매일 8시간을 집중해서 좋은 결과를 낼 수 없습니다.”

 

Worry code

“혹시 남편/아내와 격하게 싸우고나서, 또는 친구/부모님과 격한 논쟁을 벌이고나서 코드를 짜보려고 한 적이 있나요?“

“코드에 집중하기 위해서는 background process를 꺼야합니다. 아니면 적어도 코딩에 방해가 되지 않을 정도로 중요도를 낮출 수 있어야해요.”

“저는 그 일을 해결할 시간을 따로 만들어서 문제를 해결했습니다. 3시간은 코딩을 하고, 1시간은 문제 해결에 시간을 썼습니다. 아이가 아프다면 집에 전화해서 상태를 확인해본다던지, 아내와 다퉜다면 전화를 해서 푼다던지의 방법으로요. 물론 이 방법은 좋지 않습니다. 개인적인 일은 오피스에 가져오지 않고 개인적인 시간에 해결하는게 제일 좋죠.”

 

The Flow zone

“종종 집중해서 프로그래밍을 하다보면 ‘the zone‘에 들어가게 됩니다. 주변 상황이 모두 차단되고, 코드에만 집중하게 되면서 생산성이 엄청나게 오르게 되는걸 느끼죠. The zone에서 나올 때 쯤에는 엄청난걸 해낸 것 같은 느낌이 납니다.”

“팁을 하나 드리죠. The zone에 빠지는걸 피하세요.”

“The zone에는 함정이 있습니다. 한가지 분야에만 집중하게 되면 큰 그림을 완전히 놓쳐버리게 되는 아주 큰 단점이 있습니다. 완전히 터널-비전이 되어버려서, 그 문제를 풀고 있을 때는 잘 하고 있는 것 같지만 나중에 큰 그림으로 봤을 때는 잘못되어서 결국 다시 고치게 되는거죠.”

“저는 그래서 the zone에 들어가는 것 같으면, 잠깐 일어나서 동네 한바퀴 걷고 옵니다. 이메일을 확인하거나 트위터를 보면서 머리를 비우기도 해요.”

“The zone에 들어가면 좋을 때는 당신이 ‘연습하고 있을 때‘ 입니다.”

 

Music

“저는 음악을 듣고 있을 때 코드를 더 못치는 것 같아요. 음악을 듣다보면 거기에 에너지를 많이 뺏겨요. 근데 혹시 몰라요, 당신은 음악을 들으면 오히려 더 집중을 잘 하는 타입일수도요.”

“하지만 저는 음악이 the zone에 들어가기 쉽게 만들어주는 것 같아서 음악을 듣는걸 추천하지 않습니다.”

 

Interruption

“누군가 질문을 하러 왔다면 어떻게 반응해야할까요?“

“대부분의 ‘예의 없는 반응’은 the zone에서 옵니다. 엄청나게 집중을 하고 있었는데, 외부 질문 때문에 the zone에서 끌려나와지는 거지요.”

“하지만 가끔은 진짜 복잡한 문제를 풀기 위해 집중하고 있을 수도 있죠.”

“사실 효율적인 업무를 위해서 팀원끼리 질문을 할 수도 있는건데, 혼자서 집중하는 과정은 이러한 질문 과정을 방해하는 부분이 될 수도 있습니다.”

“페어 프로그래밍을 하고 있다면, 여러분이 질문에 답을 해주고 있는 동안 여러분의 파트너가 문제의 컨텍스트를 그대로 잡고 있을 수 있습니다.”

“또는 TDD를 하고 있다면, 질문에 답을 하고 오면 failing test 사이클로 다시 돌아올 수 있죠.”

“결국 협업을 하는 과정에서는 무조건 질문에 답을 해야할 때가 올겁니다. 그렇게 시간을 뻇기게 되는 것도 당연한 거구요. 하지만 그런 상황이 왔을 때, 당신도 언젠가는 질문을 할 것이고 누군가의 집중을 깨야할 때가 올 수 있다는 것을 인지해야합니다. 그러므로 질문에 예의있고 도움이 될 수 있는 방향으로 힘을 써주는 것이 프로다운 자세입니다.”

 

Writer’s block

“가끔은 진짜 그냥 코드가 안나오는 경우도 있습니다. 잠을 충분히 못잤거나, 무언가가 걱정이 된다거나, 우울해져있다거나의 이유가 있겠습니다.”

“이메일을 읽거나, 트위터를 읽거나, 책을 읽거나, 스케줄을 다시 짠다거나, 도큐먼트를 적는다거나, 미팅을 한다거나, 팀원과 이야기를 한다거나 등으로 환기를 시켜볼 수 있습니다. 하지만 종종 무슨 짓을 해도 코드가 안 짜여질 때가 있습니다.”

“여기에는 아주 쉬운 솔루션이 있습니다. Pair programming을 같이 할 파트너를 찾으세요. 누군가와 함께 앉아서 문제에 대해 이야기하는 순간 마법같이 코드가 다시 짜지기 시작할겁니다.”

 

Creative input

“창의적인 아웃풋을 내기 위해서는 창의적인 인풋이 필요합니다.”

“주변을 창의적인 것들로 가득 채우세요. 그러면 당신도 무언가 창의적인걸 만들어내야한다는 느낌을 받게 될 것입니다.”

 

Debugging time

“코딩을 하는데에 들어가는 시간과 비용이 높듯이, 디버깅을 하는데에 들어가는 시간과 비용도 높습니다.”

“저는 요즘에 디버깅을 하는데에 훨씬 적은 시간을 씁니다. 대충 10 분의 1 정도 되는 것 같아요. TDD를 도입함으로써 버그가 엄청나게 줄어들었기 때문입니다.”

“TDD를 하거나, 아니면 다른 비슷한 효율적인 방법론을 잘 쓰면… 디버깅의 시간은 0으로 수렴하게 됩니다.”

“의사들도 수술을 끝낸 환자를 다시 개복하고 싶지 않아합니다. 변호사들도 이미 끝난 사건을 다시 열고싶지 않아합니다. 다시 수술을 하려는 의사나 다시 케이스를 열려고 하는 변호사는 프로답지 못한 겁니다.”

 

Pacing yourself

“소프트웨어 개발은 단거리 달리기가 아니라 마라톤입니다.”

“프로들은 에너지와 창의력을 비축해서 적시적기에 사용할 줄 압니다.”

 

Know when to walk away

“문제가 풀리지 않아서 집에 갈 수 없나요? 오, 천만에요. 집에 가세요!“

“창의성과 똑똑함은 건강한 몸에만 존재합니다.”

“몸이 피곤할 때는 조금 쉬어주세요. 그러면 적은 시간과 적은 노력으로도 더 많은 일을 해낼 수 있을 겁니다.”

 

Being late

“당신도 언젠가 한번쯤은 일정을 맞추지 못할 겁니다.“

“일정이 늦어지는걸 관리하려면 1. 빠르게 늦어지는걸 알아차려야하고, 2. 그 사실을 투명하게 공유해야합니다.”

“가장 최악인건, 모두에게 마지막 순간까지 잘 만들고 있다고 하다가, 정말 마지막 순간에 늦는다고 하는겁니다. 절대 이러지 마세요. 대신, 정기적으로 당신이 얼마나 작업을 진행했는지 공유하고 3가지 작업종료일의 경우의 수를 알려주세요 - 제일 좋은 케이스, 적당히 잘 됬을 때의 케이스, 최악의 케이스 입니다. 그리고 제발 솔직하게 말하세요! 당신의 희망을 estimate에 넣지 마세요.”

 

Hope

“희망이 프로젝트를 말아먹습니다.”

“데모가 열흘 후라고 해보죠. 그리고 당신이 담당하는 작업의 3가지 작업종료일이 8/12/20 이라고 해보죠. 이런 경우에, ‘8일 안에 작업을 끝낼 수도 있지 않을까?’ 라는 희망을 갖지 마세요!”

“대신, 고객들과 프로젝트 관리자들이 이 상황에 대해 정확하게 인지하게 하세요.”

 

Rushing

“매니저가 ‘8일 안에 끝낼 수 있지 않을까요? 당신을 잘 해낼 수 있을거에요’ 라고 해도 속아넘어가지 마세요. 당신은 당신이 직접 만든 estimate를 고수하세요. 급하게 일을 끝내서 데드라인을 맞추려고 하지 마세요. 상사에게 가서 정확하게 estimate를 공유하고, 데드라인을 맞추기 위해서는 개발품목을 줄여야한다고 솔직하게 이야기하세요.”

“급하게 짠다고해서 당신이 코드를 짜는 속도가 더 빨라지는게 아닙니다.”

 

Overtime

“상사가 매일 2시간씩 야근을 더 한다던지, 토요일 출근을 요청해서 데드라인을 맞추려고 요구하면 어떻게 해야할까요?”

“초과근무는 좋은 방법이긴 합니다. 가끔은 진짜 필요하기도 하구요. 하지만 정말 리스크가 큰 방법입니다. 20%의 시간을 더 투입한다고 20%의 작업이 더 되는게 아닙니다.”

“초과근무를 해도 되는 상황은 다음과 같습니다. 1. 개인적으로 시간을 낼 수 있다. 2. 초과근무를 하는 시간이 2주 또는 그 이하이다. 3. 초과근무를 해도 실패했을 경우 백업 플랜이 있다.”

“마지막 조건이 제일 중요합니다. 마지막 조건이 갖춰지지 않았다면 절대로 초과근무를 하면 안됩니다.”

 

False delivery

“제일 나쁜건, 작업이 다 끝나지도 않았는데 다 끝났다고 해버리는겁니다.”

“‘다 끝났다’의 정의를 새로 만들어버리는 경우도 있습니다. 이건 진짜 위험합니다. 이 새로운 정의가 팀원들에게 퍼지게 되면 안됩니다. 이를 위해 팀원들끼리 ‘다 끝남’의 정의를 새롭게 내리거나, 또는 자동 테스트 파이프라인을 구축함으로써 정의를 내려야합니다.”

 

Help

“당신이 얼마나 프로그래밍을 잘 하는 사람이던, 누구나 다른 프로그래머의 시각과 아이디어에서 도움을 얻을 수 있습니다.”

“그렇기 때문에 동료들을 도와줘야합니다. 동료가 도움을 요청하는데 그걸 무시하고 진행해야할 만큼 중요한 일은 없습니다.”

“물론 이게 혼자만의 개발시간이 필요하지 않다는건 아닙니다. 혼자 집중할 시간은 필요하죠. 대신, 동료들과 서로 이 시간을 예의있게 존중해야합니다.”

“누군가 도움이 필요해보이면, 도움을 주세요. 옆에 같이 앉아서 코드를 같이 짜세요. 1시간, 또는 그 이상의 시간이 걸릴껄 생각하고 차분하게 도와주세요.”

 

Being helped

“누군가 나를 도와줬다면, 고마움을 표현하세요.”

“당신이 바쁘고 여유가 없다고해서 고마움을 표현하지 않고 넘어가려고 하지 마세요.”

“누군가 도와주려고 하면 30분 정도 함께 하세요. 그 시간이 지났는데도 큰 도움이 되지 않는다면, 예의바르게 이야기를 하고 고마움을 표시하며 세션을 종료하세요.”

“도움을 요청하는 방법을 익히세요. 남들이 쉽게 도와줄 수 있는 상황인데, 혼자서만 막혀있는 것도 프로답지 못한 행동입니다.”

 

Mentoring

“경험이 부족한 프로그래머들을 멘토링하는 작업은 경험이 더 많은 프로그래머의 책무입니다. 온라인 코스나 책을 읽는거랑은 효율성이 비교가 되지 않습니다.”

“주니어 프로그래머가 열정이 있고, 거기에 맞춰 시니어 프로그래머가 좋은 멘토링을 해준다면, 이보다 더 빠른 성장은 없을 겁니다.”