Skip to content

Add chapter 14 to 23 review and discussion #543

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
jongfeel merged 1 commit into from
May 27, 2025
Merged

Add chapter 14 to 23 review and discussion #543

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
45 changes: 45 additions & 0 deletions 2025/Becoming a Better Programmer/jongfeel/Chapter_14_to_23.md
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -0,0 +1,45 @@
## 책 내용 정리

14장 소프트웨어 개발이란
15장 규칙 가지고 놀기
16장 간결하게 하기
17장 머리 쓰기
18장 변하지 않는 것은 없다
19장 코드 재사용 사례
20장 효과적인 버전 관리
21장 골키퍼 있다고 골 안 들어랴
22장 프리징된 코드의 신기한 사례
23장 제발 저를 출시해주세요

- https://github.com/jongfeel/BookReview/issues/1265
- https://github.com/jongfeel/BookReview/issues/1267
- https://github.com/jongfeel/BookReview/issues/1270
- https://github.com/jongfeel/BookReview/issues/1271
- https://github.com/jongfeel/BookReview/issues/1272
- https://github.com/jongfeel/BookReview/issues/1275
- https://github.com/jongfeel/BookReview/issues/1276
- https://github.com/jongfeel/BookReview/issues/1278
- https://github.com/jongfeel/BookReview/issues/1279
- https://github.com/jongfeel/BookReview/issues/1281

## 소감

이번 챕터는 2부 연습을 통해 완벽해진다의 전체 챕터를 다루고 있었습니다.
간결하게 하기, 머리 쓰기, 변하지 않는 것은 없다 챕터는 개발자의 태도와 의식에 대해 조금 다루고 있어서 좋은 내용이었고
코드 프리징, 출시 부분은 데브옵스 엔지니어링에서 많이 다루고 있었던 내용이라 리뷰 형태로 remind 했던 내용이었습니다.

## 논의 주제

저는 18장의 변하지 않는 것은 없다를 어느 수준까지 받아들일 수 있는지를 얘기해 보면 좋을 것 같습니다.

지난 모임에서도 태형님이 얘기해 주신 내용으로는 자신이 짠 코드는 절대 수정이 불가능하다 해서 못건드리게 하는 개발자, 그리고 같은 사례로 지수님도 주니어 개발자 시절에 그런 선임이 있었다고 얘기해 주셔서 아주 특이 케이스는 아닌 것 같다는 생각입니다.

추가로 책에서는 과거 퇴사한 개발자들의 레거시 코드를 못건드리는 이유는 수정할 용기가 없어서라고 했는데, 사실 수정은 할 수 있어도 얼마나 오래 걸릴지 가늠하기 어려운 문제가 더 크지 않나 생각합니다.
Copy link
Contributor

@hemil0102 hemil0102 May 16, 2025 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

저 같은 경우는 얼마나 오래 걸릴지 가늠하는 것에 추가로
레거시로 남겨진 코드의 문제해결을 위한 코드의 의도가 온전히 인수인계 되었다면,
그 의도를 보존하면서 코드를 리팩토링할텐데요.
그런 경우가 아니라면 조금 어려움을 느끼는 것 같습니다.

예를 들어서 어떤 서버의 통신 불량을 해결하기 위해 작성된 코드가 있는데,
이 불량이 원인이 잘 파악되지 않는 것이라 땜빵한 코드라 한다면,
땜빵한 코드 자체가 일반적인 상황에서는 심플하지 않아보이므로,
모르는 사람은 리팩토링을 하고 싶어할텐데,
이때 단순히 이 코드가 지저분하다고 수정을 멋대로 해버린다면 큰일 날 수 있습니다.
따라서 용기가 있다면 이런 의도를 잘 물어가면서 수정할 수 있어보이고,
의도를 알 수 없다면 백업을 통해 용기를 내보는 것도 나쁘진 않은 것 같습니다.


이제 자신의 코드에 대한 과도한 소유욕과 다른 사람의 코드 수정의 불가능에 대한 경우는 지난 모임에 했기 때문에 책에 언급된 '수정을 대한 설계' 단락의 내용을 논의 주제로 얘기해 보면 좋을 것 같습니다.
Copy link
Member Author

@jongfeel jongfeel May 15, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
이제 자신의 코드에 대한 과도한 소유욕과 다른 사람의 코드 수정의 불가능에 대한 경우는 지난 모임에 했기 때문에 책에 언급된 '수정을 대한 설계' 단락의 내용을 논의 주제로 얘기해 보면 좋을 것 같습니다.
이제 자신의 코드에 대한 과도한 소유욕과 다른 사람의 코드 수정의 불가능에 대한 경우는 지난 모임에 했기 때문에 책에 언급된 '수정을 위한 설계' 단락의 내용을 논의 주제로 얘기해 보면 좋을 것 같습니다.


코드 수정을 통해 변화를 가할 때 과거의 저는 리팩터링이라고 얘기하고 구조 및 기능 변경을 과하게 적용해서 수정했던 경험이 있었습니다.

그 때는 그게 정당한 개발의 과정이고 더 좋은 코드 개선의 시간이라고 생각해 리팩터링이라는 대의명분으로 시간을 썼지만, 지금은 한꺼번에 많은 변경을 위해 1주 이상의 시간을 따로 쓸 만큼의 큰 작업을 하지 않습니다. 정말 조금의 변경, 하루 안에 작업할 수 있고 pull request 한 번 혹은 두 번 정도로 해서 정말 미미한 개선을 개발하는 과정 중간에 넣고 개선하는 방향을 가지고 있습니다.

이와 관련된 얘기를 자유롭게 해보면 좋겠습니다.
Copy link
Contributor

@hemil0102 hemil0102 May 14, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

오타가 있어보입니다. 240페이지 수정을 위한 설계 파트를 말씀하시는거죠?

Copy link
Member Author

@jongfeel jongfeel May 15, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

오타 맞네요.
수정 제안을 해서 main branch에 들어갈 때는 수정된 내용으로 들어갈 예정입니다.

Copy link
Collaborator

@TaeHyoungKwon TaeHyoungKwon May 15, 2025 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

저는 18장의 변하지 않는 것은 없다를 어느 수준까지 받아들일 수 있는지를 얘기해 보면 좋을 것 같습니다.

지난 모임에서도 태형님이 얘기해 주신 내용으로는 자신이 짠 코드는 절대 수정이 불가능하다 해서 못건드리게 하는 개발자, 그리고 같은 사례로 지수님도 주니어 개발자 시절에 그런 선임이 있었다고 얘기해 주셔서 아주 특이 케이스는 아닌 것 같다는 생각입니다.

변하지 않는 것은 없다 라는 말 자체에 대해선 100% 공감 합니다. 실제로 현업에서 일하면서, 절대로 변하지 않을 것 같았던 요구사항들이 정말 상상도 못하는 형태로 변하는 것을 생각보다 자주 경험을 하다보니, 이 말에 대해선 정말로 공감하게 되었습니다.

여기서 중요한 것은 변하지 않는 것은 없다 라는 것을 깨달은 이후에, 이를 어떻게 내 업무에, 내 코드에 적용시킬까 라는 것인데요. 제 개인적인 생각은 변하지 않는 것이 없는 것은 맞지만, 미래에 언제, 얼만큼 변할지 예상할 수 없기 때문에 일단은 현재 기준에 집중하자 라는 생각이고, 변화가 어떻게 일어날지에 대한 예측 가능성은 시간에 비례 한다고 생각 합니다.

즉, 지금 당장 어떻게 변경될지 모르니까, 현재 기준 요구사항만 고려해서 개발을 진행하고, 시간이 점점흐르면서, 프로젝트의 코드가 어느정도 성숙해졌을 때, 변화의 패턴들이 보이는 시점에 다시 재설계를 진행하는게 합리적인 방안이 아닐까 라는 생각 입니다

Copy link
Collaborator

@TaeHyoungKwon TaeHyoungKwon May 15, 2025 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

추가로 책에서는 과거 퇴사한 개발자들의 레거시 코드를 못건드리는 이유는 수정할 용기가 없어서라고 했는데, 사실 수정은 할 수 있어도 얼마나 오래 걸릴지 가늠하기 어려운 문제가 더 크지 않나 생각합니다.

저도 말씀주신 내용에 동의하는 바이고, 우선순위의 문제로 볼 수 있을 것 같습니다. 나의 업무가 레거시 코드들을 관리하고, 유지보수 하는 것이 아닌 이상은 대부분의 개발자의 업무는 새로운 피쳐를 만들거나, 요구사항에 맞는 유지보수 업무를 하는 것이기 때문에, 레거시 코드를 건드려서, 굳이 나에게 이익(혹은 명분?)이 없다고 판단한다면, 우선순위에서 당연하게도 밀릴 수 밖에 없는 것 같습니다

Copy link
Collaborator

@TaeHyoungKwon TaeHyoungKwon May 15, 2025 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

이제 자신의 코드에 대한 과도한 소유욕과 다른 사람의 코드 수정의 불가능에 대한 경우는 지난 모임에 했기 때문에 책에 언급된 '수정을 대한 설계' 단락의 내용을 논의 주제로 얘기해 보면 좋을 것 같습니다.

수정을 위한 설계를 적용할 것인가? 에 대한 전제조건은 수정이 매우 잦아야 한다고 생각 합니다

애초에 수정이 잦지 않다면, 수정을 위한 설계를 굳이 고려하지 않아도 된다고 생각 합니다

수정이 매우 잦은지, 아닌지 여부는 요구사항 분석을 할 때부터, 확실하게 예측을 할 순 있지만, 이 또한 요구사항이 내가 예상 범위로만 변경이 될거라고, 예측하는 것이기 때문에.. 요구사항이 급변하는 환경에선 저는 어느정도 프로젝트가 성숙한 단계에 와야만 이것을 더 확신을 가지고 예측, 판단할 수 있다고 생각하는 편이고, 위에 글에서 변화가 어떻게 일어날지에 대한 예측 가능성은 시간에 비례 한다 라는 말로도 대체 가능할 것 같습니다

확실히 수정을 위한 설계가 필요하다는 확신이 든 이후에는, 이를 실천하는 구체적인 방법은 상황에 따라서, 개발자의 역량껏 적절한 방법을 고민하고, 선택하면 된다고 생각 합니다(흔히 전략패턴을 쓸지, 추상화 수준에 따라서 레이어를 어떻게 나눠서 배치할지 등)

개인적으로는, 미리부터 수정을 위한 설계를 고려하는 것을 경계하는데요. 그 이유는 순서가 잘못되었다고 생각해서 입니다. 어떤 문제(패턴)이 드러나지 않은 상황에서, 선제적으로 수정을 위한 확장적인 설계를 고려한다는게 너무 비효율적이라고 생각하고 그래서 가능하면 미리 수정을 위한 설계를 고려하지 않는 편 입니다

Copy link
Contributor

@dhlee3994 dhlee3994 May 16, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

주민등록번호도 변할 수 있으니 "변하지 않는 것은 모든 것이 변한다"라는 말뿐이라고 생각합니다.
다만 변화의 텀을 생각하면서 대응해야할 것 같습니다.
100%는 아니지만 많은 경우에 변화에 유연한 코드는 더 많은 양의 코드가 필요한 것 같습니다.
그래서 일정과 변화의 텀을 잘 저울질 하는 것이 중요한 것 같습니다.

Copy link
Contributor

@ymkim97 ymkim97 May 16, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

저는 18장의 변하지 않는 것은 없다를 어느 수준까지 받아들일 수 있는지를 얘기해 보면 좋을 것 같습니다.

저도 다른 분들과 마찬가지로 "변하지 않는 것은 없다"라는 것에 100% 공감합니다.
그렇다고 코드를 작성하면서 모든 코드에 대해서 변화를 대비해서 작성해야 하는가 라는 말이 나올 수 있는데 이것은 현실적으로 불가능하고 비효율적이라고 생각합니다.
대신 프로젝트에 기여하는 모든 팀원들이 "변하지 않는 것은 없다"를 모두 인정하면서 변화가 일어날 가능성이 크게 보이는 부분에만 미리 조치를 취하거나, 기록을 하는 방안이 있는 것 같습니다.