더 나은 프로그래머 되는법 3주차 - 김지수

2025/Becoming a Better Programmer/tttghost/Chapter14~23.md

@@ -0,0 +1,169 @@
+# Part2 02 연습을 통해 완벽해진다.
+
+## 더 나은 프로그래머 되는 법 14~23장  
+
+### 14장 소프트웨어 개발이란
+
+`Summary`
+- 스포츠, 놀이, 집안일의 예시를 통해 소프트웨어 개발의 본질을 이해할 수 있음
+- 영상 시청만으로는 실력이 늘지 않으며, 직접 코딩하며 연습해야 한다
+- 끊임없이 학습하고 새로운 것을 배우는 자세를 가져야 한다
+- 겸손한 마음가짐으로 개발에 임해야 한다
+- 코드를 작성할 때마다 "왜?"라는 질문을 던져 명확한 코드를 만들어야 한다
+- 코드 정리와 같은 지루한 작업도 피하지 말고 받아들여야 한다
+- 복잡한 코드를 정리하고 개선하는 과정을 즐기는 자세가 필요하다  
+
+`Topics`
+- 최근들어 배웠던 부분중 인상깊었던 것이 있나요?
+
+### 15장 규칙 가지고 놀기
+
+`Summary`  
+- 규칙은 협업을 위해 꼭 필요하다. 신입도 바로 와서 할 수 있을 정도의 규칙
+- 세가지 원칙
+  - 간결하게 하라
+  - 머리를 쓰라
+  - 변하지 않는 것은 없다
+    - 규칙을 정하되 언제든 변할 수 있다고 생각해야하 함, 규칙은 깨지라고 존재하는 것
+    - 팀 규칙을 만들어라
+
+`Topics`  
+- 최근 팀 내에서 세운 규칙이 뭐가 있을까요?
+- 
+### 16장 간결하게 하기
+
+`Summary`  
+- 코드의 간결함은 두 가지 방향으로 나타날 수 있다
+  - 잘못된 간결함
+    - 지나치게 단순화된 코드
+    - 깊은 고민 없이 작성된 코드
+    - 복잡한 문제를 과도하게 단순화한 코드
+  - 좋은 간결함
+    - 깊은 고민과 설계가 반영된 코드
+    - 직관적으로 이해할 수 있는 코드
+    - 별도의 설명 없이도 자연스럽게 사용할 수 있는 인터페이스
+    - 복잡한 로직을 깔끔한 인터페이스로 추상화한 코드
+    - 적절한 단위로 모듈화된 설계
+- 문제를 지나치게 단순화하면 오히려 복잡한 코드가 만들어질 수 있다
+- 정확한 문제 분석과 설계를 통해 진정한 간결함을 달성할 수 있다
+- 결론: 좋은 간결함은 초기 설계 단계에서부터 고려되어야 한다
+
+`Topics`  
+- 설계나 구조 수준에서 최적화 하신 사례가 있으신가요?
+
+### 17장 머리 쓰기
+
+`Summary`  
+- 단순한 문제는 단순하게, 복잡한 문제는 적절히 해결하기
+- KISS 원칙: 불필요한 복잡성 제거, 중복 최소화
+- 코드 작성 전 충분한 설계와 고민이 필요
+- 실수를 두려워하지 말고 개선의 기회로 삼기
+- 기계적인 코딩보다 논리적 사고를 통한 해결
+- 더 나은 해결책을 위한 지속적인 학습과 개선
+
+`Topics`  
+- 가장 멍청한 코드를 작성한 경험이 있나요?
+
+### 18장 변하지 않는 것은 없다
+
+`Summary`  
+- 모든 코드는 변경 가능하다
+- 완벽한 코드는 없다
+- 코드 수정에 대한 두려움은 자연스럽다
+  - 기능이 망가질까 봐
+  - 추가 작업이 생길까 봐  
+  - 익숙하지 않은 코드를 건드릴까 봐
+- 테스트와 리뷰로 두려움 극복하기
+- 기술 부채는 기록하고 계획에 반영하기
+
+`Topics`  
+- 코드 소유권과 전문성 균형에 대해 어떻게 생각하시나요?
+
+
+### 19장 코드 재사용 사례
+
+`Summary`
+- 코드 복사 붙여넣기는 DRY와 KISS 원칙 위반
+- 서드파티 라이브러리가 존재한다면 적극 매입
+
+
+`Topics`  
+- 현재 진행중인(혹은 진행했던) 프로젝트에서 얼마나 많은 복제코드가 존재하나요?
+
+### 20장 효과적인 버전 관리
+
+`Summary`  
+- 버전 관리는 지금 당장 시작하라
+  - 늦었다고 생각할 때가 가장 좋은 시작점이다
+  - git init 하나로 시작
+- 버전 관리 도구를 신중히 선택하라
+  - 한번 선택한 도구는 끝까지 사용하라
+  - 잦은 도구 변경은 혼란을 가져온다
+- 커밋은 작은 단위로 쪼개 관리하라
+  - 하나의 변경사항은 하나의 커밋으로
+  - 명확한 커밋 메시지로 이력 관리
+- 브랜치를 적극 활용하라
+  - 새로운 기능은 새로운 브랜치에서 개발
+  - 안정적인 메인 브랜치 유지
+
+`Topics`
+- 버전관리도구중 GUI와 CLI중 어떤 것을 자주 사용하시나요? 빈도는 어떻게 되시나요?  
+
+### 21장 골키퍼 있다고 골 안 들어가랴
+
+`Summary`  
+- QA팀과의 협력 관계
+  - QA팀은 품질 향상을 위한 파트너
+  - 테스트 부서가 아닌 품질 보증 전문가 집단
+  - 상호 존중이 협업의 기본
+- 개발자의 책임
+  - 배포 전 자체 테스트 수행
+    - 단위테스트 작성
+    - 통합테스트 실행
+  - 안정적인 QA 배포 버전 제공
+  - 명확한 릴리즈 노트 작성
+- 피드백 수용 자세
+  - 오류 보고는 개선의 기회
+  - 고객 발견 전 수정 기회로 인식
+  - 건설적인 피드백 환영
+- 핵심 원칙
+  - 품질은 전체 팀의 공동 책임
+  - 상호 신뢰와 존중이 기본
+  - 효과적인 커뮤니케이션 필수
+
+`Topics`  
+- 테스트코드 작성에 대한 자신의 노하우가 있을까요?
+
+### 22장 프리징된 코드의 신기한 사례
+
+`Summary`  
+- 코드 프리징
+  - 완료일과 출시일 사이 코드 수정을 제한하는 기간
+  - RTM(Release to Manufacturing)은 최종 출시 버전
+  - 프리징 단계
+    - 기능 프리징: 버그 수정만 가능
+    - 코드 프리징: 심각한 이슈만 수정
+    - 완전 프리징: 모든 변경 금지
+  - 출시 브랜치는 격리하여 관리
+  - 프리징 기간 동안 기술 부채 점검
+
+`Topics`  
+- 코드프리징을 선택할 때 어느정도 확신을 가지고 하시나요?
+
+### 23장 제발 저를 출시해주세요
+
+`Summary`  
+- 출시는 단순 빌드가 아닌 체계적인 프로세스
+- 효과적인 출시 요소
+  - 규율과 계획
+  - 단순하고 명확한 과정
+  - 반복 가능한 자동화
+  - 신뢰할 수 있는 검증
+- 자동화된 빌드/배포
+  - CI/CD 파이프라인 활용 
+  - 자동화된 테스트
+- 체계적인 출시 브랜치 관리
+
+
+`Topics`  
+- CI/CD 파이프라인 구축 및 자동화된 테스트 워크플로우 적용 경험과 그로 인한 이점/개선점은 무엇인가요?