개발자 원칙 sprint 11 - 김종필#668
Hidden character warning
Conversation
jongfeel
requested review from
GeunJuLEE,
TaeHyoungKwon,
chichoon,
dhlee3994,
hemil0102,
tttghost and
ymkim97
|
우측에 있는 |
![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 book review summaries and personal reflections for Chapters 3, 4, and 5 of "Developer Principles" (개발자 원칙). The reviewer identified a few minor Korean spelling and typo issues in Chapters 3 and 4, providing code suggestions to correct them.
|
|
||
| 구현 담당이면 소프트웨어 디자인에 대해 알아볼 필요가 있고, 왜 해야 하는지 그리고 왜 좋은지를 경험해 볼 수 있으면 좋다. | ||
| 구현이라면 설계해 둔 내용을 파악해 코드 작성이나 이미 구현된 내용에 대한 버그 수정일텐데 | ||
| 그런 작업을 하고 있으면 설계에 대한 내용을 이해하기 어렵기 떄문이다. |
There was a problem hiding this comment.
오타가 발견되었습니다. '떄문이다'를 '때문이다'로 수정하는 것이 좋습니다.
| 그런 작업을 하고 있으면 설계에 대한 내용을 이해하기 어렵기 떄문이다. | |
| 그런 작업을 하고 있으면 설계에 대한 내용을 이해하기 어렵기 때문이다. |
| 그래서 논의 주제는 이 분의 17가지 원칙에서 받아들이기 어려운 원칙이나 이해가 안됐던 원칙을 얘기해 보면 어떨까 합니다. | ||
|
|
||
| 저는 미적 설계 부분이 이전에 읽었던 수많은 책들 중에는 없었던 내용이었는데 특이하게도 ISO 9241-12 로 등록되어 있는 표준이더군요. | ||
| 그런데도 그 표에 나와 있는 수치화 점수가 얼마나 의미가 있나 싶을 정도로 미심적인 부분이 많았습니다. |
There was a problem hiding this comment.
'미심적인'은 올바른 맞춤법 표현이 아닙니다. '미심쩍은'으로 수정하는 것이 올바릅니다.
| 그런데도 그 표에 나와 있는 수치화 점수가 얼마나 의미가 있나 싶을 정도로 미심적인 부분이 많았습니다. | |
| 그런데도 그 표에 나와 있는 수치화 점수가 얼마나 의미가 있나 싶을 정도로 미심쩍은 부분이 많았습니다. |
| 이 책이 2022년 출판, 즉 2021년 까지의 저자들의 경험을 담고 있다고 했을 때 | ||
| 중요한 요소는 코드가 아니라 그 코드를 작성하면서 겪는 과정이 중요하다는 2026년에는 더 크게 와 닿는 말이라고 본다. | ||
|
|
||
| 특히 내가 AI가 있기 전에도 중요하게 생각했던 설계 리뷰에 대한 내용이 언급되서 반가웠다. |
There was a problem hiding this comment.
'언급되서'는 맞춤법상 '언급돼서'가 올바른 표현입니다.
| 특히 내가 AI가 있기 전에도 중요하게 생각했던 설계 리뷰에 대한 내용이 언급되서 반가웠다. | |
| 특히 내가 AI가 있기 전에도 중요하게 생각했던 설계 리뷰에 대한 내용이 언급돼서 반가웠다. |
| ## 논의주제 | ||
|
|
||
| 사실 제가 리뷰에도 적었지만 저는 구현인지 리더인지 구분하고 디자인 원칙에 대해 접근하는 방법에 대해 얘기했습니다. | ||
| 설계 원칙을 만들어야 하는 건 리더의 몫이고, 설계를 하고 구현을 담당하는 개발자는 설계에 대한 경험을 쌓을 수 있는 좋은 기회라는 걸 얘기한 것입니다. | ||
|
|
||
| 저자의 17가지 설계 원칙은 이미 기존에 있던 원칙을 자신만의 기준으로 다시 정리해서 설명해 주고 있는데 여태까지 읽었던 다른 저자와 달리 경험담 보다는 기술 서적의 내용의 요약 정리에 가깝다는 느낌이 들었습니다. | ||
|
|
||
| 그래서 논의 주제는 이 분의 17가지 원칙에서 받아들이기 어려운 원칙이나 이해가 안됐던 원칙을 얘기해 보면 어떨까 합니다. | ||
|
|
||
| 저는 미적 설계 부분이 이전에 읽었던 수많은 책들 중에는 없었던 내용이었는데 특이하게도 ISO 9241-12 로 등록되어 있는 표준이더군요. | ||
| 그런데도 그 표에 나와 있는 수치화 점수가 얼마나 의미가 있나 싶을 정도로 미심적인 부분이 많았습니다. | ||
| 그게 직관의 영역이 맞지 않나 싶은데 표에는 객관적 지표인 - 정보 체계는 80점, 코드화는 60점 이상 달성한다 라는 말이 이상하게 들릴 정도였습니다. | ||
| ISO 9241-12를 검색해 보면 바로 알 수 있는데 그 기준이 1998년에 만들어진 표준입니다. | ||
| 무려 28년전 기준으로 소프트웨어 원칙을 논하기에는 너무 무리수를 두지 않았나 하는 아쉬움이 많이 드네요. No newline at end of file |
There was a problem hiding this comment.
저는 이분이 제시한 17가지 원칙에 대해서 뭔가 원칙에 공감할 수 없다라는 의견 보다는 각 원칙에 대해서 세부적으로 설명하는 부분에서 그냥 해당 원칙에 대한 팩트를 나열해서 말한 부분을 보면서, 굳이 이 책을 볼 필요가 있을까 라는 생각이 들었습니다 제가 원하는 것은 구체적인 how 에 대한 경험담인데, what에 대해서만 얘기하는게 제 기준에서는 별로 유익하지 않았다고 판단했습니다(그냥 하나마나한 이야기...)
이전에 비슷한 느낌을 받은 글이 있었고, 그 때도 위 내용과 비슷한 평을 했었습니다
그리고 본인의 현재 업무와 유관해서, 테라폼이랑, K8s 관련된 내용들이 나오는데, 억지로 매칭한 것 같은 느낌이 들었습니다. 사례가 적절치 않았던 것인데, 저만 이렇게 느낀것인지 잘 모르겠네요 😢
그와 별개로, 제시한 17가지 설계 원칙에 대해서 나만의 기준을 만들고 프로젝트 때 그 기준을 두고 판단해보는 연습을 해보는 것은 좋을거 같습니다
2 participants
태형님이 지난 sprint 10 모임 때 얘기했던 대로 챕터 3의 소프트웨어 디자인 원칙에 대해 논의하는 게 좋은 것 같네요.
저랑 비슷한 의견인지 아니면 또 다른 의견이 있는지는 모임 때 얘기해 보면 좋겠습니다.
Close #667