thkwon1: Add md files in 1 week #344
Conversation
|
우측에 있는 |
|
리뷰어 추가하는 actions가 정상작동하지 않는듯 해서 해당 PR 기준으로 테스트 몇번만 좀 하겠습니다 🙇🏻 |
github-actions
bot
requested review from
dhlee3994,
fkdl0048,
hongsam14,
jeeyn,
jongfeel,
wooyaggo86 and
yeslee-v
TaeHyoungKwon
removed request for
wooyaggo86,
jongfeel,
jeeyn,
yeslee-v,
hongsam14,
fkdl0048 and
dhlee3994
github-actions
bot
requested review from
dhlee3994,
fkdl0048,
hongsam14,
jeeyn,
jongfeel,
wooyaggo86 and
yeslee-v
TaeHyoungKwon
force-pushed
the
thkwon-the-psychology-of-programming-1-week
branch
from
a0dc8f7 to
47a11b2
Compare
TaeHyoungKwon
force-pushed
the
thkwon-the-psychology-of-programming-1-week
branch
from
d16b938 to
47a11b2
Compare
완료 했습니다 |
|
|
||
| ### 논의할 내용 | ||
|
|
||
| 1. 어려운 코드 읽는 방법에 대한 본인 만의 노하우가 있다면 공유해보면 좋을 것 같습니다. |
There was a problem hiding this comment.
노하우 까지는 아니고 일반적인 방법일 수 있는데
디버깅 하면서 실행해보고 문맥을 파악하면 코드를 빠르게 파악할 수 있긴 합니다.
그런데 실행할 수 없는 코드이고 텍스트로만 존재한다면 분석하면서 읽어야 할 것 같긴 하네요.
주로 메소드 위주로 어떤 행위를 하는가를 살펴보고, 어떤 의존성을 가지는지 더 살펴보면서 보면 어려운 코드라도 분석적 읽기가 가능할 것 같습니다.
| 1. 내가 작성한 코드의 실제 동작을 QA 과정에서 개발자 본인이 직접 확인하시나요? | ||
| 1. 그렇다면, 어떤 이유로 확인을 하시나요? | ||
| 2. 그렇지 않다면, 확인하지 않는 이유는 무엇인가요? |
There was a problem hiding this comment.
실제 코드 동작을 확인하는 방법으로 target container(or device)에서 실행을 해야 하는데
보통은 자신의 개발 환경에서만 실행하는 것으로 확인하므로 실제 환경하고의 차이를 확인할 수는 없다고 봅니다.
(실제 환경도 같을 것이라고 판단하고 개발하므로)
저의 경우는 복합적으로 합니다.
현재는 클라이언트 프로그램을 개발하므로 개발 환경에서 동작하는 것도 확인함과 동시에 빌드해서 디바이스에 설치하는 것도 같이 확인합니다. 빌드 자동화가 되어 있으므로 디바이스 환경에서 확인하는데 아주 많은 차이가 있지는 않긴 해서 확인을 하는 편이라고 볼 수 있습니다.
| 2. 최근에 맥킨지에서 개발자의 생산성을 체크할 수 있는 방법을 공개하였고, 이에 대해서 켄트 벡 등의 개발자들이 반대 의견을 내는 글이 많이 화제가 되었습니다. | ||
| 1. 개발자의 생산성을 체크할 수 있다고 생각하시나요? | ||
| 1. 그렇다면, 어떤 항목으로 생산성 체크를 할 수 있다고 생각하시나요? | ||
| 2. 그렇지 않다면, 왜 체크할 수 없다고 생각하시나요? |
There was a problem hiding this comment.
- 개발자의 생산성을 체크할 수 있다고 생각하는가?
이 질문에 답변하기 위해 사전 조건이 있습니다.
생산성 체크의 목적이 무엇인가? 라는 것인데
성과 측정이나 보상, 페널티 등의 목적이라면 의미가 조금 퇴색될 것이라고 봅니다.
그리고 이런 목적이 아니더라도 저는 생산성을 체크할 수 없다고 보는 입장입니다.
- 왜 체크할 수 없는가?
최대한 객관적이고 정량적으로 체크할 수 있는 기준과 그 데이터를 얻는 다고 하더라도
커뮤니케이션 관점에서:
- 어떤 사람과 함께 일하는가? (어떤 팀에서 일하는가?)
- 개발 제약 조건이 어떻게 되는가? (직접 대화 가능한지 혹은 원격으로 일하는지)
개인적인 관점에서:
- 내가 얼마나 개발을 잘 할 마음이 있는지, 즐겁게 일할 수 있는지?
- 내 개발 역량이 현재 프로젝트에 기여하는데 많이 도움이 되는지?
에 따라 달라질 수 있기 때문에 생산성 체크라는게 의미가 있다고 보기는 어렵다는 입장입니다.
그리고 지표가 설정되고 데이터가 뽑히는 순간 부터 그 생산성 체크를 위해 조직이나 개인의 입장이 달라지거나 본래 소프트웨어 엔지니어링의 의미는 퇴색되고 그 지표 기준으로 일을 하면서 생기는 부작용으로 인해 어쨌든 생산성 체크는 불가능한 부분이라고 봅니다.
| 2. 참고 | ||
| 1. 맥킨지 글 | ||
| 1. [Yes, you can measure software developer productivity](https://www.mckinsey.com/industries/technology-media-and-telecommunications/our-insights/yes-you-can-measure-software-developer-productivity?fbclid=IwAR3wDWrWeMPzGO7_odkOTH3rp1acP24EtVVjLeAR4oA4ds622025dzdDY7A) | ||
| 2. 반박글 | ||
| 1. [Measuring developer productivity? A response to McKinsey](https://tidyfirst.substack.com/p/measuring-developer-productivity?fbclid=IwAR1Y_8P2MpTsBaaj40LN21axWcnU-_3SBThaYK_EsUWznvk9WWzeoUMqglo) | ||
| 2. [Measuring developer productivity? A response to McKinsey 2](https://tidyfirst.substack.com/p/measuring-developer-productivity-440) |
There was a problem hiding this comment.
알려주신 링크의 문서를 번역해서 읽다가 구글에 "개발자 생산성" 이라고 치니까 맥킨지의 생산성 관련 글들과 요약 혹은 반박 글들이 쏟아져 나오더라고요
몇 개의 글을 읽고 대략적으로 뭘 하고 싶었는지에 대해 파악해 볼 수 있었습니다.
|
|
||
| ### 논의할 내용 | ||
|
|
||
| 1. 저는 프로그래밍에는 올바른 해답이 없다 라는 말은 오해의 소지가 있다고 생각합니다. 자칫 해답이 없기 때문에 무엇이든 답이 될 수 있다라고 오해할 수 있다고 생각되는데요 저는 특정 상황에 따라서 적절한 해답이 있다고 생각합니다. 그렇기 때문에 그 상황, 맥락을 파악하고 거기에 맞는 적절한 해결책을 고민하고 적용하는 능력이 중요하다고 생각하는데, 다른 분들의 의견도 궁금합니다! |
There was a problem hiding this comment.
태형님의 생각에 적어 놓으신 내용은 많이 동의하는 쪽입니다.
저도 사례를 하나 적어 보자면 디자인 패턴 공부가 있습니다.
제가 디자인 패턴을 공부하겠다는 사람들을 살펴 봤을 때 느낀 점은
"디자인 패턴을 공부해서 내 실무에 적용하면 실력있는 사람이 될 것이다" 라는 어떤 강한 믿음을 가지고 한다는 점이었습니다.
하지만 실제로 디자인 패턴을 공부하는 사람들의 한결같은 패턴(?)은
어렵다 혹은 이걸 실무에 적용할 수 있을지 잘 모르겠다 등의 대답이었습니다.
그렇기 때문에 디자인 패턴은 자신이 개발하고 있는 상황을 잘 파악하고 그걸 디지인 패턴의 어떤 방식으로 적용할 수 있는지를 살펴봐야 한다고 봅니다..
그러려면 자신이 실무에서 개발하고 있는 코드가 아닌 설계 내용을 다시 리뷰해 보고 잘못된 설계 혹은 디자인 패턴에 어떤 패턴을 적용할지 찾아보는 거죠.
디자인 패턴이라는 단어 자체에는 주니어 개발자들이 깨닫지 못한 팩트와 진실이 드러나 있습니다.
그건 디자인 패턴을 코딩 하는 방법으로 접근하려는 자세인 것인데
디자인 패턴을 번역하면 "반복되는 설계의 요소들" 쯤으로 볼 수 있습니다.
즉 설계 관점으로 접근해 본다면 잘 모르겠는 부분, 어려운 부분을 해소할 수 있을 것이라고 봅니다.
|
|
||
| ### 논의할 내용 | ||
|
|
||
| 1. 어려운 코드 읽는 방법에 대한 본인 만의 노하우가 있다면 공유해보면 좋을 것 같습니다. |
There was a problem hiding this comment.
- 의도가 중요한 것 같습니다. 이 맥락으로 저자에게 도움을 요청하는게 유용할 때가 많은 것 같습니다.
- 위와 같은 의도로 파일의 commit history를 잘 체크합니다.
- 사람들이 꼼쳐놓은 설계 문서 찾아보기.
- 좋은 코드 navigation tool도 중요한 것 같습니다. (e.g. https://source.chromium.org/chromium)
라떼토크로 source insight툴도 잘 썼었는데 요즘은 어떻게 됬는지 모르겠네요ㅎㅎ.
| ### 논의할 내용 | ||
|
|
||
| 1. 내가 작성한 코드의 실제 동작을 QA 과정에서 개발자 본인이 직접 확인하시나요? | ||
| 1. 그렇다면, 어떤 이유로 확인을 하시나요? |
There was a problem hiding this comment.
팀의 구조와 Project의 중요도에 따라 다르게 생각합니다.
- QA팀이 잘 꾸려져 있고, Production과 staging에 명확하게 차이가 있을때는, QA팀에게 맡기는 편입니다.
- (많은경우)제가 직접 동작하는지 QA환경에서 한번 테스트 해보고 넘깁니다.
그래도 적지 않은 경우 QA에서 피드백을 주는데, production과 dev환경이 달라서 생기는 어려운 문제라ㅜ; - Test automation 할 수 있는 경우에는, QA 테스트시 오류가 확실히 주는 경향이 있는 것 같습니다.
| 2. 최근에 맥킨지에서 개발자의 생산성을 체크할 수 있는 방법을 공개하였고, 이에 대해서 켄트 벡 등의 개발자들이 반대 의견을 내는 글이 많이 화제가 되었습니다. | ||
| 1. 개발자의 생산성을 체크할 수 있다고 생각하시나요? | ||
| 1. 그렇다면, 어떤 항목으로 생산성 체크를 할 수 있다고 생각하시나요? | ||
| 2. 그렇지 않다면, 왜 체크할 수 없다고 생각하시나요? |
There was a problem hiding this comment.
절대적인 의미로 생산성을 측정한다는 것은 어렵지만. 평가를 하는 사람의 입장에서는 어느정도 말이 되는 척도는 있다고 생각합니다.
- 해당 Product이 얼마나 Revenue에 영향을 줬는가?
- 주변의 피드백이 어떠한가? (주변 동료에게 긍정적인 영향을 주는 사람인가?)
- Technical decision을 Leading할 수 있는 사람인가? (설계나 구현한 시스템의 복잡도에 따라서)
하지만 반대급부로, 이 척도에만 맞춰서 일하는 기형적인 사람들도 간혹 있습니다..
고과에 적용되는 일만하고, 아닌 일은 회사에 도움이 되더라도 무시하죠.
|
|
||
| ### 논의할 내용 | ||
|
|
||
| 1. 저는 프로그래밍에는 올바른 해답이 없다 라는 말은 오해의 소지가 있다고 생각합니다. 자칫 해답이 없기 때문에 무엇이든 답이 될 수 있다라고 오해할 수 있다고 생각되는데요 저는 특정 상황에 따라서 적절한 해답이 있다고 생각합니다. 그렇기 때문에 그 상황, 맥락을 파악하고 거기에 맞는 적절한 해결책을 고민하고 적용하는 능력이 중요하다고 생각하는데, 다른 분들의 의견도 궁금합니다! |
There was a problem hiding this comment.
태형님의 의견에 공감합니다. 특히 저는 특정 상황에 따라서 적절한 해답이 있다고 생각합니다. 에 더 많은 동의를 표시하고 싶네요.
저는 엔지니어로서 Good enough한 해법을 찾고, 이를 소통하고, 구현하는 능력이 중요한 능력이라고 생각합니다.
(하나만 있는 뉘앙스를 풍기는)올바른 해답을 찾기위해 매몰되는 것 보다, (여러가지 있는)적당히 좋은 해를 찾을 수 있는 능력이 더 중요하지 않나.. 개인적으로 생각합니다. 물론 적당히 좋은 답이 올바른 해답과 가까워지기 위한 노력은 계속 해야한다고 생각합니다.
|
|
||
| ### 논의할 내용 | ||
|
|
||
| 1. 어려운 코드 읽는 방법에 대한 본인 만의 노하우가 있다면 공유해보면 좋을 것 같습니다. |
There was a problem hiding this comment.
-
구현 수준이 높아서 이해하기 어려운 코드
- 코드를 정돈한 다음 ChatGPT에게 물어보기
-
이해하기 어려운 요구사항을 구현한 코드
- 전임자에게 물어보기
저만의 노하우는 없고 그냥 이해될때까지 공부, 디버깅, 요구사항 분석을 합니다.🤣
다른 분들의 노하우가 궁금하네요.
| ### 논의할 내용 | ||
|
|
||
| 1. 내가 작성한 코드의 실제 동작을 QA 과정에서 개발자 본인이 직접 확인하시나요? | ||
| 1. 그렇다면, 어떤 이유로 확인을 하시나요? |
There was a problem hiding this comment.
저희는 따로 QA팀이 있지않아서 제가 다 하네요.
잘 조직된 QA팀이 있다고 해도 시간이 허락된다면 테스트 설계, 구현과정까지는 참여할 것 같습니다.
QA가 Tester는 아니지만 그래도 최소한 저보다는 테스트를 설계하는 능력이 뛰어날 것이기 때문에 테스트 설계 과정을 보면서 배우고 싶네요.
| 2. 최근에 맥킨지에서 개발자의 생산성을 체크할 수 있는 방법을 공개하였고, 이에 대해서 켄트 벡 등의 개발자들이 반대 의견을 내는 글이 많이 화제가 되었습니다. | ||
| 1. 개발자의 생산성을 체크할 수 있다고 생각하시나요? | ||
| 1. 그렇다면, 어떤 항목으로 생산성 체크를 할 수 있다고 생각하시나요? | ||
| 2. 그렇지 않다면, 왜 체크할 수 없다고 생각하시나요? |
There was a problem hiding this comment.
제가 글을 읽으며 우려했던 상황이 2번째 반박 글에서 나오는데요.
서로 자신의 생산성 측정에서 이익을 얻기 위해 생산성에 도움이 되지 않는 일을 하지 않거나, 심하면 다른 사람의 생산성을 망칠 수도 있다고 생각합니다.
그렇다면 온전히 개발자의 생산성을 측정할 수 없을 것 같습니다.
하지만 이것과는 별개로 제 생산성을 측정해보고는 싶네요.🤣
|
|
||
| ### 논의할 내용 | ||
|
|
||
| 1. 저는 프로그래밍에는 올바른 해답이 없다 라는 말은 오해의 소지가 있다고 생각합니다. 자칫 해답이 없기 때문에 무엇이든 답이 될 수 있다라고 오해할 수 있다고 생각되는데요 저는 특정 상황에 따라서 적절한 해답이 있다고 생각합니다. 그렇기 때문에 그 상황, 맥락을 파악하고 거기에 맞는 적절한 해결책을 고민하고 적용하는 능력이 중요하다고 생각하는데, 다른 분들의 의견도 궁금합니다! |
There was a problem hiding this comment.
저는 그 문구를 읽고 공부에는 왕도가 없다.라는 말이 떠올랐습니다.
하지만 공부에도 왕도는 없지만 정도는 있는 것처럼 저도 상황에 맞는 적절한 해답이 있을 것으로 생각합니다.
|
|
||
| ### 논의할 내용 | ||
|
|
||
| 1. 어려운 코드 읽는 방법에 대한 본인 만의 노하우가 있다면 공유해보면 좋을 것 같습니다. |
There was a problem hiding this comment.
저는 대부분 툴 환경에서 동작하는 코드가 많아서 직접 실행해보고 디버깅 해보면서 추적해보는 것 같습니다.
노하우보단 해당 코드를 내가 다시 짠다면 수정할 부분을 생각하며 약간 비관적인 시각으로 읽으면 더 코드 자체에 이해가 올라가는 것 같습니다.
어떻게 보면 제 수준에 맞게 문제를 추상화하는 것 같네요
| 1. 내가 작성한 코드의 실제 동작을 QA 과정에서 개발자 본인이 직접 확인하시나요? | ||
| 1. 그렇다면, 어떤 이유로 확인을 하시나요? |
There was a problem hiding this comment.
개발 과정에선 직접 해보고 테스트 코드를 작성하여 넘깁니다.
팀 회의 때 빌드된 파일을 팀원 전부가 같이 보면서 개발 방향성에 대해서 이야기 할 때 개개인이 QA를 진행합니다.
|
|
||
| ### 논의할 내용 | ||
|
|
||
| 1. 저는 프로그래밍에는 올바른 해답이 없다 라는 말은 오해의 소지가 있다고 생각합니다. 자칫 해답이 없기 때문에 무엇이든 답이 될 수 있다라고 오해할 수 있다고 생각되는데요 저는 특정 상황에 따라서 적절한 해답이 있다고 생각합니다. 그렇기 때문에 그 상황, 맥락을 파악하고 거기에 맞는 적절한 해결책을 고민하고 적용하는 능력이 중요하다고 생각하는데, 다른 분들의 의견도 궁금합니다! |
There was a problem hiding this comment.
저도 "정답은 없지만 좋은 방향은 있다"라고 생각합니다.
| ### 논의할 내용 | ||
|
|
||
| 1. 어려운 코드 읽는 방법에 대한 본인 만의 노하우가 있다면 공유해보면 좋을 것 같습니다. |
There was a problem hiding this comment.
노하우가 없어서 고민 중인 1인입니다. 다른 사람 코드를 읽는 것은 항상 어렵네요.
논의되는 코멘트들을 통해 좋은 팁을 얻어가고 싶습니다!
| 2. 최근에 맥킨지에서 개발자의 생산성을 체크할 수 있는 방법을 공개하였고, 이에 대해서 켄트 벡 등의 개발자들이 반대 의견을 내는 글이 많이 화제가 되었습니다. | ||
| 1. 개발자의 생산성을 체크할 수 있다고 생각하시나요? | ||
| 1. 그렇다면, 어떤 항목으로 생산성 체크를 할 수 있다고 생각하시나요? | ||
| 2. 그렇지 않다면, 왜 체크할 수 없다고 생각하시나요? |
There was a problem hiding this comment.
책의 내용대로라면 측정하기 어렵고, 저도 그 내용에 공감합니다.
프로젝트의 상황이나, 개인의 관점 등 열거하기도 힘든 너무도 많은 고려해야 할 요소들이 있고,
또 그 우선순위에 따라서도 달라질 수 있기 때문에요.
그러나 조직 관리의 측면에서,
조직의 한 구성원의 입장에서서는 모두가 공감할 수 있는 측정 지표가 짠 하고 있었으면 하는 바람입니다.
| ### 논의할 내용 | ||
|
|
||
| 1. 저는 프로그래밍에는 올바른 해답이 없다 라는 말은 오해의 소지가 있다고 생각합니다. 자칫 해답이 없기 때문에 무엇이든 답이 될 수 있다라고 오해할 수 있다고 생각되는데요 저는 특정 상황에 따라서 적절한 해답이 있다고 생각합니다. 그렇기 때문에 그 상황, 맥락을 파악하고 거기에 맞는 적절한 해결책을 고민하고 적용하는 능력이 중요하다고 생각하는데, 다른 분들의 의견도 궁금합니다! |
There was a problem hiding this comment.
저도 태형님 의견에 공감합니다.
결국, 정답은 없더라도 좋은 방향은 있다고 전제하고 접근하고 사고하는 자세가 가장 중요하겠네요!
|
|
||
| ### 논의할 내용 | ||
|
|
||
| 1. 어려운 코드 읽는 방법에 대한 본인 만의 노하우가 있다면 공유해보면 좋을 것 같습니다. |
There was a problem hiding this comment.
너무 이해가 안가면 작성자에게 물어봤습니다. 변수 하나를 계속 따라가는 식으로 보기도 했습니다.
|
|
||
| ### 논의할 내용 | ||
|
|
||
| 1. 저는 프로그래밍에는 올바른 해답이 없다 라는 말은 오해의 소지가 있다고 생각합니다. 자칫 해답이 없기 때문에 무엇이든 답이 될 수 있다라고 오해할 수 있다고 생각되는데요 저는 특정 상황에 따라서 적절한 해답이 있다고 생각합니다. 그렇기 때문에 그 상황, 맥락을 파악하고 거기에 맞는 적절한 해결책을 고민하고 적용하는 능력이 중요하다고 생각하는데, 다른 분들의 의견도 궁금합니다! |
There was a problem hiding this comment.
저도 "프로그래밍의 법칙" 이란 것이 나오지 않는 한, 상황과 맥락에 따른 최선의 답을 찾아야 된다고 생각합니다.
그렇다고 "프로그래밍에 정답은 없다. " 라고 라고 생각하지는 않는게, 꼭 프로그래밍 뿐 아니라 정답이 없는 다른 분야에서도 "보편적인 정답"을 찾기 위해 사람들이 노력한 결과가 그 분야에 긍정적 영향을 미쳤다고 생각하기 때문입니다.
재미있게 읽었습니다~ 저도 마지막에 질문 부분이 생각해볼 거리들이 많았던 것 같아서 각각 의견을 적어보았습니다 😄