[최서희] 8장, 9장, 10장 : 품질과 실용주의 사이에서 균형을 유지하라 외 2장

10장/최서희.md

@@ -0,0 +1,36 @@
+ # Part 3: 장기적인 가치를 구축하라
+
+## Ch 10. 팀의 성장에 투자하라
+
+### 인상 깊었던 내용
+
+> 훌륭한 엔지니어링 문화의 특징은 다음과 같다.
+>
+> 1. 개발 주기 반복 속도를 최적화한다.
+> 2. 끊임없이 자동화를 추구한다.
+> 3. 올바른 소프트웨어 추상화를 구축한다.
+> 4. 코드 리뷰를 활용해서 높은 코드 품질을 유지하 는 데 집중한다.
+> 5. 서로 존중하는 근무 환경을 유지한다.
+> 6. 코드 소유권을 공유한다.
+> 7. 자동 테스트에 투자한다.
+> 8. 20%의 시간이나 해커톤을 통해 실험할 시간을 준다.
+> 9. 학습하고 꾸준히 발전하는 문화를 조성한다.
+> 10. 최고의 개발자를 고용한다.
+> 
+> 주변 사람들의 성공을 도와라. 높은 엔지니어링 직위는 동료들이 더 효과적으로 일할 수 있게 도와주는 이들을 위한 자리다. 게다가 주변 사람이 성공하면 여러분도 함께 이끌려 간다.
+> 
+> 코드 소유권을 공유하라. 본인이 개발의 병목이 되지 않도록 버스 지수가 2 이상이 되게 하라. 그러면 레버리지가 높은 다른 활동에 집중할 유연성이 생긴다.
+> 
+> 집단 지성을 디브리핑하고 기록하라. 소중한 지혜를 놓치지 않도록 팀원들과 함께 프로젝트를 되돌아보고, 효과가 있었던 부분과 그렇지 않은 부분을 알아보고, 배운 교훈을 기록하고 공유하라.
+> 
+> 훌륭한 엔지니어링 문화를 만들어라. 이는 생산성을 높이고 의사 결정을 능률화하고 뛰어난 개발자를 채용하는 데 도움이 된다. 영향력을 효과적으로 발휘하는 데 필요한 습관을 기르다 보면 훌륭한 문화도 만들어진다.
+
+---
+
+### 느낀 점
+
+개발을 시작하면서 상호 성장의 중요성을 많이 느꼈다. 개인적으로 공부하며 얻은 것도 많지만, 협업을 통해 팀원들에게서 배운 게 훨씬 더 많았다. 꼭 개발자 팀원들뿐 아니라 다른 분야의 팀원들에게서도 배울 점이 많다는 걸 직접 경험하며 깨달았다.
+
+개발은 개인 역량도 물론 중요하지만, 결국 여러 사람이 협력해 산출물을 만들어내는 작업이라 혼자만 잘한다고 좋은 결과가 나오는 게 아니라고 생각한다. 그래서 "주변 사람들이 성공하면 함께 이끌려 간다."는 말에 깊이 공감했다. 앞으로도 팀원들과 함께 배우고 성장하면서 더 좋은 결과를 만들어내고 싶다.
+
+또한 “코드 소유권을 공유하라”는 내용을 읽으며, 지금은 코드 리뷰를 통해 서로의 코드에 책임을 나누고 있지만, 여기에 각자 구현한 내용을 직접 설명하는 시간을 추가하면 더 좋겠다는 생각이 들었다. 그렇게 하면 팀원들 간의 이해도가 높아지고, 나중에 버그가 발생했을 때도 함께 더 빠르게 문제를 파악하고 해결할 수 있을 것이다.

8장/최서희.md

@@ -0,0 +1,29 @@
+# Part 3: 장기적인 가치를 구축하라
+
+## Ch 8. 품질과 실용주의 사이에서 균형을 유지하라
+
+### 인상 깊었던 내용
+
+> 일례로 구글에서는 소프트웨어 검사를 통해 개발자가 코드 리뷰 없이 저장소에 코드를 커밋하지 못하게 방지하며, 커밋할 때마다 최소한 1명이라도 다른 사람의 리뷰를 받아야 한다.
+코드 리뷰가 개발자에게 제공하는 명확한 혜택은 다음과 같다.
+> 1. 설계 결함이나 버그를 초기에 포착한다.
+> 2. 좋은 코드 작성법을 배우는 모델로써 도움이 된다.
+> 3. 코드베이스에 관한 실용적 지식을 공유한다.
+> 4. 장기적인 작업 속도가 향상된다.
+>
+> 어려운 문제를 한 번 해결하면 그 해결책을 여러 번 사용 할 수 있다.
+DRY(Don t repeat yourself, 반복하지 마라) 원칙의 간단한 응용인 좋은 추상화는 때로는 복잡한 공 통의 세부사항을 한 곳에 통합한다. 어려운 문제를 한 번 해결하면 그 해결책을 다시 사용할 때마다 보람을 느낄 것이다.
+>
+> 게다가 좋은 추상화는 복잡하게 꼬인 개념을 단순하 게 풀어낸다. 프로그래밍 언어 클로저clojure를 만든 리치히키Rich Hickey는 Simple made easy(단순한 것이 쉽다)'라는 자신의 강연에서 단순한 것은 하나의 역할 을 맡고, 하나의 작업을 수행하고, 하나의 목표를 달성 하고, 하나의 개념을 다룬다고 설명한다. 35 단순한 추 상화는 여러 개념을 서로 얽지 않으므로 의도치 않게 여러 개념을 동시에 고려할 필요 없이 각 개념에 대해 독립적으로 추론할 수 있다.
+
+---
+
+### 느낀 점
+
+최근 새로운 동아리 활동을 시작하면서 매주 개발 과제를 수행하고, 팀원들과 서로 코드 리뷰를 주고받고 있다. 예전에도 코드 리뷰가 중요하다는 건 알고 있었지만, 빠듯한 마감일에 쫓기다 보니 구현에만 집중할 때가 많았다. 그런데 이번 활동을 통해 다양한 피드백이 내 코드를 훨씬 더 완성도 높게 만들어준다는 걸 몸소 느끼고 있다.
+
+이 경험을 다른 프로젝트에도 적용하면서, 팀원들에게도 코드 리뷰의 중요성을 강조하게 됐다. 그래서 지금은 팀원 모두가 리뷰를 남겨야만 머지할 수 있는 프로세스를 만들었다. 단순히 기능을 완성하는 데 그치는 게 아니라, 좋은 피드백을 통해 품질을 높이는 과정이 얼마나 가치 있는지 점점 더 깨닫고 있다.
+
+또한 8장에서 가장 인상 깊었던 부분은 "어려운 문제를 한 번 해결하면 그 해결책을 여러 번 사용 할 수 있다."였다. 예전에는 문제를 마주할 때마다 '혹시 해결하지 못하면 어떡하지?’ 하는 두려움이 먼저 들었지만, 돌이켜보면 결국 해결하지 못한 문제는 없었다. 오히려 그 과정을 통해 더 성장했고, 나중에는 같은 문제로 고민하는 사람들에게 해결책을 공유할 수 있는 기회도 생겼다.
+
+이제는 문제를 단순한 장애물이 아니라 나를 성장시키는 중요한 요소로 바라보게 되었다. 앞으로도 어려운 문제를 피하지 않고 정면으로 마주하며, 그 과정에서 배우고 쌓은 경험들을 더 잘 활용해가고 싶다.

9장/최서희.md

@@ -0,0 +1,19 @@
+# Part 3: 장기적인 가치를 구축하라
+
+## Ch 9. 운영 부담을 최소화하라
+
+### 인상 깊었던 내용
+
+> 이펙티브 엔지니어는 단순하게 만드는 데 주력한다. 단순한 해결책은 이해하고 유지 보수하고 수정하기 쉽기 때문에 운영 부담이 적다.
+>
+> 크리거는 이렇게 설명했다. 간단한 일부터 하는 것이 핵심 엔지니어 링 신조 중 하나였어요. 저희는 이 신조를 제품에 적용 하고 고용에 적용하고 엔지니어링에 적용합니다. 이 원칙을 적은 포스터도 붙여 두었어요." 인스타그램 팀 은 설계를 검토할 때 "이것이 가장 간단한가?" 또는 " 지금 작성 중인 기능을 위해 완전히 새로운 시스템을 만드는 것이 가장 간단한 방법일까?"라고 물었다. 답 이 "아니오.”라면 다른 접근법을 떠올렸다.
+> 
+> 빨리 실패하면 오류의 원인을 정확히 찾을 수 있다. 오류를 감추고 실패를 지연시키지 않으면 디버깅이 더 쉬워진다.
+>
+> 짐 쇼어 Jim Shore는 IEEE 소프트웨어에 실린 기사 'Fail Fast(빨리 실패하라)' 에서 이렇게 설명한다. "빨리 실패하는 시스템은 문제가 일어났을 때 즉시 눈에 띄게 실패한다. 빨리 실패하기는 직관에 반하는 기법이다. '즉시 눈에 띄게 실패' 하게 하면 소프트웨어가 더 취약해질 것 같지만, 실제 로는 더 견고해진다. 버그를 찾고 수정하기 더 쉬워지 므로 프로덕션으로 가는 버그가 줄어든다." 빨리 실패하면 더 빠르고 효과적으로 문제를 드러내고 해결할 수 있다.
+
+---
+
+### 느낀 점
+
+"빨리 실패하라"는 내용이 특히 흥미로웠고 인상 깊었다. 보통 실패는 부정적인 것이라고 생각하기 쉬운데, 여기서는 오히려 빠르게 실패하는 것이 더 좋은 코드로 가는 빠른 길이라는 점을 강조하고 있어 새롭게 느껴졌다. 이 내용을 읽으며, 실패를 두려워하지 말고 오히려 빨리 실패해 문제를 드러내고 해결함으로써 더 나은 결과를 만들 수 있다는 중요한 교훈을 배울 수 있었다.