Docs: Add 1~8.md

Author: thkwon1

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

@@ -0,0 +1,19 @@
+# ch01. 코드에 신경 쓰기
+
+# 논의 내용
+
+- 상황과 상관없이, 본인 스스로가 코드를 작성하는 의도를 가지지 않고, 무지성으로 어떤 아키텍쳐를 적용하자고 하거나(헥사고날), 어떤 유명한사람(엉클밥, 마틴 파울러, 에릭에반스 등등)이 이런 개념(TDD, DDD, 클린 시리즈 등등)들을 가지고 와서 회사 코드에 적용하려고 하는게, 동료들에게 피해를 주는 행동이라고 생각하는데요. 이 의견에 대해서 공감이 될만한 경험이 있으셨다면 경험담을 얘기해주시면 좋을 것 같습니다
+
+# 키워드
+
+1. 태도
+2. 의도
+
+# 내 생각
+
+- 개발자는 코드를 작성함으로써, 작동하는 소프트웨어를 만들고, 이를 통해서 비즈니스 가치를 창출한다 그렇기 때문에, 개발자로써 코드에 신경쓰기 않는 다는 것은 말이되지 않는 것이다. 코드에 신경써야 하는 것은 당연한 것이다
+- 대부분의 개발자들은 이 말엔 동의할 것이다. 다만, 이 말을 착각해선 안된다고 생각하는게, 모든 가치 중에 코드를 1순위로 봐야한다고 생각한다면, 문제가 될 수 있다고 생각한다
+- 만약에, 비즈니스적으로 굉장히 빠르게 개발되어서 고객에게 배포 되어야하는 소프트웨어 제품을 만들어야한다고 했을 때, 코드 자체에 가장 큰 가치를 두는 개발자는 당장의 비즈니스의 중요성과 상관없이 본인의 코드 그 자체에만 매몰되는 경향성을 보이는데, 개인적으로 이는 매우 잘못되었다고 생각한다. 본인 일은 코드를 작성하는 행위를 통해서 비즈니스 가치를 창출하는것이지 코드 자체를 잘작성하는 것이 아니기 때문이다.
+- 그래서, 의도가 중요하다고 생각한다. 개발자는 본인의 코드를 작성할 때, 의도를 담게 되는데, 그 의도가 충분히 동료에게 납득이 된다는 전제하에, 제대로 동작하는 코드는 모두 가치있는 코드라고 볼 수 있다고 생각한다
+- 위의 맥락하에서, 특히 저연차 개발자들로 부터, 코드 그 자체에만 집중하는것, 그 구체적인 사례로, 클린 코드, 클린 아키텍쳐에서 말하는 내용들이 정답이고, 그렇지 않으면 정답이 아니라는 식의 태도는 매우 잘못되었다고 생각한다.
+- 의도에 맞게 동작하는 코드를 잘 작성하여서, 비즈니스 가치를 최적화 할 수 있는 쪽으로 트레이드 오프를 적절하게 고려하여서, 적절한 해결책을 낼 수 있는 것이 개발자의 문제 해결사로써의 역량이 아닐까 생각한다

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

@@ -0,0 +1,12 @@
+# ch02. 정돈된 코드 유지하기
+
+# 논의 내용
+
+1. 개인적으론, 가독성은 주관적이고, 상대적인 기준이라고 생각됩니다. 누군가에게는 가독성이 좋을 수 있는 것이 누군가에겐  좋다고 느껴지지 않을 수 있을 것 같습니다. 만약 가독성의 기준이 주관적이지 않고, 기준이 절대적이라고 생각하신다면, 어떤 코드가 가독성이 좋다고 할 수 있는지에 대해서 의견 주시면 좋을 것 같습니다
+
+# 내 생각
+
+- 책에서 나오는 코드 레이아웃을 포맷팅의 관점으로 좁혀서 생각해본다면, 포맷팅은 취향의 측면이 강하기 때문에, 팀에서 기준을 정하는게 맞다고 생각한다.
+- 책 37page 에 나오는 예제는 왜 항상 exit(0)을 호출하는 것인지 잘 이해하지 못하였다.
+- 전반적인 내용은 가독성에 대한 내용으로 볼 수 있을 것 같다
+- 이 장에서 저자가 말하고 싶은 내용은 맨 마지막 마치며 부분에 나오는데, 가독성은 사람마다 주관적이라고 생각하기 때문에, 본인만의 기준을 가지고 있되, 팀으로 일할 때는 팀의 기준에 따르는게 좋지 않을까 생각된다

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

@@ -0,0 +1,12 @@
+# ch03. 코드 적게 쓰기
+
+# 논의 내용
+
+1. 책의 내용이 전반적으로, 단호하게 어떤 주장을 따르도록 적혀 있는데, 틀린 얘기를 하는 것은 아니지만, 그렇다고 모든 경우에 맞다고도 볼 수 없는 것을 단호하게 주장하는게 아쉽다고 생각됩니다. 다른 분들은 어떻게 느끼셨는지 궁금하네요
+
+# 내 생각
+
+- 책에 나오는 삼항연산자 같은 것의 가독성이 좋냐 나쁘냐 같은 경우도 주관적이라고 생각하는데, 개인적으로는 나쁘다고 생각하지 않고, 적절하게 사용해야할 때는 사용하는 편이다. 허나 나의 생각과 반대로, 가독성을 떨어뜨린다는 것으로 삼항연산자 자체를 쓰지 말자고 하는 경우도 있을 것 같은데, 이러한 경우가 발생할 수 있기 때문에, 가독성으로 논의하는 것은 적절치 않다고 생각한다(주관적이고, 취향의 영역이기 때문에)
+    - `장황한 내용` 부분에 나오는 short circuit evaluation(&&)의 경우도 상황에 따라서, 더 읽기 쉬울 때가 있고, 그렇지 않을 때도 있다. 즉, if-else 로 표현 하든, &&으로 표기하든 상황에 따라서 의도에 맞게 동작한다면, 문제가 없다고 생각한다
+- 책 내용에 `코드가 많을 수록 수정해야할 부분도 많아진다. 즉 프로그램을 수정하기 어려워진다.` 라는 내용이 있는데, 이 말에 동의하지 않는다. 예를들어서, 객체지향적으로 코드를 작성하게되면, 객체지향적인 코드를 작성하지 않을 때보다, 확실히 코드를 더 쓰게 되는데, 코드가 늘어난다고 해서, 프로그램을 수정하기 어려워지는게 아니기 때문이다. 오히려 객체지향적으로 잘 설계 한다면, 프로그램을 수정하기 더 쉬워질 수 있다. 그렇기 때문에, 이 책에서 위 주장을 한다면, 주장에 대한 맥락과 적절한 근거로 예시로 들어야하는데, 그 예시가 없어서 아쉬웠다.
+- `if (something)` 같은 것이 훨씬 더 표현력이 좋다는 것은 인정하는데, 자바에서는 쓸 수 없다. 그렇다면, 쓸 수 없는 언어에서는 어떻게 해야하는걸까?

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

@@ -0,0 +1,14 @@
+# ch04 코드 줄여 개선하기
+
+# 논의 내용
+
+- 개인적으로 불필요한 코드를 삭제해야할 가장 큰 이유는 쓰면 안되는 코드를 import 해서 사용할 수 있기 때문 입니다 이 경우가 아니라면, 지워야하는게 맞으면서도, 우선순위는 높진 않다고 생각됩니다 다른 분들의 의견이 궁금합니다
+
+# 키워드
+
+1. 죽은 코드
+
+# 내 생각
+
+- 웹 백엔드 기준으로 죽은 코드를 찾는 방법은 APM 을 사용하고 있다면, 어렵진 않은 작업이다. DataDog을 쓰는 경우라면, Trace를 조회해서, 어떤 API들이 사용되고 있는지 확인할 수 있고, 여기에 리스트가 없다면 사용하지 않는 API라고 쉽게 식별할 수 있다
+- 4장의 내용도 3장의 내용과 맥락적으로는 동일한데, 결국 코드를 통해서, 컴퓨터를 동작시키고, 다른 개발자가 그 코드를 읽게 되기 때문에, 코드는 헷갈리지 않도록 명확하게 작성 되어야 하고, 불필요한 코드는 필요한 코드를 읽는데 방해가 되기 때문에, 지워야만 한다

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

@@ -0,0 +1,9 @@
+# ch05. 코드베이스의 망령
+
+# 논의 내용
+
+- 없음
+
+# 내 생각
+
+- 여기서도 코드 레이아웃 얘기가 나오는데, 앞에서도 말했지만, 논쟁의 대상으로 삼을만큼의 꺼리가 되지 않는다고 생각한다. 예전에 생활 코딩 페이스북 그룹을 가입했다가 지금은 탈퇴했었는데, 탈퇴했었을 때의 이유는 꽤나 자주 반복적으로 if 문을 쓸 때, 중괄호 위치를 어디에 두냐 라는 글이 올라온 것 때문이였다. 단순히 코드 레이아웃 이상의 더 많은 것을 얻고 싶어서 가입했는데, 이런 취향과 관련된 글이 꾸준히 올라오는걸 보면서 굳이 이 그룹에서 얻을게 없다고 생각했기 때문이다. 이 책에서도 계속 레이아웃 얘기가 나오는데, 비슷한 생각이 든다

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

@@ -0,0 +1,9 @@
+# ch06. 경로 탐색하기
+
+# 논의 내용
+
+- 없음
+
+# 내 생각
+
+- 내용에 딱히 틀린부분은 없지만, 실무적으로 활용할만한 조언이라기 보다는 사회초년생 혹은 학생들이 보고 익힐정도의 수준의 조언들을 해주고 있고, 내용에 대한 깊이가 없어서 좀 아쉽다

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

@@ -0,0 +1,10 @@
+# ch07. 똥통에서 뒹굴기
+
+# 논의 내용
+
+- 코드가 제대로 작성되지 않아서, 이해하기 힘든 경우 책에서 말하는 똥통 코드가 만들어지는 이유는 개인의 문제일까요? 구조(회사, 팀 동료, 시스템) 이 문제일까요? 본인의 생각을 말해보면 좋을 것 같습니다
+
+# 내 생각
+
+- 대개 회사에서 작성된 코드 중에 이해하기 힘들고 조잡하게 작성된 코드들이 있다면, 이는 그 코드를 작성한 사람의 문제이기 보다는 상황자체가 그렇게 만들었을 가능성이 높다. 급하게 개발을 했어야만 했기때문에 코드의 추상화를 제대로 적용하지 못했다던지, 테스트를 꼼꼼하게 제대로 작성하지 못했다던지 그럼에도 불구하고, 비즈니스 요구사항을 충족한 잘 동작하는 코드라면, 일단 박수를 쳐야한다 비록 사람이 읽기 힘들지만, 비즈니스 요구사항을 훌륭히 수행하는 코드이기 때문이다. 일단 동작하게 해두고, 고치는 것은 나중에 하면된다 물론 깨진창문을 보수하지 않고, 방치한채로 덕지덕지 붙이는 형태가 된다면 곤란하지만
+- 팁 중에 코드 수정은 천천히, 신중하게 하라. 한 번에 하나씩 수정하라 라는 말은 매우 공감한다. 코드를 수정하는 것은 기본적으로 회귀테스트가 통과해야하는 것을 전제하면서, 수정한 코드도 잘 동작하는지 검증해야하기 떄문에, 기본적으로 체크해야할 것들이 많다. 이런 상황에서, 한번에 하나씩 하지 않게되었을 때, 물론 내가 모두 커버할 수 있는 수준에선 상관없지만 그렇지 않으면, 디버깅 하기 매우 까다로울 수 있기 때문이다. 아무튼 헷갈리지 않게 하기위해서 수정은 최대한 보수적으로 다른 영향이 없도록 격리 시킨 이후에 할 수 있도록 하자

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

@@ -0,0 +1,10 @@
+# ch08. 오류 무시하지 않기
+
+# 논의 내용
+
+- 각 사람마다, 회사마다, 팀마다 예외 핸들링 에 대한 나름의 기준이 있을 것 같은데, 그 기준이 있다면, 공유해보면 좋을 것 같습니다
+    - 제 개인적으로는 기준을 너무 빡세게 가져가지는 않고, 커스텀 예외를 너무 남용해서 쓰지 말자 정도로만 하고 있네요. 커스텀 예외를 씀으로써, 코드의 표현력을 올릴 수 있는 부분이 있다는 장점이 있지만, 너무 남용 되었을 때, 오히려 코드 관리 포인트 가 늘어나서 불편했던 것 같습니다
+
+# 내 생각
+
+- try-catch 문을 쓸 때는 책에 나온 내용대로, 의도적으로 전역 Exception을 잡아서, 에러가 발생해야하는데, 숨기는 일은 없어야할 것이다. 애플리케이션에서 에러가 발생하는 것을 무언가 문제가 있다고 생각해서, 불필요하게 무의식적으로 try-catch를 쓰는 경우가 있는데, 개인적으로는 낭비라고 생각한다. 오히려 에러가 반드시 드러나야할 부분을 숨김으로써, 진짜 문제를 감출 수 있는데, 이게 더 큰 문제이기 때문이다. 정상적이지 않은 상태라면, 과감하게 에러가 발생하도록 해서, 문제가 발생한것을 빠르게 인지할 수 있도록 하면 좋을 것 같다