더 나은 프로그래머 되는법 2주차 - 권태형

2025/Becoming a Better Programmer/taehyoung/10.md

@@ -0,0 +1,12 @@
+# ch10. 버그 사냥하기
+
+# 논의 내용
+
+- 버그를 줄이는 구체적인 방법에 대해서, 본인이 생각하는 혹은 주로 사용하는 방법을 이유와 함께 말해보면 좋을 것 같습니다
+
+# 내 생각
+
+- 버그가 생기지 않도록 적극적으로 예방하는 편이 낫다 라는 말에는 동의하지만, 그 방법으로 제시한 섬세한 설계, 코드 검토, 페어 프로그래밍 심사숙고한 테스트 등등은 사실 말하지 않는 것이 더 낫지 않나 라는 생각이 든다. 서울대를 가려면 어떻게 해야하나요? 라는 질문에 공부를 정말 열심히 해야합니다 라고 답변한 정도랄까?..
+- 내 경험을 기준으로 볼 때, 버그 발생의 대부분은 소통의 오류 혹은 내가 짠 코드가 하위레벨에서 까지 어떻게 동작하는지 정확히 모른채 작성된 경우에 발생했던 것 같다. 이를 예방하기 위해선, 소통의 오류를 어떻게 개선해야할지? 내가 작성한 코드의 하위레벨까지, 컴퓨터 자체에 대한 이해력을 높이는게 좀 더 근본적인 해결책이 아닐까?
+- 개인적으로는, 버그가 생기지 않도록 적극적으로 예방하는 노력은 당연한 것이라고 생각한다. 그러나 그럼에도 버그는 발생하고 내 의도와 다르게 프로그램이 동작하는 경우는 생길 수밖에 없기 때문에, 해결하는 방법 즉, 디버깅을 어떻게 하면 더 잘할지에 대해서도 고민하는게 반드시 필요하다고 생각한다
+- 시스템 내의 불변요소 검증을 위해서, 책에 assert를 추가하라고 나오는데, 나는 assert를 넣을 거면, 차라리 이전에 실패하도록 두라고 한부분처럼 하는게 더 낫다고 보고, 비즈니스로직에선 제외하는게 낫다고 생각한다 이런 의도를 굳이 강조하고 싶은거면 테스트 코드에서 사용하면 될것이라고 생각한다

2025/Becoming a Better Programmer/taehyoung/11.md

@@ -0,0 +1,10 @@
+# ch11. 테스트하기
+
+# 논의 내용
+
+- 없음
+
+# 내 생각
+
+1. 테스트와 관련해서 여러가지 얘기들이 많지만, 개인적으론 결론은 내린 것은 테스트의 본질은 검증 이라는 것이다. 즉, 내가 작성한 코드를 검증하기 위해서 테스트는 필요하고, 내가 의도한 대로 작성한 코드가 잘 동작한다면, 그것으로 테스트의 역할은 끝난다고 생각한다. 이게 가장 먼저 충족되어야하고, 그 다음에 테스트 속도, 회귀 테스트 활용, 테스트 더블, TDD 등등이 고려될 수 있다고 생각한다. 근데 개인적으로는 모두 도구로써, 활용되는 것들이라고 생각하고 지금 현재는 가장 우선적인 가치로 두고 있지 않고, 내 현재 상황에 맞게 적절히 도구로 활용하고 있다
+2. 예전에 테스트에 관심을 많이 가졌던 시기에는 테스트 방법론과 관련된 세세한 사항까지 깊게 학습하고, 다른 사람들과도 논쟁하였었는데, 지금은 위에서 생각한 본질에 대해서 나름 깨닫고 나서는 더 논쟁할 필요가 없다고 느끼고 있고, 내가 사용할 수 있는 도구로써만 활용 중이다

2025/Becoming a Better Programmer/taehyoung/12.md

@@ -0,0 +1,13 @@
+# ch12. 복잡도 다루기
+
+# 논의 내용
+
+- 코드 기준이 아니더라도, 실생활에서 복잡도와 관련된 것을 많이 만나게 되는데, 복잡도를 잘 다뤄본 혹은 실패해본 경험이 있는지 얘기해봅시다
+
+# 내 생각
+
+- 책에서 나오는 블롭은 코드베이스 자체를 말하는 것으로 보이고, 많은 요구사항으로 블롭 자체가 커지는 경우에 복잡도가 높아진다고 말할 수 있다.
+- 결국엔 어떻게 쪼갤 것인가에 대한 문제인데, 책에선 일단 코드 베이스가 객체지향 코드로 작성되어있다고 했을 때, 각 클래스 마다 하나의 역할을 가지도록 설계하여서 쪼개는 것을 말하고 있다
+- 라인의 경우는 블롭들 간의 관계를 나타낸다 당연하게도 관계가 복잡하고 많으면, 복잡도가 올라간다 특히 양방향으로 관계를 지정할 때는, 이로인해서, 복잡도가 높아질 수밖에 없음을 인지를 반드시 해야한다
+- 하지만, 결국 이런 블록들과 라인들을 만들어 내는 것은 사람 이므로, 본질적으론 사람이 본인 스스로가 복잡도를 만들어낸다는 것을 알 수 있다. 즉, 스스로 더 복잡하게 만들 수 있으면서도, 복잡하지 않게도 만들 수 있다는 것이다
+- 그래서, 우리는 복잡도를 줄일 방법에 대해서 항상 고민하고, 의사 결정하는 것이 필요하다고 생각한다

2025/Becoming a Better Programmer/taehyoung/13.md

@@ -0,0 +1,13 @@
+# ch13. 두 개의 시스템에 대한 이야기
+
+# 논의 내용
+
+- 개인적으로 디자인 타운 에서 말하는 가치에 대해선 동의하지만, 현실적으로는 대부분 지저분한 대도시에 해당된다고 봐야할 것 같습니다. 그럼에도 디자인 타운에서 말하는 가치 중에 가장 중요하다고 생각하는 것은 어떨 것 일까요?(저는 일관성 뽑겠습니다 - 코드 분석 할 때, 이부분에서 가장 많이 헷갈림이 발생함)
+
+# 내 생각
+
+- 책에 나오는 지저분한 대도시의 경우는 일하면서 몇번 겪어 본적이 있다. 핵심 비즈니스로직을 파악하기 너무 힘들었고, 기능을 추가해야하는데, 영향도 파악이 너무 힘들었고, 테스트 추가하기도 힘들었었다. 그날 이후에 한가지 결론을 얻은 것은 다른 건 다 망가져도 되는데, 정말 서비스의 핵심로직부분의 코드는 프로젝트 테크리드 혹은 개발자중 1명이 책임을 지고, 유지보수성을 잘 유지할 수 있도록 챙겨야한다는 것이다
+- 그러나 책에서 말한 것 처럼 지저분한 대도시가 되는 경우에 대해서는 이해할 순 있다. 모든 상황이 내 예상처럼 돌아가지 않기 때문이다. 해당 코드를 작성하는 개발자 자체가 문제인 경우도 있지만, 회사 정책상 말도 안되는 수정을 갑자기 생기거나 하는 경우가 있기 때문이다
+- 이런 갑작스런 수정이 있을 때 마다, 예상과 다른 방향성에 대해서 제한된 시간에 빠르게 문제해결부터 하려면 어쩔 수 없이 부채는 쌓이게 된다
+- 디자인 타운의 경우는 다수가 함께 일하는 환경 기준으로, 현실에선 사실상 존재할 수 없는 경우라고 본다. 그리고, 현실에 존재한다고 하더라도, 무조건 장점이 있는 것은 아니라고 생각하는 이유는 관리 비용이 들기 때문이다. 그렇기 때문에 어느정도의 선을 정하는게 중요하다고 생각한다
+- 개인적으론 중요하지 않은 도메인의 경우는 상관없는데, 정말 자주 요구사항이 만들어지고 변경되는 코어 도메인과 그 비즈니스로직의 경우는 이 디자인 타운에서 말하는 기능 위치 선정, 일관성, 구조확장 등등이 반드시 유지되도록 관리하는게 중요하다고 생각한다 위에서 말한 것 처럼 코어 도메인 비즈니스 로직에서 이게 안지켜지니 너무 고통스러웠다

2025/Becoming a Better Programmer/taehyoung/9.md

@@ -0,0 +1,12 @@
+# ch09. 예상하지 못한 것을 예상하기
+
+# 논의 내용
+
+- 없음
+
+# 내 생각
+
+- 책에 나오는 오류를 무시하지 말라는 말은 성공 케이스, 실패 케이스 모두 모든 경우의 수를 대비하라는 말에 부분집합으로 볼 수 있다. 내가 개발하려고하는 비즈니스 로직이 수행되는 중에 발생할 수 있는 모든 경우의 수를 대비한다면, 문제 될 것이 없다
+- 가끔씩 보면, 기도메타로 별일 없길 바라는 경우를 바라는 개발자들이 있는데, 이 문제의 본질을 들여다 보면, 결국엔 모든 경우의 수를 파악하지 못했기 때문에, 혹시 모르게 생길 문제에 대해서 불안을 가지게 되는 것이다
+- 책에서 말하는 실패하도록 두라 라는 철학의 경우 개인적으로 많이 강조하는 것인데, 비즈니스 로직적으로 절대로 발생할 수 없는 경우가 있을 때, 이에 대해서도 방어적으로 코드를 작성한다면, 이는 불필요한 코드를 생산하는 행위이고, 코드 읽는데에도 방해가 된다고 생각한다. 문제가 당연히 없어야하고, 문제가 혹시 있다면, 에러가 발생해서 빠르게 인지 할 수 있도록 해야하는게 이 철학의 가장 핵심이라고 볼 수 있다
+- 책에서 말하는 예상치 못한 상황은 꼭 비즈니스로직 코드에만 해당되는 것은 아니다. 프레임워크의 동작, 인프라 리소스들의 동작, OS 의 동작 등등 어떤 서비스가 실행되기 위한 모든 것들에서 예상치 못한 상황이 발생할 수 있다. 그래서 개발자라면, 이 모든 것을 예상 할 수 있기 위해서, 분야를 가리지 말고, 내 역량을 쌓을 수 있어야 한다