더 나은 프로그래머 되는법 2주차 - 하업서

2025/Becoming a Better Programmer/hemil0102/9~13장.md

@@ -0,0 +1,79 @@
+# 논제 
+페어프로그래밍을 해본적이 있는가? 해봤다면 장단점을 이야기 해봅니다. 
+
+# 9장 예상하지 못한 것을 예상하기
+## 1. 예상치 못한 상황을 적절히 다루지 못한 코드에서 어떤 문제들을 발견하였는가?
+설계가 제대로 되지 않았음을 발견한다. 고의는 아니겠지만, 문제가 발생할 때마다 땜빵 형식으로 커버가된 코드는 근본적인 원인을 파악하지 못했기 때문에 문제가 있어보인다. 예를 들어 네트워크의 응답이 2번 오는 경우가 있어 수정을 위해 땜빵하는 코드라던지, 왜 2번이 오는지는 파악하지 않으며 그저 겉으로 제대로 동작하는 코드를 발견하게 된다. 
+
+## 2. 모든 코드는 자신 속에 항상 견고한 오류 처리를 포함하고 있는가? 
+그렇다. 목적이 명확하다면 그 목적에 벗어나는 상황도 뚜렷하다. 그렇기에 오류 역시 견고할 수 밖에 없다. 목적이 뚜렷하지 않은 코드는 그만큼 오류도 뚜렷하지 않을거라 생각한다. 
+
+## 3. 어떤 상황에서 엄격한 오류 처리를 포기할 수 있는가? 
+글쎄... 오류처리를 포기하는 경우는 아직까지 겪어보지 않아서 잘 모르겠다. 
+
+## 4. 코드의 품질과 견고함에 영향을 줄 수 있는 다른 놀라운 시나리오로는 어떤 것이 있다고 생각하는가? 
+데드라인에 맞춰서 만들어야 하는 하드코딩, 서비스 중인 프로젝트의 구성원의 잦은 교체로 스파게티처럼 만들어진 땜빵 코드, 더 나은 상황으로 가지 않고 현재에 만족하는 마인드
+
+# 10장 버그 사냥하기 
+## 1. 자신이 얼마나 많은 시간을 디버깅에 할애하는지 평가해보라, 시스템에 새로운 코드를 작성하지 않는 모든 활동도 고려하라. 
+신입으로 요즘은 코드 작성보다는 설계와 코드 정적 분석에 많은 시간을 할애한다. 누군가가 작성한 코드에 중복이나 개선할 부분이 보이면 기록을 하고 있고, 아직은 디버깅을 직접 수행하지는 않는다. 때가 되면 천천히 하나씩 수정할 것들을 기록하는 것을 하고 있다. 
+
+## 2. 자신이 작성한 새로운 코드에 디버깅 시간을 더 많이 할애하는가, 아니면 기존 코드를 조정하는 데 더 많은 시간을 할애하는가? 
+음... 지금은 기존 코드를 조정하는데 더 많은 시간을 할애하는 것 같다. 이유는 새롭게 작성한 코드가 제대로 작성되었는지? 더 효율적인 방법이 있는지? 뭐가 제일 나은건지 아직은 모르는 부분도 많기 때문에... 작성해놓은 코드 단에서 수정을 많이 하는 편이다. 이런 상황에서 단위 테스트를 도입해 입력과 출력부터 조금 안정적이게 가져가려는 연습을 하려고 하고 있다. 
+
+## 3. 기존 코드를 위한 단위 테스트들은 디버깅 시간에 변화를 주는가, 아니면 디버깅 방법에 변화를 주는가? 
+아직 단위 테스트를 제대로 도입해본적이 없어서 적용 해봐야 알 것 같다. 그래도 예전에 잠시 학습할 때 적용해본 기억으로는 디버깅 방식에 변화를 준다. 가상 시뮬레이션과 같은 가상의 환경을 만들어서 객관적으로 테스트하기에 실시간 print문이나 log로 테스트를 하는 것과 달리 조금은 정량적으로 상황을 파악할 수 있어 좋았다. 
+
+## 4. 버그 없는 소프트웨어를 목표로 삼는 것은 현실적인가? 이것은 실현 가능한가? 버그 없는 소프트웨어를 진짜 목표로 삼는 때는 언제가 적절한가? 소프트웨어에서 버그의 양을 결정하는 요소는 무엇인가? 
+버그 없는 소프트웨어를 목표로 삼는 것은 현실적이다. 예를 들어 어떤 소프트웨어는 1+1=2다 라는 간단한 수식만 주어지면 여기에 버그가 생길 건덕지가 어디에 있는가? 다만 소프트웨어가 복잡해지고 여러 견해와 변화가 생길 경우 목표가 희미지는 만큼 또 제대로된 설계가 없이 만들어 진다면 버그는 언제나 생길 수 있다. 버그 없는 소프트웨어를 목표로 삼는 때는 언제나 지금 그렇게 생각을 하고 있어야 버그가 줄어들 것 같다. 버그는 어쩔 수 없이 생긴다고 하지만 그렇다고 어차피 생길 버그라고만 생각하고 있다면 조금 버그가 더 생겨날 것 같은 기분이 든다. 버그의 양을 결정하는 요소는... 설계, 경로의 복잡성, 데이터, 개인 실수, 제대로된 검증 등이 있을 것 같다. 
+
+
+
+# 11장 테스트하기 
+## 1. 얼마나 많은 종류의 테스트를 보거나 사용해보았는가? 
+부트캠프에서 단위 테스트와, TDD, 네트워크 테스트를 위한 더미 스텁 목을 잠깐씩 활용해봤다. 
+
+## 2. 테스트 우선 방식과 코드 작성 직후의 테스트 방식 중에 가장 좋은 개발자 테스트 기법은 무엇인가? 그 이유는 무엇이며 어떤 경험을 통해 그 결론을 내렸는가? 
+사실 TDD 방식을 처음부터 활용하는 사람을 주변에서 많이 보지 못했다. 그 이유는 처음부터 입력과 출력이 제대로 나오는 테스트로 부터 시작하는데, 어느 정도는 설계적으로 입력과 출력이 이렇게 하면 제대로 나오겠지? 설계를 한 다음에 코드를 작성하는 것이 일반적이었던 것 같다. 그런데 또 그렇다고 테스트 없이 코드만 작성하면 테스트를 언제 적용할지 애매하고 결국에는 테스트를 잘 안하게 되는 것 같다. 그래서 약간은... 입력과 출력이 나오는 설게가 이뤄지고 코드가 구현될 때 테스트를 도입하는게 좋지 않을까란 생각을 해봤다. 
+
+## 3. 고품질의 테스트를 작성하기 위해 단위 테스트를 작성하는 전문 개발자를 고용하는 것은 좋은 생각인가? 
+좋은 생각은 아닌 것 같다. 왜냐면 설계와 구현은 개발자가 하는데 테스터가 따로 있으면 물론 어떤 경우에는 객관적으로 개발자가 볼 수 없는 문제를 볼 수 있겠지만 의도까지 파악할 수는 없을거라 보기 때문에, 전문적으로 테스트만 하는 사람보다는 개발자들끼리 서로의 코드를 테스트 해보는게 실력도 향상시키고 좋겠다는 생각이 든다. 
+
+## 4. 왜 QA부서에서 많은 테스트 코드를 작성하지 않고, 테스트 스크립트와 탐험적 테스트를 수행하는 데 집중하는가? 
+음.. QA가 없어서 잘 모르겠다만, 코드 내용을 알고 있고 취약점이나 어떤 부분을 알게 될 경우에는 그런 부분때문에 사용적인 면에서의 테스트가 제대로 이뤄질 수 없다고 생각한다. 예를 들어 A를 하면 코드적으로 취약해서 불량이 많이 날 것을 알지만, 실제 사용환경에서는 A를 잘 안해서 불량이 안날 수도 있고, 어쩌면 A가 다른 어떤 무언가 때문에 더 심각해지는 문제가 될 수있는데, 코드를 알아서 A가 이미 문제라는 것을 알고 있다면 다른 문제들을 못보게 될 수도 있지 않을까란 생각이 든다. 
+
+## 5. 한 번도 자동화 테스트를 하지 않은 코드베이스에 어떻게 하면 TDD를 가장 잘 적용할 수 있을까? 이때 어떤 문제에 직면하게 될까? 
+음... 지금도 테스트 코드를 다 작성된 프로젝트에 넣고 싶은데, 가장 직면할 것 같은 문제는 ... 테스트 코드를 기존에 작성하지 않은 환경에서 팀원이나 업무 프로세스를 어떻게 설득하고 변화시켜야 이걸 도입할 수 있는 시간을 챙길 수 있을까란 생각이 들고, 어떻게 하면 TDD를 가장 잘 적용할 수 있을지는 사실 내공이 없어서 잘 모르겠지만, 지금은 그저 할 수 있는 가장 작은 단위 또는 가장 문제가 많이 발생하는 부위를 도려내서 테스트하게끔 하고 싶다. 
+
+## 6. 행동 주도 개발은 전통적인 TDD와 어떻게 다른가? 어떤 문제를 해결해주는가? TDD를 보충하는가? 해동 주도 개발이 테스트가 나아갈 방향인가? 
+테스트 주도 개발과 행동 주도 개발이 뭔지 아직 잘 모르겠다. 
+
+# 12장 복잡도 다루기 
+## 1. 간결한 코드 설계가 더 좋은 이유는 무엇인가? 설계의 간결함과 코드의 단순함은 어떤 차이가 있는가? 
+음 코드가 짧아지면 전자의 유동량도 줄어들어 전기세를 아낄 수 있고 자원을 절약할 수 있다. 간결한 코드 설계가 좋은 이유는 지구와 환경을 사랑할 수 있어서 좋고, 심플화된만큼 동작이 잘 된다면 이해하기도 쉽고 목적을 잘 이해했으니 심플해졌다는 방증도 할 수 있는 것 아닌가... 설계의 간결함과 코드의 단순함은 음... 설계의 단순함은 모델이 잘 설계된 것을 나타내는 것 같고 코드의 단순함은 문법이나 유지보스 확장적인 면에 조금 더 포커스 된게 아닐까 싶다. 
+
+## 2. 코드를 단순하게 만들기 위한 노력으로는 어떤 것이 있는가? 이를 달성했다는 것을 어떻게 알 수 있는가? 
+음... 사실 노력을 하고 있는데, 단지 짧아졌다 만으로는 단순하다라고 말할 수 있을까 싶은데, 단순한 코드는 아직 잘 짜고 있지 않으므로 잘 모르겠다. 그런데 주변 경험자 말에 의하면 GPT에 던졌을 때 GPT가 코드를 수정해서 내놓지 않으면 간결한 코드 같다며 그게 그렇게 기쁘다고란 말을 들었다. 
+
+## 3. 연결의 성격도 연결의 수만큼 중요한가? 어떤 성격의 연결 방식이 더 좋은가? 
+뭔가 책에서 소개한 것 처럼 이리저리 연결되는 방식보다는 모듈처럼 맺고 끊는게 명확한 연결 방식이 좋아보인다. 
+
+## 4. 만약 소프트웨어 복잡도가 사람 사이의 문제에서 기인한다면, 이를 어떻게 해결할 수 있는가? 
+친하고 즐겁게 지내는게 중요해보인다. 
+
+## 5. 필요한 복잡도와 불필요한 복잡도 간의 차이를 어떻게 설명할 수 있는가? 
+필요한 복잡도는 세상에 내놨을 때 그 복잡함으로 인한 높은 가치를 인정 받는 것이고, 
+불필요한 복잡도는 세상에 내놨을 때 외면 받는 것이다. 
+
+## 6. 만약 많은 프로그래머가 자신의 소프트웨어 설계가 더 간결해야 함을 알고 있다면, 그들이 더 간결한 코드를 작성할 수 있도록 독려하는 방법은 무엇인가? 
+음... 좋은 코드를 보여주고 그 팀에서 일하는 사람의 행복한 모습과 생산적인 모습을 직접 경험하게 하면 좋지 않을까? 
+
+# 13장 두 개의 시스템에 대한 이야기 
+## 1. 지금까지 본 것 중 최고의 시스템 구조는 무엇이 있는가? 
+음 최고의 시스템 구조는 아직 접해보지 못한 것 같지만, 그나마 클린 아키텍처로 짜여진 코드... 아 또 예전에 토스에 근무하는 개발자가 네트워크 관련해서 짠 코드에 여러가지 기법을 보여줬는데, 뭔가 단순히 동작하는 코드 보다는 정리된 코드가 멋져보였던 것 같다. 
+
+## 2. 지금까지 본 것 중 최악의 시스템 구조는 무엇이었는가? 
+음 최악의 시스템 구조는... 사실 지금 회사에서 하는 프로젝트도 복잡하고 중복이 많지만 나쁜 프로젝트라고 보여지진 않은데, 음 최악의 시스템 구조는 모르겠고 예전에 부트캠프 수강할 때 지피티로 의도도 모른채 단순히 과제를 마무리 하기 위해 동작되는 코드를 덕지 덕지 붙여놓은 코드가 최악의 프로젝트라고 생각한다. 
+
+## 3. 현재 당신의 프로젝트는 두 개의 도시 가운데 어디쯤 속하는가? 이전의 어떤 경험을 바탕으로 코드 혹은 코드를 빌드하는 절차를 개선할 수 있는가? 
+음.. 지저분한 대도시 쪽에 가깝다. 어디서 손대야할지 나의 경험이 부족한데, 컴퓨터 프로그램은 데이터와 그 처리이므로 데이터단부터 살펴보고 제대로된 데이터를 받아오는지 확인하고 그 데이터를 또 올바르게 보내는지를 체크할 것 같다.