유년

유년

개발자

[Books] 이펙티브 엔지니어

이펙티브 엔지니어 - 개발자의 인생을 바꾸는 효율성의 법칙 (The Effective Engineer)

  • 저자: 에드먼드 라우
  • 출판사: 길벗
  • 발행일: 2022.06.27 (초판 발행) / 원서: 2015.03

효율적으로 일하기

주니어 개발자로서 어떻게 하면 효율적이고 발전적으로 일할 수 있는 지 생각하는 도중 이 책을 읽게 되었습니다.

이 책의 1부 1장은 레버리지가 높은 활동에 집중하라입니다.

그리고 이후 내용들은 전부 레버리지가 높은 활동들을 파악하고 효율적으로 처리하는 방법에 대한 설명들입니다.

저자가 구글을 떠난 이유

저자는 신입 개발자로 구글에 입사한 지 2년만에 스타트업으로 이직했다고 합니다.

이유는 “구글은 더이상 내가 학습하기에 최적의 장소가 아니라는 걸 깨달았기 때문”이었습니다.

세계 최고의 기업에서 일하면서도 더 많이 배우기 위해 스스로 떠날 수 있다는 게 충격이었습니다.

저도 현실에 안주하지 않고 계속 발전해 나갈 수 있도록 마음을 다잡아야겠습니다…

작업기억

“기억하는 데 노력을 기울이면 주의력이 떨어지고 의사 결정 능력이 손상되며 신체 수행 능력까지 망가진다.”

작업기억은 지금 읽고 있는 심리학 책 “생각은 어떻게 행동이 되는가”에도 나온 개념입니다.

작업기억에 저장할 수 있는 항목의 수는 제한되어 있으므로, 할 일 목록과 우선순위 등을 기록하여 뇌가 에너지 낭비를 하지 않도록 하는 게 좋습니다.

또한 할 일 목록을 작성한 뒤에도 레버리지가 높은 다른 할 일이 있을 지 반복해서 물어야 합니다.

프로젝트를 후퇴시키지 않는 법

프로젝트를 진행하다 보면 항상 앞으로만 나아가지는 않습니다.

책에는 이를 보완할 수 있는 방안들이 소개되어 있습니다.

무작정 앞으로 나아가려고 하기 보다는 후퇴하지 않도록 신경쓰면서 나아가는 것이 중요할 수도 있겠다는 생각이 들었습니다.

회귀 테스트

회귀 테스트는 패치가 실제로 버그를 수정했는지 확인하고 앞으로 그 버그가 다시 나타나는 것을 감지하는 테스트이다.

성능 래칭

성능 래칭이라는 임계값을 설정하여 지연 시간 등의 주요 지표가 래칭을 넘어서지 않도록 한다. 사로운 변경 사항이 래칭을 넘어갈 경우, 최적화하거나 다른 기능으로 이를 상쇄시켜야 배포할 수 있다.

개발과 경제

이 책은 “레버리지”라는 단어로부터 시작해서 많은 경제 용어를 비유적으로 사용합니다.

(개발 부채와 코드 수정을 통한 부채 상환, 잘못된 코드로 인한 이자, 온보딩 자료를 통한 배당 수익 등)

이해는 하지만 실천하기 어려운 내용들을 ‘손실’을 피하고 ‘이익’을 얻을 수 있다고 피부로 느낄수 있게 해주어서 강력한 동기부여가 되었습니다.

책을 읽은 이유 (목적 의식)

주니어 개발자로서 효율적이고 발전적으로 일할 수 있는 방법을 알고 싶어!

업무 시 참고할 것

  1. 사용하는 언어의 코어 개념 이해하기.
  2. 업무 처리시 항상 자동화 요소 고려하기.
  3. 지표는 드릴 다운할 수 있어야 한다.
  4. 프로젝트의 목표에 집중하자.
  5. 올바르지 않은 코드에 드는 시간은 부채에 대한 이자다. (주기적으로 부채를 상환해야 한다)
  6. “적은 운영 부담으로 이 작업을 완료할 가장 간단한 해결책은 무엇일까?”
  7. 팀이 성공하도록 투자하자 (그것이 나의 성공 가능성을 높여준다)
  8. 버스 지수를 높이자 (동료들과 프로젝트를 공유하자)
  9. 비판적인 피드백에 동요하지 말자 (비난이 아니다)

추천 프레임 워크

오픈소스 시스템 계측 도구

Graphite, StatsD, InfluxDB, Ganglia, Nagios, Munin

무료 or 오픈소스 A/B 테스트 프레임워크

Feature-flagging API, Vanity, Genetify, Content Experiments

더 읽고 싶은 책

  1. 스티븐 코비의 성공하는 사람들의 7가지 습관: “액티브 리딩”에서도 추천하는 책
  2. 스티븐 레비의 In the Plex 0과 1로 세상을 바꾸는 구글. 그 모든 이야기
  3. 스티브 맥코넬의 Software Estimation
  4. 톰 드마르코의 Controlling Software Projects
  5. 마틴 파울러의 리펙터링: 팀장님이 사주셔서 읽고 있는 책
  6. 티모시 리스터의 피플웨어
  7. 짐 쇼어의 Fail Fase: IEEE 소프트웨어에 실린 기사

인용구

  1. 토니 셰이 & 앨프리드 린 “매일 딱 1% 발전하고 이를 다음 성장의 기반으로 삼는다고 생각해보라. 이는 극적인 효과를 보이며 1년 후 우리를 365%(3.65배)가 아닌 37배 성장시킬 것이다.”
  2. 보비 존슨 “자신이 모르는 코드에 뛰어드는 것을 겁내지 않는 것”
  3. 페이스북 본사의 “MOVE FAST AND BREAK THINGS”
  4. 샘 쉴리스 “개발자가 저지르는 가장 대가가 큰 실수는 무언가를 처음부터 재작성하려고 하는 거죠. 그건 저질러서는 안 되는 가장 큰 죄에요.”
  5. 샘 쉴리스 “길을 잃을 수 있기 때문에 그렇게 하면 안 됩니다.” (C# -> JAVA 과정에서 리펙터링을 하지 않고, 변환 후에 정상 작동을 확인하고 리펙터링 한다)
  6. 워드 커닝햄 “첫 번째 코드를 배포하는 것은 부채를 지는 것과 같다. 약간의 부채는 재작성을 통해 즉시 상황하는 한 개발 속도를 높인다. (…) 부채를 상환하지 않은 채 두면 위험해진다. 올바르지 않은 코드에 들이는 시간은 부채에 대한 이자로 간주된다.”
  7. 스티브 잡스 “문제를 해결하려 시도할 때 처음 떠올리는 해결책은 매우 복잡한데 대부분의 사람들은 거기서 멈춥니다. 하지만 포기하지 말고 문제를 붙들고 양파처럼 껍질을 더 벗겨내다 보면 종종 매우 우아하고 간단한 해결책에 도달할 수 있습니다. 대부분이 거기에 도달할 때까지 시간이나 에너지를 들이지 않는 것뿐입니다.”
  8. 넷플릭스 개발 블로그의 “예기치 못한 큰 실패에 대한 최선의 방어책은 자주 실패하는 것이다.”

구절

  1. 파레토 법칙은 다양한 활동에서 20%의 작업이 80%의 효과를 낸다는 개념이다.
  2. 빠른 작업을 위해 파이썬이나 루비 같은 스크립트 언어를 최소한 하나는 익혀서 스위스 군용 칼처럼 활용하라.
  3. 그림 그리기와 글쓰기처럼 관련이 없어 보이는 영역이 교차하는 프로젝트가 더 나은 개발자로 발전할 기회가 될지도 모른다.
  4. 새로운 기능을 끊임없이 배포해야 한다는 압박 때문에 시간 절약 도구 제작이라는, 중요하지만 급하지 않은 작업을 중단하거나 포기하지 마라.
  5. 테스트 과정을 더 짧게 만들 수 없을지 잠시 생각할 시간을 가져라.
  6. 나는 일반적으로 어떤 작업을 수동으로 3~4번 정도 수행했다면 자동화할 가치가 있는지 고민한다.
  7. 회귀 테스트는 패치가 실제로 버그를 수정했는지 확인하고 앞으로 그 버그가 다시 나타나는 것을 감지한다.
  8. 만약 내가 하는 일이 핵심 지표에 영향을 미치지 못한다면 할 가치가 있을까? 또는 내가 놓치고 있는 핵심 지표가 있을까?
  9. 주당 근무 시간을 늘려서 생산량을 늘리려는 시도는 지속 가능하지 않다.
  10. 하루에 3시간 쓰기가 아닌 하루에 1,000 단어 쓰기에 집중하기로 했다. (올바른 지표를 선택하라)
  11. 어떤 때는 상관관계를 인과관계로 착각한다.
  12. ‘관심에 감사드립니다. 본 기능은 곧 출시될 예정입니다.’ (기능 수요 검증)
  13. 낮은 추정치가 초기에 기준점으로 자리 잡으면 나중에 더 정확한 추정치를 설정하기 어려우므로 관련 작업의 윤곽을 짜기 전에는 수치를 이야기하지 마라.
  14. 조사에 3일 정도 걸린다고 추정하지 말고, 3일 이내에 찾은 데이터를 기반으로 최선의 결정을 내리려고 노력하라.
  15. 해결하지 못한 핵심적인 X, Y, Z 기능은 어떻게 할건가요? (프로젝트 목표를 구체적으로 설정하고 부가적인 기능에 매달리지 마라)
  16. 코드 복잡성은 실제 코드 줄 수가 아니라 코드 줄 사이의 상호작용 수에 비례해 늘어난다.
  17. 이들은 재작성에 앞서 HTML5 컴포넌트를 플래시 애플리케이션에 삽입할 수 있게 해주는 애플리케이션 하이브리드 버전을 지원할 인프라를 구축했다. (재작성 프로젝트의 시간압박을 줄여라)
  18. 스타트업이나 소기업에서는 구글의 엔지니어링 관행이 지나칠 것이다. 신입 개발자에게 코드를 읽게 하고 가독성 검사를 통과하라고 강제한다면 작업 완료에 불필요한 간접 비용이 추가될 것이다. (품질 vs 실용주의)
  19. 구글, 페이스북, 링크드인, 트위터 같은 IT 기업의 오픈 소스 프로젝트를 살펴보라. 프로토콜 버퍼, 쓰리프트, 하이브, 맵리듀스와 같은 추상화가 회사가 성장하는 데 필수였던 이유를 알아보라.
  20. 개발 비용은 출시와 함께 멈추는 것이 아니었다. 오히려 바로 그때부터 쌓이기 시작하는 것으로 보아야 했다.
  21. 팀의 성공을 위한 투자가 자신의 성공 가능성도 높여준다.
  22. 어떤 프로젝트를 책임지는 유일한 개발자가 되면 자신의 가치가 올라간다는 잘못된 통념이 존재한다.
  23. 참가자는 디브리핑의 목표가 비난이 아닌 집단 지성의 극대화에 있다는 것을 명심하며 비판적인 피드백에 동요하지 않아야 한다.

저자 블로그

http://www.effectiveengineer.com/

댓글남기기