Skip to content

Commit 4957dc9

Browse files
authored
Add ch14~23 (#547)
1 parent d642ba4 commit 4957dc9

File tree

1 file changed

+23
-0
lines changed
  • 2025/Becoming a Better Programmer/donghyeon

1 file changed

+23
-0
lines changed
Lines changed: 23 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,23 @@
1+
# 더 나은 프로그래머 되는법 = ch14~23
2+
3+
## 논의
4+
5+
같은 코드라도 도메인 특성, 의도에 따라 YAGNI가 되기도, 확장성 설계가 되기도 하는 것 같습니다.
6+
간단하게 예를 들면, 인터페이스와 구현체가 1:1 대응이 될 때, 의도적인 추상화라면 '확장성 설계'가 될 것이고,
7+
'그냥 인터페이스가 있으면 좋으니까'라면 YAGNI가 될 것 같습니다.
8+
9+
좀 억지스러운 예제라고 느끼실 수도 있지만 그만큼 저는 YAGNI와 확장성 사이의 균형을 잡는 것이 어렵다고 생각하는데요.
10+
특히나 도메인에 대한 충분한 이해가 없는 경우에는 정확한 판단이 매우 어려운 것 같습니다.
11+
12+
여러분들은 어떤 기준으로 둘을 구분하시나요?
13+
너무 추상적인 질문이지만 평소에 궁금했었던 내용이라 논의내용으로 선정했습니다.
14+
15+
## 내용
16+
17+
- 팀의 규칙을 구두로만 전하지 말고, **명백하게 공식화**해야 한다.
18+
- 팀의 규칙은 팀이 성장함에 따라 **변할 수 있음**을 인지해야 한다.
19+
- 코드의 **일관성**은 간결함의 기초이다.
20+
- 문제를 해결하기 위해 딱 **필요한 양의 코드만 작성**해야 한다.
21+
- 당장 관련 없는 문제에 대한 일반적인 해결책을 발명하지 말아야 한다.
22+
- **생각 후 코딩**하라.
23+
- **모든 테스트 통과 != 완벽한 소프트웨어**

0 commit comments

Comments
 (0)