도서 리뷰

[IT 도서 리뷰] 구글 엔지니어는 이렇게 일한다 (CH. 7)

CH.7 엔지니어링 생산성 측정하기 소프트웨어 엔지니어링 측면에서 엔지니어링 생산성 자체에 집중하는 전문가팀을 별도로 꾸려두면 회사 성장 과정에서 아주 중요하고 값진 통찰을 얻을 수 있다. 7.1 엔지니어링 생산성을 측정하는 이유 사업을 키운다는 건 소통 비용이 증가한다는 것을 의미한다. 이를 개개인의 생산성을 높이는 것으로 소통 비용 증가를 억제할 수 있다. 생산성을 늘리기 위해서는 엔지니어링 프로세스에서 비효율적인 부분을 찾아 고쳐야 한다. 하지만 개선 사이클 자체를 만들고 관리하는 데도 인력이 투입된다. 구글은 엔지니어링 생산성을 이해하기 위한 전담 연구팀을 꾸려 이 ㅌㅌ트레이드오프에 대응했다. 우선 문제를 분류하는 일부터 시작한다. 예시: 가독성 프로세스 7.2 선별: 측정할 가치가 있는가? 생산..

[IT 도서 리뷰] 구글 엔지니어는 이렇게 일한다 (CH. 6)

CH.6 성장하는 조직 이끌기 팀 하나를 이끌게 되었다면 연관된 여러 팀을 이끄는 게 자연스러운 흐름이다. 훌륭한 리더로 성장하기 위해서는 다음이 필요하다. 3A 리더십: 늘 결정하라(Always Be Deciding), 늘 떠나라(Always Be Leaving), 늘 확장하라(Always Be Scaling) 6.1 늘 결정하라(Always Be Deciding) 여러 팀으로 구성된 팀을 관리한다 = 기존보다 높은 수준에서 더 많은 걸 결정해야 한다 6.1.1 비행기 일화 트레이드오프에 관한 일화. 리더의 역할은 '나무들 사이로 숲 전체를 보면서' 목표한 중요 나무까지로 가는 길을 찾아 엔지니어들을 안내해주는 것이다. 이 과정은 세 단계로 나뉜다. 먼저 '눈가리개'를 찾아내고, '트레이드오프'들을 파..

[IT 도서 리뷰] 구글 엔지니어는 이렇게 일한다 (CH. 5)

CH. 5 팀 이끌기 리더가 없다면 엔지니어들은 값진 시간을 허비할지도 모른다. 이번 장의 주제는 사람 관리와 기술 리더십이지만, 개인 기여자에게도 좋다. 리더를 이해하는데 도움이 될 것이기 때문에 5.1 관리자와 테크 리드(혹은 둘 다) 5.1.1 엔지니어링 관리자 팀의 구성원 모두의 성과, 생산성, 행복을 책임 져야 한다. 5.1.2 테크 리드 제품의 기술적인 면, 즉 기술과 관련한 결정과 선택, 아키텍쳐, 우선순위, 성능과 일반적인 프로젝트 관리를 책임진다. 5.1.3 테크 리드 매니저 소규모의 초기 팀에서는 기본적으로 테크 리드 매니저를 두는 경우가 많다. 인적, 기술적 요구를 혼자 관장한다. 5.2 개인 기여자에서 리더로 리더십의 장단점을 이해하느냐 못하느냐는 업무의 방향에 지대한 영향을 준다...

[IT 도서 리뷰] 구글 엔지니어는 이렇게 일한다 (CH. 4)

CH.4 공정 사회를 위한 엔지니어링 소프트웨어 엔지니어링 분야는 아직 새롭기 때문에 사회적 약자나 다양한 문화권에 미치는 영향을 이해해가는 중이다. 가장 취약한 고객들을 보호하지 못한 실패 사례를 구글도 많이 가지고 있으며 그래서 더 공정한 제품을 만드려고 노력한다. 4.1 편견은 피할 수 없다 사용자의 국적, 민족, 인종, 성별, 연령, 사회 경제적 위치, 장애 여부, 신념 체계 등에 신경 쓰지 않는다면 가장 우수한 엔지니어라 할지라도 의도와 달리 사용자에게 피해를 줄 수 있다. 구글의 엔지니어는 대부분 남성이고, 백인 혹은 아시아인이라서 모든 커뮤니티를 대변하지 못하는 게 사실이다. 예시 - 이미지 인식 4.2 다양성이 필요한 이유 이해하기 구글은 뛰어난 엔지니어가 되려면 제품 설계와 구현에 다양한..

[IT 도서 리뷰] 구글 엔지니어는 이렇게 일한다 (CH. 3)

CH.3 지식 공유 조직에 배움의 문화가 자리 잡혀야 하며 그러려면 사람들에게 모르는 걸 인정할 수 있도록 돕는 심리적 안전을 제공해야 한다. 3.1 배움을 가로막는 장애물 조직 전체에 전문성을 공유하기란 결코 쉬운 일이 아니고 구글은 특히 회사 규모가 커지면서 다음의 문제를 겪었다. 심리적 안전 부족: 불이익이 두려워서 위험을 감수하거나 실수를 드러내기 꺼리는 환경 정보 섬: 조직의 각 부서가 서로 소통하거나 자원을 공유하지 않아서 지식이 파편화 단일 장애점: 중요한 정보를 한 사람이 독점하면 병목이 생김 전부 아니면 전무 전문성: 조직 구성원이 '모든 것을 아는' 사람과 '아무것도 모르는' 초심자로 나뉨 앵무새처럼 흉내내기: 이해하지 못한 상태로 흉내만 내는 것 유령의 묘지: 무언가 잘못될 게 두려워..

[IT 도서 리뷰] 구글 엔지니어는 이렇게 일한다 (CH. 2)

2.1 내 코드를 숨기고 싶어요 불안감: 사람들은 자신이 진행 중인 작업물을 다른 사람이 보고 판단하는 걸 두려워 함 (인간으 ㅣ본성) 2.2 천재 신화 리눅스 리누스가 한 일은 유닉스와 유사한 커널의 시제품을 만들어 메일링 리스트로 뿌린 것 진짜 업적은 사람들을 협업하도록 이끈 것 파이썬 귀도 반 로섬이 첫 번째 버전을 작성한 건 사실이지만 그 후 버전들은 수천 명의 사람이 아이디어를 모으고 기능 개발 & 버그 수정 천재 신화는 팀이 이룬 성공을 단 한 사람(리더)에게 몰아주어 만들어지는 경향이 있으며 결국 우리 내면의 불안을 드러내는 또 다른 사례일 뿐이다. 2.3 숨기는 건 해롭다 자신이 올바른 길을 걷고 있음을 확인할 수 없다. 2.3.1 조기 감지 아이디어를 숨기는 것은 엄청난 도박으로 초기 설..

[IT 도서 리뷰] 구글 엔지니어는 이렇게 일한다 (CH. 1)

CH 1. 소프트웨어 엔지니어링이란? 프로그래밍과 소프트웨어 엔지니어링의 가장 큰 차이는 시간, (규모) 확장, 실전에서의 트레이드오프, 이렇게 세 가지이다. 시간: 시간의 흐름과 언젠가 변경될 가능성에 더 신경 써야 함 확장: 소프트웨어 자체뿐 아니라 제작하는 조직까지 양 측면 모두에서의 확장과 효율에 더 집중해야 함 트레이드오프: 대체로 수명과 성장 속도를 정밀하게 예측하기 어려운 상황에서, 결과에 더 큰 영향을 주는 보다 복잡한 결정을 내려야 함 더보기 시간 소프트웨어 엔지니어링에서 프로그래밍이 큰 비중을 차지하지만 결국 프로그래밍은 새로운 소프트웨어를 제작하는 수단이다. 코드의 예상 수명에 대해 생각하라. 단명하는 시스템은 '그저' 프로그래밍 문제와 다를 게 없지만 수명이 길어질수록 변경이라는 요..

[IT 도서 리뷰] 읽기 좋은 코드가 좋은 코드다 (Part. 4)

Part.4 선택된 주제들 14. 테스트와 가독성 테스트 코드에 대한 가독성에 대해 다룬다. 여기서 핵심은 다른 프로그래머가 수정하거나 새로운 테스트를 더하는 걸 쉽게 느낄 수 있도록 읽기 쉬워야 한다는 점이다. 14-1. 이 테스트를 더 읽기 쉽게 만들기 덜 중요한 세부 사항은 사용자가 볼 필요 없게 숨겨서 더 중요한 내용이 눈에 잘 띄게 해야 한다. 이 부분은 앞파트에서 배웠던 함수를 분리하는 것과 비슷한 이치인듯 하다. 14-2. 읽기 편한 메시지 만들기 assert를 호출할 때 무슨의미인지 알려주도록 해야 한다. 코딩을 시작하고 항상 에러가 뜨면, 무슨에러인지 몰라서 구글링하기 바빴던 기억이 있다. 에러를 보자마자 어떤 에러인지 알 수있다면 더욱 도움이 될 것이다. 특히, 파이썬같은 경우에 uni..

[IT 도서 리뷰] 읽기 좋은 코드가 좋은 코드다 (Part. 3)

Part 3. 코드 재작성하기 10. 상관없는 하위문제 추출하기 대표적인 예시 해당 코드부분에서 주요 목적과 상관없는 하위 문제라면 별도의 함수로 추출해준다. 코드를 작성할 때, 어디까지 함수화해야할지 고민이 될 때가 있었는데, 이를 명심한다면 고민이 줄어들 것이다. 가독성 이외에도 얻는 장점이 많다. 독립적인 테스트도 용이하며 함수 재사용성이 높아지며 손쉽게 개선할 수 있다. 다만, 너무 자잘한 부분까지 하려할 필요는 없다. (오히려 가독성을 해칠 수도 있음) 11. 한 번에 하나씩 ch.10과 이어지는 내용인듯 하다. 한 번에 여러 가지 일을 수행하는 코드는 이해하기 어렵다. 따라서 작업을 분리하는 것이다. 코드가 복잡하고 읽기 어렵다면, 많은 논리가 어우러져있다는 뜻이고 이는 보통 작업이 뒤엉켜있는..

[IT 도서 리뷰] 읽기 좋은 코드가 좋은 코드다 (Part. 2)

Part 2. 루프와 논리를 단순화하기 루프는 중요하다. 언어를 배울 때 생각하면 if, for, while 문 등을 제일 처음에 배우지 않는가. 이들이 모여 루프가 되고 논리가 된다. 코드는 수많은 루프와 논리로 이루어져 있고 이것만 단순화해도 좋은 코드가 될 것임이 자명하며 해당파트에서는 이 부분을 다뤘다. 7. 읽기 쉽게 흐름제어 만들기 part 1에서 일관성이 중요하다고 했었다. 읽기 쉽기 위해서 여기서도 적용된다. 그에 대한 예시는 다음과 같다. # 왼쪽이 검사를 수행하는 대상 / 오른편은 비교대상 (고정값) while (bytes_received < bytes_expected): ''' ''' if와 else에 대한 순서도 주목할 수 있다. if에 어떤 조건을 넣느냐에 따라 읽기 쉬운 코드가 ..