reading >
html version (eng) : https://abseil.io/resources/swe-book/html/ch01.html
1.1 CH 1. 소프트웨어 엔지니어링이란? #
'프로그래밍' vs '소프트웨어 엔지니어링'
- 프로그래밍: 코드 생산에 관한 것
- 소프트웨어 엔지니어링: 프로그래밍을 확장하여 소프트웨어 수명이 다할때 까지 코드를 유지보수하는 문제까지 고려
- 코드의 기대 수명 동안 의존성, 기술, 제품 요구사항 변경에 대응할 역량이 갖춰져야 지속 가능한 소프트웨어
- 하이럼의 법칙: API 사용자가 충분히 많다면 API 명세서는 중요하지 않다. 시스템에서 눈에 보이는 모등 행위(동작)를 누군가는 이용하게 된다.
- 조직에서 반복적으로 수행하는 모든 작업은 필요 인력 측면에서 확장 가능해야 한다.(선형 증가 혹은 그 이하)
2.1 CH 2. 팀워크 이끌어내기 #
내 코드를 숨기고 싶어요
천재 신화
숨기는 건 해롭다
- 조기 감지
- 버스 지수
- 진척 속도
결론은, 숨기지 말자
'홀로 일하기'는 '함께 일하기'보다 본질적으로 더 위험합니다. 다른 사람이 아이디어를 훔친다거나 여러분이 똑똑하지 않다고 생각하는 게 두렵더라도, 잘못된 일에 여러분의 천금 가은 시간을 낭비 할 가능성을 더 걱정해야 합니다.
- 버스 지수
- 진척 속도
모든 건 팀에 달렸다
고기능 팀(high-functioning team)은 황금처럼 귀한, 성공으로 가는 열쇠입니다. 그러니 가능한 한 고기능 팀을 경험하는 걸 목표로 삼아야 합니다.
사회적 상호작용의 세 기둥
- 겸손(humility)
- 존중(respect)
- 신뢰(trust)
- 자존심 버리기
- 비평하고 비평받는 법 배우기
- 빠르게 실패하고 반복하기
비난 없는 포스트모템 문화
- 비평하고 비평받는 법 배우기
- 빠르게 실패하고 반복하기
- 포스트모템: 실패한 근본 원인을 분석하여 문서로 남기는 것이 실수로부터 배우는 핵심입니다
- 사건의 개요
- 사건을 인지하고 해결에 이르기까지의 타임라인
- 사건의 근본 원인
- 영향과 피해 평가
- 문제를 즉시 해결하기 위한 조치 항목(소유자 명시)
- 재발 방지를 위한 조치 항목
- 해당 경험에서 얻은 교훈
마음을 열고 받아들이자
구글다움
- 모호함을 뚫고 번창한다
- 피드백을 소중히 한다
- 저항(항상성)을 극복한다
- 사용자를 우선한다
- 팀에 관심을 기울인다
- 옳은 일을 한다
2.2 CH 3. 지식 공유 #
배움을 가로막는 장애물
- 심리적 안전 부족
- 정보 섬(information islands)
- SPOF
- all-or-nothing expertiese
- 앵무새처럼 흉내내기(parroting)
- 유령의 묘지
- 멘토 제도
- 큰 그룹에서의 심리적 안전
Recurse Center의 사회적 규칙- "음, 실제로는..." 금지
- "뒷좌석 운전 금지"
- 미묘한 '-주의' 금지("이건 우리 할머니도 할 수 있겠네!")
- 질문하기
- 맥락 이해하기
- 그룹 채팅: 간단한 질문에 적합
- 메일링 리스트: 맥락 정보가 많이 필요한 복잡한 질문에 적합
- YAQS: 질의응답 플랫폼
- 오피스 아워
- 기술 강연(tech talk)과 수업(class)
- 문서 자료
- 코드
- 지식 공유 문화 일구기
많은 회사에서 조직 문화를 나중에 생각해볼, 깔끔하게 딱 떨어지지 않는 '사람 사이의 문제'로 치부합니다. 하지만 구글은 코드 같은 살출물보다 문화와 환경을 첫 번째로 두고 생각해야 더 나은 결과를 얻는다고 믿습니다.
- 존중
구글 소프트웨어 엔지니어링 직무 사다리에서의 리더십 항목: 높은 수준의 기술 리더십을 요구하지만, 모든 리더십이 기술 문제와 관련된 것은 아닙니다. 리더는 주변 사람들을 성장시키고, 팀의 심리적 안전을 개선하고, 팀워크와 협업 문화를 조성하고, 팀 내 긴장을 해소하고, 구글 문화의 가치를 설정하며, 구글을 더 활기차고 신나는 일터로 가꿔야 합니다. 괴짜는 좋은 리더가 아닙니다.
- 보상과 인정
동료 상여 제도, 쿠도스(공개 칭찬) 제도
- 존중
- 개발자 가이드: 코딩 스타일 가이드, 공식 소프트웨어 엔지니어링 모범 사례, 코드 리뷰 가이드, 테스트 가이드, 금주의 팁
- go/ 링크
- 코드랩
- 정적 분석
- 뉴스레터
- 커뮤니티
- 구글에서 '갇고성 제도(readability)'는 단순한 코드 가독성 이상을 의미합니다. 프로그래밍 언어 모범 사례를 전파하기 위한 구글 전사 차원의 '표준 멘토링 프로세스'를 지칭하죠. 그리고 언어 이디엄, 코드 구조, API 설계, 공통 라이브러리의 올바른 사용법, 문서화, 테스트 커버리지 등의 전문 지식을 광범위하게 다룹니다.
- 가독성 인증 프로세스
가독성 승인: 모든 CL(Changelist)은 해당 언어의 가독성 자격증이 있는 누군가의 승인을 얻어야 함
2.3 CH 4. 공정 사회를 위한 엔지니어링 #
우리는 편견에서 벗어날 수 없다.
다양한 사용자층을 포용하도록 설게하려면 조직 구성 측면에서도 반드시 다양성을 갖춰야합니다.
제품 개발 속도는 모든 사용자에게 진정 유용해야 한다는 관점에서 평가되어야 합니다. 일부사용자에게 해를 끼칠 수 있는 제품이라면 차라리 출시를 늦추는 편이 낫습니다.
2.4 CH 5. 팀 이끌기 #
섬기는 리더십
- 관리자들이 질병
- 사람들을 '관리'하게 되는 병: 마이크로매니징, 저성과자 방치, 만만한 사람 고용
- '관리'병을 치료하려면 '섬기는 리더십'을 자유롭게 응용할 수 있어야 합니다.
2.6 CH 7. 엔지니어링 생산성 측정하기 #
Data-driven 회사
엔지니어링 생산성?
7.1 엔지니어링 생산성을 측정하는 이유
조직 규모 두 배 → 소통 비용 제곱 증가 (맨먼스 미신)
개개인의 생산성 높이기 → 소통 비용 증가 억제 → 사업 키우기 가능
생산성 개선 뿐 아니라 개선업무 자체의 효율성까지 높이기
7.2 선별: 측정할 가치가 있는가?
측정자체에도 비용이 많이 든다.
평소 작업방식에 영향을 주지 않도록 현명하게 측정, 평가 필요 (관찰자 효과?)
단순 추측도 안되지만 그렇다고 무의미한 측정으로 시간과 자원 낭비 말아야
어떤 결과를 기대하고, 왜 기대하나?
→ 예: 가독성 프로세스가 투자한만큼 값어치를 하는지
데이터가 기대한 결과를 뒷받침한다면 어떤 조치를 취하겠는가?
→ 결과 무관하게 현상유지 할것이라면 불필요
부정적인 결과가 나온다면 적절한 조치를 취할 것인가?
→ 안좋은예: 부정적 결과가 나오면 다른 이유를 들어서라도 기정 진로를 잘 틀지 않는다
결과에 따른 조치는 주가 결정은 누가 결정하고, 언제 수행하는가?
→ 측정 의뢰자가 조치(or 대행) 권한 있나? 결정권자가 결과 신뢰않는다면 측정 불필요
어떤 도구나 프로세스가 생산성에 미치는 영향을 측정하지 "말아야" 할 합당한 이유
당장 프로세스/도구를 변경할 여유가 없다.
결과 무관하게 곧 다른 요인으로 무의미해질 것이다. (예: 결정권자의 생각이 너무 확고하여 측정 결과가 무의미)
측정 결과를 이미 확정된 계획 뒷받침 용도로만 사용 (예: 프로세스 개선 효과는 이미 확실하나 어느 정도인지 알고 싶다??)
측정가능 지표들이 평가하기에 부정확하고 다른 요인으로 인해 혼탁 우려 크다
7.3 GSM 프레임워크: 목표와 신호를 뒷받침하는 의미 있는 지표 선정하기
Goal: 원하는 최종 결과, 측정을 통해 이해하고 싶은 내용을 고차원의 어휘로 표현, 특정 방식 명시하지 않음
Signal: goal을 이루었는지 판단하는 방법, 우리가 측정하고 싶어하는 것이지만 signal 자체는 측정하지 못할 수 있다.
Metric: signal을 대변, 실제 측정하는 대상, 이상적인 측정법이 아닐 수 있으나 충분히 가깝다고 믿는 것이어야 한다.
GSM f/w 유용성
"가로등 효과"를 없에준다. GSM은 이용하기 쉬운 지표가 아닌 목표성취에 도움이 되는 지표를 찾도록 이끌어준다.
원칙에 입각한 적절한 지표 선정 가능케 해준다. 목표를 측정할 수 있는 능력을 기준으로 지표 선정
측정 가능영역과 불가능 영역을 알려준다.
tracability 잃지 않는 것이 중요, 지표 → 신호 → 목표
7.4 Goal
원하는 속성 설명, 특정 지표를 명시하지 않아야 함
구글의 생산성 5개 요소 (QUANTS)
코드 품질
엔지니어들의 몰입도
지적 복잡성
박자와 속도
만족도 ** gerrit?
구글의 가독성 예를 여기에 적용해보자
7.5 Signal
신호는 목표 달성 여부를 알 수 있는 방법
모든 신호를 측정할 수 있는 것은 아니다.
모든 목표에는 최소 하나의 신호는 필요하다
구글 가독성 프로세스의 예시
7.6 Metric
측정의 최종 형태
신호 자체가 아니라 측정 가능한 프록시이기 때문에 완벽히 측정해내지 못할 수 있다. → 여러지표 종합
(가독성 예시: 코드리뷰 빨라졌나? 측정위해 설문과 로그 데이터 조합)
측정 불가 신호: 포기 (코드 품질 측정 → 엔지니어 스스로 평가 요청, 정량 측정 포기)
7.7 데이터로 지표 검증하기
가독성 예시
7.8 조치를 취하고 결과 추적하기
목표가 무언가 조치를 취해서 생산성을 끌어올리기였다는 걸 상기하자
도구 개선, 문서 보강, 낡은 프로세스 제거, 성과보상제도 개편 제안..
4.3 CH 18. 빌드 시스템과 빌드 철학 #
빌드 시스템의 핵심은 의존성 관리
Task-based build system: Ant, Maven, Gradle, Grunt, Rake
Task-based build system의 어두운 면
- 병렬실행 어렵다. 분산 빌드 불가능
- 증분 빌드 어렵다.
- 스크립트 유지보수, 디버깅 어렵다.
- 함수형 프로그래밍과 비슷한점 많다.
- 병렬실행 가능
- 확장
- 환경 격리
- 외부 의존성 명확히 드러내기
- 분산빌드
- 원격 캐싱
- 원격 실행
last modified 2022-10-08 10:17:41
Processing time 0.2267 sec