thkwon1: Add md files in 1 week

2024/ThePsychologyOfComputerProgramming/taehyoung/1.md

@@ -0,0 +1,45 @@
+## 1장 프로그램 읽기
+
+### 논의할 내용
+
+1. 어려운 코드 읽는 방법에 대한 본인 만의 노하우가 있다면 공유해보면 좋을 것 같습니다.
+
+### 중요 문장
+
+- 프로그래밍이 어떤 과정으로 이루어지는가를 밝히고 싶다면, 프로그램을 읽어서 무엇을 배울 수 있는지를 아는 것이 그 출발점이 될것이다.
+- 코드를 한 줄 만날 때마다 “이 코드가 왜 여기에 있을까?를 생각하는 것이다.
+- 심리학과 좀 더 밀접한 주제는 사용하는 컴퓨터와 언어, 그리고 프로그래머 자신에 대한 지식이나 이해가 부족함으로 인해 얼마나 많은 코드를 쓸데없이 추가하느냐다
+- 코드에는 각각 나름의 이유가 있고, 그 이유들에는 심리적인 면이 있다. 따라서, 프로그래밍을 인간의 행위로 연구하다 보면 수많은, 때로는 예상치 못한 소득을 얻게 될 것이라 믿는다.
+- 프로그래머들은 자신의 코드를 다른 사람에게 검토해 달라고 요청하거나 다른 사람의 코드를 보며 자신의 능력을 키우는 것에 왜 그렇게 인색할까? … 항상 그렇듯이 부익부 빈익빈 현상이 발생한다.
+
+### 내 생각
+
+- 코드를 읽는 행위는 매우 중요하다. 코드에 작성한 사람의 스타일, 작성한 당시의 상황과 의도가 암묵적으로 포함되어 있기 때문에 우리는 코드를 읽음으로써, 이 암묵적인 의도를 인지 해볼 수 있다
+- 코드를 읽을 때 가장 중요하게 여겨야 할 것은 이 코드는 왜 이렇게 썼을까? 라는 생각이다. 한줄 한줄 작성자가 작성한 코드를 읽고 의도를 파악하는 과정에서 코드를 이해하는 역량이 높아질 수 있다고 생각한다
+- 다른 사람에게 내 코드를 보여주는 것을 꺼리는 이유는 내 역량이 드러나기 때문이고, 그것을 드러내기 싫기 때문이 아닐까? 라는 생각이다. 그러나 책에서도 나왔듯이 상대적으로 실력이 좋은 개발자들은 적절한 상황에 적절한 코드를 추가한다. 우리는 이런 그들의 역량으로 부터 의도를 파악하면서 내 코드를 개선하는 노력이 필요하고, 이 노력을 통해서, 내 개발 역량을 늘릴 수 있다고 생각한다.
+
+### 질문에 대한 답변
+
+관리자에게
+
+1. 질문1
+    1. 나는 관리자가 아니지만, 다른 개발자가 작성한 코드를 읽을 능력은 있다
+    2. but, 내가 다루고 있는 언어가 파이썬에 한정되기 때문에 그 외 언어에 대해서는 아직 역량이 부족하다
+    3. 파이썬 코드에 대해서는 읽을 능력이 있기 때문에 코드리뷰 혹은 실제 코드를 통해서 코드를 실제로 읽어 본다
+    4. 생각해보면, 파이썬 코드가 아닌 경우에는 아무래도 익숙하지 않기 때문에 읽으려는 시도를 하지 않으려는 경향이 있는 것 같다
+2. 질문2
+    1. 사람에 따라 다르다고 생각한다 어떤 관리자는 코드를 읽을 능력이 있는 반면, 그렇지 않은 관리자도 분명히 있을 것이다
+    2. 코드를 보지 않고도 관리자가 개발자를 평가하는 방법은 존재한다고 생각한다. 코드가 자체의 가치가 있는 것도 맞지만, 그보다 더 중요한 것은 개발자가 그 코드를 생산하는 활동을 통해서, 얼마나 큰 비즈니스 가치를 가져왔는지, 그 코드가 잘 동작하는지에 대한 것이라고 생각한다. 따라서 관리자가 개발자의 코드를 읽고 피드백도 줄 수 있으면서, 그 개발자의 업무를 더 잘 평가할 수있으면 좋겠지만, 꼭 그렇지 않더라도 다른 가치들로 평가를 진행할 순 있다고 생각한다
+
+프로그래머에게
+
+1. 질문1
+    1. 코드리뷰 할 때 매번 다른 사람의 코드를 읽는다
+    2. 코드리뷰 혹은 그 외 과정을 통해서 거의 매일 토론을 한다
+    3. 그 대상이 상사든 아니든 크게 중요하진 않다고 생각한다
+2. 질문2
+    1. 책에서 `프로그래머의 한계` 부분을 보면, 개발자의 지식과 이해가 부족함으로써, 얼마나 많은 코드를 쓸데 없이 추가하느냐에 대한 내용이 나온다. 이 말은 지식과 이해가 충만할 수록 적절한 코드를 적절한 곳에 추가한다라는 말로 치환할 수 있다
+    2. 이 문장을 내 방식대로 해석해보면, 코드 한줄 한줄 더 정확한 의도를 표현할 수 있다로 말할 수 있을 것 같다. 반대로 말하면, 개발 지식과 이해가 상대적으로 떨어질 수록 코드를 통해서 본인의 작성 의도를 제대로 표현하지 못하는 경우가 많았다는 것이고, 코드를 읽을 때도 의도를 제대로 이해하지 못하는 경우가 많았다는 것이다
+    3. 책에서 나온 연습을 해보고 나서, 나보다 상대적으로 뛰어난 사람의 코드를 한줄 한줄 내 나름의 작성의도를 파악해보고, 실제 작성한 사람의 의도를 비교 해보면서 내 개발지식과 이해력을 판단해볼 수 있고, 이것을 내 역량 발전에 활용할 수 있을 것 같다는 생각이 들었다.
+3. 질문3
+    1. 생략

2024/ThePsychologyOfComputerProgramming/taehyoung/2.md

@@ -0,0 +1,90 @@
+## 2장 좋은 프로그램이란 무엇인가?
+
+### 논의할 내용
+
+1. 내가 작성한 코드의 실제 동작을 QA 과정에서 개발자 본인이 직접 확인하시나요?
+    1. 그렇다면, 어떤 이유로 확인을 하시나요?
+    2. 그렇지 않다면, 확인하지 않는 이유는 무엇인가요?
+2. 최근에 맥킨지에서 개발자의 생산성을 체크할 수 있는 방법을 공개하였고, 이에 대해서 켄트 벡 등의 개발자들이 반대 의견을 내는 글이 많이 화제가 되었습니다. 
+    1. 개발자의 생산성을 체크할 수 있다고 생각하시나요?
+        1. 그렇다면, 어떤 항목으로 생산성 체크를 할 수 있다고 생각하시나요?
+        2. 그렇지 않다면, 왜 체크할 수 없다고 생각하시나요?
+    2. 참고
+        1. 맥킨지 글
+            1. [Yes, you can measure software developer productivity](https://www.mckinsey.com/industries/technology-media-and-telecommunications/our-insights/yes-you-can-measure-software-developer-productivity?fbclid=IwAR3wDWrWeMPzGO7_odkOTH3rp1acP24EtVVjLeAR4oA4ds622025dzdDY7A)
+        2. 반박글
+            1. [Measuring developer productivity? A response to McKinsey](https://tidyfirst.substack.com/p/measuring-developer-productivity?fbclid=IwAR1Y_8P2MpTsBaaj40LN21axWcnU-_3SBThaYK_EsUWznvk9WWzeoUMqglo)
+            2. [Measuring developer productivity? A response to McKinsey 2](https://tidyfirst.substack.com/p/measuring-developer-productivity-440)
+
+### 중요 문장
+
+- 우리는 어떤 프로그램을 다른 프로그램과 비교해 상대적으로 평가하기보다는 개발에 관련된 모든 상황에 비추어 그 프로그램을 평가 해야 한다.
+- 솔직히 말해서, 우리가 원하는 것은 최고의 프로그램이 아니다. … 우리가 원하는 것은 요구 명세에 부합하는 프로그램 이다.
+- 프로그램이 작동하지 않는 상황에서 효율성이나 적응성, 개발 비용 등의 다른 척도는 전혀 의미가 없다.
+- 개발자는 어떤 결점의 중요성을 평가할 때 그로 인해 곤란을 겪을 사용자 수가 얼마나 될지 그리고 그것을 극복하려면 얼마나 많은 노력이 필요할지 고려해야 한다.
+- 프로그램 수정은 피할 수 없는 일임을 잘 아는 프로그래머들이 그에 대한 대비는 왜 하지 않을까?
+- 단순히 컴퓨터 상의 실행 시간만 줄인다고 능사는 아닌 것이다.
+- 시간이 지날수록 효율성보다는 효용성이 더 중시될 것이다.
+- 특히 이 책에서는 좋은 프로그램 혹은 좋은 프로그래머라는 개념을 마치 모두가 동의하는 것 또는 동의할 수 있는 것 또는 동의해야만 하는 것처럼 쓰지 말아야 할 것이다.
+- 많은 관리자가 아직도 모든 것을 원하는 것 같다. … 즉, 적절한 트레이드 오프가 필요함을 여전히 모른다.
+
+### 내 생각
+
+- 비즈니스 요구사항을 무리 없이 수행한다면, 무조건 좋은 코드라고 말할 순 없지만, 최소한 우리가 원했던 것 이라고는 말할 수 있을 것 같다. 우리가 원하는 것은 코드를 통해서 비즈니스 가치를 창출하는 것이기 때문이다. 그러나 이런 엔지니어링에 대한 평가가 필요한 이유는 아무래도 개발자 평가, 생산성 측정을 통한 관리 때문이지 않을까 싶다.
+- 나는 작동하는 소프트웨어의 가치에 대해서 매우 높이 평가하고, 모든 기준은 여기에 맞춰져야 한다고 생각한다. 책의 예시로 나오는 것처럼 아무리 엔지니어링 적으로 성능이 10배 좋아도, 실제로 작동하지 않는다면, 그 소프트웨어의 가치는 0이라고 볼 수 있다.
+    - 하지만, 대부분 작동하는 소프트웨어가 중요하다고 생각하면서도, 정작 제대로 실천하지 못할 때가 있는데, 바로 QA 시점이다.
+
+    나의 짧은 경험 하에서 얘기해보자면, 개발자들(특히 BE 개발자들)이 본인의 코드가 실제로 동작하는지를 코드 단에서만 확인하려는 경향성이 있었던 것 같다. 그래서 코드를 보고 문제가 없다면 실제 소프트웨어의 동작도 문제가 없을 것이라고 단정 짓는 것이다. 
+
+    허나 이는 잘못된 생각이라고 생각한다. 반드시 실제 동작 여부를 눈으로 확인해야하고, 정상적으로 작동하는 소프트웨어 라는 것이 확인이 되어야 한다. 코드에서 아무리 본인이 맞게 작성했다고 판단하더라도, 실제로는 작동하지 않을 가능성은 여러가지 변수들로 인해서 매우 많다. 아무리 내가 코드를 잘 작성 했더라도, 소프트웨어가 동작하지 않는다면 가치는 0이다.
+- 책에서 말하는 적응성은 유지보수성으로 말할 수 있을 것 같다. 이게 잘 안되는 이유는 대부분의 개발자들이 유지보수성의 중요성을 몰라서가 아니라, 정확한 방법을 몰라서 라고 생각한다. 그러다보니, 당장은 일단 급한 업무를 처리부터 먼저하게되고,  이게 쌓이고 쌓여서 점점 더 유지보수하기 힘들어지는 것이라고 생각한다
+    - 내가 생각하는 유지보수성을 올리는 방법은 [변화율](https://www.youtube.com/watch?v=_JGchAMbPGI&t=2667s)에 따라서 코드를 관리하는 것이다.
+- 개인적인 경험에 의해서 효율성과 적응성을 동시에 요구하는 것에 대한 깊은 거부감을 가지고 있다. 이 말을 조금 풀어서 설명해보자면, `빨리 꼼꼼하게 해주세요` 라는 말인데, 빠르게 하는 것과 꼼꼼하게 하는 것은 서로 반비례 관계라고 생각하고, 그래서 동시에 둘다 잘하는 것은 모순이라고 생각한다
+
+빨리하면 덜 꼼꼼해지고, 꼼꼼하게 하면 느려지는게 당연한 것이다. 둘다 한번에 잘하는 것은 모순이다. 혹여나 내가 나중에 관리자가 된다고 했을 때도 이 점은 모순임을 잘 인지 해야만 한다.
+    - 근데 `빨리 꼼꼼하게` 가 되는 경우가 있다. 특정 분야에서 많은 경험과 역량을 갖춘 사람일 경우 이게 된다. 나는 이런 사람들을 전문가 라고 정의한다.
+    - 결국 `빨리 꼼꼼하게` 는 모순이지만, 이 모순의 격차를 줄이고 `빨리 꼼꼼하게` 하는 사람은 전문가 이다. 개인의 관점에서는 전문가가 되도록 노력하는게 필요하고, 관리자 입장에서는 개발자의 역량이 어떤지에 따라서 요구하는 내용이 달라야 한다고 생각한다
+- 맨마지막 장에 이 말이 나온다
+
+    > 특히 이 책에서는 좋은 프로그램 혹은 좋은 프로그래머라는 개념을 마치 모두가 동의하는 것 또는 동의할 수 있는 것 또는 동의해야만 하는 것처럼 쓰지 말아야 할 것이다.
+    > 
+    - 이 말을 듣고 떠오르는 책이 있었는데 클린 XXX 시리즈 이다. 나는 이 책이 나쁘다고 생각해본적은 없다. 오히려 도움을 더 많이 받았고, 주니어 시절에 어떤 방향성을 가지고 개발을 해야할지에 대해서 개발적인 측면, 개발 외적인 측면에서도 도움을 받았다.
+    - 하지만, 좋지 않게 생각하는 부분은 여기 나오는 내용이 무조건 맞다고 주장하고 맹목적으로 따르는 것이다. 클린XXX 책에도 나오지만, 클린 XXX 책의 내용과 주장은 하나의 의견일 뿐이다. 그 책에 나오는 내용이 아무리 좋은 내용이라고 할지라도, 모든 개발자들에게 적용될 것이라고 착각해선 안되고, 거기에 있는 내용을 무조건적으로 따른 개발자는 좋은 개발자, 그렇지 않은 개발자는 좋지 않은 개발자는 아니다 라는 식으로 생각해선 안된다 라고 말하고 싶다
+
+### 질문에 대한 답변
+
+관리자에게
+
+1. 위에 내 생각에도 적었지만, 전문가를 제외한 대부분의 사람들이 `빨리 꼼꼼하게` 할 순 없다. 관리자로써, 서로 모순되는 포인트에 대해서 말도 안되는 요구를 하고 있진 않은지 생각해볼 필요가 있다고 생각한다.
+2. 비즈니스 방향에 따라서, 프로그램 수정이 잦은 부분이 있고, 이 부분에서는 분명히 수정 비용이 많이 든다. 하지만, 이 수정 비용이 많이 들것을 예상하는 것은 쉬우면서도 어렵다. 비즈니스 방향이 언제든 바뀔 수 있고, 미래를 예측할 순 없기 때문이다. 개인적으로 아직까지는 명확한 답을 찾지 못하였다.
+3. 제가 이전에 작성한 [일정](https://medium.com/@kth5604/%EC%9D%BC%EC%A0%95%EC%97%90-%EB%8C%80%ED%95%9C-%EB%82%98%EC%9D%98-%EC%83%9D%EA%B0%81-%EC%9D%B4-%EC%9D%BC-%EC%96%B8%EC%A0%9C-%EA%B9%8C%EC%A7%80-%EB%81%9D-%EB%82%BC-%EC%88%98-%EC%9E%88%EB%82%98%EC%9A%94-e98d26e06597)에 관해서 작성한 글로 대신 합니다
+    1. 추가로, 일정과 관련된 인사이트를 얻어가실 수 있는 [영상](https://www.youtube.com/watch?v=o5CntwRYXac&t=4820s) 하나도 공유합니다(17분정도)
+
+        [요약]
+
+        - **일정은 뒤로 갈수록 확실해 지는 확률이다**
+        - 데일리스크럼으로 스케쥴을 계속 다시 세워서 확률을 높이자
+
+        [주요 내용]
+
+        - **일정은 확률이 낮은 단계에서 확률이 높은 단계로 만들 때 가치가 생긴다**
+        - 그래서 프로젝트 관리에서 중요한 점은 **프로젝트 초반부터 어떻게 확률을 높일 수 있을 것이냐?에 대한 것**이다
+        - 가장 쉬운 방법은 **매일 프로젝트의 스케쥴을 다시 세우는 것**
+        - 이 맥락에서 **데일리스크럼을 매일매일 스케쥴을 다시 세우고, 이를 통해 일정의 확률을 높이는 행위**로 볼 수 있다
+        - 데일리 스크럼이던, 그와 비슷한 것이던, 프로젝트 스케쥴을 체크하고 확률을 계산해서 **확률을 줄이려는 노력이 하지 않거나 줄일 수 없다면, 무의미한 프로세스**로 볼 수 있다
+
+        [기타 내용]
+
+        - 스프린트가 실패하는 이유는 2가지인데, 목표를 이루지 못하거나, 일정을 맞추지 못하거나 이다. 데일리스크럼에서 이 두가지를 매일 체크하는 것이 필요하다
+        - 일정은 고정된 기간, 약속이 아니다
+
+프로그래머에게
+
+1. 나 스스로 프로젝트를 시작할 때 명확한 기준은 주어진 요구사항에 맞게 이상 없이 개발을 해내는 것이다. 
+그 다음으로는 일정인데, 일정이 후순위인 이유는 위에서 말한대로 `빨리 꼼꼼하게` 할만큼의 전문가 역량이 되지 않기 때문이다.
+
+여기서 나는 `꼼꼼하게` 에 좀 더 많은 가치를 부여 했다. 하지만 그렇다고 해서 `빨리` 는 중요하지 않냐? 그것은 아니다. 왜냐하면, 위 일정에 관한 [영상](https://www.youtube.com/watch?v=o5CntwRYXac&t=4820s) 내용을 보면, 경영학에서는 예측이 곧 돈이라고 말하고 있다. 즉, 예측한 일정 안에 개발이 맞춰져야 회사에서는 돈을 벌 수 있게 되고, 일정에 맞지 않은 수록 예측에서 벗어난 것이기 때문에 돈을 그만큼 덜 벌 가능성이 높아진다.
+
+그래서 내가 선택한 차선의 방법은 일정을 확정하진 못하더라도, 특정 날짜가 아닌, 범위로 추정해서 지속적으로 공유하는 것이다 이 내용은 위에서 언급한 [일정](https://medium.com/@kth5604/%EC%9D%BC%EC%A0%95%EC%97%90-%EB%8C%80%ED%95%9C-%EB%82%98%EC%9D%98-%EC%83%9D%EA%B0%81-%EC%9D%B4-%EC%9D%BC-%EC%96%B8%EC%A0%9C-%EA%B9%8C%EC%A7%80-%EB%81%9D-%EB%82%BC-%EC%88%98-%EC%9E%88%EB%82%98%EC%9A%94-e98d26e06597)에 관한 내 글에 적혀 있다.
+2. 이 부분을 한 단어로 표현하자면, `배려` 라고 볼 수 있다. 나는 이 `배려` 가 매우 중요하다고 생각한다. 우리가 각각 따로 일하는 사람이 아니라, 하나의 팀, 동료 로써 같이 일을 한다면 이 `배려` 를 항상 고려 했으면 좋겠다
+3. 효율성 추가하다가 망쳐본적 있다. 위에도 말했지만, 회사는 `빨리 꼼꼼하게` 를 원하지 빠른데 꼼꼼하지 않은 것은 원하지 않고, 꼼꼼하면서 느린 것을 원하지 않는다. 빠르게 한 대신에 , 장애가 자주 발생하는 시스템을 만들었다면? 당연히 문제이다. 그래서 나는 차선으로 꼼꼼하면서 느린 것을 택하였다.