From 0fec52f928a6c4f0dd513074ad23ddce9ba12d75 Mon Sep 17 00:00:00 2001 From: dhlee3994 Date: Fri, 16 May 2025 00:07:06 +0900 Subject: [PATCH] Add ch14~23 --- .../donghyeon/ch14~23.md | 23 +++++++++++++++++++ 1 file changed, 23 insertions(+) create mode 100644 2025/Becoming a Better Programmer/donghyeon/ch14~23.md diff --git a/2025/Becoming a Better Programmer/donghyeon/ch14~23.md b/2025/Becoming a Better Programmer/donghyeon/ch14~23.md new file mode 100644 index 00000000..78373329 --- /dev/null +++ b/2025/Becoming a Better Programmer/donghyeon/ch14~23.md @@ -0,0 +1,23 @@ +# 더 나은 프로그래머 되는법 = ch14~23 + +## 논의 + +같은 코드라도 도메인 특성, 의도에 따라 YAGNI가 되기도, 확장성 설계가 되기도 하는 것 같습니다. +간단하게 예를 들면, 인터페이스와 구현체가 1:1 대응이 될 때, 의도적인 추상화라면 '확장성 설계'가 될 것이고, +'그냥 인터페이스가 있으면 좋으니까'라면 YAGNI가 될 것 같습니다. + +좀 억지스러운 예제라고 느끼실 수도 있지만 그만큼 저는 YAGNI와 확장성 사이의 균형을 잡는 것이 어렵다고 생각하는데요. +특히나 도메인에 대한 충분한 이해가 없는 경우에는 정확한 판단이 매우 어려운 것 같습니다. + +여러분들은 어떤 기준으로 둘을 구분하시나요? +너무 추상적인 질문이지만 평소에 궁금했었던 내용이라 논의내용으로 선정했습니다. + +## 내용 + +- 팀의 규칙을 구두로만 전하지 말고, **명백하게 공식화**해야 한다. +- 팀의 규칙은 팀이 성장함에 따라 **변할 수 있음**을 인지해야 한다. +- 코드의 **일관성**은 간결함의 기초이다. +- 문제를 해결하기 위해 딱 **필요한 양의 코드만 작성**해야 한다. +- 당장 관련 없는 문제에 대한 일반적인 해결책을 발명하지 말아야 한다. +- **생각 후 코딩**하라. +- **모든 테스트 통과 != 완벽한 소프트웨어** \ No newline at end of file