진짜 공감하는게 함수랑 주석부분보고, 엥? 이런게 너무 많아서 이게 맞나 싶기도 했습니다. 특히 어느기업은 과제조차 주석자체를 극혐하는 곳도 많고 애초에 클린코드를 넣어버린 곳도 많은데 클린코드에 대한 부분을 명확히 인지하고 쓰는건지 의구심이 들뿐입니다. 그래서 저는 '클린코드'보단 '좋은코드 나쁜코드' 이 책을 더 많이 추천해주는 편입니다. 오히려 구글 엔지니어가 작성하여 직접 경험에 의한 내용이라서 더 좋고 실무에도 적용시킬 내용이 많아서 오히려 이책이 더 좋은거 같네요
저도 처음 개발할 때 저 책읽고 광신도마냥 코딩 했다가 개욕먹었습니다 ㅋㅋㅋ 후에 고수분들이 해놓은 코드를 보면서 배운것을 요약하자면, 명확하게 장점이 더 큰 선택이 있기도 하지만, 작업의 깊이가 깊어질수록 이를 구분하기 점점 어려워진다는 것입니다. 필요성을 명확하게 파악한다면 아키텍쳐를 명확하게 만들어낼 수 있지만, 그 필요성에 불확신이 가미될수록 어떻게 아키텍쳐를 구성해야되는지 구분하기 어려워진다는 것입니다. 따라서 고수분들의 필요성을 파악하고 정의해내는 능력을 우선 배우고 있습니다. 그렇게하면 코드 구조는 각 상황에서 어느정도 최선의 것이 존재한다는 것을 알았습니다.
클린 코드라는 책이 오래됐기도 하고 어느정도 걸러서 들어야 하는건 사실입니다. 그런데 결국 저자가 하고 싶은 말은 코드 그 자체가 의도를 충분히 설명할 수 있어야 한다는 것 같아요. 함수 부분에서 "왔다갔다 하느라 훨씬 읽기 어렵다" 하신 부분도 사실 원래 의도대로라면 왔다갔다 할 필요가 없죠. "왔다갔다" 하지 않아도 뭘 하는지 알 수 있도록 함수 이름을 지으라는 뜻이니까.
경력이 쌓이고 그 과정속에서 여러 프로젝트를 개발하다보면 본인만의 개발 철학이 생기는거 같아요. 저도 신입때는 함수의 파라미터들을 객체로 감싸서 넘길지 말지, 프로젝트 폴더구조를 어떻게 해야할지 등.. 그러다보니 기능구현을 하기도 전에 지쳐버리는 경우가 있었어요. 너무 체력을 소모하는거 같아 이 버릇을 고치려고 노력했던 기억이 나네요 나름 클린하게 리팩토링 해놓은 플젝 레포지토리를 몇년뒤 다시봤을때 내가 왜 이렇게 피곤하게 해놨을까 했던 기억도 나네요 ㅋㅋ
중복에 대한 얘기는, 같은 저자가 쓴 클린 아키텍처 책을 보시면 알겠지만, 마틴님도 영상에 나온 예시와 같은 경우는 코드를 다 분리해서 쓰는게 좋다고 말합니다. 애초에 유스케이스를 제대로 분리하지 못해서 생긴 '가짜 중복'이라며, "중복은 없어야돼!"라는 강박때문에 함정에 빠져선 안된다고 저자도 얘기하더라구요.
저희 학원 쌤은 딱 이 정도 강요합니다. 1. 코드를 더 함축적으로 쓸 수 있는거 아니면 풀어 짜라. 2. 주석 없애고 싶으면 야근은 각오해라. 3. 변수명은 기존 팀원들 코드를 둘러보고 알잘딱 따라가라. 그게 시간 단축이다. 4. 이동이 3회 이상 벌어지는 코드는 재활용 하지 말고 그냥 새로 써라.
실무자 입장에서 특정 책에 대한 맹신을 경계하게 하는 아주 좋은 영상 같습니다. 거의 전적으로 동의합니다! Clean code는 개념도 그렇고, 저 책의 출간 목적도 그렇고, 결국은 "나랑 전혀 관계없던 사람"이 와서 봤을 때도 내 코딩 의도가 완전히 전달되어야 한다는 게 지상목표이고, 이런저런 '팁'은 전부 그걸 달성하기 위한 수단 중 하나에 불과하지요. 극단적으로 얘기했을 때 우리 팀 전원이 어느 날 갑자기 해고되거나 비행기사고로 몰살당하거나 해도 프로젝트가 계속될 수 있어야 합니다. 그 목표를 위해서 때로 다양한 기능을 한 클래스에 몰아넣거나, 주석에 약간 구질구질한 설명을 넣거나 하는 일이 필요하다면, 그렇게 하는 게 더 우선되어야 하는 거죠.
주석 부분이 이상한 이유에 대해 생각해봤는데 언어적 차이도 있는 거 같아요 영어가 모국어인 사람들은 그냥 코드만 읽어도 어느 정도 순식간에 이해할 수 있으니까요 근데 한국인들은 아무리 영어를 잘한다고 해도 미세한 속도 면에서 한국어 주석으로 읽을 때 코드를 더 빨리 이해할 수 있더군요
모든 일이 그렇듯이 책 하나만 읽고 맹종하는게 문제. 비슷한 예로 디자인패턴 배웠다고 모든걸 디자인패턴으로 만드려고 하는 사람들이 있음. 나도 그랬거든ㅋㅋ 취미로 프로그래밍하는 초보라서 업계에서는 어떻게 하는지 모르겠지만 적어도 나한테는 클린 코드는 유용했음. 개인적으론 주석은 별로 안좋아하는데, 쓰면 안된다는 정도는 아니지만 코드는 주석없이 이해할 수 있게 작성하는게 자신과 다른 사람들을 위해 좋은 것 같음. 물론 개인적인 의견임. 옛날에 작성한 코드 주석 적은거 봐도 솔직히 도움 안되던데ㅋㅋ 코드 협업하는게 참 어렵다는걸 이것만 봐도 알겠는게, 코드는 자기 철학이 들어가기 마련임. 다른 사람 사소한 띄어쓰기까지 거슬린다ㅋㅋ 코딩을 업으로 하는 사람들은 당연히 여러 책을 읽어야겠지만, 취미로 하는 사람에게는 이 책을 기준으로 삼아도 나쁘지 않음. 어차피 나중에 코드 개판인건 마찬가지라ㅎㅎ 여기서 좀 더 깊이 들어가는 사람은 다른 책도 읽어보는거고, 그거 아니면 그냥 그 개판 자체를 즐기는 거고. 동영상은 비판하고 있긴 하지만, 개인적으론 책 읽으면서 함수 이름 짓는거, 매개변수 개수 정하는거 도움 많이 받았음. 아 그리고 번역서는 내용이 약간 이상해서 원서 읽는걸 추천.
코드의 중복 제거 여부는 명확한 기준이 있다고 생각해요. 중복된 코드가 논리적으로 같은 의미이고 둘중 하나가 바뀌었을 때 다른 하나도 같이 바뀌어야 한다면 무조건 함수로 빼야합니다. 변경을 누락하는 실수를 방지할 수 있기 때문이죠. 하지만 중복 코드간 구현이 같더라도 논리적인 의미가 다르면 함수로 추출해선 안 됩니다. 한 부분의 수정이 다른 부분에 의도치 않은 사이드 이펙트를 줄 수 있기 때문이에요. 좋은 영상 감사합니당 굿
코드의 중복이 아니라 논리의 중복이죠 사실 ㅎㅎ 예를 들어 세금 10% 계산로직과 팁 10% 계산로직이 우연히 같다고 해서 하나의 함수로 빼버리는 순간 지옥이 시작되는거죠. 팁이 5%로 바뀐순간 세금이 바뀌는 버그가 생기고, 이걸 해결하겠다고 세금/팁 타입을 넣고 분기를 넣기 시작하면 만든사람만 아는 레거시가 되는거죠 ㅋㅋ 이땐 코드가 아니라 한걸음 물러서서 추상화된 개념을 생각해야 하고 그냥 분리해야합니다. 코드만 보고 단순하게 리팩터링하면 걸리기 쉬운 함정입니다 ㅎㅎ
함수를 가볍게 짧게 만드는 것은 메서드명을 통해서 가독성을 개선하는 것에 있는데요. 일일이 한줄 한줄 다 읽어가지 않아도 어떤 내용인지 직관적으로 파악함에 있어요. 책으로 치면 목차같은 느낌으로... depth가 너무 깊어지는 것도 가독성에 방해가 되니 적절하게 나누는 게 짬바이브 아닐까요?
이런 사소한 이유로 코드의 가독성은 달라집니다. 팀의 룰을 따르세요. 그게 답입니다. 가끔씩 프로그램 팀이 아니라 업무 연관이 있는다른 팀 때문에 어쩔수 없이 하드코딩을 해야 하는 경우도 있습니다. 결국 코드를 최종적으로 승인 하는건 팀 그리고 팀장이므로. 왜 그렇게 짰는지 이유만 설명하고 그게 합리적이면 되는 겁니다.
@@georgestokes4728 그냥 팀 방침 따르는게 대부분은 맞지 않나 싶은... 따지고 보면 팀 방침도 결국 협업 효율성을 위한거니... 근데 저는 {} 내려쓰는거 읽는거나 그렇게 쓰는거나 불편해서 원.. 스코프 시작점이 어떤 파트에서 시작되었는지 그게 함수인지 조건문인지 판단하는게 그쪽이 더 편해서.. 어차피 2중 3중 중첩되면 읽기 ㅈ같은건 똑같으니
오.....제가 개발 하면서 개인적으로 철학화 시킨 사항들과 다 일치하네요. 대표적으로 코드 복붙 3개 정도 까지는 허용하는게 나중에 어떻게 서로 다르게 커스텀이 들어갈지 알 수 없는 경우 동일 코드로 두는 점이랑 구체적인 필요나 구조화 아이디어가 생기기 전 까지는 일단 하나에 때려넣는거랑 주석부분도 그렇군요. 주석은 생략하게 되는 경우가 많기는 하지만.......
진짜 맞는말인게 유독 하나만 읽고 그걸 맹신하는 사람들이 많음.. 읽으면서 무조건 받아들이지말고 비판적인 시각을 유지해야하는데.. 자기가 실력이 없다면 관련 서적을 읽으면서 잘은 모르겠지만 이 부분은 대체 왜 이렇게 해야하는거지 하면서 다른 관련 문서들도 찾아봐야하는데 그냥 유명한 책에서 맞다고하니까 의심없이 받아들이는 그런
1:07 함수로 감싸놓음으로서 동작이 의도하는바가 뭔지 알기쉽고 동작들을 구분하기 쉬움 문제 생긴곳 파악도 쉬움 1:51 주석의설명과 코드의 실제작동방식이 일치하는것은 보장할 수 없음 좋은 코멘트의 예시들은 괜찮지만 실제코드의 작동방식이나 사이드이펙트에대한 주석은 지양하는게 좋음 차라리 변수명이나 함수명을 잘지어서 코드에 들어나게하는게 정답임 3:11 길고복잡한 변수명과 함수명은 하나가 너무큰역할을 하기때문임 분리해서 쪼개야함 4:15 공통된 부분을 우선묶는게 좋음 . 후에 if나 switch문 같은걸로 쪼개는게 아니라 각동작을하는 함수를 만들어서 공통된함수를 사용하도록 래핑하면됨 주의해야할건 문맥상 완전 다른 위치에서 완전 다른의도로 운이좋아서 닮은 코드가 있는데 이건 구분을잘해서 따로둬야함
