[구글 엔지니어는 이렇게 일한다] 가볍게 읽기 좋은 구글 개발문화 탐방 책

한동안 트위터에서 핫했던 구글 엔지니어는 이렇게 일한다.

마침 트친님이 이 책을 같이 읽지 않겠냐 스터디를 제안하여 매주 토요일마다 함께 감상을 나누었다. 

매주 2장씩 읽었고, 약 한 달 반이 지난 현재 12장 단위테스트까지 읽었다.

 

구글 엔지니어는 이렇게 일한다 

 

[세 줄 평가]

- 구글의 개발 문화를 살펴보며 '다른 기업은 이렇게도 하는구나'를 느낄 수 있다. 그러나 구글이라고 다 정답은 아니다. 각 조직 특성에 맞는 문화가 있을 것. 또 돈도 많고 사람도 많은 '구글'이라서 적용할 수 있는 문화도 있다. 

- 시니어급이 보면 더 좋을 거 같은 책. 팀 관리자가 참고할 만한 내용이 많고, 또 직접 본인이 변화를 빠르게 추진할 수 있는 위치니까. (주니어도 제안할 수 있는 조직이 있긴 하겠지만 시니어만큼 파워가 있는 게 아니니)

- 개발자 필수책! 까진 아니고, 구글 개발자들이 일하는 방식 중 내게 필요한 것을 쏙쏙 차용해오면 좋을 정도. 

 

[내용 정리]

3장 지식 공유

• 무언가를 시도하다가 실패해도 안전하다는 인식이 중요하다는 부분이 인상적. 현재 속해 있는 곳은 시간낭비를 해서는 안 되고, 당일 할당된 일감을 당일에 쳐내야 함(…) 빠른 시간 안에 문제를 해결하지 못하면 능력 없는 사람이 됨. 이 때문에 일이 할당되면 압박감부터 받음. 사람을 성장시키는 조직을 만들고 싶으면, 실패에 대한 안전지대를 만들어두는 게 좋을 듯.
• 사람 무시하지 않는 게 중요함. 
  • 뭐라고? 스택이 뭔지 모른다니 믿을 수가 없네!
  • 음, 실제론… 세세하기 설명하지 않기.(자신을 뽐내기 위함),
  • 미묘하게 인종주의, 연령주의, 동성애 혐오 발언하지 않기. → 이런 선배 및 동료가 되지 않기 위해 노력하기.
• 질문하는 것을 두려워하지 않기. 모르는 것이 있다는 건 성장할 기회이므로. 가면증후군, 자신의 능력보다 과대평가받고 있다고 느껴서 실수하면 사기꾼임을 들킬지 모른다는 두려움. 누구나 있지 않을까? 걱정하지 말고 모르는 건 바로바로 물어봐야 더 빨리 성장하고 팀에도 도움이 됨. 
• 결국 핵심은 존중. 조직이 성장하기 위해서는 팀원끼리 서로 존중하는 문화가 젤 중요. 남 탓하지 않고, 다른 사람과 함께 성장하려고 하기.. 그게 제일 중요함.

스터디원들과 논의 내용

• 되게 이상적인 내용. 구글같이 큰 회사나 돼야 .. 우리나라는 타이트하게 업무 하는 스타일이라 사람들이 짜증도 많고
• 상급자라면 모든 걸 알아야 한다는 인식이 생기지 않게 해야한다는 게 인상적. 상급자 하급자 서로 질문해야 하는 거임. 서로가 서로에게 배우는 거.
• 기술이나 지식을 나누는 데 있어서 경제적인 보상도 중요하지만, 동료들의 인정이 매우 중요함.
• 모질게 말하는 사람한테는 질문을 안 하게 된다. 검색 안 해봤냐 이걸 모르냐 이런 식으로 답이 옴. 질문을 하기 전에 검색과 컨플루언스를 하긴 하는데, 1시간 정도 후에 질문.
• 질문하는 게 좀 부담스러워서. 특정한 요일에 질문하고. 오전에 물어보면 오후에 아웃풋 내서 리뷰 요청드리는 그런 느낌으로 질문함.
• 나의 질문이 달갑지 않아하는 게 보인다든가, 그런 사람들한테 질문한다는 거 자체가 싫어짐. 개인적으로도 친해지고 싶지 않음.

4장 공정 사회를 위한 엔지니어링

• 어떤 사람이든 편견은 있음. 그래서 조직적으로 이 편견을 최대한 없애기 위해 조치를 취해야 함. 대표적인 것이 다양한 사람들로 조직을 구성하기

5장 팀 이끌기

• 전통적인 관리자는 일을 어떻게 처리할지를 고민하는 반면, 훌륭한 관리자는 무슨 일을 처리할지 고민.
• 훌륭한 관리자는 팀이 나아갈 길을 다지면서, 동시에 안전과 복지를 챙겨줌. 관리자가 직원들을 신뢰한다는 분명한 신호를 주면, 직원들은 신뢰에 부응해야 한다는 긍정적인 압박을 느낀다.
• 나보다 못한 사람이 아닌, 나보다 잘난 사람을 뽑는다고 생각해야 함. 나를 위협한다는 생각하지 말고, 잘하는 사람을 뽑으면 오히려 배울 기회.
• 저성과자 방치하지 말 것. 단 한두 명의 저성과자 때문에 팀은 해체될 수 있다. 관리자들은 저성과자가 마법처럼 환골탈태하거나 알아서 어디론가 사라지기를 그저 희망하지만, 정말로 그럴 가능성은 희박하다. 저성과자의 존재는 모두가 정확하게 꿰뚫고 있다. 왜냐하면 저성과자를 업고 뛰는 당사자가 바로 그들이기 때문.. ㅋㅋㅋ
• 팀의 고성과자들은 저성과자들을 밀고 당겨주느라 귀중한 에너지를 낭비하고 팀의 사기는 점점 떨어져간다. 그래서 저성과자는 그대로 두면 안 된다.
• 저성과자 매니징방법 : 기간을 정하고, 아주 구체적인 목표 제시하기. 작고 점진적이고 측정할 수 있는 목표여야. 단, 겸손 존중 신뢰가 바탕이 돼야 한다. 팀원과 매주 만나서 진척 상황을 확인하기.
• 그럼 뭘 해야 하나요 ? 자존심 버리기. 우리 모두는 완벽한 정답을 알고 있지 않고, 때로는 잘못된 길로 갈 수도 있다. 이 사실을 인지하기. 마음 다스리기. 리더는 팀원들에게 24시간 감시당한다. 리더의 행동 하나하나가 팀에 전염된다. 리더로서 여러분의 역할은 사람들을 고무시키는 것.
• 그럼 마음을 어케 다스리냐.. 질문하기. 팀원의 문제를 바로 해결하려고 하지 말고, 팀원이 자기 문제를 스스로 해결하도록 도와주려고 하기. 그러려면 질문해야.
  
  스터디원들과 이야기한 가고 싶은 팀
• 팀의 비전을 알려주고 , 내가 기여할 수 있는 부분이 뭔지 알려주는 팀
• 주니어들에게 동기부여를 해주는 팀. 성취할 수 있도록 해야.
• 어떤 걸 성공했고, 어떤 식으로 기여하고 있다 알려주는 팀.
• 팀을 아끼는 사람이었으면 한다.
• 팀을 꾸려가는 데 관심이 많은 팀원 및 팀장이었으면.
• 피드백 문화가 강조되는 곳이었으면.

8장 스타일 가이드와 규칙 

구글 스타일가이드 : http://google.github.io/styleguide

Google Style Guides

 

스터디원들과 논의한 내용

• 규칙이 주가되는 것보다는, 회사에서 추구하는 목표가 뭐고, 거기에 집중했을 때 어떤 규칙이 나올지, 그걸 생각해야 한다.
• 중요한 건 일관성이다. 일관성 있게만 써주시면 된다는 말을 엄청 많이 들었다. 내가 쓴 코드 안에서도 일관성이 없었다. 변수명, 메서드명, 로직 짜는 데 있었어도 어떤 부분은 static으로 하고 어떤 데는 response 하고, 내부 통신용 api는 static이고 외부는 response 하고. 
• 주석 문장 구조 맞추는 것도 필요한 듯. 
• 주석을 지양하는 회사도 있음. 한눈에 읽히는 코드를 지향하는 업무도 있음.  메소드마다 주석을 남기는 곳도 있고, 아닌 곳도 있고. 
• 보통 주석에 개선점, todo 를 적거나. 
• 읽는 사람에게 맞춰야 한다
• 스타일 스터디를 여는 것도 좋을 거 같다. 같은 언어 쓰는 사람 모아서 다른 회사 스타일 보는 스터디.
• 다른 회사들 걸 보면서 자기 회사의 기준을 세울 수도 있고, 좋은 예제들을 수집할 수 있음. 

9장 코드 리뷰

• 코드리뷰는 이런 고민을 하게 해 준다 : 이 코드는 유지 보수하기 쉬운가? 내게 기술 부채를 안겨주나? 우리 팀원 중에 이 코드를 유지 보수해줄 전문가가 있는가?
• 코드리뷰도 하나의 태스크. 리뷰에 들어가는 시간도 너무 많이 들어가면 안 되니까. 리뷰의 이점을 살리면서 시간이 너무 들어가 지 않게 하는 것이 중요하다
• 리뷰어가 대안을 제시하는 건 가능하지만 이해하기 더 쉽거나 기능을 더 개선하는 대안일 경우에 리뷰어가 다른 대안을 제시할 수 있다. 다른 사람의 코드를 갈아엎는 건 예의 없는…
• 코드리뷰를 하면 다른 사람이 봤을 때 뭔 소리야? 싶은 거를 쓰지 않게 노력하는 거 같다.
• 코드리뷰 장점
  • 코드 정확도 확인
  • 변경된 코드를 다른 엔지니어도 이해
  • 코드베이스 일관되게 관리
  • 팀이 주인의식을 강하게 느낌
  • 지식이 공유
  • 코드 리뷰 자체의 기록이 남음(디버깅에 용이함)
• 코드리뷰는 공손하고 전문가답게!
  
  
  스터디원들과 논의한 내용 
• 코드리뷰를 리뷰: 한 번 한 번이 기억에 남는다. 근데 상사가 해준 코드리뷰가 진리처럼 받아들이지는 않게 조심해야 한다.

11장 테스트 개요

• 테스트 체계가 잘 갖춰져 있다면, 변화를 두려워할 필요가 없음. 테스트는 소프트웨어 개발의 핵심 역량
• 자동테스트 : 테스트작성, 수행, 실패 테스트에 대한 조작
• 오늘날 시스템 규모와 배포 속도를 따라잡으려면 엔지니어가 테스트도 같이 개발해야
• 테스트 코드가 주는 혜택 : 디버깅 감소, 변경사항 유연하게 수용 가능, 테스트를 통해 문서의 노후화 점검, 코드리뷰 시간 감소
• 더 작은 테스트가 더 빠르고 안정적이다
• 크기 : 테스트 케이스 하나를 실행하는 데 필요한 자원 메모리 프로세스 시간
• 범위 : 주어진 테스트가 얼마나 많은 코드를 검증하느냐
• 작은 테스트 : 테스트는 단 하나의 프로세스에서 실행돼야.
• 작은 테스트 중간 테스트 큰 테스트의 차이를 잘 모르겠다
• 꺠뜨려보고 싶은 모든 것을 테스트하라.

12장 단위테스트

• 구글은 테스트 유지보수성을 중시한다. 단위 테스트는 엔지니어 일상에서 비중이 크기 때문에.
• 테스트는 유지보수하기 쉬워야 한다. 이 테스트가 무엇을 테스트하기 위한 것인지 명확해야 하고, 무엇이 잘못됐는지, 어떻게 고쳐야 하는지 명확하게 알 수 있도록 해야 한다. 그렇지 않으면, 버그가 아님에도 버그라고 오류를 내뱉는 경우가 생김.
• 깨지지 않는 테스트 만들기
  • 이상적인 테스트 : 변하지 않는다. 시스템의 요구 사항이 바뀌지 않는 한 수정할 일이 없어야 함. 리팩토링, 새로운 기능 추가 시에는 테스트에 변경이 없어야 함. 버그 수정으로 코드를 수정할 경우, 해당 버그에 대한 테스트 코드를 작성해야. 기존 테스트는 변경 없어야. 시스템의 기존 행위를 변경할 경우, 기존 테스트 역시 변경돼야,
  • 공개 API로 테스트
  • 상호작용이 아니라 상태를 테스트
  • 명확한 테스트 작성하기 : 테스트 실패 이유 1) 진짜 버그를 잡아서 2) 테스트가 잘못돼서. 테스트 실패 시 둘 중 어떤 이유인지 파악하고 문제를 조사해야 한다. 실패 원인이 불분명하거나, 왜 만들어진 테스트인지 알아내기 어려우면 명확하다고 할 수 없다.테스트 메서드 이름은 검사하려는 행위를 작성
  • 메서드명으로는 내용을 모두 파악하기 어려울 수 있으므로 테스트코드 주석에다가 given when then 적기. 상세 내용은 아래에. 
  • 명확한 테스트는 어떻게 작성하는가?
    • 완전하고 간결하게 만들기 : 테스트코드를 봤을 때 뭘 테스트하는지 모르게 쓰지 마삼. 관련 없는 내용을 숨기기.
    • 메서드가 아니라 행위를 테스트하기
    • 제품 코드의 메서드 하나에 테스트 메소드도 하나 두는 식으로 코드 구조와 일치시킬 필요는 없음. 메소드 하나가 몇 가지 일을 하는 경우도 있기 때문에.
    • 따라서 테스트를 메서드 별로 작성하지 말고, 행위별로 작성해야. 행위: 어떤 상태에서 어떤 입력받았을 때 시스템이 보장하는 반응. given/when/then 은행 잔고가 빈 상태에서(given) 돈을 인출하려 한다(when) 면, 거래를 거부한다(then)
    • 테스트 구조는 행위가 부각되도록 구성. given, when, then 구조를 지키자
    • 테스트 이름 : 수행하는 동작, 예상 결과를 모두 담아야 좋은 이름. 사람이 읽는 것이므로 엄청 길게 써도 된다.
    • 테스트에 논리 넣지 말기 : 연산자 반복문 조건문 등 실패 메시지 명확하게 작성하기.