구글에서 말하는 단위 테스트는 단일 클래스나 메서드처럼 범위가 상대적으로 좁은 테스트를 뜻한다. 테스트의 가장 중요한 목적은 버그 예방이다. 그 다음으로는 엔지니어의 생산성 개선이 있다. 범위가 넓은 테스트와 비교했을 때 단위 테스트는 생산성을 끌어올리는 훌륭한 수단이 될 수 있다. 단위 테스트는 대체로 작은 테스트에 속한다. 작은 테스트는 빠...

테스트는 처음부터 프로그래밍과 함께였다. 하지만 오랫동안 테스트 프로세스는 크게 개선되지 못 했고, 대부분 수동으로 이루어져 오류가 나기 쉬운 프로세스였다. 2000년대 초부터 테스트 방식이 진화되었고 그 진회의 중심에는 개발자가 주도하는 테스트와 자동 테스트가 있었다. 자동 테스트는 버그가 몰래 숨어들어 고객을 놀라게 하는 시태를 막아준다. 또 새...

대부분의 엔지니어의 대표적인 불만이 양질의 문서자료가 부족하다는 것이다. 현실적으로 대부분의 문서자료는 소프트웨어 엔지니어 스스로가 작성해야 한다. 따라서 엔지니어가 문서화를 효과적으로 할 수 있도록 도와주는 적절한 도구와 보상이 필요하다. 구글에서 문서자료를 개선하고자 해본 시도 중 가장 성공적이었던 방법은 문서자료를 코드처럼 취급하여 엔지니어링 ...

코드 리뷰는 작성자 이외의 사람이 코드를 검토하는 프로세스로, 주로 코드를 코드베이스에 반영하기 전에 수행한다. 코드 리뷰는 버그가 코드베이스로 침투하기 전에 잡아낸다처럼 확실하고 쉽게 납득되는 이점을 제공한다. 9.1 코드 리뷰 흐름 코드 리뷰는 소프트웨어 개발 단계 곳곳에서 이루어질 수 있다. 구글에서는 변경을 코드베이스에 커밋하기 전에 수행한다...

대부분 엔지니어링 조직에는 내부 코드베이스를 관리하는 규칙이 있다. 예) 소스코드를 저장하는 위치, 코드 포맷팅, 명명 방식, 패턴, 예외와 스레드 사용법 등을 규정한다. 규칙은 제안이나 권장사항이 아닌 엄격하고 꼭 지켜야하는 법이다. 한편 지침은 권장사항과 모범 사례를 말한다. 구글에는 코딩할 때 따라야하는 규칙들을 모아서 프로그래밍 스타일 가이드...

구글은 데이터를 토대로 결정하는 데이터 주도 회사이다. 대다수 결정을 객관적으로 내릴 수 있고, 그에 따라 대체로 좋은 결과로 이루어진다. 사람과 관련해서는 데이터를 수집하고 분석하기가 만만치 않다. 구글은 소프트웨어 엔지니어링 측면에서 엔지니어링 생산성 자체에 집중하는 전문가 팀을 별도로 꾸려두면 회사 성장 과정에서 아주 중요하고 값진 통찰을 얻을...

팀 하나를 이끌게 되면 다음 순서로는 연관된 여러 팀을 이끄는 게 자연스러운 흐름이다. 역할이 커져도 기존의 모범 사례들은 계속 유효하다. 여러분은 똑같이 ‘섬기는 리더’여야 한다. 다만 섬겨야할 대상이 많아졌을 뿐이다. 이제 기술적이거나 엔지니어링적인 세부 내용을 접할 일은 점점 줄어서 깊게 보다는 넓게 살펴야 하는 위치가 된다. 그동안 자랑스러워한...

지금까지는 소프트웨어를 제작하는 팀의 구성과 문화의 관한 이야기를 다뤘다면 이번 장에서는 이 모두를 궁극적으로 책임져야 할 ‘사람’으로 시선을 돌려본다. 어떤 팀도 리더 없이는 제대로 굴러갈 수 없다. 구글에서는 리더 역할을 두 가지로 구분해 생각한다. 관리자 는 사람을 이끌고 테크 리드 는 기술과 관련한 책임을 진다. 선장없는 배와 같이 소프트웨어...

프로그래밍은 당면한 문제에 집중하여 코드를 생성하고, 소프트웨어 엔지니어링은 수십년 혹은 평생에 걸친 유동적이고 모호한 문제에 대응하기 위해 코드, 도구, 정책, 프로세스 등을 응용하는 더 폭 넓은 개념이다. 이번 장에서는 다양한 계층의 사용자를 위한 제품을 설계할 때 엔지니어가 짊어져야 할 책임에 관해 이야기한다. 4.1 편견은 피할 수 없다. ...

조직에는 배움의 문화가 자리 잡혀 있어야 하고, 그러려면 사람들에게 모르는 걸 인정할 수 있도록 돕는 심리적 안전을 제공해야 한다. 3.1 배움을 가로막는 장애물 심리적 안전 부족 - 불이익이 두려워서 스스로 위험을 감수하거나 실수를 드러내기 꺼리는 환경 정보 섬 - 조직의 각 부서가 서로 소통하거나 자원을 공유하지 않아서 지식이 파편화(정...