함수를 가볍게 짧게 만드는 것은 메서드명을 통해서 가독성을 개선하는 것에 있는데요. 일일이 한줄 한줄 다 읽어가지 않아도 어떤 내용인지 직관적으로 파악함에 있어요. 책으로 치면 목차같은 느낌으로... depth가 너무 깊어지는 것도 가독성에 방해가 되니 적절하게 나누는 게 짬바이브 아닐까요?
ㅋㅋㅋ 이번 영상은 클린코드라는 책의 문제점을 정확하게 지적해 주셨네요. 특히 함수 부분 너무 시원합니다. 쭉 한 번 보면 그냥 알 수 있음에도 불구하고 함수를 무조건 나누려는 인간들이 있어요. 정말 광신도들은 답이 없어요. 더 한심한 건 너무 많아진 함수들이 관리되지 않아서 같은 기능의 함수들을 또 만드는 미친 인간도 있더군요. 환장합니다.
@@silver33412님이 그렇다고 말하는 것은 절대 아님을 미리 말하고요. 진짜 잘 하는 사람들도 해당 안 됩니다. 가장 큰 문제는 실력도 없는 사람들이 광신도처럼 맹신을 하는 바람에 현업에 방해가 되는 경우가 엄청 많다는 거죠. tdd도 마찬가지. 맹신을 하면 절대 안 되고 상황에 따라 내가 활용한다는 생각으로 접근을 해야 하는데 아무 생각없이 함수를 다 나눠서 나중에 자신이 그 함수들을 관리 못 하고 또 똑같은 함수들을 만들기도 하더군요. 나중엔 마땅한 함수명 고르는데도 시간 낭비... 이 영상도 그런 부분이 지나침을 말하는 거죠. 병적으로 함수를 나누려고 하지 마라...
하나의 메소드만 ㅋㅋㅋㅋ 이 부분에 제 생각을 추가 해 본다면 공통 기능을 뽑아 쓴다고 할때 확장성이나 특수성을 고려 해야 하는게 더 중요할 것 같고 이는 곳 자신이 개발하는 서비스에 대한 이해도가 높아야 알 수 있는 부분이라고 봅니다. 코드를 잘 짜는 것도 물론 중요하지만 개발은 그 외에도 확장해서 생각해야 될 부분이라고 생각합니다.
뭔가 초보가 짠듯한 느낌의 코드인데 딱히 문제는 없고 물흐르듯 읽혀지면 그게 정말 좋은 코드 입니다. 괜히 복잡하게 있어보이게 중첩에 중첩에 추상화에 캡슐화에 최신 패턴 접목하면...그거 누가 봅니까?...자기만 볼려는거 아니면... 같이 일하는 사람 모두가 쉽게 쉽게 읽고 고칠 수 있어야 합니다.
모든 일이 그렇듯이 책 하나만 읽고 맹종하는게 문제. 비슷한 예로 디자인패턴 배웠다고 모든걸 디자인패턴으로 만드려고 하는 사람들이 있음. 나도 그랬거든ㅋㅋ 취미로 프로그래밍하는 초보라서 업계에서는 어떻게 하는지 모르겠지만 적어도 나한테는 클린 코드는 유용했음. 개인적으론 주석은 별로 안좋아하는데, 쓰면 안된다는 정도는 아니지만 코드는 주석없이 이해할 수 있게 작성하는게 자신과 다른 사람들을 위해 좋은 것 같음. 물론 개인적인 의견임. 옛날에 작성한 코드 주석 적은거 봐도 솔직히 도움 안되던데ㅋㅋ 코드 협업하는게 참 어렵다는걸 이것만 봐도 알겠는게, 코드는 자기 철학이 들어가기 마련임. 다른 사람 사소한 띄어쓰기까지 거슬린다ㅋㅋ 코딩을 업으로 하는 사람들은 당연히 여러 책을 읽어야겠지만, 취미로 하는 사람에게는 이 책을 기준으로 삼아도 나쁘지 않음. 어차피 나중에 코드 개판인건 마찬가지라ㅎㅎ 여기서 좀 더 깊이 들어가는 사람은 다른 책도 읽어보는거고, 그거 아니면 그냥 그 개판 자체를 즐기는 거고. 동영상은 비판하고 있긴 하지만, 개인적으론 책 읽으면서 함수 이름 짓는거, 매개변수 개수 정하는거 도움 많이 받았음. 아 그리고 번역서는 내용이 약간 이상해서 원서 읽는걸 추천.
이 영상이 한 달전에 나왔더라면 더 좋았을정도로 책과는 별개로 배운 게 많습니다 ㅠㅠ 특히 후반부에 나오는 중복코딩 몇 개 나온다고 나누는 부분에서 뼈져리게 느꼈습니다.. 최근 대학 팀플 과제 중 코드가 3~4개 중복되다보니 이걸 나눠야되겠지? 하는 생각에 나누고보니 진짜 영상에서 말한 것처럼 A에는 이게 필요한데 B에는 저것만 필요하고 하다보니 switch, if 문 등으로 오히려 더러워지더라구요.. 그쯤되니 머리론 아 이거 진짜 아닌 거 같은데.. 이게 진짜 효율적인게 맞나? 오히려 효율을 찾다가 비효율에 더러워진 것 같다 란 생각만 들었는데 그게 오늘 영상으로 확신이 되었습니다.. 쓸데없이 반복에 집착하지말고 뭐가 더 좋은지 한 번 더 생각하고 짜겠습니다! 너무 감사합니다 ㅠㅠ
영상 전반적으로 공감하며, 제가 클린코드를 읽던 주니어 때 항상 의문이었던 부분을 잘 짚어주신 것 같습니다. 코드의 반복과 관련해서는 특히 그런데, 동일한 코드가 두 번 내지 세 번 정도 반복되는 것만으로도 리뷰 지적을 받을때가 많았습니다. 타당한 의견이면 수정해야 맞으나, 그 이유는 대체로 "당연히 그래야 한다" 였던 것 같아요. 동일한 코드라도 함수 단위로 묶을 "가치" 가 있을 때 전 함수로 묶는 편입니다. 결국 재사용성이 얼마나 있는지를 보고 판단하는 거죠. 그런데 처음 개발할 때는 개발한 코드가 얼마나 그러할지는 알기 어렵기에 일단 직관적으로 이해할 수 있도록 적절히 블랭크로 나누어 로직을 코드로 설명하고, 이후 유지보수 단계에서 해당 코드가 여러 군데에서 사용될 법 할 때 비로소 코드를 분리하여 적절한 함수로 정의합니다. 극단적으로는 아예 함수 단위로 나누지 않고 하나의 큰 기능을 하나의 함수 내에서 모두 구현해보는 방법도 취해봅니다. 경우에 따라서 구현을 하면서 아 어느 구간에서 어떻게 역할 분담을 해야하고, 그럼 이렇게 함수와 클래스를 정의해서 파라미터로 넘기면 되겠다 라는게 얼추 보일 때가 있습니다. 그렇게 해서 전체 구조를 잡아갈 때도 있습니다. 다만 사람마다 지향하는 바는 달라서, 영상에서 나온 함수로 막 쪼갰을 때 모습이 직관적인 (제 기준에선 약간 변태적인..) 사람이 있을 수도 있겠습니다. 그래서 전 이런 내용으로는 리뷰를 잘 안하긴 합니다. (개취 존중이랄까요..) 클린코드를 찬양한 적은 없습니다만, 그래도 꽤나 괜찮은 가이드라고 생각했을 때가 있었는데요, 지금은 사실 이런 책 보다는 개발 업무를 하면서 스스로 지향(양) 해야 할 습관을 생각하는 게 더 좋더라구요. 최근에는 업무로 주어지는 리뷰가 아니더라도, 다른 팀원이 짠 코드를 10분 정도 리뷰하는 습관을 가지려고 합니다. 대부분 개발자 분들이 그러하신지는 모르겠습니다만, 전 남의 코드를 보는게 매우 힘들더라구요. (제 능력 부족일 수도 있겠습니다.) 업무 능력과 스킬을 맹목적으로 배우는 것도 중요할 때가 있지만, 업무와 스킬 능력 향상을 위해 스스로 고민해보는 것도 매우 중요한 것 같아요. 그러한 고민에 대한 참고로 영상에 나온 책들이 도움이 될 가능성은 충분히 있습니다. (클린코드도 그 중 하나이지요.)
클린코드를 기본적으로 지향해야 하는건 맞다고 봐요. 거기에 목매서 애초에 클린코드를 하는 목적이 사라지면 안되지만. 솔직히 근데 클린코드는 둘째치고 프로젝트에서 정해놓은 기본적인 컨벤션만 잘 지켜줘도 바랄게 없겠네요. 코드 포맷팅 안하고 작명규칙 자기 맘대로고 그런 사람들 너무 많이 봐서
함수부분은 그 모든 함수를 보라는 뜻이 아니라 추상화 레벨을 맞춰서 그 디테일을 안보게 하는게 목적이라 영상내용에 동의는 크게 안되네요. 모든코드를 보려면 가독성이 떨어져도 추상화된 상위 함수만 본다면 가독성이 올라가죠. 로그인 함수라면 로그인 함수에 모든 디테일을 if문 처리해서 if문 여러개의 의미를 해석하는거 보다는 재사용 하지 않더라도 함수로 나눠서 인증 검증 유저 정보 가져오기 가입 안되어 있으면 회원가입 유도 이런 함수로 나누는게 더 읽기 좋겠죠. 모든 함수의 디테일을 읽을 필요는 없습니다. 우리가 보려는건 이 함수가 무슨 동작을 하느냐이지 함수를 어떻게 구현했는지 정밀검사하려는게 아니니까요
그 부분은 중괄호로 감싸고 주석다는 것으로 해결 할 수 있습니다. - 함수는 하이퍼링크처럼 이 페이지 저 페이지 왔다 갔다 하게 하는 불편한 점을 - 중괄호 치고 IDE에서 접어버리면 문서에서 대,중,소단원 나누는것처럼 접어버릴수 있어요. 함수로 추상화해서 가독성을 챙기는 목적도 해결되고 함수 호출에 대한 비용도 아끼고 이 함수 저 함수 넘나드는 것에 대한 불편함도 해결되더라고요. 추가적으로 함수로 추출했으면 이 함수는 재사용이 될 것이다라는 명확한 기준이 생겨서도 좋구요.
효율성을 추구하는 언어인 프로그램 언어가 제 아무리 뛰어나도 작성의도를 실사용 언어인 주석만큼 잘 설명할 수 없죠 뛰어난 코드 작성자, 척하면 척하고 알아듣는 해독자, 중의적이거나 모호하지 않은 코드문법 이것들이 전부 갖춰진다고 하더라도 내 의도를 말로 설명하는것보다 정확하지 못할텐데 하물며 저것들이 다 갖춰지는 경우도 별로 없을테니까요 애초에 매우 뛰어난 사람이라고 해도 집단지성만큼 우수하지 않을거라 특정 사람이 쓴 책이 바이블이 되는건 문제라고 봅니다 수학정석이나 성문영어 이런게 바이블처럼 팔리는것도 참 별로였어요
어쩌다보니 학부때부터 야매로 코딩하다 책을 0권만 보고 졸업후 인턴생활하면서 어쩌다보니 비즈니스 로직 최상단에 있는 모듈을 만들어 버렸는데... 세상에서 가장 큰 교훈들을 얻었습니다. "깔끔하게 짤려 하지 말라, 어짜피 계획대로 흘러가질 못하는것이 개발이다." "내가 설계한 인터페이스는 실개발에선 리소스만 처먹는 돼지다." "너에게 어떤 계획이 있었던지간에 우리는 실제 도입시에 문서와 다르게 행동할것이다."
함수를 짧게 많이 쓰면 함수를 호출할때 소요되는 시간이 점점 쌓여서 성능에 큰 영향을 줄 수 있습니다. 연산보다 함수 호출로인한 오버헤드가 커지는 것이죠. 적당히 씁시다. inline 함수를 자동으로 만들어줘서 상관 없긴한데 습관화 되ㅣ면 큰일납니다. 정신차려요 !!!!!
왜 저렇게 까지 쪼개야하는가는 얼마나 많은 사람이 이 소스에 간섭할 것인가에 따라 달라집니다. 몇 명의 인원에서 application 전체를 개발/유지보수 하는 집단에서는 솔직히 날코딩과 주석이 좋죠. 라고 말을 맺기엔 요즘 AI라는 놈이 생겼죠. 이 녀석은 파편화된 소스를 떠먹이고 최적화시키면 더 잘합니다. 명세서 먹이고 코드 먹이고 수정시켜보세요. ㅎㅎㅎ 이 작업은 소스를 쪼개기 쉬울 수록 시키기 좋습니다. I/O와 사용된 이론 얘기하고 기본 소스 만들게 시키고 소스 리팩토링시키면 기본 작업틀 나옵니다. 테스트 코드도 만들라고 하면 만듭니다. 물론 실수가 적지 않으므로 반드시 검토 필수이긴 한데, 신뢰도 낮은 직원에게 주는 준비시간 + 검토시간보다 적게 걸립니다. 나중엔 이 작업도 필요없어질 것 같긴 합니다만 ㅎㅎㅎㅎ 그리고 주석 중심의 코드 설명은 코드 구현 규칙의 임의성이 강화되어 위험하다고 봅니다. 특히, 사람 손을 많이 탈 수록. 그래서 복잡하고 변화가 많은 코드일수록, 라인에 대한 설명이 아닌 함수 단위의 주석이 더 적절하게 된다 봅니다. 짧게 쓰려고 하다 보니 맥락이 이상한데, 한 줄 요약하면 TDD가 최고이나 이게 안되면 현행이 최고.
그건 클린코드의 방침보다 그 사람의 실력이 문제일지도... 결국 거기서 말하는거도 장황하게 가는거보다 적은 단서로도 많은 의미를 간결하게 전할수 있는 방향으로 코드 짜는방법을 말하는거라서.. 근데 그거랑 별개로 가독성과 코드길이 둘다 던져버리고 돌아만 가면 ㅇㅋ식으로 짜는 인간들도 ㅈㄴ 많으니 문제..
다른부분은 공감하고 함수 부분이나 주석은 공감이가지 않습니다. 클린코드에서 함수는 한가지역할을 하라는건 세부 함수를 읽지않아도 될정도로 추상화수준을 최대한 잘게 쪼개고 맞추라는 것을 의미하는 거여서 1:15 의 오른쪽이 가독성이 떨어진다는 말에는 동의살수없습니다. 왼쪽의 코드에 if else block이 추가되어도 오른쪽보다 더 가독성이 좋을까요? 코멘트도 코멘트는 유지보수가 되지않기때문에 최대한 쓰지않는게 좋은거같아서 동의가되지않습니다. (물론 javadoc같은건 당연히 써야하고요)
저는 코딩규칙 언리얼 문서에있는게 좋은거같아요 예시로 자체적으로 설명이 되는 코드를 작성하세요: // Bad: t = s + l - b; // 좋아요: TotalLeaves = SmallLeaves + LargeLeaves - SmallAndLargeLeaves; 함수 호출에서 익명 리터럴 사용은 피하세요. 네임드 상수로 의미를 설명하는 것이 좋습니다. // 옛 스타일 Trigger(TEXT("Soldier"), 5, true);. // 새 스타일 const FName ObjectName = TEXT("Soldier"); const float CooldownInSeconds = 5; const bool bVulnerableDuringCooldown = true; Trigger(ObjectName, CooldownInSeconds, bVulnerableDuringCooldown); 함수 선언을 조회하지 않고도 이해할 수 있어 일반적인 독자에게 의도가 더욱 명확해 집니다. 이런거 알려줌
이런 사소한 이유로 코드의 가독성은 달라집니다. 팀의 룰을 따르세요. 그게 답입니다. 가끔씩 프로그램 팀이 아니라 업무 연관이 있는다른 팀 때문에 어쩔수 없이 하드코딩을 해야 하는 경우도 있습니다. 결국 코드를 최종적으로 승인 하는건 팀 그리고 팀장이므로. 왜 그렇게 짰는지 이유만 설명하고 그게 합리적이면 되는 겁니다.
@@georgestokes4728 그냥 팀 방침 따르는게 대부분은 맞지 않나 싶은... 따지고 보면 팀 방침도 결국 협업 효율성을 위한거니... 근데 저는 {} 내려쓰는거 읽는거나 그렇게 쓰는거나 불편해서 원.. 스코프 시작점이 어떤 파트에서 시작되었는지 그게 함수인지 조건문인지 판단하는게 그쪽이 더 편해서.. 어차피 2중 3중 중첩되면 읽기 ㅈ같은건 똑같으니
진짜 공감하는게 함수랑 주석부분보고, 엥? 이런게 너무 많아서 이게 맞나 싶기도 했습니다. 특히 어느기업은 과제조차 주석자체를 극혐하는 곳도 많고 애초에 클린코드를 넣어버린 곳도 많은데 클린코드에 대한 부분을 명확히 인지하고 쓰는건지 의구심이 들뿐입니다. 그래서 저는 '클린코드'보단 '좋은코드 나쁜코드' 이 책을 더 많이 추천해주는 편입니다. 오히려 구글 엔지니어가 작성하여 직접 경험에 의한 내용이라서 더 좋고 실무에도 적용시킬 내용이 많아서 오히려 이책이 더 좋은거 같네요
저도 처음 개발할 때 저 책읽고 광신도마냥 코딩 했다가 개욕먹었습니다 ㅋㅋㅋ 후에 고수분들이 해놓은 코드를 보면서 배운것을 요약하자면, 명확하게 장점이 더 큰 선택이 있기도 하지만, 작업의 깊이가 깊어질수록 이를 구분하기 점점 어려워진다는 것입니다. 필요성을 명확하게 파악한다면 아키텍쳐를 명확하게 만들어낼 수 있지만, 그 필요성에 불확신이 가미될수록 어떻게 아키텍쳐를 구성해야되는지 구분하기 어려워진다는 것입니다. 따라서 고수분들의 필요성을 파악하고 정의해내는 능력을 우선 배우고 있습니다. 그렇게하면 코드 구조는 각 상황에서 어느정도 최선의 것이 존재한다는 것을 알았습니다.
경력이 쌓이고 그 과정속에서 여러 프로젝트를 개발하다보면 본인만의 개발 철학이 생기는거 같아요. 저도 신입때는 함수의 파라미터들을 객체로 감싸서 넘길지 말지, 프로젝트 폴더구조를 어떻게 해야할지 등.. 그러다보니 기능구현을 하기도 전에 지쳐버리는 경우가 있었어요. 너무 체력을 소모하는거 같아 이 버릇을 고치려고 노력했던 기억이 나네요 나름 클린하게 리팩토링 해놓은 플젝 레포지토리를 몇년뒤 다시봤을때 내가 왜 이렇게 피곤하게 해놨을까 했던 기억도 나네요 ㅋㅋ
클린 코드라는 책이 오래됐기도 하고 어느정도 걸러서 들어야 하는건 사실입니다. 그런데 결국 저자가 하고 싶은 말은 코드 그 자체가 의도를 충분히 설명할 수 있어야 한다는 것 같아요. 함수 부분에서 "왔다갔다 하느라 훨씬 읽기 어렵다" 하신 부분도 사실 원래 의도대로라면 왔다갔다 할 필요가 없죠. "왔다갔다" 하지 않아도 뭘 하는지 알 수 있도록 함수 이름을 지으라는 뜻이니까.
중복에 대한 얘기는, 같은 저자가 쓴 클린 아키텍처 책을 보시면 알겠지만, 마틴님도 영상에 나온 예시와 같은 경우는 코드를 다 분리해서 쓰는게 좋다고 말합니다. 애초에 유스케이스를 제대로 분리하지 못해서 생긴 '가짜 중복'이라며, "중복은 없어야돼!"라는 강박때문에 함정에 빠져선 안된다고 저자도 얘기하더라구요.
코딩애플 유튜브채널 하나만 보면 코딩 잘 할 수 있음
코딩이아니라 어그로 잘끌 수 있음
개추 ㅋㅋ
개추
나 코딩애플인데 개추눌렀다
엄준식 잘할 수 있음
"주석이 거짓말을 한다" 라는 건 경험적으로 봤을때, 코드만 고치고 주석은 고치지 않은 사람들 때문이죠.
그러면 코드와 주석이 내용이 다르게 되고 주석이 거짓말을 하는 상황이 됩니다.
주석이 나쁜게 아닙니다.
코드를 고치고 주석은 고치지 않는 사람이 나쁜 거죠.
대부분은 주석만 안고치게 됩니다..... 주석을 달더라도 문단 제목을 달듯 간략한 코드 흐름정도만 표현하는게 낫다고 봅니다
클린코드 제대로 안보셨네요. 그 안고치는 사람이 주석을 지양하는 이유 중 하나로 설명합니다...쩝...
덧붙여 주석 지양은 클린코드책과 별개로 원래 대부분의 it업계서 하던 말입니다.
왜 이걸 책한권만 읽고 모든걸 판단한다고 호도해버리는지 모르겠네요
이제 유지보수하기 어렵게 코딩하는방법만
읽으면 완벽하군요
인수인계자를 ㅅㅏㄹ...
1:19 왔다갔다하는게 아니라 함수 이름으로 읽고 그런 일을 하는구나하고 자세히 분석하지 않고 그냥 넘어가면 됩니다. 잘 짜져 있는 코드라면 그렇게 하면 됩니다. 왔다갔다하라고 저렇게 하는거 아니에요. 주석처럼 함수 이름 만드는거에요
주석이 거짓말을 하는 경우 -> 먼저 써놓고 나중에 코드를 수정했는데, 까먹거나 귀찮아서 주석을 수정 안했음
중복 코드 허용은 진짜 맞는 말임
전혀 다른 기능에서 당장 똑같이 생긴거 있다고 함수로 묶은다음에 미묘하게 달라지면 if문 난사하게댐
기능이 다르면 각자 써야함 나중에 코드최적화 할때 판단해도 늦지 않음
코드의 의도를 분명하게 담아내는 주석 작성방법만 익혀도 이사람 배려할 줄 아는 사람이구나 느낄수 있어요, 괜히 시니어들이 주석 활용 잘하는게 아님
기본적으로 영어를 잘해야 네이밍을 잘하고,
네이밍을 잘해야 주석도 없앨 수 있는 거죠.
네이밍 잘하고 펑셔널 프로그래밍 잘하면
굳이 함수의 속까지 매번 뜯어볼 필요 없이 잘 읽히는 코드 되는 거고.
편집과 설명 ..... ..우리 여고생님 짱이야
3:04 전설의 Quake 3 inverse square root...
f(x)=1/sqrt(x)를 나누기 혹은 루트 연산 "없이" 비트쉬프트만으로 계산하는 미친 함수죠
함수를 가볍게 짧게 만드는 것은 메서드명을 통해서 가독성을 개선하는 것에 있는데요.
일일이 한줄 한줄 다 읽어가지 않아도 어떤 내용인지 직관적으로 파악함에 있어요.
책으로 치면 목차같은 느낌으로... depth가 너무 깊어지는 것도 가독성에 방해가 되니 적절하게 나누는 게 짬바이브 아닐까요?
함수 남발한 코드 보면 토 쏠려요..
함수 소스 찾아가다가 어 내가 왜 여기까지 왔지?? 합니다
제가 클린 코드 작성하면서 정말 느낀 부분들이네요. 코드 피드백 주고받으면서 제가 느끼기에는 주석이 있는게 훨씬 가독성이 좋아지는데 이걸 구지 없애고, 하나의 기능만 담아야 된다면서 엄청 나누는데 결국 가독성은 가져다 버리는... 잘 보고 갑니다
ㅋㅋㅋ 이번 영상은 클린코드라는 책의 문제점을 정확하게 지적해 주셨네요. 특히 함수 부분 너무 시원합니다. 쭉 한 번 보면 그냥 알 수 있음에도 불구하고 함수를 무조건 나누려는 인간들이 있어요. 정말 광신도들은 답이 없어요. 더 한심한 건 너무 많아진 함수들이 관리되지 않아서 같은 기능의 함수들을 또 만드는 미친 인간도 있더군요. 환장합니다.
그건 잘못 이해한 사례인데
@@silver33412님이 그렇다고 말하는 것은 절대 아님을 미리 말하고요. 진짜 잘 하는 사람들도 해당 안 됩니다. 가장 큰 문제는 실력도 없는 사람들이 광신도처럼 맹신을 하는 바람에 현업에 방해가 되는 경우가 엄청 많다는 거죠. tdd도 마찬가지. 맹신을 하면 절대 안 되고 상황에 따라 내가 활용한다는 생각으로 접근을 해야 하는데 아무 생각없이 함수를 다 나눠서 나중에 자신이 그 함수들을 관리 못 하고 또 똑같은 함수들을 만들기도 하더군요. 나중엔 마땅한 함수명 고르는데도 시간 낭비... 이 영상도 그런 부분이 지나침을 말하는 거죠. 병적으로 함수를 나누려고 하지 마라...
@@심심하다능-r6w 뭔 말인지 모르겠는데 난 그냥 그 광신도 들이 잘못 이해한 사례라고 말하는건데 오해한듯?
@@silver33412 ㅋㅋㅋ 그렇군요 나의 실수.. 그리고 님 말씀이 맞죠. 제대로 이해를 못하고 맹신한 결과죠.
오늘, 내 세상이 무너졌다
클린코드 보면 20자 이상의 아름은 인지비용이 높아진다고 지양하라고 합니다. 3:10 쯤 나오는 예시는 부적절한 것 같네요.
이제 너 코딩애플 유튜브안봤어? 클린코드 책 쓰레기야라는 사람도 등장하겠네요😂
1:13
JetBrains의 AI Assistant에서 리펙토링 시키면 딱 우측거대로 나옵니다 ㅋㅋㅋ
그리고 조용히 창을 닫죠
주석을 달지 않음으로써 나만 알아봄으로 내 가치를 높이라는 깊은 뜻 일리가 없죠
코딩 안하고 모르는데 이영상을 그냥 보고있음
끝까지 다 봤다!!
2:59 이 코드는 봐도봐도 쓴 놈이 미친놈임...
난 코딩애플만 본 개발자다
엄랭으로 취준을 하고 있지
감사합니다ㅠ 늘 고민 했던 부분이였습니다! 함수가 최소한의 기능만 담당하게 하라는데 쪼개면 쪼갤수록 좋은게 맞는건가? 하는 의문을 항상 가졌던거 같아요! 오늘 어느정도 그 궁금증을 해소할 수 있었던거 같습니다! 좋은 영상 감사합니다ㅎㅎ
하나의 메소드만 ㅋㅋㅋㅋ
이 부분에 제 생각을 추가 해 본다면
공통 기능을 뽑아 쓴다고 할때 확장성이나 특수성을 고려 해야 하는게 더 중요할 것 같고
이는 곳 자신이 개발하는 서비스에 대한 이해도가 높아야 알 수 있는 부분이라고 봅니다.
코드를 잘 짜는 것도 물론 중요하지만 개발은 그 외에도 확장해서 생각해야 될 부분이라고 생각합니다.
뭔가 초보가 짠듯한 느낌의 코드인데 딱히 문제는 없고 물흐르듯 읽혀지면 그게 정말 좋은 코드 입니다.
괜히 복잡하게 있어보이게 중첩에 중첩에 추상화에 캡슐화에 최신 패턴 접목하면...그거 누가 봅니까?...자기만 볼려는거 아니면... 같이 일하는 사람 모두가 쉽게 쉽게 읽고 고칠 수 있어야 합니다.
모든 일이 그렇듯이 책 하나만 읽고 맹종하는게 문제. 비슷한 예로 디자인패턴 배웠다고 모든걸 디자인패턴으로 만드려고 하는 사람들이 있음. 나도 그랬거든ㅋㅋ 취미로 프로그래밍하는 초보라서 업계에서는 어떻게 하는지 모르겠지만 적어도 나한테는 클린 코드는 유용했음. 개인적으론 주석은 별로 안좋아하는데, 쓰면 안된다는 정도는 아니지만 코드는 주석없이 이해할 수 있게 작성하는게 자신과 다른 사람들을 위해 좋은 것 같음. 물론 개인적인 의견임. 옛날에 작성한 코드 주석 적은거 봐도 솔직히 도움 안되던데ㅋㅋ 코드 협업하는게 참 어렵다는걸 이것만 봐도 알겠는게, 코드는 자기 철학이 들어가기 마련임. 다른 사람 사소한 띄어쓰기까지 거슬린다ㅋㅋ
코딩을 업으로 하는 사람들은 당연히 여러 책을 읽어야겠지만, 취미로 하는 사람에게는 이 책을 기준으로 삼아도 나쁘지 않음. 어차피 나중에 코드 개판인건 마찬가지라ㅎㅎ 여기서 좀 더 깊이 들어가는 사람은 다른 책도 읽어보는거고, 그거 아니면 그냥 그 개판 자체를 즐기는 거고. 동영상은 비판하고 있긴 하지만, 개인적으론 책 읽으면서 함수 이름 짓는거, 매개변수 개수 정하는거 도움 많이 받았음. 아 그리고 번역서는 내용이 약간 이상해서 원서 읽는걸 추천.
자기 코드를 유지보수 하다보면, 중복 작성해둔 코드가 여기 저기 흩어져 있으니, 이걸 좀 더 실수를 줄이고, 신속하게 수정할 수 없을까 생각이 들 때, 힌트를 얻는 정도로 읽는게 좋은것 같아요
이 영상이 한 달전에 나왔더라면 더 좋았을정도로 책과는 별개로 배운 게 많습니다 ㅠㅠ
특히 후반부에 나오는 중복코딩 몇 개 나온다고 나누는 부분에서 뼈져리게 느꼈습니다..
최근 대학 팀플 과제 중 코드가 3~4개 중복되다보니 이걸 나눠야되겠지? 하는 생각에 나누고보니
진짜 영상에서 말한 것처럼 A에는 이게 필요한데 B에는 저것만 필요하고 하다보니 switch, if 문 등으로 오히려 더러워지더라구요..
그쯤되니 머리론 아 이거 진짜 아닌 거 같은데.. 이게 진짜 효율적인게 맞나? 오히려 효율을 찾다가 비효율에 더러워진 것 같다 란 생각만 들었는데
그게 오늘 영상으로 확신이 되었습니다..
쓸데없이 반복에 집착하지말고 뭐가 더 좋은지 한 번 더 생각하고 짜겠습니다! 너무 감사합니다 ㅠㅠ
"가짜 중복"이었던겁니다
영상 전반적으로 공감하며, 제가 클린코드를 읽던 주니어 때 항상 의문이었던 부분을 잘 짚어주신 것 같습니다. 코드의 반복과 관련해서는 특히 그런데, 동일한 코드가 두 번 내지 세 번 정도 반복되는 것만으로도 리뷰 지적을 받을때가 많았습니다. 타당한 의견이면 수정해야 맞으나, 그 이유는 대체로 "당연히 그래야 한다" 였던 것 같아요. 동일한 코드라도 함수 단위로 묶을 "가치" 가 있을 때 전 함수로 묶는 편입니다. 결국 재사용성이 얼마나 있는지를 보고 판단하는 거죠. 그런데 처음 개발할 때는 개발한 코드가 얼마나 그러할지는 알기 어렵기에 일단 직관적으로 이해할 수 있도록 적절히 블랭크로 나누어 로직을 코드로 설명하고, 이후 유지보수 단계에서 해당 코드가 여러 군데에서 사용될 법 할 때 비로소 코드를 분리하여 적절한 함수로 정의합니다.
극단적으로는 아예 함수 단위로 나누지 않고 하나의 큰 기능을 하나의 함수 내에서 모두 구현해보는 방법도 취해봅니다. 경우에 따라서 구현을 하면서 아 어느 구간에서 어떻게 역할 분담을 해야하고, 그럼 이렇게 함수와 클래스를 정의해서 파라미터로 넘기면 되겠다 라는게 얼추 보일 때가 있습니다. 그렇게 해서 전체 구조를 잡아갈 때도 있습니다.
다만 사람마다 지향하는 바는 달라서, 영상에서 나온 함수로 막 쪼갰을 때 모습이 직관적인 (제 기준에선 약간 변태적인..) 사람이 있을 수도 있겠습니다. 그래서 전 이런 내용으로는 리뷰를 잘 안하긴 합니다. (개취 존중이랄까요..)
클린코드를 찬양한 적은 없습니다만, 그래도 꽤나 괜찮은 가이드라고 생각했을 때가 있었는데요, 지금은 사실 이런 책 보다는 개발 업무를 하면서 스스로 지향(양) 해야 할 습관을 생각하는 게 더 좋더라구요. 최근에는 업무로 주어지는 리뷰가 아니더라도, 다른 팀원이 짠 코드를 10분 정도 리뷰하는 습관을 가지려고 합니다. 대부분 개발자 분들이 그러하신지는 모르겠습니다만, 전 남의 코드를 보는게 매우 힘들더라구요. (제 능력 부족일 수도 있겠습니다.) 업무 능력과 스킬을 맹목적으로 배우는 것도 중요할 때가 있지만, 업무와 스킬 능력 향상을 위해 스스로 고민해보는 것도 매우 중요한 것 같아요. 그러한 고민에 대한 참고로 영상에 나온 책들이 도움이 될 가능성은 충분히 있습니다. (클린코드도 그 중 하나이지요.)
개발자는 아니어서 저 책을 많이 따라 했는데 ㅎㅎ 역시 두루두루 읽어 봐야 하군요.
뭔가 속이 시원해지는 영상 이네요
항상 적당한게 좋다
저는 개발 업무 10년 넘게 해본 사람으로서 한 가지 원칙에만 충실합니다.
"가독성"
이것만 좋으면 되요. 개발은. 근데 가독성이 좋으려면 결국 클래스, 함수 이름 및 구조, 변수 셋팅, api 호출 방식 등등 몽땅 잘 해야 한다는게 함정...
주석쓰지말라는 것은 영어권에서 영어로 코딩하니까 변수, 함수 네이밍만 잘 하면 주석 필요없어지는게 맞긴한데, 저 책이 로버트씨가 쓴거라서... 다른 언어권에서 통하지 않는 내용이 되었지만 번역은 충실히 해야해서 했는데, 그것을 또 믿고 따르는?
ㅋㅋㅋ 이번 영상 극 공감합니다.
걍 누가 읽어도 깔끔한, 읽기 좋다고 생각되는 코드를 짜면됨 책은 참고용임
애플님 VSCode 대체 가능성있는 Code Editor Cursor도 한번 다뤄주십쇼
좀 더 깊이 있게 왜 그런지, 해결책은 무엇인지 알려주었으면 좋을 것 같네요. 뭔가 어디서 분노 쌓고 영상에 분풀이 하는 것 같아서 혼란만 더 생기네요. 종교엔 종교로 대항한다는 느낌을 받았습니다. ㅋㅋ;;
와... 이 형님 이제 10시간 만에 5만을 돌파하네.
코드를 ”내 집“이라고 비유해서
먼지없이 청소되어 깔끔한 집보다
적당히 먼지 있고 어질러짐이 적당히(!!!)
있는 집에서 사는게 속편하겠어요 ㅎㅎㅎ
방바닥에 스파게티 흩뿌려진 집만 아니면 땡
ㅋㅋㅋㅋㅋㅋㅋㅋ
세상 만사에 통용될 수 있는 말이네요.
ㄹㅇ함수 합칠건합치고해야하는데 다 쪼가리내버리라하니 ㅋㅋ
1:02 ...와 미친... 내 무습다... 함수 포장지 미쳤네...
클린코드를 기본적으로 지향해야 하는건 맞다고 봐요. 거기에 목매서 애초에 클린코드를 하는 목적이 사라지면 안되지만. 솔직히 근데 클린코드는 둘째치고 프로젝트에서 정해놓은 기본적인 컨벤션만 잘 지켜줘도 바랄게 없겠네요. 코드 포맷팅 안하고 작명규칙 자기 맘대로고 그런 사람들 너무 많이 봐서
TDD도 언제 한번 다뤄주시죠. 클린코드급 종교.
오해들 하실까봐 덧붙이면 테스트 코드를 작성하는 것과 TDD(테스트 주도형 프로그래밍)는 엄연히 다른 것이고, 제가 비판하는건 TDD에 대한 맹목적인 찬양입니다.
포큐형님한테 들었던 내용이네요 ㅋㅋ
함수부분은 그 모든 함수를 보라는 뜻이 아니라 추상화 레벨을 맞춰서 그 디테일을 안보게 하는게 목적이라 영상내용에 동의는 크게 안되네요. 모든코드를 보려면 가독성이 떨어져도 추상화된 상위 함수만 본다면 가독성이 올라가죠.
로그인 함수라면 로그인 함수에 모든 디테일을 if문 처리해서 if문 여러개의 의미를 해석하는거 보다는
재사용 하지 않더라도 함수로 나눠서
인증 검증
유저 정보 가져오기
가입 안되어 있으면 회원가입 유도
이런 함수로 나누는게 더 읽기 좋겠죠.
모든 함수의 디테일을 읽을 필요는 없습니다.
우리가 보려는건 이 함수가 무슨 동작을 하느냐이지 함수를 어떻게 구현했는지 정밀검사하려는게 아니니까요
그 부분은 중괄호로 감싸고 주석다는 것으로 해결 할 수 있습니다.
- 함수는 하이퍼링크처럼 이 페이지 저 페이지 왔다 갔다 하게 하는 불편한 점을
- 중괄호 치고 IDE에서 접어버리면 문서에서 대,중,소단원 나누는것처럼 접어버릴수 있어요.
함수로 추상화해서 가독성을 챙기는 목적도 해결되고
함수 호출에 대한 비용도 아끼고 이 함수 저 함수 넘나드는 것에 대한 불편함도 해결되더라고요.
추가적으로 함수로 추출했으면 이 함수는 재사용이 될 것이다라는 명확한 기준이 생겨서도 좋구요.
개인차 때문에 답은 존재하지 않는 것 같습니다. 클린 코드를 쓴사람이 만약 10년 개발자라면 10년 개발자들이 공감할 내용일테고, 그렇지 않은 경우는 공감하지 않을테니...
헉 저도 이렇게 바꾸라는 말에 그러면 가독성떨어지는것 같다고해도 미드랑 시니어에게 니가 뭘 안다고 까이기만했는데 제가 이상한게 아니었군요..
진짜 이전 회사 팀장이 이 책에 미쳤는지... 가독성, 성능 다 무시하고 이 책에서 말하는 클린코드만.... 추구함.. 아직 안 읽어 봤는데 하는 짓이 소름 돋게 책이랑 똑같네요.. 이 책 저책 많이좀 보지 진짜 클린코드만 읽은 사람 같았음.... 왜지...
효율성을 추구하는 언어인 프로그램 언어가 제 아무리 뛰어나도 작성의도를 실사용 언어인 주석만큼 잘 설명할 수 없죠
뛰어난 코드 작성자, 척하면 척하고 알아듣는 해독자, 중의적이거나 모호하지 않은 코드문법 이것들이 전부 갖춰진다고 하더라도
내 의도를 말로 설명하는것보다 정확하지 못할텐데 하물며 저것들이 다 갖춰지는 경우도 별로 없을테니까요
애초에 매우 뛰어난 사람이라고 해도 집단지성만큼 우수하지 않을거라 특정 사람이 쓴 책이 바이블이 되는건 문제라고 봅니다
수학정석이나 성문영어 이런게 바이블처럼 팔리는것도 참 별로였어요
초보때: 클린코드 짜려고 진짜 겁나 열심히함
10년차: 이렇게 짜나 저렇게 짜나 내 퇴근시간은 별차이 없다는 것을 내 몸이 깨달아서 대충 짬.
이거 이렇게 짜면 나중에 좟댄다는거 레이더 발동한것만 신경써서 만듬. 이게 짬밥 클라스
어쩌다보니 학부때부터 야매로 코딩하다 책을 0권만 보고 졸업후 인턴생활하면서 어쩌다보니 비즈니스 로직 최상단에 있는 모듈을 만들어 버렸는데...
세상에서 가장 큰 교훈들을 얻었습니다.
"깔끔하게 짤려 하지 말라, 어짜피 계획대로 흘러가질 못하는것이 개발이다."
"내가 설계한 인터페이스는 실개발에선 리소스만 처먹는 돼지다."
"너에게 어떤 계획이 있었던지간에 우리는 실제 도입시에 문서와 다르게 행동할것이다."
- 남들이 싼 코드를 라인단위로 쪼개서 분해결합하는 야매인 -
아마 아규먼트 부분은 제가 알기로는 아규먼트가 늘어나고 사용이 반복된다면 하나의 object로 capsulation 시키라는 말이라고 기억합니다. 그래서 함수 갯수랑은 크게 상관은 없을거에요.
중복코드는 어느정도는 괜찮은거군요 ㅎㅎ 함수화강박
클린코드에서 가져가야할 가장 큰 덕목은 테스트코드를 짜자 아닐까 싶네요
주제만큼은 무시해선 안되는데 저거만 바이블로 여기고 다른걸 배제하면 나락
약간 유지보수에 좋은 것들이네여
1:10 넥스트 스텝 오열....
이 영상의 내용을 맹목적으로 따르기로 했습니다 ! 감사합니다 코딩그애프루 상!!
코딩그애프루상을 숭배하라!!
아 이제부터 이 영상 내용대로만 코드 짜야겠다
1:50 여기서 육성으로 육두문자가 튀어나오는 걸 참을 수 없었습니다.
주석을 쓰지 말라고요? 뭐요 C++bal?
사놓고 아예 1페이지도 안열어봤는데 5분으로 끝났네 ㅋㅋㅋㅋㅋ
그런 상태면 꼭 한번은 읽어보시는 걸 추천드립니다. 영상에서 말한거처럼 읽고나서 맹신하는 사람들이 문제인거지 내용은 ㄹㅇ 좋음
함수를 짧게 많이 쓰면 함수를 호출할때 소요되는 시간이 점점 쌓여서 성능에 큰 영향을 줄 수 있습니다.
연산보다 함수 호출로인한 오버헤드가 커지는 것이죠.
적당히 씁시다. inline 함수를 자동으로 만들어줘서 상관 없긴한데 습관화 되ㅣ면 큰일납니다. 정신차려요 !!!!!
함수 호출 깊이 수를 말하는거 같은데 함수를 짧게 많이 쓰는 것과는 다른 의미 전달일거라고 보는데 의미전달은 명확하게
그리고 아예 쓰지 말라고 하면 그냥 main 함수에서 코드 다 집어 넣지 그러셈?
신성 모독이다!
왜 저렇게 까지 쪼개야하는가는 얼마나 많은 사람이 이 소스에 간섭할 것인가에 따라 달라집니다. 몇 명의 인원에서 application 전체를 개발/유지보수 하는 집단에서는 솔직히 날코딩과 주석이 좋죠. 라고 말을 맺기엔 요즘 AI라는 놈이 생겼죠. 이 녀석은 파편화된 소스를 떠먹이고 최적화시키면 더 잘합니다. 명세서 먹이고 코드 먹이고 수정시켜보세요. ㅎㅎㅎ 이 작업은 소스를 쪼개기 쉬울 수록 시키기 좋습니다. I/O와 사용된 이론 얘기하고 기본 소스 만들게 시키고 소스 리팩토링시키면 기본 작업틀 나옵니다. 테스트 코드도 만들라고 하면 만듭니다. 물론 실수가 적지 않으므로 반드시 검토 필수이긴 한데, 신뢰도 낮은 직원에게 주는 준비시간 + 검토시간보다 적게 걸립니다. 나중엔 이 작업도 필요없어질 것 같긴 합니다만 ㅎㅎㅎㅎ
그리고 주석 중심의 코드 설명은 코드 구현 규칙의 임의성이 강화되어 위험하다고 봅니다. 특히, 사람 손을 많이 탈 수록. 그래서 복잡하고 변화가 많은 코드일수록, 라인에 대한 설명이 아닌 함수 단위의 주석이 더 적절하게 된다 봅니다.
짧게 쓰려고 하다 보니 맥락이 이상한데, 한 줄 요약하면 TDD가 최고이나 이게 안되면 현행이 최고.
코딩애플 수강하려다 구라 아닌가 의심되서 고민하다 결국 수강 안 했네요! 감사합니다!
돼
@@ljs6467ㅋㅋㅋㅋㅋㅋㅋ
허용 되는 주석은 TODO: 뿐이다.
극공감합니다. 클린코드에 중독되서 함수는 무조건 짧게, 코드잘짜면 주석필요없다. 이런 사람들 짜증납니다ㅋㅋㅋ 당신 코드가 이해가 안된다고ㅋㅋㅋㅋㅋ
그건 클린코드의 방침보다 그 사람의 실력이 문제일지도... 결국 거기서 말하는거도 장황하게 가는거보다 적은 단서로도 많은 의미를 간결하게 전할수 있는 방향으로 코드 짜는방법을 말하는거라서.. 근데 그거랑 별개로 가독성과 코드길이 둘다 던져버리고 돌아만 가면 ㅇㅋ식으로 짜는 인간들도 ㅈㄴ 많으니 문제..
다른부분은 공감하고 함수 부분이나 주석은 공감이가지 않습니다.
클린코드에서 함수는 한가지역할을 하라는건 세부 함수를 읽지않아도 될정도로 추상화수준을 최대한 잘게 쪼개고 맞추라는 것을 의미하는 거여서 1:15 의 오른쪽이 가독성이 떨어진다는 말에는 동의살수없습니다. 왼쪽의 코드에 if else block이 추가되어도 오른쪽보다 더 가독성이 좋을까요?
코멘트도 코멘트는 유지보수가 되지않기때문에 최대한 쓰지않는게 좋은거같아서 동의가되지않습니다. (물론 javadoc같은건 당연히 써야하고요)
말하고자 하는 바에는 공감 하는 편이긴 한데 뭔가 단적으로 말씀 하시는 것을 보니 역시 유튜브는 유튜브인가 라는 생각이 들기도 하네요
주석이 필요 없다는건 시진핑을 말하는 겁니다.
뭐든 적당히가 좋습니다.
저는 코딩규칙 언리얼 문서에있는게 좋은거같아요 예시로
자체적으로 설명이 되는 코드를 작성하세요:
// Bad:
t = s + l - b;
// 좋아요:
TotalLeaves = SmallLeaves + LargeLeaves - SmallAndLargeLeaves;
함수 호출에서 익명 리터럴 사용은 피하세요. 네임드 상수로 의미를 설명하는 것이 좋습니다.
// 옛 스타일
Trigger(TEXT("Soldier"), 5, true);.
// 새 스타일
const FName ObjectName = TEXT("Soldier");
const float CooldownInSeconds = 5;
const bool bVulnerableDuringCooldown = true;
Trigger(ObjectName, CooldownInSeconds, bVulnerableDuringCooldown);
함수 선언을 조회하지 않고도 이해할 수 있어 일반적인 독자에게 의도가 더욱 명확해 집니다.
이런거 알려줌
너무 까지는 말자.. 이 형(마틴)이 구닥다리 개발자들을 UML 개미 지옥에서 구출해 준 것 만해도 1번 정도는 절해줄 만 함..
최고
솔직히 클린코드, 클린아키텍쳐는 입문자용이 아니라 중급자용임
막코딩도 해보고 6개월 전의 나를 원망도 해보고 과도한 구조 설계로 고생도 해보고 잘 짜려다 기한 안에 못만들어보고 이것저것 삽질해본 후에 '원칙은 이건데 상황에 맞게 알잘딱해라' 정도의 지침서로 보면 딱임
이름 짓는 법은 씹인정인데
함수는 뭔....🤔 저지랄 함수 몇개씩 더 호출해야되잖아 차라리 저정도 가독성이면 그냥 내장함수 써~!
하지만 다음 챕터 주석 쓰지말라해서 내장함수 쓰면 코드 못 알아먹을 수도 있음ㅋㅋㅋㅋ
주석이 그 주석이 아니라 대륙의 주석인듯
형 이제 테스트주도기반 신도들 기분상해죄로 테러당함 ㅅㄱ
Code Complete by McConnell Steve
Working Effectively with Legacy Code by Michael Feathers
Writing Secure Code by David LeBlanc
굿
이책 보지도 않았지만 파이서닉하게 쓰는게 목적이라고 보는데 적어도 아무 근본없는 코더보단 이책 하나라도 보는게 협업할때 좋을것같네요
클린코드 따르면 가독성이 좋아지죠.. 점점 규모가 늘어날때 따라야할 좋은 방법.
짧은 코드로 예시를 들면 그런것은 당연히 필요없음
함수는 궤변이다 ㅋㅋㅋㅋㅋㅋㅋㅋㅋ
클린 코드를 통해서 배울 점이 많은데..
주의해야할 부분은 적절한 양의 코딩 경험 없이 뉴비 레벨에서 무지성으로 읽게되면 내옹이 잘 와닿지도 않고 얻을 수 있는게 1도 없다는 것..!
공감요
Art of programming 3권 말곤 사실 추천안하는데..
공감되는 내용입니다.
됐고..
중괄호 올려쓰는거 보면 진짜... ㅋㅋ
니들이랑 같이 일 못하겠다...
이런 사소한 이유로 코드의 가독성은 달라집니다.
팀의 룰을 따르세요. 그게 답입니다.
가끔씩 프로그램 팀이 아니라 업무 연관이 있는다른 팀 때문에 어쩔수 없이 하드코딩을 해야 하는 경우도 있습니다.
결국 코드를 최종적으로 승인 하는건 팀 그리고 팀장이므로. 왜 그렇게 짰는지 이유만 설명하고 그게 합리적이면 되는 겁니다.
@@georgestokes4728 그냥 팀 방침 따르는게 대부분은 맞지 않나 싶은... 따지고 보면 팀 방침도 결국 협업 효율성을 위한거니... 근데 저는 {} 내려쓰는거 읽는거나 그렇게 쓰는거나 불편해서 원.. 스코프 시작점이 어떤 파트에서 시작되었는지 그게 함수인지 조건문인지 판단하는게 그쪽이 더 편해서.. 어차피 2중 3중 중첩되면 읽기 ㅈ같은건 똑같으니
진짜 공감하는게 함수랑 주석부분보고, 엥? 이런게 너무 많아서 이게 맞나 싶기도 했습니다.
특히 어느기업은 과제조차 주석자체를 극혐하는 곳도 많고 애초에 클린코드를 넣어버린 곳도 많은데 클린코드에 대한 부분을 명확히 인지하고 쓰는건지 의구심이 들뿐입니다.
그래서 저는 '클린코드'보단 '좋은코드 나쁜코드' 이 책을 더 많이 추천해주는 편입니다.
오히려 구글 엔지니어가 작성하여 직접 경험에 의한 내용이라서 더 좋고 실무에도 적용시킬 내용이 많아서 오히려 이책이 더 좋은거 같네요
@@rendarcb1908 함수 시그내처와 주석에 관한내용은 클린코드와 무관합니다. 훨씬 오래전부터 it업계 전반에 통용되던 것이며, 분야를 막론하고 구루급 개발자들이 공통적으로 하는 말입니다
클린코드 찬양하지 말라는 영상을 보고 무조건 부정적인 댓글 다는 아이러니한 사람이 많은듯...
극과 극은 통한다고 하더라고요
난 가끔 생각해.. 이 형은 개발보다 영상편집의 재능이 더 뛰어난게 아닐까? 하는..
"정보미디어 전공 희망편"
개발자로만 구독자 20만명인데 메이져 쟝르 유튜버였으면 최소 100만 이상 하셨을듯 싶습니다
이거 인정하는 부분입니다
코딩커뮤니케이터 ㅋㅋㅋㅋ
이 형의 멋있는 점은 겉으로 보면 정신이 나가있는거같은데 내용을 보면 이만큼 좋은 가르침을 주는 사람이 별로 없음.
ㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋ 정신이 나간것같은데 개잘해!!
맥이는건지 띄어주는건지 ㅋㅋ
원래 이런 일 하는 사람들은 나사 하나씩 빠져 있는 게 기본소양이기 때문
저도 처음 개발할 때 저 책읽고 광신도마냥 코딩 했다가 개욕먹었습니다 ㅋㅋㅋ 후에 고수분들이 해놓은 코드를 보면서 배운것을 요약하자면, 명확하게 장점이 더 큰 선택이 있기도 하지만, 작업의 깊이가 깊어질수록 이를 구분하기 점점 어려워진다는 것입니다. 필요성을 명확하게 파악한다면 아키텍쳐를 명확하게 만들어낼 수 있지만, 그 필요성에 불확신이 가미될수록 어떻게 아키텍쳐를 구성해야되는지 구분하기 어려워진다는 것입니다. 따라서 고수분들의 필요성을 파악하고 정의해내는 능력을 우선 배우고 있습니다. 그렇게하면 코드 구조는 각 상황에서 어느정도 최선의 것이 존재한다는 것을 알았습니다.
경력이 쌓이고 그 과정속에서 여러 프로젝트를 개발하다보면 본인만의 개발 철학이 생기는거 같아요.
저도 신입때는 함수의 파라미터들을 객체로 감싸서 넘길지 말지, 프로젝트 폴더구조를 어떻게 해야할지 등..
그러다보니 기능구현을 하기도 전에 지쳐버리는 경우가 있었어요.
너무 체력을 소모하는거 같아 이 버릇을 고치려고 노력했던 기억이 나네요
나름 클린하게 리팩토링 해놓은 플젝 레포지토리를 몇년뒤 다시봤을때 내가 왜 이렇게 피곤하게 해놨을까 했던 기억도 나네요 ㅋㅋ
C++로 유명한 유튜버 분도 2년 전에 클린 코드 책 엄청 깠던 거 보고, 클린 코드에 대해서 비판적으로 접근하기 시작했는데, 정작 제가 이런 말 하니깐 주위에서는 절 이상한 사짜 취급하더라구요. 한 번 신랄하게 까주셔서 감사합니다.
이건 정치색드러내는거랑 비슷한 개념같아요.
개인적으로 옳은 생각이란건 이거구나 하며 마음에만 품고 살아가면 별일없는데 그걸 누군가한테 얘기하거나 납득시키려면 필요한 자료나 내 사회적 위상 등, 따지고보면 짜증나는 과정을 거칠수밖에 없는거죠
비판을 하면 좋은 경험을 가졌던 사람에게서 반박이 따를수밖에 없죠 그런 경험적 부분은 서로 설득도 안되니 권위가없다면 사짜취급은 감수할수밖에..
그분 포프님인가
보통 저런책들 박사들이 내니까 바이블 삼는 사람들은 니가 그 박사들보다 잘알아? 대단해? 이런식으로 걍 권위에 맡기기 하는...
클린 코드를 비판해서 욕 먹은 게 아니라 비판을 제대로 된 논리와 근거 없이 해서 욕 먹은 걸 거라는 게 댓글을 통해서 짐작이 되네 ㅋ
오버 하지말란말을
클린코드는 틀렸다 라고 이해를 하시나 다들..
책에서 말하는 모든 것을 맹신하지 말고 이런 부분도 있으니 비판적 사고를 가지고 읽어라는 영상을 클린코드 책은 쓰레기다로 받아들이는 인간들이 댓글에 보이는데 한권만 읽고 맹신하는 자나 영상 하나 보고 전부까기 하는 자나 다를 바 없는 듯
클린 코드라는 책이 오래됐기도 하고 어느정도 걸러서 들어야 하는건 사실입니다.
그런데 결국 저자가 하고 싶은 말은 코드 그 자체가 의도를 충분히 설명할 수 있어야 한다는 것 같아요.
함수 부분에서 "왔다갔다 하느라 훨씬 읽기 어렵다" 하신 부분도 사실 원래 의도대로라면 왔다갔다 할 필요가 없죠. "왔다갔다" 하지 않아도 뭘 하는지 알 수 있도록 함수 이름을 지으라는 뜻이니까.
네 이영상은 그런 말을 합니다.
@@실험맨 몇초 부근인지 남겨주시면 감사하겠습니다 제가 놓쳤는지 안보이네요😅
코드는 깔끔하게, 함수 네이밍도 알맞게 지어 놨어도 주석을 달았다는 이유만으로 배격하는 사람들이 있습니다. 그걸 실제로 당해보면 사실 약간 어이가 없죠.
결국 책에서 얘기하고자 하는 의미도 그게 맞죠
단순히 다 쪼개야한다는 맹목적인 의견이 아니라 절차지향적인 코드로 인해서 가독성이 떨어지는 코드를 지양하고 선언적인 형태로서 줄글쓰듯이 하는걸 권장하는거니까요
@@실험맨 혹시 어디서 나오나요?? 1:20 에서 동영상은 가독성은 작게 분리해놓은거보다 합쳐놓은게 가독성이 더 좋다고 하던데요. 개인차가 있겠지만 저는 따로 분리해놓은게 더 가독성이 있다고 느낍니다. 적어도 함수 이름과 실제로 동작하는게 동일하다면요.
동의합니다.
뭐든지 적당히 받아들이는 유연함이 필요하죠. ㅎㅎ
클린을 강조했다고 해서 결벽증 환자가 되라는 말은 아닙니다.
중복에 대한 얘기는, 같은 저자가 쓴 클린 아키텍처 책을 보시면 알겠지만, 마틴님도 영상에 나온 예시와 같은 경우는 코드를 다 분리해서 쓰는게 좋다고 말합니다. 애초에 유스케이스를 제대로 분리하지 못해서 생긴 '가짜 중복'이라며, "중복은 없어야돼!"라는 강박때문에 함정에 빠져선 안된다고 저자도 얘기하더라구요.