더 나은 프로그래머 되는법 3주차 - 권태형 #544
Conversation
TaeHyoungKwon
requested review from
jongfeel,
hemil0102,
ymkim97,
aquamagic9,
fkdl0048,
tttghost and
dhlee3994
|
우측에 있는 |
![gemini-code-assist[bot]](https://avatars.githubusercontent.com/in/956858?s=60&v=4){kind=small}
There was a problem hiding this comment.
Hello @TaeHyoungKwon, I'm Gemini Code Assist1! I'm currently reviewing this pull request and will post my feedback shortly. In the meantime, here's a summary to help you and other reviewers quickly get up to speed!
Summary of Changes
Hello team, gemini-code-assist here to provide a summary of this pull request. This PR, titled "더 나은 프 3주차 - 권태형" (Becoming a Better Programmer Week 3 - TaeHyoungKwon), appears to be part of a study group or course related to the book "Becoming a Better Programmer". The primary purpose of this pull request is to add the author's personal notes, discussion points, and reflections on chapters 14 through 23 of the book.
Highlights
- Chapter Reflections Added: New markdown files have been added for chapters 14 through 23 of the book "Becoming a Better Programmer". Each file contains sections for '논의 내용' (Discussion Points) and '내 생각' (My Thoughts) related to the specific chapter's content.
- Discussion on Software Development Concepts: The notes cover a range of topics from the book, including the nature of software development (art vs. business value), managing rules and conventions, code conciseness, the importance of thinking before coding, handling code changes, strategies for code reuse, effective version control practices, the relationship between developers and QA, and managing code freezing and deployment processes.
- Personal Opinions and Critiques: The author provides personal opinions and sometimes critiques the book's points based on their own experience, particularly regarding the balance of values in development, the practicality of 'boldly modifying' code in critical systems, and the nuances of code reuse and version control practices in real-world scenarios.
Changelog
Click here to see the changelog
- 2025/Becoming a Better Programmer/taehyoung/14.md
- Added notes and reflections for Chapter 14: Software Development as Art.
- 2025/Becoming a Better Programmer/taehyoung/15.md
- Added notes and reflections for Chapter 15: Playing with Rules.
- 2025/Becoming a Better Programmer/taehyoung/16.md
- Added notes and reflections for Chapter 16: Keeping it Concise.
- 2025/Becoming a Better Programmer/taehyoung/17.md
- Added notes and reflections for Chapter 17: Using Your Head.
- 2025/Becoming a Better Programmer/taehyoung/18.md
- Added notes and reflections for Chapter 18: Nothing Stays the Same.
- 2025/Becoming a Better Programmer/taehyoung/19.md
- Added notes and reflections for Chapter 19: Code Reuse Cases.
- 2025/Becoming a Better Programmer/taehyoung/20.md
- Added notes and reflections for Chapter 20: Effective Version Control.
- 2025/Becoming a Better Programmer/taehyoung/21.md
- Added notes and reflections for Chapter 21: You Can't Keep the Ball Out Just Because There's a Goalkeeper.
- 2025/Becoming a Better Programmer/taehyoung/22.md
- Added notes and reflections for Chapter 22: Curious Cases of Frozen Code.
- 2025/Becoming a Better Programmer/taehyoung/23.md
- Added notes and reflections for Chapter 23: Please Release Me.
Using Gemini Code Assist
The full guide for Gemini Code Assist can be found on our documentation page, here are some quick tips.
Invoking Gemini
You can request assistance from Gemini at any point in your pull request via creating an issue comment (i.e. comment on the pull request page) using either /gemini <command> or @gemini-code-assist <command>. Below is a summary of the supported commands.
| Feature | Command | Description |
|---|---|---|
| Code Review | /gemini review |
Performs a code review for the current pull request in its current state. |
| Pull Request Summary | /gemini summary |
Provides a summary of the current pull request in its current state. |
| Comment | @gemini-code-assist | Responds in comments when explicitly tagged, both in issue comments and review comments. |
| Help | /gemini help |
Displays a list of available commands. |
Customization
To customize Gemini Code Assist for GitHub experience, repository maintainers can create a configuration file and/or provide a custom code review style guide (such as PEP-8 for Python) by creating and adding files to a .gemini/ folder in the base of the repository. Detailed instructions can be found here.
Limitations & Feedback
Gemini Code Assist is currently in preview and may make mistakes. Please leave feedback on any instances where its feedback is incorrect or counter productive. You can react with 👍 and 👎 on @gemini-code-assist comments to provide feedback.
You can also get AI-powered code generation, chat, as well as code reviews directly in the IDE at no cost with the Gemini Code Assist IDE Extension.
Pages turn, ideas flow,
New thoughts take root and grow,
Better code will bloom.
Footnotes
-
Review the Privacy Notices, Generative AI Prohibited Use Policy, Terms of Service, and learn how to configure Gemini Code Assist in GitHub here. Gemini can make mistakes, so double check it and use code with caution. ↩
There was a problem hiding this comment.
Code Review
안녕하세요! '더 나은 프로그래머 되는법' 3주차 스터디 내용에 대한 PR을 잘 보았습니다. 챕터 14부터 23까지의 내용을 읽고 개인적인 생각과 논의 내용을 잘 정리해주셨습니다. 책의 내용을 바탕으로 현업에서의 경험을 녹여내어 깊이 있는 의견을 제시해주신 점이 인상 깊습니다.
전반적으로 내용 구성이나 흐름은 좋으나, 몇 가지 사소한 오탈자나 문법 오류, 그리고 문체(존댓말/반말)의 일관성 부분에서 개선할 점이 보입니다. 이러한 부분들을 수정하면 글의 가독성과 전달력을 더욱 높일 수 있을 것 같습니다.
리뷰 설정에 따라 medium 이상의 심각도를 가진 이슈에 대해서만 개별 댓글을 남겼습니다. low 심각도의 사소한 이슈들은 findings_summary에만 포함시켰으니 참고 부탁드립니다.
Summary of Findings
- 문체 일관성 (존댓말/반말): 글 전체에서 존댓말과 반말이 섞여 사용되고 있습니다. 스터디 기록과 같은 글에서는 한 가지 문체로 통일하여 사용하는 것이 가독성과 일관성을 높이는 데 도움이 됩니다. (Medium severity, 댓글 포함)
- 오탈자 및 문법 오류: '앉고' (-> 않고), '회사에서느' (-> 회사에서는)와 같은 오탈자 및 '~하는게' (-> ~하는 것이), '~때문 입니다' (-> ~때문입니다)와 같은 사소한 문법 오류가 발견되었습니다. (Medium/Low severity, 일부 댓글 포함)
- 띄어쓰기 오류: 단어 간 또는 조사와의 띄어쓰기가 필요한 부분에서 붙여 쓰거나, 불필요한 쉼표가 사용된 부분이 있습니다. (Low severity, 댓글 미포함)
- 비격식 표현: '나도' (-> 저도), '~등등' (-> ~등)과 같은 비격식 표현이 사용되었습니다. (Medium/Low severity, 일부 댓글 포함)
Merge Readiness
제 리뷰 결과, 코드 자체는 Markdown 파일로 구성되어 기능적인 문제는 없으나, 글의 가독성과 일관성을 해치는 몇 가지 medium 심각도의 오탈자 및 문체 관련 이슈가 발견되었습니다. 이러한 이슈들은 글의 품질에 영향을 줄 수 있으므로, 병합 전에 수정하는 것을 권장합니다. 저는 이 PR을 직접 승인할 권한이 없으므로, 다른 리뷰어분들이 검토 후 승인해주셔야 합니다.
|
|
||
| - 현재 일하고 있는 회사에서, 납득하기 힘든 혹은 잘 지켜지지 않는데도 유지되고 있는, 팀의 규칙 혹은 개발자 컨벤션이 있을까요? 있다면, 그것이 무엇이고, 본인의 생각엔 어떻게 바꾸는게 좋다고 생각하는지 얘기해보면 좋을 것 같습니다 | ||
| - 개인적으로, 규칙을 추가하는 것은 관리자를 기준으로한 탑다운이 아니라, 실무자들을 기준으로한 바텀업이 되어야한다고 생각합니다. 다른 분들의 의견은 어떠한가요? | ||
| - 이유는 제 경험 하에서, 관리자는 본능적으로 실무자들의 통제를 목적으로 규칙을 추가하려고 하는데, 애초에 효율성 보다는 통제의 목적이 강하기 때문에, 추가는 쉽게 생각하고 삭제는 보수적으로 생각했었던것 같습니다. 이로 인해서, 현상황에서 굳이 불필요한 규칙들이 계속 없어지지 앉고 남아서 실무자들에게 괜한 불편함을 줬던 경험들이 있습니다 |
There was a problem hiding this comment.
오탈자가 있는 것 같습니다. '없어지지 앉고'는 '없어지지 않고'로 수정하는 것이 맞습니다.
| - 이유는 제 경험 하에서, 관리자는 본능적으로 실무자들의 통제를 목적으로 규칙을 추가하려고 하는데, 애초에 효율성 보다는 통제의 목적이 강하기 때문에, 추가는 쉽게 생각하고 삭제는 보수적으로 생각했었던것 같습니다. 이로 인해서, 현상황에서 굳이 불필요한 규칙들이 계속 없어지지 앉고 남아서 실무자들에게 괜한 불편함을 줬던 경험들이 있습니다 | |
| - 이유는 제 경험 하에서, 관리자는 본능적으로 실무자들의 통제를 목적으로 규칙을 추가하려고 하는데, 애초에 효율성 보다는 통제의 목적이 강하기 때문에, 추가는 쉽게 생각하고 삭제는 보수적으로 생각했었던 것 같습니다. 이로 인해서, 현상황에서 굳이 불필요한 규칙들이 계속 없어지지 않고 남아서 실무자들에게 괜한 불편함을 줬던 경험들이 있습니다 |
| - 제가 규칙이 많은 것을 좋아하지 않는 이유는 인간의 심리적인 관성 때문인데요. 규칙이 늘어난다는 것은 어떤 프로세스가 추가되고 늘어난다는 것인데, 제가 경험하에서, 관리자 레벨에서는 프로세스 추가는 쉽게 하고, 삭제는 신중하게 생각하는 경향이 있다보니, 이 프로세스가 현 상황에서 필요하지 않은 상황에서도 쉽게 없애지 못하는 것 같습니다 | ||
| - 이러한 프로세스들이 적용되는 것은 대개 관리자보단 실무자이다보니, 제가 실무자 입장에선 굳이 필요 없는 프로세스들이 계속 추가되는게, 불필요하다고 느낌에도 불구하고, 없애지 못하는게 답답한 경우가 많았던 것 같습니다. | ||
| - 오히려 제 생각에는 어떤 룰을 추가하는데 더 고민이 필요하고, 삭제는 더 과감하게 해야하는데, 주로 반대로 나타나다 보니 안타까운 것 같습니다 | ||
| - 규칙 추가에는 꼭 필요한 경우에만, 보수적으로 추가하고, 불필요한 규칙은 과감하게 없애자 |
There was a problem hiding this comment.
글 전체에서 존댓말('~습니다', '~습니다')을 사용하고 계신데, 이 부분만 '없애자'로 반말이 사용되었습니다. 글의 일관성을 위해 존댓말로 통일하는 것이 어떨까요?
| - 규칙 추가에는 꼭 필요한 경우에만, 보수적으로 추가하고, 불필요한 규칙은 과감하게 없애자 | |
| - 규칙 추가에는 꼭 필요한 경우에만, 보수적으로 추가하고, 불필요한 규칙은 과감하게 없애야 합니다. |
|
|
||
| # 내 생각 | ||
|
|
||
| - 책에서 나온 것 처럼 간결한 코드의 의미가 사람마다 다르게 받아들여질 수 있다. 가독성 처럼 주관적 영역에 가깝다고 볼 수 있을 것 같다. 나도 간결성에 대해서는 매우 동의하는 편인데, 코드의 간결성도 중요하지만(사람 마다 기준은 다르겠지만), 무엇보다 문제 해결 영역에서의 간결성이 중요하다고 생각한다. 이 문제를 가장 쉽고 간단하게 푸는 방법이 무엇일까? 에 대한 것이다. 이 해결의 영역을 기준으로 보면, 꼭 개발적으로 풀지않아도 풀 수 있는 문제들도 있고, 결국에는 개발자 공수가 전혀 들지 않고도 문제를 해결 할 수 있는 것들이 있다. 개인적으로, 엔지니어로써, 개발자 역량은 문제를 잘 정의하고, 가장 간단하고 쉽게 문제를 해결할 수 있는 해결책을 제안 할 수 있느냐에 달렸다고 생각한다 |
There was a problem hiding this comment.
글 전체의 문맥이 비교적 정중한 문체('~습니다', '~합니다')를 사용하고 있는데, '나도', '~같다', '~한다'와 같은 표현이 섞여 있습니다. 공식적인 글쓰기나 스터디 기록에서는 '저도', '~같습니다', '~합니다' 등으로 통일하여 사용하는 것이 더 자연스럽고 일관성 있어 보입니다.
| - 책에서 나온 것 처럼 간결한 코드의 의미가 사람마다 다르게 받아들여질 수 있다. 가독성 처럼 주관적 영역에 가깝다고 볼 수 있을 것 같다. 나도 간결성에 대해서는 매우 동의하는 편인데, 코드의 간결성도 중요하지만(사람 마다 기준은 다르겠지만), 무엇보다 문제 해결 영역에서의 간결성이 중요하다고 생각한다. 이 문제를 가장 쉽고 간단하게 푸는 방법이 무엇일까? 에 대한 것이다. 이 해결의 영역을 기준으로 보면, 꼭 개발적으로 풀지않아도 풀 수 있는 문제들도 있고, 결국에는 개발자 공수가 전혀 들지 않고도 문제를 해결 할 수 있는 것들이 있다. 개인적으로, 엔지니어로써, 개발자 역량은 문제를 잘 정의하고, 가장 간단하고 쉽게 문제를 해결할 수 있는 해결책을 제안 할 수 있느냐에 달렸다고 생각한다 | |
| - 책에서 나온 것 처럼 간결한 코드의 의미가 사람마다 다르게 받아들여질 수 있습니다. 가독성처럼 주관적 영역에 가깝다고 볼 수 있을 것 같습니다. 저도 간결성에 대해서는 매우 동의하는 편인데, 코드의 간결성도 중요하지만(사람마다 기준은 다르겠지만), 무엇보다 문제 해결 영역에서의 간결성이 중요하다고 생각합니다. 이 문제를 가장 쉽고 간단하게 푸는 방법이 무엇일까? 하는 것입니다. 이 해결의 영역을 기준으로 보면, 꼭 개발적으로 풀지 않아도 풀 수 있는 문제들도 있고, 결국에는 개발자 공수가 전혀 들지 않고도 문제를 해결할 수 있는 것들이 있습니다. 개인적으로, 엔지니어로써, 개발자 역량은 문제를 잘 정의하고, 가장 간단하고 쉽게 문제를 해결할 수 있는 해결책을 제안할 수 있느냐에 달렸다고 생각합니다 |
|
|
||
| - 기본적으로는 복사/붙여넣기 방식이 책에서 말한 것과 같이 해선 안될 안티패턴임을 인정하지만, 개인적으론 테스트 코드 작성할 때, 복사/붙여넣기를 하기도 한다. 즉, 필요하면 쓰되, 중복이 생기는 것에 대한 의도를 확실히 드러나게 해야할 필요가 있다고 생각한다 | ||
| - 스택오버플로우 같은 곳에서 가져온 코드를 내가 이해를 했다는 전제하에서는 가져와서 사용하는게 아무 문제 없다고 생각하고, 그것도 능력이라고 생각한다. | ||
| - 재사용을 위한 설계 부분은 이 책에서 거의 제일 공감되는 부분이다. 개인적인 경험에서 봤을 때, 정말로 확장될 부분이 확실해서 확장성을 고려해야하는 것이 아니라면, 최대한 확장성을 고려하지 않고 현재 요구사항을 충실하게 수행할 수 있는 코드를 만드는게 낫다고 생각한다. 그 이유는 확장성을 고려하던, 고려하지 않던, 요구사항은 바뀌는데, 그 요구사항의 변경은 상상을 초월하기 때문이다. 애초에 요구사항을 보고 확장성을 고려하더라도, 기대대로 확장이 안되는 경우에는 다시 갈아엎고 설계를 해야하는데, 오히려 이전 요구사항 기준으로 설계한것을 갈아엎는게 더 공수가 들었던 것 같다. 라이브러리의 경우도 마찬가지 인데, 미리부터 공통으로 사용할 코드들 부터 미리 전부 만들어두는게 정말로 효율적인 판단인지 모르겠다고 생각한 이유는 그 공통 코드에 예외가 생기는 순간 공통 코드를 수정해야하는 이슈가 생기기 때문이다. 공통 코드들의 경우는 의존하는 코드 모두를 커버할 수있도록 설계가 되어야 하기 때문에, 미리 부터 그 설계 가능성을 모두 고려하기 보다는, 어느정도 프로젝트가 성숙해서 중복적으로 발생하는 부분이 생길 때 하는게 낫다고 생각한다 |
There was a problem hiding this comment.
'~하는게'는 구어체에서 자주 사용되지만, 글에서는 '~하는 것이'로 쓰는 것이 더 자연스럽고 정중한 표현입니다. 다른 부분에서도 '~게' 대신 '~것이'를 사용하면 글의 완성도를 높일 수 있습니다.
| - 재사용을 위한 설계 부분은 이 책에서 거의 제일 공감되는 부분이다. 개인적인 경험에서 봤을 때, 정말로 확장될 부분이 확실해서 확장성을 고려해야하는 것이 아니라면, 최대한 확장성을 고려하지 않고 현재 요구사항을 충실하게 수행할 수 있는 코드를 만드는게 낫다고 생각한다. 그 이유는 확장성을 고려하던, 고려하지 않던, 요구사항은 바뀌는데, 그 요구사항의 변경은 상상을 초월하기 때문이다. 애초에 요구사항을 보고 확장성을 고려하더라도, 기대대로 확장이 안되는 경우에는 다시 갈아엎고 설계를 해야하는데, 오히려 이전 요구사항 기준으로 설계한것을 갈아엎는게 더 공수가 들었던 것 같다. 라이브러리의 경우도 마찬가지 인데, 미리부터 공통으로 사용할 코드들 부터 미리 전부 만들어두는게 정말로 효율적인 판단인지 모르겠다고 생각한 이유는 그 공통 코드에 예외가 생기는 순간 공통 코드를 수정해야하는 이슈가 생기기 때문이다. 공통 코드들의 경우는 의존하는 코드 모두를 커버할 수있도록 설계가 되어야 하기 때문에, 미리 부터 그 설계 가능성을 모두 고려하기 보다는, 어느정도 프로젝트가 성숙해서 중복적으로 발생하는 부분이 생길 때 하는게 낫다고 생각한다 | |
| - 재사용을 위한 설계 부분은 이 책에서 거의 제일 공감되는 부분입니다. 개인적인 경험에서 봤을 때, 정말로 확장될 부분이 확실해서 확장성을 고려해야 하는 것이 아니라면, 최대한 확장성을 고려하지 않고 현재 요구사항을 충실하게 수행할 수 있는 코드를 만드는 것이 낫다고 생각합니다. 그 이유는 확장성을 고려하던, 고려하지 않던, 요구사항은 바뀌는데, 그 요구사항의 변경은 상상을 초월하기 때문입니다. 애초에 요구사항을 보고 확장성을 고려하더라도, 기대대로 확장이 안 되는 경우에는 다시 갈아엎고 설계를 해야 하는데, 오히려 이전 요구사항 기준으로 설계한 것을 갈아엎는 것이 더 공수가 들었던 것 같습니다. 라이브러리의 경우도 마찬가지인데, 미리부터 공통으로 사용할 코드들부터 미리 전부 만들어두는 것이 정말로 효율적인 판단인지 모르겠다고 생각한 이유는 그 공통 코드에 예외가 생기는 순간 공통 코드를 수정해야 하는 이슈가 생기기 때문입니다. 공통 코드들의 경우는 의존하는 코드 모두를 커버할 수 있도록 설계가 되어야 하기 때문에, 미리부터 그 설계 가능성을 모두 고려하기보다는, 어느 정도 프로젝트가 성숙해서 중복적으로 발생하는 부분이 생길 때 하는 것이 낫다고 생각합니다 |
|
|
||
| # 내 생각 | ||
|
|
||
| - 책에서 말하는 코드 프리징은 완료기간과 출시일 사이 기간동안을 말하는데, 용어 자체가 그렇게 와닿는 것 같진 않다. 저자가 말한 것 처럼 프리징은 모든 테스트가 끝나고, 배포 준비가 완료된 시점이 기준이 되어야 한다고 생각하고, 이 코드는 가능한 빠르게 배포가 되어야한다고 생각한다. 이 중간에 무언가 기능을 추가하기 위해서 코드를 수정하는 것은 정말로 크리티컬한 경우가 아니면, 그 다음 릴리즈에 진행하는 것으로 해야한다고 생각한다 |
There was a problem hiding this comment.
이 부분에서도 문체 일관성이 필요해 보입니다. '~않다', '~생각한다' 대신 '~않습니다', '~생각합니다'를 사용하여 글 전체의 톤을 맞추는 것이 좋습니다.
| - 책에서 말하는 코드 프리징은 완료기간과 출시일 사이 기간동안을 말하는데, 용어 자체가 그렇게 와닿는 것 같진 않다. 저자가 말한 것 처럼 프리징은 모든 테스트가 끝나고, 배포 준비가 완료된 시점이 기준이 되어야 한다고 생각하고, 이 코드는 가능한 빠르게 배포가 되어야한다고 생각한다. 이 중간에 무언가 기능을 추가하기 위해서 코드를 수정하는 것은 정말로 크리티컬한 경우가 아니면, 그 다음 릴리즈에 진행하는 것으로 해야한다고 생각한다 | |
| - 책에서 말하는 코드 프리징은 완료 기간과 출시일 사이 기간 동안을 말하는데, 용어 자체가 그렇게 와닿는 것 같지는 않습니다. 저자가 말한 것처럼 프리징은 모든 테스트가 끝나고, 배포 준비가 완료된 시점이 기준이 되어야 한다고 생각하고, 이 코드는 가능한 빠르게 배포가 되어야 한다고 생각합니다. 이 중간에 무언가 기능을 추가하기 위해서 코드를 수정하는 것은 정말로 크리티컬한 경우가 아니면, 그 다음 릴리즈에 진행하는 것으로 해야 한다고 생각합니다 |
| - ch22 에서 말하는 코드 프리징과 이어지는 내용으로 보인다 배포와 관련해서 어떤 절차와 준비들이 필요하고, 구체적으로 브랜치 관리는 어떻게 해야하는지에 대한 내용을 말한다 | ||
| - 구체적인 방법인 조금씩은 다르지만, 책에서 말하는 대부분의 조언에 맞게 현재 회사에서는 배포관리를 하고 있다 그러다보니, 챕터에 나오는 내용을 이해하는데 어렵진 않았다. |
There was a problem hiding this comment.
이 부분에서도 문체 일관성이 필요해 보입니다. '~보인다', '~말한다', '~하고 있다', '~않았다' 대신 '~보입니다', '~말합니다', '~하고 있습니다', '~않았습니다'를 사용하여 글 전체의 톤을 맞추는 것이 좋습니다.
| - ch22 에서 말하는 코드 프리징과 이어지는 내용으로 보인다 배포와 관련해서 어떤 절차와 준비들이 필요하고, 구체적으로 브랜치 관리는 어떻게 해야하는지에 대한 내용을 말한다 | |
| - 구체적인 방법인 조금씩은 다르지만, 책에서 말하는 대부분의 조언에 맞게 현재 회사에서는 배포관리를 하고 있다 그러다보니, 챕터에 나오는 내용을 이해하는데 어렵진 않았다. | |
| - ch22 에서 말하는 코드 프리징과 이어지는 내용으로 보입니다. 배포와 관련해서 어떤 절차와 준비들이 필요하고, 구체적으로 브랜치 관리는 어떻게 해야 하는지에 대한 내용을 말합니다. | |
| - 구체적인 방법은 조금씩 다르지만, 책에서 말하는 대부분의 조언에 맞게 현재 회사에서는 배포 관리를 하고 있습니다. 그러다 보니, 챕터에 나오는 내용을 이해하는 데 어렵지는 않았습니다. |
|
|
||
| # 논의 내용 | ||
|
|
||
| - 해당 챕터에서 말하는 예술작품으로써의 소프트웨어 개발이 자칫 회사에서 소프트웨어 개발을 해야하는 본질적인 이유인 비즈니스 가치를 창출 보다 더 중요한 가치처럼 여겨 질 수 있지 않을까 하는 우려점이 있습니다. 제 개인적으로는 비즈니스 가치를 창출할 수 있는 제대로 동작하는 코드, 유지보수성과 확장성을 고려하는 것을 전제한 상태에서, 이후에 코드의 미적인 가치, 가독성 등을 고려하는게 맞지 않나 라는 생각인데요(미적 가치라는 것이 주관적인 영역에 가깝다고 생각하기 때문에) 이에 어떻게 생각하시는지 의견을 나눠보면 좋을 것 같습니다 |
There was a problem hiding this comment.
저는 사실 코드를 작성하는 여러 관점에서의 비유를 설명해준 거라 생각했습니다.
소프트웨어 개발의 영역이 비즈니스 가치 창출이 아닌 순수 취미의 영역이라면 놀이에 더 가까울 수 있으니까요.
해커와 화가라는 책은 예술을 하다 해커가 된 저자의 경험을 쓴 걸 본다면, 아예 별개의 영역으로 보기 보다는 연관성이 있다고 볼 수도 있습니다.
해커와 화가 책의 챕터 2 부분에 대한 링크를 달아 보겠습니다.
There was a problem hiding this comment.
저는 책에서 말하는 예술적인 부분도 비즈니스 가치에 포함되는 것이 아닌가란 생각이듭니다.
단순히 예술만 보면 비즈니스성이 있나 싶겠지만,
예를 들어 아이폰같은 경우는 하드웨어 기판부터 미적인 부분을 기능과 함께 가져갑니다.
갤럭시는 같은 기능이라도 기능에 치중해서 회로를 그리죠.
위 두 경우 비즈니스만 달성하면 실상 같은거라 생각될 수 있지만,
미적 부분으로 인한 마케팅 요소나, 수정 용이성이 가져오는 시간 절약 등에서 오는 디테일은
직결적으로 돈하고 연결이 되지 않더라도,
부가적으로 수익을 창출하는 요소라 봅니다.
책에 앞에서도 소개가 있었던 것 같은데
코드를 보는데 아...이 코드는 1800년대에 ... 풍과 ...풍을 곁들여 이 시대에 어쩌구 저쩌구 하는
예술로 보는 그런 예술이라기 보다는,
저자는 정리정돈이 완벽하고, 확장도 용이하고, 유지보수도 잘되는 그런 어떤 구조를 예술이라 칭하는 것 같습니다.
There was a problem hiding this comment.
결국 회사의 궁극적인 목표는 비즈니스 가치를 창출하고 금전적인 이익을 얻는 것이며 이 또한 회사 존재의 이유라고 생각하기 때문에 태형님이 말씀하신 "제대로 동작하는 코드, 유지보수성과 확장성을 고려하는 것을 전제한 상태"는 가장 우선순위라는 것에 공감합니다.
결국 유지보수성과 확장성은 미적인 것으로부터도 어느정도 나올 수 있는 부분이라고 생각하여 미적 가치를 해당 기능의 완성 전, 후로 얼마만큼의 비율로 적용해야할지가 중요하다고 생각합니다.
| # 논의 내용 | ||
|
|
||
| - 현재 일하고 있는 회사에서, 납득하기 힘든 혹은 잘 지켜지지 않는데도 유지되고 있는, 팀의 규칙 혹은 개발자 컨벤션이 있을까요? 있다면, 그것이 무엇이고, 본인의 생각엔 어떻게 바꾸는게 좋다고 생각하는지 얘기해보면 좋을 것 같습니다 | ||
| - 개인적으로, 규칙을 추가하는 것은 관리자를 기준으로한 탑다운이 아니라, 실무자들을 기준으로한 바텀업이 되어야한다고 생각합니다. 다른 분들의 의견은 어떠한가요? |
There was a problem hiding this comment.
제가 관리자의 입장이다 보니 조금 의견을 적어보자면,
실무자들이 그런 기준을 만들어 준다면 저는 수용할 수 있습니다.
하지만 제가 만났던 개발자 5명 중에 4명인 80% 이상은 그런 규칙이나 기준이 없고
자기가 처음 코드 문법 배웠을 때 그리고 회사에서 아무 문제 없이 코드 작성만 했던 기준으로만 해온 개발자가 대부분이었습니다.
그래서 저는 해당 언어가 가지고 있는 관례(best practice)를 따르는 걸 기준으로 하고,
그걸 따르지 않는 규칙에 대해서 추가 규칙을 적용합니다.
추가 규칙은 아래 5개이며, 그 규칙을 따라야 하는 이유도 함께 적었습니다.
Unity 환경에서 C# 코드 의존적인 규칙은 1, 3, 5번 정도입니다.
- Inspector binding을 통한 UnityEvent 사용 제한 => 필드 참조 + 메서드 호출 방식 권장
- Callback 구현 방식 제한 => 비동기 방식 구현을 통해 소모적인 callback 메서드 추가 구현 방지
- GameObject name과 Script class name을 맞춰서 개발 => 하나의 GameObject에 하나의 script, namespace가 달라 참조가 어려운 경우에만 예외 허용
- Remove commented code(주석 처리한 코드 삭제) => git 버전 관리 시스템을 사용하면 이런 코드들은 남길 이유가 없음
- async/await 사용, Coroutine 지양 => Coroutine으로 할 수 있는 일은 충분히 비동기 프로그래밍으로 가능함
There was a problem hiding this comment.
아예 새로운 팀이 아니라면 말씀하신대로 규칙은 바텀업이 될수록 팀원 모두가 동의하는 규칙일 가능성이 높고, 그러면 규칙을 지키기 훨씬 편해질 것이라 저도 바텀업이 되어야 한다고 생각합니다.
There was a problem hiding this comment.
규칙은 프로젝트에 훨씬 가깝게 기여하고 있는 실무자들을 기준으로한 바텀업이 되는 것이 정말 좋다고 생각합니다.
결국 당사자들에게 와닿아야 효율이 그만큼 올라갈 것 같기 때문입니다.
|
|
||
| # 논의 내용 | ||
|
|
||
| - 간결성을 지키고, 간결하게 한다가 저는 주관적영역에 해당한다고 생각하기 때문에, 개인 마다 구체적인 실천사항들도 차이가 있을 것이라고 생각합니다. 본인이 최근에 실천한 간결성과 관련된 것이 있다면 공유해보면 좋을것 같습니다 |
There was a problem hiding this comment.
제가 작성한 코드의 간결함은 읽을 수 있는 코드이고 추가 설명을 해주거나 주석을 읽지 않아도 이해할 수 있는 코드입니다.
그리고 한 파일의 길이가 그래도 200 라인은 넘지 않게 작은 단위로 작성하는 실천 규칙도 있습니다.
There was a problem hiding this comment.
코드가 하고 있는 행위을 한 문장으로 끝낼 수 있으면, 충분히 간결하고 읽기 쉽다. 라고 생각합니다.
즉, 추상화를 할 수록 간결성이 올라간다고 생각합니다. 그런데 말씀하신 대로 '어느 레벨의 추상화 수준부터 읽기 편한가'는 주관적인 것이라서 애매한 것 같습니다.
결국 코드 리뷰 등으로 적절한 추상화 정도를 찾고, 이를 달성하기 위해 노력하는 것 밖에 없을 것 같네요.
|
|
||
| # 논의 내용 | ||
|
|
||
| - 책 내용에서 코드에 두려움을 가짐으로써, 수정하지 못하고, 방치하는 상황은 피해야하지만, 반대로, 이런 두려움 타파를 위해서, 대담하게 수정하라는 말은 조금 책임 없는 말처럼 들립니다. 물론, 암묵적으로 롤백 가능성에 대해서도 언급을 하고 있고, 수정을 잘하기위해서, 어떤 식으로 설계해야할지에 대한 얘기도 나옵니다만, 제 개인적으로는 좀 더 명시적으로 모든 케이스에 대해서 살펴보고, 혹시나 문제가 생겼을 때, 어떻게 대응을 해야한다고 말하는게 현실성 있는 답변이 아닐까 하는 비판을 해봅니다. 다른 분들은 이부분을 읽고 어떻게 느끼셨는지 궁금하네요 |
There was a problem hiding this comment.
용기를 가지라는 게 코드 상으로 잘못된 부분이 분명 있고 그걸 그대로 방치하는 상황을 유지시키지 말고 빠르게 수정하자라고 생각했습니다.
남이 짠 코드 혹은 과거에 퇴사한 개발자가 작성한 레거시 코드일 수 있는데
태형님이 얘기한 문제 대응 방안 조차도 얘기 안하고 그대로 두는 경우이지 않을까 합니다.
아마 아무런 얘기와 협의도 없이 불쑥 수정한 코드에 대한 pull request가 올라오는 상황만 아니면 되지 않을까 싶네요.
There was a problem hiding this comment.
두려움을 가짐으로써, 수정하지 못하는 사람들을 종종 만나는데, 이런 분들에게 해주고 싶은 말이었어서 시원하게 읽었습니다 ㅎㅎ
|
|
||
| # 논의 내용 | ||
|
|
||
| - 책의 내용과는 조금 동떨어지지만, `오류 보고서를 개인적으로 받아들이지 마라. 개인적 모욕이 아니다` 라는 말은 꼭 이 경우만 쓸 수 있진 않은 것 같습니다. 예를 들면, 그 대상이 오류 보고서가 아니라, 내가 작성한 코드 일 수 도 있고, 내가 회사에서 했던 업무, 업무 태도 같은 것들이 될 수 있다고 생각합니다. 개인적 모욕을 위한 것이 아니라는 전제하에서는 이런 모든 나에게 부정적 피드백을 줄 수 있는 것들이 오히려 나에게 개선할 수 있는 좋은 기회라고 저는 생각하는데, 다른 분들은 어떻게 생각하시는지 궁금하네요 |
There was a problem hiding this comment.
개인적으로 받아들여서 감정적으로 대응하는 사람들에게 주는 조언이지 않을까요?
QA에서 만들어진 오류들이 QA 팀과의 감정적인 대응을 하면 안된다의 내용으로 이해했고
태형님 얘기처럼 오히려 좋은 기회로 받아들일 수도 있는 것 역시 감정적인 대응이 아닐 때 생길 것 같습니다.
There was a problem hiding this comment.
책에서도 언급한 것 같은데 충분히 논리적인 비판이 아니라면 좋은 것 같습니다.
저는 오히려 "나를 공격해줘"라고 얘기하곤 합니다. 🤣
|
|
||
| # 논의 내용 | ||
|
|
||
| - 코드 프리징을 어떻게 관리할 것인가? 에 대한 얘기는 결국에 어떤 기준을 가지고 코드 배포를 할 것인가? 라는 말로 치환할 수있을 것 같습니다. 회사에서 배포 프로세스가 어떻게 되어있는지 공유해보면 좋을 것 같습니다 |
There was a problem hiding this comment.
QA에서 정해진 우선순의 높은 수정 건에 대해 수정을 완료하고 QA가 통과되면 즉시 배포하는 프로세스로 되어 있습니다.
회사가 아직 크지 않다 보니 정해진 날과 시간에 맞춰서 하진 않는 프로세스입니다.
여기서부터는 옛날 얘기:
이 책의 출판 시점이 2014년 이라는 점을 감안하면 아마 과거의 CD나 인스톨러에 의한 설치와 자동 업데이터로 진행하는 온라인 배포의 과도기 일 것으로 예상해 볼 수 있습니다.
실제 저도 코드 프리징이라는 용어는 2000년 후반에 안랩과 삼성전자 프로젝트를 하면서 썼던 용어였습니다.
삼성전자 프로젝트를 하면서 빌드 자동화라는 걸 겪어봤고 그 전까지는 빌드를 자동화 프로세스로 돌린다라는 경험도 없었고
2007년에는 실제로 실행 파일로 실행하는 인스톨러 파일을 CD에 복사(구워서)해서 배포한 경험도 있었습니다.
이제 한글로도 답변을 주는군요 ㅎㅎ 👍🏻 |
저도 지금 봤는데 그런걸로 보입니다 ㅎㅎ 저희 회사 레포에도 제미나이 코드리뷰 도입 해둔 이후에, 제가 요즘 코드는 많이 못쓰고 있다보니 신경 못썼는데요 뭔가 더 발전된거 같아서 좀 살펴봐야할것 같네요 ㅎㅎ |
|
안녕하세요 @TaeHyoungKwon 님! 네, 맞습니다. 코드 리뷰 과정에서 발견된 오탈자나 문법 오류 등 개선이 필요한 부분에 대해 한국어 텍스트에 대한 오탈자 및 문법 오류 수정 제안도 지원하고 있습니다. 이번 PR에서 Markdown 파일의 내용을 분석하여 해당 제안들을 생성했습니다. 제 기능에 관심을 가져주셔서 감사합니다! 앞으로도 코드 리뷰 과정에서 도움이 될 수 있도록 노력하겠습니다. 😊 |
오.. 답변줘서 고마워 제미나이! 😄 |
| # 논의 내용 | ||
|
|
||
| - 현재 일하고 있는 회사에서, 납득하기 힘든 혹은 잘 지켜지지 않는데도 유지되고 있는, 팀의 규칙 혹은 개발자 컨벤션이 있을까요? 있다면, 그것이 무엇이고, 본인의 생각엔 어떻게 바꾸는게 좋다고 생각하는지 얘기해보면 좋을 것 같습니다 | ||
| - 개인적으로, 규칙을 추가하는 것은 관리자를 기준으로한 탑다운이 아니라, 실무자들을 기준으로한 바텀업이 되어야한다고 생각합니다. 다른 분들의 의견은 어떠한가요? |
There was a problem hiding this comment.
아예 새로운 팀이 아니라면 말씀하신대로 규칙은 바텀업이 될수록 팀원 모두가 동의하는 규칙일 가능성이 높고, 그러면 규칙을 지키기 훨씬 편해질 것이라 저도 바텀업이 되어야 한다고 생각합니다.
|
|
||
| # 논의 내용 | ||
|
|
||
| - 간결성을 지키고, 간결하게 한다가 저는 주관적영역에 해당한다고 생각하기 때문에, 개인 마다 구체적인 실천사항들도 차이가 있을 것이라고 생각합니다. 본인이 최근에 실천한 간결성과 관련된 것이 있다면 공유해보면 좋을것 같습니다 |
There was a problem hiding this comment.
코드가 하고 있는 행위을 한 문장으로 끝낼 수 있으면, 충분히 간결하고 읽기 쉽다. 라고 생각합니다.
즉, 추상화를 할 수록 간결성이 올라간다고 생각합니다. 그런데 말씀하신 대로 '어느 레벨의 추상화 수준부터 읽기 편한가'는 주관적인 것이라서 애매한 것 같습니다.
결국 코드 리뷰 등으로 적절한 추상화 정도를 찾고, 이를 달성하기 위해 노력하는 것 밖에 없을 것 같네요.
|
|
||
| # 논의 내용 | ||
|
|
||
| - 책 내용에서 코드에 두려움을 가짐으로써, 수정하지 못하고, 방치하는 상황은 피해야하지만, 반대로, 이런 두려움 타파를 위해서, 대담하게 수정하라는 말은 조금 책임 없는 말처럼 들립니다. 물론, 암묵적으로 롤백 가능성에 대해서도 언급을 하고 있고, 수정을 잘하기위해서, 어떤 식으로 설계해야할지에 대한 얘기도 나옵니다만, 제 개인적으로는 좀 더 명시적으로 모든 케이스에 대해서 살펴보고, 혹시나 문제가 생겼을 때, 어떻게 대응을 해야한다고 말하는게 현실성 있는 답변이 아닐까 하는 비판을 해봅니다. 다른 분들은 이부분을 읽고 어떻게 느끼셨는지 궁금하네요 |
There was a problem hiding this comment.
두려움을 가짐으로써, 수정하지 못하는 사람들을 종종 만나는데, 이런 분들에게 해주고 싶은 말이었어서 시원하게 읽었습니다 ㅎㅎ
|
|
||
| # 논의 내용 | ||
|
|
||
| - 책의 내용과는 조금 동떨어지지만, `오류 보고서를 개인적으로 받아들이지 마라. 개인적 모욕이 아니다` 라는 말은 꼭 이 경우만 쓸 수 있진 않은 것 같습니다. 예를 들면, 그 대상이 오류 보고서가 아니라, 내가 작성한 코드 일 수 도 있고, 내가 회사에서 했던 업무, 업무 태도 같은 것들이 될 수 있다고 생각합니다. 개인적 모욕을 위한 것이 아니라는 전제하에서는 이런 모든 나에게 부정적 피드백을 줄 수 있는 것들이 오히려 나에게 개선할 수 있는 좋은 기회라고 저는 생각하는데, 다른 분들은 어떻게 생각하시는지 궁금하네요 |
There was a problem hiding this comment.
책에서도 언급한 것 같은데 충분히 논리적인 비판이 아니라면 좋은 것 같습니다.
저는 오히려 "나를 공격해줘"라고 얘기하곤 합니다. 🤣
|
|
||
| # 논의 내용 | ||
|
|
||
| - 해당 챕터에서 말하는 예술작품으로써의 소프트웨어 개발이 자칫 회사에서 소프트웨어 개발을 해야하는 본질적인 이유인 비즈니스 가치를 창출 보다 더 중요한 가치처럼 여겨 질 수 있지 않을까 하는 우려점이 있습니다. 제 개인적으로는 비즈니스 가치를 창출할 수 있는 제대로 동작하는 코드, 유지보수성과 확장성을 고려하는 것을 전제한 상태에서, 이후에 코드의 미적인 가치, 가독성 등을 고려하는게 맞지 않나 라는 생각인데요(미적 가치라는 것이 주관적인 영역에 가깝다고 생각하기 때문에) 이에 어떻게 생각하시는지 의견을 나눠보면 좋을 것 같습니다 |
There was a problem hiding this comment.
결국 회사의 궁극적인 목표는 비즈니스 가치를 창출하고 금전적인 이익을 얻는 것이며 이 또한 회사 존재의 이유라고 생각하기 때문에 태형님이 말씀하신 "제대로 동작하는 코드, 유지보수성과 확장성을 고려하는 것을 전제한 상태"는 가장 우선순위라는 것에 공감합니다.
결국 유지보수성과 확장성은 미적인 것으로부터도 어느정도 나올 수 있는 부분이라고 생각하여 미적 가치를 해당 기능의 완성 전, 후로 얼마만큼의 비율로 적용해야할지가 중요하다고 생각합니다.
| # 논의 내용 | ||
|
|
||
| - 현재 일하고 있는 회사에서, 납득하기 힘든 혹은 잘 지켜지지 않는데도 유지되고 있는, 팀의 규칙 혹은 개발자 컨벤션이 있을까요? 있다면, 그것이 무엇이고, 본인의 생각엔 어떻게 바꾸는게 좋다고 생각하는지 얘기해보면 좋을 것 같습니다 | ||
| - 개인적으로, 규칙을 추가하는 것은 관리자를 기준으로한 탑다운이 아니라, 실무자들을 기준으로한 바텀업이 되어야한다고 생각합니다. 다른 분들의 의견은 어떠한가요? |
There was a problem hiding this comment.
규칙은 프로젝트에 훨씬 가깝게 기여하고 있는 실무자들을 기준으로한 바텀업이 되는 것이 정말 좋다고 생각합니다.
결국 당사자들에게 와닿아야 효율이 그만큼 올라갈 것 같기 때문입니다.
github-project-automation
bot
moved this from In review
to Done
in 2025 Academic Conference
Close #542