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

2025/Becoming a Better Programmer/hemil0102/34장~39장.md

@@ -0,0 +1,92 @@
+## 논제 
+태도에 대한 이야기를 책에서 많이 했습니다. 그런데 이 태도라는 것은 사람의 성향마다 다르게 생각할 수 있을까요? 
+예를 들어서 어떤 멘토는 잘 모르는 사람을 대할 때 모르는게 당연하니 적절한 순간에 도움을 줄 수도 있겠고, 
+어떤 멘토는 잘 모르는 사람을 대할 때 왜 모르냐며 갈굼을 시도할 수도 있겠습니다.
+반대로 어떤 멘티는 잘 모르는 상황에서 질문을 할 수 있겠고, 
+또 어떤 멘티는 잘 모르는 상황에서 스스로 찾아보고 정 안되면 질문을 할 수도 있습니다. 
+또 어떤 사람은 잘 모르는 것을 대할 때 조심스럽게 대하는데, 
+어떤 사람은 잘 모르는 것을 대할 때 가정을 하면서 접근하면서 알아갑니다. 
+모두 다 잘못된 것은 아니라고 생각을 하는데, 태도라는 것을 생각해보면 때로는 어르신들이 잔소리를 할 때 무조건 네네 하는 것이 바른 태도라고만은 생각하진 않는데, 
+사회나 회사에서는 대게 태도는 말 잘듣는 사람을 의미합니다. 
+이와 같은 생각에 동의하시는지 여러분이 생각하는 태도는 어떤 것인지 이야기를 나눠보면 좋겠습니다.
+
+# 34장 사람의 힘
+## 1. 지금 훌륭한 프로그래머라고 생각되는 사람과 함께 있는가? 그 이유는 무엇인가? 그렇지 않다면 그 이유는 무엇인가? 
+### 나와 함께하는 사람은 다 훌륭한 프로그래머이다. 누구나 각자 장점을 갖고 있고, 성향이 맞지 않아 다투기는 하지만, 장점 하나 없는 사람을 본적은 없는 것 같다. 다만 그런 사람들과 함께했을 때, 정치든 사람의 조합이든 일의 성향이든, 내가 성장할 수 없다면 다른 환경을 찾아야 한다고 생각한다. 
+
+## 2. 어떻게 하면 더 나은 코더와 더 가까이 있을 수 있는가? 새로운 프로젝트나 팀으로 옮길 수 있는가? 다른 회사로 이직할 때가 아닌가? 
+### 현재로써는 인터넷 예제나 이직한 전임자의 코드가 더 나은 코더와 가까이 할 수 있는 기회라 생각한다. 새로운 프로젝트나 팀으로 옮기는 것은 불가능하고, 다른 회사로 이직할 때라고도 생각하지 않는다. 
+
+## 3. 누가 훌륭한 개발자이고 누가 아닌지를 어떻게 판단할 수 있는가? 
+### 사실 책에서 설명한 것처럼 사람 됨됨이가 더 중요하다고 생각하는 편이지만, 어느정도는 자신의 실력이 부족한 것을 알거나 자신이 논리적인지 아닌지를 판가름하여서 부족한 부분을 보완하는 사람이 훌륭한 개발자라 생각한다. 그러니까 어렵지만 스스로를 되돌아볼 수 있는 사람이 훌륭한 사람인 것 같다. 스스로를 되돌아 보려면 스스로를 판단하는 기준을 잘 세워야하고, 이 기준을 잘 보유한 사람이 훌륭한 사람이라 생각한다. 
+
+# 35 생각이 중요하다
+## 1. 본인 작업의 품질에 대해 다른 사람들에게 얼마나 의무감을 가지는가? 
+### 최근들어 느끼는 것은 내 작업의 품질에 대한 다른 사람들에게 의무감을 갖는다는 것은 설명을 잘해주는 것이라는 생각이 든다. 보통 스스로 작업을 하다보면 자신이 해결한 문제들은 우선순위가 낮아져서 설명할 때 조금 소홀히 하게되는데, 누군가 처음 나의 작업을 접하면 때론 소홀히 한 부분이 가장 관심있어 하는 부분일 때가 있다. 그래서 의무감이란 조금은 시행착오나 어떤 사소한 것도 잘 돌아보고 누군가에게 설명하는 것 아닐까란 생각을 한다. 
+## 2. 무엇에 대해 의무감을 가져야 하는가? 
+### 내가 작업한 것에 대해 의무감을 가져야 한다. 또한 책에서 설명한 것 처럼 타인에 작업물에 대해서도 의무감을 갖는다면, 때론 그게 불필요한 간섭이 될 수도 있겠지만, 의무감을 갖지 않는다면 각자 자기 일만하고 서로에게 관심도 없고, 코드가 잘못되었는지도 모르는채로 협업을 하게되니... 타인의 작업물에 대해서도 본인의 작업처럼 의무감을 가져보는게 더 좋아보인다. 
+## 3. 오늘 하는 작업이 이전 작업만큼 훌륭하다고 어떻게 확신하는가? 
+### 확신은 위험한 것이다. 훌륭하다고 확신을 하는 순간에도 언제 어디서 버그가 굴러가고 있을지 모른다. 다만 내가 작업한 것에 대한 피드백을 팀에서 받았을 때 그게 충분히 문제를 잘 해결했고 요구사항을 만족했다면 사각지대를 충분히 커버했다는 소리니 이 과정이 잘 이뤄지면 훌륭하다고 생각한다. 
+## 4. 어떻게 현재의 작업을 통해 배우고 발전하는가? 
+### 열심히 나도 잘 하고 있다고 생각하고 코드를 작성하는데, 그래서 뭔가 스스로에 대한 믿음?을 갖는 편이랄까... 하지만 이런 믿음과 열심히 했던 것이 때로는 정말 자신만의 착각이라는 피드백을 받을때가 있는데, 이럴 때 인정하고 회고하면서 더 나은 결과물을 만들거나, 더 나은 과정을 설계하면서... 타인의 피드백에 의해서이던 자아성찰이던 회고를 했을 때 발전하는 것 같다.
+## 5. 코드 품질을 높게 유지하는 과정은 좋지 않았지만, 결국 품질을 유지하여 기뻤던 적은 언제인가?
+### 반복되는 패턴의 코드들을 함수화하지 않고 일단은 동작하는대로 생각나는대로 작업을 했는데, 코드가 너무 길어서 공통된 부분을 분리하고, 또 역할과 책임에 따라서 캡슐화도 하고, 이런 부분들이 작업을 하면서 바로바로 되면 좋은데, 맨 처음에는 설계 없이 코드만 작성했다가 엄청 난잡한 1000줄이 넘는 코드가 되었는데, 뒤늦게라도 힘들게 빼내는 작업을 하였는데 그 이후로 유지보수가 더 잘되어서 뿌듯했던 경험이 있다.  
+## 6. 의무감을 위한 관계에 돌입하기로 스스로 결정했을 때에만 의무감이 작동하는가? 아니면 그러한 관계가 요구될 때 효과적인가? 
+### 둘 다 아닐까 싶다. 스스로 의무감을 갖겠다는 생각을 하면 그 나름대로 잘 작동할텐데, 관계에서 요구될 때여도 서로에게 의무감을 갖는다는 측면에서 효과적일거라 생각한다. 
+
+# 36 말하기! 
+## 1. 개인의 성격이 의사 소통 기술에 어떤 영향을 미치는가? 내향적인 프로그래머가 가장 효과적으로 의사소통할 수 있는 방법은 무엇인가? 
+### 음~ 성격이 소통 기술에 많은 영향을 미친다고 생각한다. 특히 말하기도 그렇지만 듣기나 받아들이는 관점부터 많이 다르다. 예를 들어 어떤 이야기를 들어도 같은 이야기를 감성적으로 받아들이거나, 감정적으로 받아들이거나, 논리적으로 받아들이거나에 따라 대화의 방향은 천지차이로 달라진다. 내향적인 프로그래머가 가장 효과적으로 의사소통할 수 있는 방법?은 기록이 아닐까 싶다. 말을 잘 못한다면 기록을 잘 정리해서 보여줌으로써 말을 적게하면 된다. 사람을 완전히 안볼 수는 없고 할 수 있는만큼 최선을 다하면 좋겠다. 그리고 내향적인 사람들은 외향적인 성격과 달리 깊이 있는 분석이 가능하므로 장점이 있다는 사실을 상기하면 좋다. 
+
+## 2. 상호 작용에 있어 얼마나 격식을 차려야 하는가? 혹은 얼마나 편안해야 하는가? 의사 소통 채널에 따라 달라지는가? 
+### 음 디폴트로 개발자이다 보니 정확한 정보를 잘 전달하기 위해서 기억하고 집중하는 노력은 상시로 필요하다고 생각한다. 그런데 사람 성격에 따라서 보수적이거나 급진적이거나 근거가 꼭 필요한 사람이거나 상상을 잘 못하는 사람이거나, 상상을 잘 하는 사람이거나에 따라서 대응하는 방식은 조금 달리하면 좋아보인다. 소통 채널에 따라서 필요한 정보가 다르므로 맞추는 노력이 필요하다고 생각한다. 
+
+## 3. 동료들을 끝 없이 방해하지 않으면서도 그들의 도움을 받을 수 있는 방법은 무엇인가? 
+### 질문이 생길때마다 질문하지 않고 동료도 해야할 일이 많은 것을 배려한다. 질문을 일정 수준으로 모으되 너무 많이 모으면 부담되니 적절한 수준으로 끌어모으고 특정 시간에 질문을 보내서 질문을 미리 파악할 시간을 주고, 답변을 천천히 얻어낸다. 
+
+## 4. 동료 프로그래머와의 의사소통과 관리자의 의사소통은 어떻게 다른가? 
+### 음 관리자는 여러 프로젝트를 관리하기 때문에 내가 하는 일에만 집중할 수 없어 조금 더 정리되고 명료한 의사소통이 필요하고 설명을 논리 정연하게 더 많이 해야한다. 동료 프로그래머는 비교적 같은 언어와 같은 환경에 있는 사람으로 조금은 척하면 척 알아듣는 경우가 많다. 
+
+## 5. 개발 프로젝트를 성공적으로 진행하는 데는 어떤 종류의 의사소통이 중요한가? 
+### 소통하는 사람마다 다를 것 같다. 대화를 좋아하면서 진행하는 팀이 있는가하면, 지시와 팔로우를 좋아하는 팀이 있는데, 이런 소통 절차를 파악하면 좋다. 가장 중요한 것은 존중하는 마음으로 소통하는 것이다. 사람들의 생각이 다 다를지언데 자신의 생각만 맞다고 근거 없이 우기거나, 제대로된 설명 없이 지시를 내리거나, 질문을 하면 귀찮아 하거나, 완벽할 수는 없겠지만 불완전한 소통이라는 것을 감안하면서 정보의 사각지대를 없애는 소통이 좋다고 생각한다.  
+
+## 6. 코드 설계에 가장 잘 의사소통하려면 어떻게 해야하는가? 어떤 사람들은 한 장의 그림이 수천 개의 단어를 말한다고 한다. 이것이 사실인가? 
+### 공감한다. 사실 코드를 제대로 이해하고 있다면 머리 속에서 한폭의 그림이 그려진다. 그런데 그리다가 뭔가 한장에 안그려진다면 그건 어딘가 이해 못한 부분이 있거나 애매한 부분이 있다는 것이다. 사실 말로만 설명하는 것은 충분하지 않고 시각적인 자료와 함께하는 것이 좋으며, 항상은 어렵겠지만 대화 중간, 마지막 즈음에 서로의 이해를 체크하는 피드백 시간을 갖으면 오해를 조금 줄일 수 있다. 
+
+## 7. 같은 장소에서 작업하는 팀에 비해 흩어져 있는 팀은 더 많이 상호 작용하고 의사소통할 필요가 있는가? 
+### 흩어져 있는 팀은 다시 끌어모으는 비용이 더 많이 들지 않을까 싶은데, 흩어져 있다보니 오히려 서로가 하는 일을 더 캐치하지 못하기 때문에 더 많은 의사소통이 필요할거라 생각한다. 
+
+## 8. 효과적인 의사소통을 방해하는 가장 일반적인 방해 요소는 무엇인가? 
+### 스스로 제대로된 이해를 못한채 소통을 하거나, 충분히 상대방의 말을 듣지 않고 말을 끊거나, 이해하지 못하는 것을 질문하지 못하는 일방적인 소통
+
+# 37장 선언문
+## 1. 현재 유지 중인 개발에 대한 기본 '원칙'은 무엇인가? 
+### 아직은 원칙을 만들어가는 중이지 않을까 싶다. 그래도 갖고 있는 생각은 음...내가 작성한 코드는 내가 설명할 수 있어야 한다. 
+
+## 2. 애자일이든 장인정신이든 혹은 제3의 무엇이 되었든 간에, 일련의 개발에 대한 흐름에 서명하거나 자신을 맞추었는가? 선언문 내의 각 항목에 대해 동의함을 어떻게 표현하였는가? 
+### 사실 선언문 같은거를 작성한 적이 없다. 그저 주워들은 클린 아키텍처니 애자일이니 이런것만 있을뿐... 뭔가 방식에 맞추기 보다는 하다보니 이런 방식이 나에게 맞았네엿던 경우가 더 많은 것 같다. 
+
+## 3. 이런 선언문을 통해 개발 커뮤니티에 어떤 것을 제공해야 한다고 생각하는가? 
+### 흠... 올바른 가치관과 규칙?
+
+## 4. 선언문들이 실제로 끼칠 수 있는 해악으로는 어떤 것이 있는가? 
+### 약간은 어떤 학파 어떤 학파처럼 편가르기같은게 생기거나 선언문을 지키기 위한 강박관념이 생기지 않을까
+
+## 5. 고개를 숙인 채 선언문들을 무시하는가? 개인적 개발 능력을 유지하기 위해 소프트웨어 개발에 있어서의 이 같은 유행이나 방식을 실제로 따라야 하는가? 
+### 본질 없이 마냥 유행을 따르는 것은 별로라고 생각하지만, 왜 유행인지는 알아야한다고 생각한다. 소프트웨어도 사람이 만드는 것이기에 유행이 왜 발생하는지 알면 어떻게 보면 더 좋은 소프트웨어 유행을 만들어낼 수도 있는 것 아닐까
+
+# 38장 코드 찬가
+## 1. 현재의 개발팀은 얼마나 건전한가? 
+### 별로 건전하지 않다. 버전 관리를 하지 않는 것 부터, 생산성 툴을 사용하지 않는 것도 그러하다. 팀장님의 지시는 맞는 말일 때도 있지만... 아주 사소한 트러블이 생기면 인격 모욕적인 발언을 30분 이상 들어야 한다는 점에서 건전하다고 볼 수 없다. 
+
+## 2. 어떤 개발자가 필요한 만큼 근면한 태도로 작업하고 있지 않을 때, 이를 빨리 인지하려면 어떻게 해야하는가? 
+### 결과물을 보면 되고, 문제 처리 시간을 보면 된다. 같은 실수를 계속 되풀이한다면 본인의 문제이거나 팀 생활이 잘 안맞거나 ... 팀을 바꿔서도 똑같이 행동하는지 보면 좋을 것 같다. 
+
+## 3. 알면서도 일부러 적당히 일하는 것과, 더 잘할 수 있는 방법을 몰라서 엉성한 것 중에 어느 쪽이 더 그럴 듯한가? 
+### 더 잘할 수 있는 방법을 몰라서 엉성한게 더 그럴듯하다. 알면서도 적당히 하는 것은 숙련되었고 노련하다는 의미도 있지만... 항상 최선을 다하지 않는다는 느낌을 준다. 반면 더 잘할 수 있는 방법을 몰라서 엉성한 것은 알고 나면 고쳐질 부분이다. 그래서 모르는 것을 잘 인지시키고 알아내는 것이 중요하고 멘토링이 중요하다고 생각한다. 
+
+## 4. 자신이 적당하게 타협하고 있지 않다는 것을 어떻게 확신할 수 있는가? 미래에 나쁜 방법을 사용하지 않도록 하려면 어떻게 해야 하는가? 
+### 음... 타협하지 않는 다는 것은 어렵다. 정 반대의 성향의 사람과 일하다보면 더 그렇게 느낀다. 타협하고 있지 않다고 느낄 때는 ... 무조건 뭔가를 다 완벽하게 하기보다는 앞으로 발전하기 위해서 매일 최소한의 무언가를 한다는 점에서 타협하지 않고 있다고 생각한다. 미래에 나쁜 방법을 사용하지 않도록 하려면 조금 흘려보내는 것도 중요하다. 나쁜 것에 얽매여 나쁜 쪽으로 생각하면 더 그쪽으로 빠져든다. 그러니 그냥 흘려보내고 상황 속에서 항상 좋은 점을 찾고 긍정적으로 지낸다. 그러면 짜증이나 화는 나더라도 그뿐이다. 음 빠르게 흘려보내고 다른 시작을 한다가 나쁜 방법을 사용하지 않는 것에 좋은 마음가짐 중 하나 같다. 
+
+
+