From 75ef4925ae52e8eb3c7da97c454c1dbfcd2c9594 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?=EA=B9=80=EC=A7=80=EC=88=98?= Date: Fri, 16 May 2025 02:29:43 +0900 Subject: [PATCH] =?UTF-8?q?=EB=8D=94=20=EB=82=98=EC=9D=80=20=ED=94=84?= =?UTF-8?q?=EB=A1=9C=EA=B7=B8=EB=9E=98=EB=A8=B8=20=EB=90=98=EB=8A=94?= =?UTF-8?q?=EB=B2=95=203=EC=A3=BC=EC=B0=A8=20-=20=EA=B9=80=EC=A7=80?= =?UTF-8?q?=EC=88=98?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit --- .../tttghost/Chapter14~23.md | 169 ++++++++++++++++++ 1 file changed, 169 insertions(+) create mode 100644 2025/Becoming a Better Programmer/tttghost/Chapter14~23.md diff --git a/2025/Becoming a Better Programmer/tttghost/Chapter14~23.md b/2025/Becoming a Better Programmer/tttghost/Chapter14~23.md new file mode 100644 index 00000000..170e33e9 --- /dev/null +++ b/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 파이프라인 구축 및 자동화된 테스트 워크플로우 적용 경험과 그로 인한 이점/개선점은 무엇인가요?