Conversation
ymkim97
requested review from
TaeHyoungKwon,
chichoon,
dhlee3994,
jongfeel and
tttghost
ymkim97
added
2026
Street Coder: The Rules to Break and How to Break
|
우측에 있는 |
![gemini-code-assist[bot]](https://avatars.githubusercontent.com/in/956858?s=60&v=4){kind=small}
There was a problem hiding this comment.
Code Review
This pull request adds a summary of the first three chapters of the book 'Street Coder,' covering topics such as the value of practical experience, foundational computer science theory, and the strategic use of anti-patterns. The review feedback focuses on correcting Korean orthography and spacing errors throughout the document to improve readability and grammatical accuracy.
| ## 1장 ~ 3장 | ||
| --- | ||
| ## 논의 내용 | ||
| * 유용한 안티패턴에서 저자는 빚(기술 부채)을 지지 말라고 하는데요, 현실적으로 이게 가능할지가 의문입니다. 자신이 아무리 잘 지키려해도 회사라는 곳에서는 빠른 기간내에 돈을 벌어야하는 것이 최우선의 목표이기도 하고, 다른 팀원 또는 자신이 선택을 조금이라도 실수하는 순간에도 기술 부채가 발생할 수 있는데(스노우볼), 이렇게 말하는 저자의 의도를 현업에서는 어떻게 해석하고 받아들여야 할까요? |
There was a problem hiding this comment.
기술 부채를 안만드는 방법은 알려주지 않았으므로
최대한 코드가 경직성을 가지면 안된다의 맥락으로 이해해 보면 좋을 것 같기도 합니다.
기술 부채 관련해서 두 가지를 언급해 드리면
첫 번째, 제가 작년에 읽었던 < 소프트웨어 엔지니어 가이드북 > 책에서 13.3 기술 부채 내용이 있습니다.
가이드북이기 때문에 기술 부채를 방지하는 가이드가 존재합니다. (하지만 뻔한 이야기입니다. 실천하기가 어려울 뿐)
또 적당한 기술 부채를 실용적인 방안으로 속도와 품질의 절충안으로 여기는 시각도 있습니다.
이 부분도 보면 기술 부채 관련된 이해가 높아질 것 같습니다.
두 번째 역시 작년에 읽었던 < 이펙티브 소프트웨어 아키텍처 > 책입니다.
여기서는 기술 부채에 대한 색다른 시각을 얘기해 주고 있습니다.
6.5 변경을 수용할 수 있는가? 소주제로 "기술 부채" 내용이 있습니다.
부채(debt)에 대한 의미를 더 해석해본 것인데, 실제 부채 의미를 가지려면 신용카드로 감당할 수 없는 비용을 결제해 여행 다녀온 후, 값지 못하고 파산하는 엔딩이 맞다로 얘기합니다.
| ## 논의 내용 | ||
| * 유용한 안티패턴에서 저자는 빚(기술 부채)을 지지 말라고 하는데요, 현실적으로 이게 가능할지가 의문입니다. 자신이 아무리 잘 지키려해도 회사라는 곳에서는 빠른 기간내에 돈을 벌어야하는 것이 최우선의 목표이기도 하고, 다른 팀원 또는 자신이 선택을 조금이라도 실수하는 순간에도 기술 부채가 발생할 수 있는데(스노우볼), 이렇게 말하는 저자의 의도를 현업에서는 어떻게 해석하고 받아들여야 할까요? |
There was a problem hiding this comment.
사실 이런 조언류로 책을 구성할 때는 반례에 대해서 반박할 수 없다는게 가장 큰 모순점이라서, 그냥 저자의 의견이 그렇다 정도로 받아들이는게 맞을거 같습니다
말씀하신대로, 회사에서 매 상황상황 마다 의사결정을 다르게 될 수밖에 없는 상황인데, 이를 일반화해서, 기술부채를 반드시 남기지 않는 쪽으로 결정을 한다면, 그건 주객이 전도된 행위 일거 같습니다
제 개인적으로는 기술부채는 만들어질 수밖에 없고, 오히려 상황에 따라서는 유용하기도 합니다. 그래서 기술부채를 어떻게 갚을것인지 까지 설계를 해서 기술부채를 만든다면, 더 좋은 선택이라고 생각하는데요 문제는 부채는 갚지 않으면서 대책없이 늘리기만 하고, 이걸 본인이 처리하지 않고 다른 사람들에게 떠넘기기를 하는 이 사람의 행태가 문제이지 않을까 싶습니다 이런 상황에서 인수인계 받은 개발자는 애궃은 기술부채를 탓할텐데, 저는 기술부채자체가 문제는 아니라고 생각합니다
Co-authored-by: gemini-code-assist[bot] <176961590+gemini-code-assist[bot]@users.noreply.github.com>
Co-authored-by: gemini-code-assist[bot] <176961590+gemini-code-assist[bot]@users.noreply.github.com>
Co-authored-by: gemini-code-assist[bot] <176961590+gemini-code-assist[bot]@users.noreply.github.com>
Co-authored-by: gemini-code-assist[bot] <176961590+gemini-code-assist[bot]@users.noreply.github.com>
3 participants
Closing #634