[dev] 이펙티브 엔지니어

원문 : https://gist.github.com/rondy/af1dee1d28c02e9a225ae55da2674a6f

읽기전에 : 저는 여기에 제시된 내용(에드몬드 라우의 책의 개요)을 제작하지 않았습니다. 인터넷 어딘가에서 복사하여 붙여 넣었지만 원본 소스가 정확히 무엇인지 기억나지 않습니다. 또한 저자의 이름을 찾을 수 없었기 때문에 적절한 크레딧을 줄 수 없습니다.

이펙티브 엔지니어

• 에드먼드 라우
• 매우 추천 👍
• http://www.theeffectiveengineer.com/

이펙티브 엔지니어란?

이펙티브 엔지니어란 일을 제대로 끝내는 사람들입니다. 그들은 결과를 산출합니다.

올바른 사고 방식 채택

큰 영향을 미치는 일에 집중하라

• 레버리지 = 생성된 임팩트 / 투자한 시간
• 레버리지을 효율성의 척도로 사용하세요.
• 임팩트의 80%는 작업의 20%에서 발생합니다.
• 쉬운 승리 만이 아니라 높은 레버리지에 집중하십시오.

학습을위한 최적화

• 필요한 경우 작업을 변경하십시오.
• 학습 최적화는 높은 레버리지를 가져옵니다.
• 성장을 위한 사고 방식을 채택하십시오.
  • 사람들과 대화하세요. 스토리 텔링에 능숙해지세요. 시간을 들일수록 나아집니다.
  • 성장을 위한 사고 방식을 가진 사람들은 노력을 통해 지식과 기술을 습득하고 발전시킬 수 있다고 생각합니다.
  • 당신의 이야기를 만드세요.
• 학습 속도에 투자
  • 다양한 분야를 학습하세요. 다양한 분야에 대한 학습은 기하 급수적인 성장으로 이어집니다. 학습은 빨리 시작 될수록 좋습니다.
  • 쉬운 작업을 수행하는 것은 엄청난 기회 비용입니다. 복합 학습의 기회를 놓칠 수 있습니다.
  • 수익성보다는 학습을 우선시하십시오.
  • 학습속도가 가장 높은 활동에 시간을 투자하십시오.
• 학습에 도움이되는 작업 환경을 찾으십시오.
  • 빠른 성장을 할 수 있는 회사 (# 문제 수 >> # 자원). 해결했을 떄 영향력이 큰 문제를 선택할 수 있는 기회를 잡으세요.
  • 우선 순위가 높은 프로젝트를 수행하고 있는지 확인하십시오.
  • 개방성 : 호기심을 가지고 문제를 해결하려는 문화를 찾으십시오.
  • 빠른 페이스의 속도.
  • 사람들은 당신보다 똑똑합니다.
  • 자율성 : 작업 대상을 선택할 자유. 소규모 회사 => 더 많은 자율성.
• 업무 중 가져야 할 마음가짐.
  • 새로운 기술을 매일 습득하는 습관을 만드십시오.
  • 뛰어난 엔지니어가 작성한 코드를 읽습니다.
  • 모르는 코드는 두려움없이 뛰어 들어보십시오.
  • 항상 배우십시오. 수요가 많은 기술에 투자하십시오.
  • 책을 읽으십시오. 회의에 참석하십시오.
  • 강력한 인간 관계를 구축하고 유지하십시오.

정기적인 우선 순위 지정

• 잘못된 아이디어를 다루는 데 드는 기회 비용으로 인해 성장이 지연 될 수 있습니다.
• ROI(Return On Investment) = 투자수익을 기준으로 작업의 우선 순위를 정하십시오.
• 정기적인 우선 순위 지정은 높은 레버리지를 취하는 방법입니다.
• TODO 목록에서 :
  • 투두 리스트를 나열 할 때 '단일작업’의 목록을 유지하십시오.
  • 무언가를 기억하려고하지 마십시오. 뇌는 기억력이 좋지 않습니다. 오히려 처리에 능숙합니다.
• 정기적으로 자문 해보십시오. 이것이 내가 작업해야 할 가장 중요한 것인가요?
• 직접 가치를 창출하는 것에 집중하십시오.
• 아니오라고 말하는 것을 배우십시오.
• 중요하고 긴급하지 않은 것에 집중하십시오.
• 깊이 집중하는 방법을 찾으십시오. “플로우 단계의 집중은 너무 깊어서 시간 감각과 자신의 문제마저 잃게합니다.”
• 가능하면 일정에 더 긴 집중의 시간 블록을 계획하십시오.
• 진행중인 작업량을 제한하십시오.
  • 컨텍스트 전환 비용은 높습니다.
• 우선 순위를 정하는 것은 어렵습니다.
• 우선 순위는 높은 이익을 가져다 줍니다. 올바른 작업 순서는 수행하는 능력에 큰 영향을 미칩니다.

반복 학습에 대한 투자

• 지속적인 배포(CD/CI)는 큰 레버리지를 가져다 줍니다.
  • 지속적인 배포는 코드를 수동으로 배포 할 때에 비해 많은 시간을 절약 해줍니다. 엔지니어는 일을 끝내는 사람들입니다. 이펙티브 엔지니어는 결과를 산출합니다.
• 빨리 배우기 위해 빨리 움직이십시오.
  • 빨리 움직이면 빠르게 문제를 해결할 수 있습니다.
  • 빠르게 움직이면 더 많은 것을 쌓고, 더 빠른 속도로 배울 수 있습니다.
• 시간 절약 도구에 투자하십시오.
  • 두 번 이상 무언가를 해야하는 경우 세 번째에는 도구를 만드십시오.
  • 도구는 '하루’라는 경계를 넘는 영향을 줄 조력자입니다.
  • 빠른 도구가 더 자주 사용됩니다.
  • 빠른 툴은 이전에는 불가능했던 새로운 워크 플로우를 가능하게합니다.
  • 도구로 생산성이 급증합니다.
  • 도구의 시간 절약 속성도 팀 채택에 따라 확장됩니다.
• 디버깅 및 유효성 검사 루프를 줄입니다.
  • 디버깅 워크 플로를 최적화하는데 소요되는 추가 시간은 적은 노력으로 성가신 버그를 해결하는 데 도움이 됩니다.
  • 디버깅은 어렵습니다. 시간이 많이 걸립니다. 디버깅 루프를 단축하기위한 사전 투자는 그만한 가치가 있습니다.
• 넓은 범위의 테스트는 빌드 및 사이트 깨짐을 줄여줍니다.
• 사람들이 프로그램을 실행하도록 장려하기 위한 빠른 단위 테스트.
• 개발 시간을 단축하기 위한 빠른 incremental 컴파일 및 리로드.
• 당신의 프로그래밍 환경을 마스터하십시오.
  • 하나의 에디. 하나의 프로그래밍 언어를 다루는 고급 스킬. Shell과 키보드로 수동 워크 플로우를 자동화합니다. Interactive shell을 사용하십시오. 특정 테스트를 쉽게 실행할 수 있습니다.
• 더 빠르게 반복하면, 빠르게 배울 수 있습니다.

개선하고 싶은 것을 측정하십시오

• 메트릭을 사용하여 진행 상황을 주도하십시오.
  • 측정 할 수 없으면 개선 할 수 없습니다.
  • 좋은 통계.
    • 올바른 일에 집중할 수 있도록 도와줍니다.
    • 앞으로 전진합니다.
    • 향후 회귀에 대비할 수 있습니다.
    • 성능 튜닝 : 모든 변경은 메트릭을 엄격하게 개선해야합니다.
    • 메트릭이 잘못되면 원치 않는 동작이 발생할 수 있습니다.
    • 예 :
      • 일한 시간 < 생산성.
      • 클릭률 < 긴 클릭률.
  • 선택한 측정 항목은 결정 및 행동에 영향을줍니다.
  • 최적화되면 팀에 대한 영향을 극대화하는 측정 항목을 찾으십시오.
  • 실행 가능한 메트릭 : 팀의 노력을 통해 팀원의 행동을 편하게 설명 할 수 있습니다.
  • 반응 형 메트릭 : 특정 변경 사항이 = ve 또는 -ive 인지에 대한 피드백을 제공하기 위해 빠르게 업데이트됩니다.
  • 메트릭을 선택하는 것은 높은 레버리지를 취합니다.
  • 올바른 측정 항목을 선택할 시간을 정하십시오.
• 무슨 일이 일어나고 있는지 이해하기 위해 모든 것을 측정 하십시오.
  • 무엇이든 측정하고 모든 것을 측정하십시오.
  • Graphite, StatsD. 한 줄의 코드로 새로운 카운터 또는 타이머를 즉석에서 정의 할 수 있습니다.
  • 달성하고자하는 목표를 측정하는 것은 높은 레버리지를 취하는 것 입니다.
• 유용한 숫자를 내면화하십시오.
  • 유용한 숫자에 대한 지식은 이익을 극대화하기위한 노력을 어디에 투자해야하는지 알 수 있는 귀중한 지름길을 제공합니다.
  • 선행 작업이 필요합니다. 정확할 필요는 없으며 대강의 아이디어만으로 충분합니다.
  • 유용한 숫자를 알면 엔벨로프 계산을하여 실제로 디자인을 만들지 않고도 디자인의 성능 속성을 신속하게 평가할 수 있습니다.
  • 유용한 숫자를 내면화하면 이상을 발견하는 데 도움이됩니다. 데이터 무결성에 대해 회의적이 되십시오.
• 데이터를 자유롭게 기록하십시오.
• 데이터 정확도를 더 빨리 반복 할 수있는 도구를 구축하십시오.
• 더 빨리 데이터를 검사하십시오.
• 숫자가 떨어지면 더 빨리 파 내십시오.

✔️ 진행 상황을 측정하십시오. 최상위 측정 항목을 신중하게 선택하십시오. 시스템을 계측하십시오. 당신의 숫자를 파악하세요. 데이터 무결성을 우선시하십시오.

아이디어를 조기에 자주 확인하라.

• 조기에 검증하지 않으면 노력이 낭비됩니다.
• 피드백을 지연시키지 마십시오.
• 작업을 검증하는 노력이 적은 방법을 찾으십시오.
• 소규모 배치작업의 힘. 흐름을 중지하여 큰 실수를하지 않도록 도와줍니다.
• 반복적으로 문제에 접근하십시오.
• 큰 구현을 하지마시오.
• 혼자 일하나요? 조심하세요. 추가로 목소리를 내고 피드백을받으세요.

프로젝트 추정 기술을 향상시킵니다.

• 맨 먼스(인력)의 환상을 조심하세요. 커뮤니케이의 오버 헤드는 매우 큽니다.
• 위험을 조기에 줄이십시오.
• 프로젝트 재 작성하세요 - 초기의 작성본은 거의 항상 실패합니다.
• 추가 시간은 생산성을 저하시킵니다. 번아웃을 일으킵니다.
• 가장 위험한 작업을 먼저 수행하십시오.
• 미지의 위험에 대비한 시간 계산을 허용하십시오.

실용주의와 품질의 균형

• 높은 코드 품질. 코드 가독성.
• 지속 가능한 코드 검토 프로세스를 설정하십시오.
• 코드 리뷰 도움말 :
  • 버그 및 디자인 문제를 조기에 파악하십시오.
  • 코드베이스에 대한 실무 지식 공유
  • 장기 민첩성이 향상됩니다. 이해하기 쉽고 수정이 쉽습니다.

추상화를 통한 복잡성 관리

• 예 : MapReduce.
• 올바른 추상화는 큰 차이를 만듭니다.
• “올바른 것을 고르면, 프로그래밍은 자연스럽게 디자인에서 흘러 나옵니다. 모듈은 작고 간단한 인터페이스를 갖습니다. 광범위한 재구성없이 새로운 기능이 더 적합 할 것입니다. "
• “잘못된 것을 고르면, 프로그래밍은 놀라 울 정도로 놀라운 일이 될 것이다. 인터페이스는 예상치 못한 상호 작용을 수용해야하므로 인터페이스가 바로크하고 어색해지며 심지어 가장 간단한 변경조차하기가 어렵다.”
• 올바른 추상화는 엔지니어링 생산성을 몇 배나 높일 수 있습니다.
• 간단한 추상화는 여러 개념을 서로 섞지 않아도되므로 함께 고려하지 않고 독립적으로 추론 할 수 있습니다.
• 좋은 추상화를 설계하려면 작업이 필요합니다.
• 추상화의 사용법과 인기는 그 품질에 대한 합리적인 대리를 제공합니다.

테스트 자동화

• 단위 테스트 사례 및 일부 통합 테스트는 점점 커지는 코드베이스를 관리하는 확장 가능한 방법을 제공합니다.
• 광범위하고 자동화 된 테스트 모음은 품질을 검증하고 회귀를 방지함으로써 전반적인 오류율을 줄일 수 있습니다.
• 또한 테스트를 통해 엔지니어는 특히 큰 리팩토링을 크게 변경할 수 있습니다.
• 이러한 이점에도 불구하고 자동화 된 테스트 문화를 정착시키기가 어려울 수 있습니다.
• 높은 레버리지 테스트에 중점을 둡니다.
• 더 많은 테스트를 작성하고 선의의 피드백주기를 만들고 더 많은 개발 시간을 절약하십시오.

기술 부채 상환

• 기술 부채는 코드베이스의 건강과 품질을 개선하는 데 필요한 모든 연기 된 작업을 말하며 다루지 않은 채 방치하면 속도가 느려집니다.
• 기술 부채는 시간 내에 상환되는 한 괜찮습니다.
• 자주 리팩토링하십시오.

운영 복잡성 감소

• 낮은 기술을 지속적으로 거부하세요. 빛나는 신기술에 흔들리지 마십시오.
• 추가적인 기술은 결국 잘못을 일으킬 수 있습니다. 당신의 시간이 필요합니다.
• 간단한 일을 먼저하십시오.
• 운영의 단순성을 받아들입니다.
• 가장 먼저 떠오르는 솔루션은 일반적으로 복잡합니다. 멈추지 마십시오. 양파 층을 벗겨 내십시오.
• 아키텍처를 단순화하여 운영 부담을 줄입니다.
• “우리의 미래 운영 부담을 줄이면서 작업을 수행 할 수있는 가장 간단한 솔루션은 무엇입니까?”
• 단순성에 중점을 둔 분야는 높은 활용입니다.

이른 실패

• 즉시 그리고 눈에 띄게 실패합니다.
• 반드시 사용자를 위한 프로그램의 충돌을 의미하지는 않습니다.
• 문제를 신속하게 해결할 수 있습니다.
• 빠른 실패는 디버깅 시간을 절약하므로 활용도가 높습니다.

끊임없이 자동화

• 기계적인 부분의 자동화는 좋습니다.
• 의사 결정 자동화는 안됩니다.
• 신속하게 대응하고 회복 할 수 있는 능력을 연마하십시오.
  • 장애 방지 보다는 신속하게 복구 활용을 활용합니다.
• “성공을위한 스크립트”, 실패 시나리오를 연습하고 신속하게 복구 할 수있는 능력에 노력하십시오.
• 배치 프로세스를 견고하게 만들기
• 프로세스를 재시도 가능하게하십시오 (즉, 전역 상태를 떠나지 않음).

팀의 성장에 투자

• 조직의 합류에 투자하십시오.
• 엔지니어링 단계를 올라 갈수록 개인의 기여가 아니라 주변 사람들에게 미치는 영향으로 효과가 더 많이 측정됩니다.
• "당신은 팀 전체를 다른 팀보다 향상시킬 경우 직원 엔지니어입니다. 회사 전체를 다른 팀보다 개선 할 경우 주요 엔지니어입니다. ‘업계를 개선하고 있습니다.’ - 주변의 모든 사람이 성공하도록하는 데 중점을 둡니다.
• 당신의 커리어는 팀의 성공에 달려 있습니다.
• 모두의 책임을 다하십시오.
• 코드의 공유 소유권.
  • 버스지수를 두 명 이상 유지하십시오.
  • 공유 소유권은 격리 된 정보를 제거합니다.
• 사후 모템을 통해 집단적 지혜를 쌓으십시오.
• 자동화 된 테스트에 투자하십시오.
  • 자동화 된 테스트 케이스는 리팩토링시 신뢰도가 높아집니다.
  • 코드가 최신 인 경우 테스트 사례를 작성하십시오.
  • 100 % 코드 범위에 대해 독단적으로 행동하지 마십시오.
  • 테스트 가치는 시간이 지남에 따라 증가하고 작성 비용은 줄어 듭니다.
• 최고를 고용하십시오.
• 훌륭한 조언자와 함께하십시오

☀️“레버리지는 효과적인 엔지니어가 활동을 보는 데 사용되는 렌즈입니다. ☀️

읽어볼 만한 책 10권 :

• Peopleware Productive projects and Teams. Amazon. My Summary.
• Team Geek: A Software Developer’s Guide to Working Well with Others. (Debugging Teams) Amazon. My Summary.
• High Output Management
• Getting Things Done: The Art of Stress-Free Productivity
• The 4-Hour Workweek: Escape 9-5, Live Anywhere, and Join the New Rich
• The 7 Habits of Highly Effective People: Powerful Lessons in Personal Change
• Conscious Business: How to Build Value Through Values
• Your Brain at Work
• Flow: The Psychology of Optimal Experience
• Succeed: How We Can Reach Our Goals

팔로우 추천 블로그 :

• http://www.theeffectiveengineer.com/ - Effective Engineer는 개인의 블로그로 엔지니어링 습관, 생산성 팁, 리더십 및 문화에 대해 글을 씁니다.
• http://www.kalzumeus.com/ - Patrick McKenzie는 자체 소프트웨어 비즈니스를 운영하고 있으며 경력 조언, 컨설팅, SEO 및 소프트웨어 판매에 관한 많은 훌륭한 기사를 작성했습니다.
• http://katemats.com/ - Microsoft 및 Amazon과 같은 대기업 및 신생 기업에서 근무한 Kate Matsudaira는 블로그에서 기술, 리더십 및 생활에 대한 조언을 공유합니다.
• http://randsinrepose.com/ - Michael Lopp은 Netscape, Apple, Palantir 및 Pinterest에서 수년간 리더십 직책을 수행했으며 기술 수명 및 엔지니어링 관리에 관해 글을 썼습니다.
• http://softwareleadweekly.com/ - Oren Ellenbogen은 엔지니어링 리더십과 문화에 관한 주간 주간 뉴스 레터를 큐 레이션합니다.
• http://calnewport.com/ - Georgetown의 컴퓨터 과학 조교 인 Cal Newport는 성공적이고 만족스러운 삶을위한 증거 기반 조언에 중점을 둡니다.
• http://www.joelonsoftware.com/ - Stack Exchange의 공동 창립자 인 Joel Spolsky는 블로그에 모든 종류의 지혜로운 프로그래밍 진주를 제공합니다.
• http://martinfowler.com/ - 리팩토링 (Refactoring) 책의 저자 인 Martin Fowler는 소프트웨어 팀의 생산성을 극대화하는 방법에 대해 쓰고 일반적인 프로그래밍 패턴에 대한 자세한 내용을 제공합니다.
• http://pgbovine.net/ - 컴퓨터 과학 교수 필립 구오는 대학원과 직장 경험에 대해 광범위하고 공개적으로 글을 썼습니다.