chapter 1 to 3 #6
Conversation
| 논의내용) | ||
| 좋은 코드, 깨끗한 코드를 위해 노력한 것이 있다면 무엇이 있을까? | ||
|
|
||
| 내 생각에는 | ||
| 잘못된 걸 알면서도 나중에 해야지 하는 마음과 | ||
| 지금 당장 조금 고치면 좋은데, 하기 싫다는 마음가짐 | ||
| 그리고 그런 마음을 가지게 하는 요인으로 | ||
| 언제 까지 구현을 완료해야 한다는 일정의 압박 그리고 핑계 정도가 있을 것 같다. | ||
|
|
||
| 그렇지 않으려면? | ||
|
|
||
| 생각을 조금 더 많이하고 정리를 해본 후에 작은 단위의 작업으로 바라보고 | ||
| 코드를 집중해서 작성한다. | ||
| 그리고 잠깐 스스로 코드 리뷰를 해본다. | ||
| 고쳐야 할 게 생기면 바로 고친다. | ||
| 그리고 실제 동작하는 지는 실행해서 판단하는게 아니라 | ||
| 유닛 테스트 코드를 짜면서 판단한다. | ||
| 모든 테스트가 통과되고 | ||
| commit 이전에 한번 더 file changes 목록과 코드를 또 검토 한다. | ||
|
|
||
| 이정도 하면 나중에 문제가 생겨도 빠르게 대처가 가능해지는 것 같다. | ||
| ``` |
There was a problem hiding this comment.
네이밍, 함수 크기, 컴포넌트 크기, 반복되는 로직 이런 부분을 신경쓰면서 컴포넌트를 작성했던것 같아요.
잘못된 것이 있으면 일단은 문제 없이 돌아가도록 수정을 하고 청소는 나중에 하는 걸로 넘겼던것 같아요.
일정을 넘기면 안되니깐!
| 지겨워서 빨리 끝내려고 | ||
| 다른 업무기 너무 밀려 후딱 해치우고 밀린 업무로 넘어가려고 | ||
|
|
||
| 우리 모두는 자신이 짠 `쓰레기` 코드를 쳐다보며 나중에 손보겠다고 생각한다. |
| 제품 출시 주기가 늘어짐 -> 이전 버전의 버그가 그대로 남아 있음 -> 프로그램이 느리고 죽는 횟수가 늘어남 -> 회사 망함 | ||
|
|
||
| 회사가 망한 이유? 출시에 바빠 코드를 마구 짬 |
| 팀에서 이제 재설계를 해야 한다는 요구가 생긴다 | ||
| 새로운 타이거 팀이 구성되고 새롭게 시스템 구축을 하면서 기존 시스템의 기능을 제공한다. | ||
| 기존 팀과 타이거팀의 경주가 시작되지만 경주는 오래 이어진다. | ||
| 새 시스템이 기존 시스템을 따라잡을 즈음이면 초창기 타이거 팀의 팀원은 모두 떠나있고 | ||
| 새 팀원이 또 새로운 시스템을 설계하자고 나선다. => 악순환의 반복 |
| 나쁜 코드로 바뀌는 온갖 이유는 많다. | ||
| 요구사항의 변경, 일정 촉박. | ||
| 멍청한 관리자, 조급한 고객, 쓸모 없는 마케팅 부서 등등 | ||
|
|
||
| 하지만 프로그래머가 전문가 답지 못했다는 걸 인정해야 한다. |
There was a problem hiding this comment.
전문가답게라면 안되는 것은 거부하고 싸워야 한다고 클린코더에서 읽었던 같은 느낌입니다.
| > 캠프장은 처음 왔을 때보다 더 깨끗하게 해놓고 떠나라. | ||
|
|
||
| 한꺼번에 많은 시간과 노력을 투자해 코드를 정리할 필요가 없다. | ||
| 변수 이름 하나를 개선하고, 조금 긴 함수 하나를 분할하고, 약간의 중복을 제거하고, 복잡한 if문 하나를 정리하면 충분하다. |
There was a problem hiding this comment.
한번에 많은 것을 수정하고 변경하고 테스트해서 시간이 많이 필요하게 되는 건가봐여
조금씩 하나라도 자주 개선 하는게 중요하다고 느꼈습니다.
| 의미 있는 이름을 짓기 위해서 나중에 이름을 바꿔봤는지 | ||
| 그리고 다른 사람이 작성한 코드의 이름이 잘못되서 바꿔본 적이 있는지 생각해 보면 좋을 것 같다. |
There was a problem hiding this comment.
있었습니다.
처음에 빠르게 작성할 때 가끔 이름을 짓기 위해서 시간을 사용하지 않고
우선 함수를 작성하고 이름을 변경하기도 합니다.
리뷰를 하면서 함수 이름과 함수 결과가 다른 경우가 있었어요.
| 사용하는 언어가 java라면 의심의 여지 없이 찬성 의견인데 | ||
| 아직도 I 접두어를 쓰는 C++과 C# 이라면 논란의 여지는 있을 것으로 보인다. |
There was a problem hiding this comment.
타입스크립트에서 인터페이스 이름을 지을 때 preifx로 I를 예전에는 사용을 많이 했었나봐요.
그래서 I를 사용하지 말라는 가이드를 본 적이 있습니당
| Microsoft의 규칙을 설명하는게 덜 귀찮다는(far less hassle) 대답에 동의하는 편이다. | ||
| 아니 많이 동의한다. | ||
|
|
||
| https://softwareengineering.stackexchange.com/questions/117348/should-interface-names-begin-with-an-i-prefix |
There was a problem hiding this comment.
남겨주신 페이지를 보고 띠용 했습니다.
사용하면 안되는구나 하고 당연하게 생각하고 생각을 멈췄는데.
당연하다고 생각한 질문에 많은 사람이 토론을 하고 의견이 달리는 것을 보니
왜라는 생각을 언제부터 하지 않고 있는 제 모습을 보았습니다. 🤕
| 남들이 이해하는 코드를 짠다는 건 상당히 중요하고 | ||
| 많이 동의하는 내용이다. | ||
|
|
||
| 가장 최악은 | ||
| 자신이 짠 코드를 이해 못하고 설명을 못하는 프로그래머일 것이다. |
왠지 클린 코더의 디테일한 버전을 보는 듯한 기분