진짜 공감하는게 함수랑 주석부분보고, 엥? 이런게 너무 많아서 이게 맞나 싶기도 했습니다. 특히 어느기업은 과제조차 주석자체를 극혐하는 곳도 많고 애초에 클린코드를 넣어버린 곳도 많은데 클린코드에 대한 부분을 명확히 인지하고 쓰는건지 의구심이 들뿐입니다. 그래서 저는 '클린코드'보단 '좋은코드 나쁜코드' 이 책을 더 많이 추천해주는 편입니다. 오히려 구글 엔지니어가 작성하여 직접 경험에 의한 내용이라서 더 좋고 실무에도 적용시킬 내용이 많아서 오히려 이책이 더 좋은거 같네요
클린 코드라는 책이 오래됐기도 하고 어느정도 걸러서 들어야 하는건 사실입니다. 그런데 결국 저자가 하고 싶은 말은 코드 그 자체가 의도를 충분히 설명할 수 있어야 한다는 것 같아요. 함수 부분에서 "왔다갔다 하느라 훨씬 읽기 어렵다" 하신 부분도 사실 원래 의도대로라면 왔다갔다 할 필요가 없죠. "왔다갔다" 하지 않아도 뭘 하는지 알 수 있도록 함수 이름을 지으라는 뜻이니까.
중복에 대한 얘기는, 같은 저자가 쓴 클린 아키텍처 책을 보시면 알겠지만, 마틴님도 영상에 나온 예시와 같은 경우는 코드를 다 분리해서 쓰는게 좋다고 말합니다. 애초에 유스케이스를 제대로 분리하지 못해서 생긴 '가짜 중복'이라며, "중복은 없어야돼!"라는 강박때문에 함정에 빠져선 안된다고 저자도 얘기하더라구요.
실무자 입장에서 특정 책에 대한 맹신을 경계하게 하는 아주 좋은 영상 같습니다. 거의 전적으로 동의합니다! Clean code는 개념도 그렇고, 저 책의 출간 목적도 그렇고, 결국은 "나랑 전혀 관계없던 사람"이 와서 봤을 때도 내 코딩 의도가 완전히 전달되어야 한다는 게 지상목표이고, 이런저런 '팁'은 전부 그걸 달성하기 위한 수단 중 하나에 불과하지요. 극단적으로 얘기했을 때 우리 팀 전원이 어느 날 갑자기 해고되거나 비행기사고로 몰살당하거나 해도 프로젝트가 계속될 수 있어야 합니다. 그 목표를 위해서 때로 다양한 기능을 한 클래스에 몰아넣거나, 주석에 약간 구질구질한 설명을 넣거나 하는 일이 필요하다면, 그렇게 하는 게 더 우선되어야 하는 거죠.
저희 학원 쌤은 딱 이 정도 강요합니다. 1. 코드를 더 함축적으로 쓸 수 있는거 아니면 풀어 짜라. 2. 주석 없애고 싶으면 야근은 각오해라. 3. 변수명은 기존 팀원들 코드를 둘러보고 알잘딱 따라가라. 그게 시간 단축이다. 4. 이동이 3회 이상 벌어지는 코드는 재활용 하지 말고 그냥 새로 써라.
코드의 중복 제거 여부는 명확한 기준이 있다고 생각해요. 중복된 코드가 논리적으로 같은 의미이고 둘중 하나가 바뀌었을 때 다른 하나도 같이 바뀌어야 한다면 무조건 함수로 빼야합니다. 변경을 누락하는 실수를 방지할 수 있기 때문이죠. 하지만 중복 코드간 구현이 같더라도 논리적인 의미가 다르면 함수로 추출해선 안 됩니다. 한 부분의 수정이 다른 부분에 의도치 않은 사이드 이펙트를 줄 수 있기 때문이에요. 좋은 영상 감사합니당 굿
코드의 중복이 아니라 논리의 중복이죠 사실 ㅎㅎ 예를 들어 세금 10% 계산로직과 팁 10% 계산로직이 우연히 같다고 해서 하나의 함수로 빼버리는 순간 지옥이 시작되는거죠. 팁이 5%로 바뀐순간 세금이 바뀌는 버그가 생기고, 이걸 해결하겠다고 세금/팁 타입을 넣고 분기를 넣기 시작하면 만든사람만 아는 레거시가 되는거죠 ㅋㅋ 이땐 코드가 아니라 한걸음 물러서서 추상화된 개념을 생각해야 하고 그냥 분리해야합니다. 코드만 보고 단순하게 리팩터링하면 걸리기 쉬운 함정입니다 ㅎㅎ
경력이 쌓이고 그 과정속에서 여러 프로젝트를 개발하다보면 본인만의 개발 철학이 생기는거 같아요. 저도 신입때는 함수의 파라미터들을 객체로 감싸서 넘길지 말지, 프로젝트 폴더구조를 어떻게 해야할지 등.. 그러다보니 기능구현을 하기도 전에 지쳐버리는 경우가 있었어요. 너무 체력을 소모하는거 같아 이 버릇을 고치려고 노력했던 기억이 나네요 나름 클린하게 리팩토링 해놓은 플젝 레포지토리를 몇년뒤 다시봤을때 내가 왜 이렇게 피곤하게 해놨을까 했던 기억도 나네요 ㅋㅋ
저도 처음 개발할 때 저 책읽고 광신도마냥 코딩 했다가 개욕먹었습니다 ㅋㅋㅋ 후에 고수분들이 해놓은 코드를 보면서 배운것을 요약하자면, 명확하게 장점이 더 큰 선택이 있기도 하지만, 작업의 깊이가 깊어질수록 이를 구분하기 점점 어려워진다는 것입니다. 필요성을 명확하게 파악한다면 아키텍쳐를 명확하게 만들어낼 수 있지만, 그 필요성에 불확신이 가미될수록 어떻게 아키텍쳐를 구성해야되는지 구분하기 어려워진다는 것입니다. 따라서 고수분들의 필요성을 파악하고 정의해내는 능력을 우선 배우고 있습니다. 그렇게하면 코드 구조는 각 상황에서 어느정도 최선의 것이 존재한다는 것을 알았습니다.
ㅋㅋㅋ 이번 영상은 클린코드라는 책의 문제점을 정확하게 지적해 주셨네요. 특히 함수 부분 너무 시원합니다. 쭉 한 번 보면 그냥 알 수 있음에도 불구하고 함수를 무조건 나누려는 인간들이 있어요. 정말 광신도들은 답이 없어요. 더 한심한 건 너무 많아진 함수들이 관리되지 않아서 같은 기능의 함수들을 또 만드는 미친 인간도 있더군요. 환장합니다.
@@silver33412님이 그렇다고 말하는 것은 절대 아님을 미리 말하고요. 진짜 잘 하는 사람들도 해당 안 됩니다. 가장 큰 문제는 실력도 없는 사람들이 광신도처럼 맹신을 하는 바람에 현업에 방해가 되는 경우가 엄청 많다는 거죠. tdd도 마찬가지. 맹신을 하면 절대 안 되고 상황에 따라 내가 활용한다는 생각으로 접근을 해야 하는데 아무 생각없이 함수를 다 나눠서 나중에 자신이 그 함수들을 관리 못 하고 또 똑같은 함수들을 만들기도 하더군요. 나중엔 마땅한 함수명 고르는데도 시간 낭비... 이 영상도 그런 부분이 지나침을 말하는 거죠. 병적으로 함수를 나누려고 하지 마라...
1:07 함수로 감싸놓음으로서 동작이 의도하는바가 뭔지 알기쉽고 동작들을 구분하기 쉬움 문제 생긴곳 파악도 쉬움 1:51 주석의설명과 코드의 실제작동방식이 일치하는것은 보장할 수 없음 좋은 코멘트의 예시들은 괜찮지만 실제코드의 작동방식이나 사이드이펙트에대한 주석은 지양하는게 좋음 차라리 변수명이나 함수명을 잘지어서 코드에 들어나게하는게 정답임 3:11 길고복잡한 변수명과 함수명은 하나가 너무큰역할을 하기때문임 분리해서 쪼개야함 4:15 공통된 부분을 우선묶는게 좋음 . 후에 if나 switch문 같은걸로 쪼개는게 아니라 각동작을하는 함수를 만들어서 공통된함수를 사용하도록 래핑하면됨 주의해야할건 문맥상 완전 다른 위치에서 완전 다른의도로 운이좋아서 닮은 코드가 있는데 이건 구분을잘해서 따로둬야함
주석 부분이 이상한 이유에 대해 생각해봤는데 언어적 차이도 있는 거 같아요 영어가 모국어인 사람들은 그냥 코드만 읽어도 어느 정도 순식간에 이해할 수 있으니까요 근데 한국인들은 아무리 영어를 잘한다고 해도 미세한 속도 면에서 한국어 주석으로 읽을 때 코드를 더 빨리 이해할 수 있더군요
@@garciakarim3544 주석이 있어서 거슬린다면 지워버리면 되며, 있으면 대부분 도움이 됩니다. 그냥 원래 코드를 개판으로 짜놓거나 혼자만 알아보게 짜놓고 주석에만 의존하고 주석에 떠넘기는 행태가 잘못된 거지 주석 자체가 문제가 아니란 말입니다. 대개는 주석 걸고 넘어지는 분들은 그냥 주석 없어도 전체적 코드 구조를 알아보는 눈이 없는 분이 많습니다. 주석이 방해만 되는 레벨에서는, 이미 아키텍쳐 수준이므로 주석이고 뭐고 짜증이 나지도 않고 별 대수가 안 됩니다. 한마디로 유난 떠는 사람들은 그냥 훌리건에 불과하다는 거에요.
1:12 함수부분에 있어서 1. 협업을 할때 클린코드 따라가세요. 2. 혼자작업할때 한 함수에 다 적는게 가독성 더 좋습니다. 쓰는 상황에 따라 좀 다른거같습니다. 추상화단계를 어디까지 밟을 것인가는 매우 중요한 논점입니다. 동료개발자의 시간을 아껴주기위해서 최대한 선언형으로 작성할 필요가 있습니다.
뭔가 초보가 짠듯한 느낌의 코드인데 딱히 문제는 없고 물흐르듯 읽혀지면 그게 정말 좋은 코드 입니다. 괜히 복잡하게 있어보이게 중첩에 중첩에 추상화에 캡슐화에 최신 패턴 접목하면...그거 누가 봅니까?...자기만 볼려는거 아니면... 같이 일하는 사람 모두가 쉽게 쉽게 읽고 고칠 수 있어야 합니다.
몇가지 팁..1. 변수를 줄여라..변수가 많다면 뭔가 잘못된거다. 변수를 줄여라 2. 함수이름은 전부 소문자로..헝가리 어쩌구하면서 대소문자 섞어쓰는데..대소문자 구분안하는 언어도 많다. 그런 언어 만나면 고생하니 그냥 전부 소문자로. 3. 탭으로 줄맞추기 잘해라. 가독성이 많이 올라감. 4. 람다함수 많이써라..코드가 짧아짐
진짜 맞는말인게 유독 하나만 읽고 그걸 맹신하는 사람들이 많음.. 읽으면서 무조건 받아들이지말고 비판적인 시각을 유지해야하는데.. 자기가 실력이 없다면 관련 서적을 읽으면서 잘은 모르겠지만 이 부분은 대체 왜 이렇게 해야하는거지 하면서 다른 관련 문서들도 찾아봐야하는데 그냥 유명한 책에서 맞다고하니까 의심없이 받아들이는 그런
24년차 사골개발자인데... 잘보고 갑니다 공감이 많이 가네요 많이 배우고 갑니다 ㅋㅋ 주석에 할말이 많은데... 주석은 꼭 필요합니다. 나는 고수지만 초보가 봐도 이해를 해야하고 왜 이렇게 썼는지 어떻게 응용이 가능한지 정도 적어줘야 다음사람이 비판도 하고 가져다 쓰고...
![I.N "HALLUCINATION" | [Stray Kids : SKZ-PLAYER]](http://i.ytimg.com/vi/n5B5q1Hwt_U/mqdefault.jpg)
클린코드 찬양하지 말라는 영상을 보고 무조건 부정적인 댓글 다는 아이러니한 사람이 많은듯...
극과 극은 통한다고 하더라고요
"주석이 거짓말을 한다" 라는 건 경험적으로 봤을때, 코드만 고치고 주석은 고치지 않은 사람들 때문이죠.
그러면 코드와 주석이 내용이 다르게 되고 주석이 거짓말을 하는 상황이 됩니다.
주석이 나쁜게 아닙니다.
코드를 고치고 주석은 고치지 않는 사람이 나쁜 거죠.
대부분은 주석만 안고치게 됩니다..... 주석을 달더라도 문단 제목을 달듯 간략한 코드 흐름정도만 표현하는게 낫다고 봅니다
클린코드 제대로 안보셨네요. 그 안고치는 사람이 주석을 지양하는 이유 중 하나로 설명합니다...쩝...
덧붙여 주석 지양은 클린코드책과 별개로 원래 대부분의 it업계서 하던 말입니다.
왜 이걸 책한권만 읽고 모든걸 판단한다고 호도해버리는지 모르겠네요
그렇게 치면 이 세상에 나쁜 물건이 어딨음? 핵무기는 나쁜게 아닙니다. 쏘는 사람이 나쁜거죠.
ㄹㅇ. 코드만 고치고, 주석 안 고치는 사람이 문제인거.
진짜 공감하는게 함수랑 주석부분보고, 엥? 이런게 너무 많아서 이게 맞나 싶기도 했습니다.
특히 어느기업은 과제조차 주석자체를 극혐하는 곳도 많고 애초에 클린코드를 넣어버린 곳도 많은데 클린코드에 대한 부분을 명확히 인지하고 쓰는건지 의구심이 들뿐입니다.
그래서 저는 '클린코드'보단 '좋은코드 나쁜코드' 이 책을 더 많이 추천해주는 편입니다.
오히려 구글 엔지니어가 작성하여 직접 경험에 의한 내용이라서 더 좋고 실무에도 적용시킬 내용이 많아서 오히려 이책이 더 좋은거 같네요
@@rendarcb1908 함수 시그내처와 주석에 관한내용은 클린코드와 무관합니다. 훨씬 오래전부터 it업계 전반에 통용되던 것이며, 분야를 막론하고 구루급 개발자들이 공통적으로 하는 말입니다
코딩애플 유튜브채널 하나만 보면 코딩 잘 할 수 있음
코딩이아니라 어그로 잘끌 수 있음
개추 ㅋㅋ
개추
나 코딩애플인데 개추눌렀다
엄준식 잘할 수 있음
주도적 비판적 학습을 위해 꼭 필요한 말씀이네요. 감사합니다!
난 가끔 생각해.. 이 형은 개발보다 영상편집의 재능이 더 뛰어난게 아닐까? 하는..
"정보미디어 전공 희망편"
개발자로만 구독자 20만명인데 메이져 쟝르 유튜버였으면 최소 100만 이상 하셨을듯 싶습니다
이거 인정하는 부분입니다
코딩커뮤니케이터 ㅋㅋㅋㅋ
코딩의 C도 모르는데 재밌어요
클린 코드라는 책이 오래됐기도 하고 어느정도 걸러서 들어야 하는건 사실입니다.
그런데 결국 저자가 하고 싶은 말은 코드 그 자체가 의도를 충분히 설명할 수 있어야 한다는 것 같아요.
함수 부분에서 "왔다갔다 하느라 훨씬 읽기 어렵다" 하신 부분도 사실 원래 의도대로라면 왔다갔다 할 필요가 없죠. "왔다갔다" 하지 않아도 뭘 하는지 알 수 있도록 함수 이름을 지으라는 뜻이니까.
네 이영상은 그런 말을 합니다.
@@실험맨 몇초 부근인지 남겨주시면 감사하겠습니다 제가 놓쳤는지 안보이네요😅
코드는 깔끔하게, 함수 네이밍도 알맞게 지어 놨어도 주석을 달았다는 이유만으로 배격하는 사람들이 있습니다. 그걸 실제로 당해보면 사실 약간 어이가 없죠.
결국 책에서 얘기하고자 하는 의미도 그게 맞죠
단순히 다 쪼개야한다는 맹목적인 의견이 아니라 절차지향적인 코드로 인해서 가독성이 떨어지는 코드를 지양하고 선언적인 형태로서 줄글쓰듯이 하는걸 권장하는거니까요
@@실험맨 혹시 어디서 나오나요?? 1:20 에서 동영상은 가독성은 작게 분리해놓은거보다 합쳐놓은게 가독성이 더 좋다고 하던데요. 개인차가 있겠지만 저는 따로 분리해놓은게 더 가독성이 있다고 느낍니다. 적어도 함수 이름과 실제로 동작하는게 동일하다면요.
중복에 대한 얘기는, 같은 저자가 쓴 클린 아키텍처 책을 보시면 알겠지만, 마틴님도 영상에 나온 예시와 같은 경우는 코드를 다 분리해서 쓰는게 좋다고 말합니다. 애초에 유스케이스를 제대로 분리하지 못해서 생긴 '가짜 중복'이라며, "중복은 없어야돼!"라는 강박때문에 함정에 빠져선 안된다고 저자도 얘기하더라구요.
실무자 입장에서 특정 책에 대한 맹신을 경계하게 하는 아주 좋은 영상 같습니다. 거의 전적으로 동의합니다!
Clean code는 개념도 그렇고, 저 책의 출간 목적도 그렇고, 결국은 "나랑 전혀 관계없던 사람"이 와서 봤을 때도 내 코딩 의도가 완전히 전달되어야 한다는 게 지상목표이고, 이런저런 '팁'은 전부 그걸 달성하기 위한 수단 중 하나에 불과하지요.
극단적으로 얘기했을 때 우리 팀 전원이 어느 날 갑자기 해고되거나 비행기사고로 몰살당하거나 해도 프로젝트가 계속될 수 있어야 합니다.
그 목표를 위해서 때로 다양한 기능을 한 클래스에 몰아넣거나, 주석에 약간 구질구질한 설명을 넣거나 하는 일이 필요하다면, 그렇게 하는 게 더 우선되어야 하는 거죠.
책에서 이랬는데 라고 권위믿고 맹신하기엔 진짜 개발이 영역마다 프젝마다 케바케가 심해서 참고는 하면 좋지만 실제 생산성 떨어지고 불편함 많고 이런데도 맹목적으로 룰을 따라야 좋아 하는건 다시 생각해볼만...
저희 학원 쌤은 딱 이 정도 강요합니다.
1. 코드를 더 함축적으로 쓸 수 있는거 아니면 풀어 짜라.
2. 주석 없애고 싶으면 야근은 각오해라.
3. 변수명은 기존 팀원들 코드를 둘러보고 알잘딱 따라가라. 그게 시간 단축이다.
4. 이동이 3회 이상 벌어지는 코드는 재활용 하지 말고 그냥 새로 써라.
이게 코딩이 영어라고 영어로 쓰인 것들 맹신하는 사람들 있는데 실상은 한국인들이 코드 겁나 잘 짬
근데 5번의 경우는 어떤걸 말하는건가요?
1:19 왔다갔다하는게 아니라 함수 이름으로 읽고 그런 일을 하는구나하고 자세히 분석하지 않고 그냥 넘어가면 됩니다. 잘 짜져 있는 코드라면 그렇게 하면 됩니다. 왔다갔다하라고 저렇게 하는거 아니에요. 주석처럼 함수 이름 만드는거에요
C++로 유명한 유튜버 분도 2년 전에 클린 코드 책 엄청 깠던 거 보고, 클린 코드에 대해서 비판적으로 접근하기 시작했는데, 정작 제가 이런 말 하니깐 주위에서는 절 이상한 사짜 취급하더라구요. 한 번 신랄하게 까주셔서 감사합니다.
비판을 하면 좋은 경험을 가졌던 사람에게서 반박이 따를수밖에 없죠 그런 경험적 부분은 서로 설득도 안되니 권위가없다면 사짜취급은 감수할수밖에..
그분 포프님인가
보통 저런책들 박사들이 내니까 바이블 삼는 사람들은 니가 그 박사들보다 잘알아? 대단해? 이런식으로 걍 권위에 맡기기 하는...
클린 코드를 비판해서 욕 먹은 게 아니라 비판을 제대로 된 논리와 근거 없이 해서 욕 먹은 걸 거라는 게 댓글을 통해서 짐작이 되네 ㅋ
포프도 딱히 잘 알고 말하는거는 아니라...
동의합니다.
뭐든지 적당히 받아들이는 유연함이 필요하죠. ㅎㅎ
클린을 강조했다고 해서 결벽증 환자가 되라는 말은 아닙니다.
이제 유지보수하기 어렵게 코딩하는방법만
읽으면 완벽하군요
인수인계자를 ㅅㅏㄹ...
코드의 중복 제거 여부는 명확한 기준이 있다고 생각해요.
중복된 코드가 논리적으로 같은 의미이고 둘중 하나가 바뀌었을 때 다른 하나도 같이 바뀌어야 한다면 무조건 함수로 빼야합니다. 변경을 누락하는 실수를 방지할 수 있기 때문이죠.
하지만 중복 코드간 구현이 같더라도 논리적인 의미가 다르면 함수로 추출해선 안 됩니다. 한 부분의 수정이 다른 부분에 의도치 않은 사이드 이펙트를 줄 수 있기 때문이에요.
좋은 영상 감사합니당 굿
@@arisa3364ㅎㅎ 그래도 기준은 있어야죠.
동의합니다
코드의 중복이 아니라 논리의 중복이죠 사실 ㅎㅎ 예를 들어 세금 10% 계산로직과 팁 10% 계산로직이 우연히 같다고 해서 하나의 함수로 빼버리는 순간 지옥이 시작되는거죠. 팁이 5%로 바뀐순간 세금이 바뀌는 버그가 생기고, 이걸 해결하겠다고 세금/팁 타입을 넣고 분기를 넣기 시작하면 만든사람만 아는 레거시가 되는거죠 ㅋㅋ 이땐 코드가 아니라 한걸음 물러서서 추상화된 개념을 생각해야 하고 그냥 분리해야합니다. 코드만 보고 단순하게 리팩터링하면 걸리기 쉬운 함정입니다 ㅎㅎ
@@이름-y8i 맞아요 원댓글하고 같은 말씀
주저리주저리 조건 달아 놓고 무조건이라는 말을 쓰는건 무조건이라는 뜻을 모르나? 코딩 공부 전에 국어공부부터 다시해야할 듯 ㅋ
와 개깔끔하네.. 5분만에 이 모든걸 이렇게 설득력있게 풀어내다니..
항상 느끼지만 이번 영상은 더욱 걸작이네요. 모든 내용에 동의합니다.
코드의 의도를 분명하게 담아내는 주석 작성방법만 익혀도 이사람 배려할 줄 아는 사람이구나 느낄수 있어요, 괜히 시니어들이 주석 활용 잘하는게 아님
주석이 거짓말을 하는 경우 -> 먼저 써놓고 나중에 코드를 수정했는데, 까먹거나 귀찮아서 주석을 수정 안했음
현업자들의 조언을 듣고 싶음..
사수가 없음..
이 영상 같은 영상 꿀임....
그래도 책은 읽어보세요
읽고나서 책에서 지향하는대로도 해보시고 시행착오도 겪으시면서 개발 철학을 쌓아나가시는게 중요합니다
명서는 명서인 이유가 있는거예요
이 영상도 이 책은 구리니까 읽지 마라 라는 말이 아니라 책을 읽되 하나의 책을 맹신하지 말고 여러 책을 읽어보며 직접 어떤 코드가 좋은지 생각해보자 라는 의도인 것 같습니다
지금 나이 오십. 프로그래머 34살까지 하고 그만뒀는데 지금 봐도 재밌네. 나 때 이런 사람 있었으면하고 감탄하고 갑니다.
경력이 쌓이고 그 과정속에서 여러 프로젝트를 개발하다보면 본인만의 개발 철학이 생기는거 같아요.
저도 신입때는 함수의 파라미터들을 객체로 감싸서 넘길지 말지, 프로젝트 폴더구조를 어떻게 해야할지 등..
그러다보니 기능구현을 하기도 전에 지쳐버리는 경우가 있었어요.
너무 체력을 소모하는거 같아 이 버릇을 고치려고 노력했던 기억이 나네요
나름 클린하게 리팩토링 해놓은 플젝 레포지토리를 몇년뒤 다시봤을때 내가 왜 이렇게 피곤하게 해놨을까 했던 기억도 나네요 ㅋㅋ
근데 그런 노력이 쌓여서 더 최적의 코드를 만들 수 있는 것 같아요 ㅎㅎ
편집과 설명 ..... ..우리 여고생님 짱이야
늘 그렇듯 깔끔하고 명쾌한 설명에 속이 시원하네요. 감사합니다.
진찌 맞는말임 ㅋㅋ 요즘 주니어 중급 개발자들이 이책대로 하면 좋은줄알고 코드를 이렇게짜서 ... 하.... 맞춰주기.너무 힘든 시니어의 넉두리... 그냥 경험밖에 답이 없으니...
기술면접에서 클린코드로 함정질문을 파놓는다는 영상을 본적이 있는데 이걸 너무 신봉해서 주변사람들 피곤하게 만드는 사람인가 아닌가 확인할라고 하는거였네요
역시 너무 과하지도 덜하지도 않는게 좋은거같습니다
김포프님 채널 아닌가요. 그건 저도 동감입니다.
사실 리팩토링을 자주 해보는 습관을 들이면 어느정도 앞으로 어떻게해야될지 답이 보임.
근데 그런거 없이 저런책하나 정독하고 지가 싸놓은 똥 한번 안치워본 인간이 저게 바이블이라면서 지하고 싶은데로만 빠득빠득 우기면 피가 꺼꾸로솟는거임.
제발 그러지 맙시다...
스펀지밥 절하는거 보고 안들어올 수가 없었다
저도 처음 개발할 때 저 책읽고 광신도마냥 코딩 했다가 개욕먹었습니다 ㅋㅋㅋ 후에 고수분들이 해놓은 코드를 보면서 배운것을 요약하자면, 명확하게 장점이 더 큰 선택이 있기도 하지만, 작업의 깊이가 깊어질수록 이를 구분하기 점점 어려워진다는 것입니다. 필요성을 명확하게 파악한다면 아키텍쳐를 명확하게 만들어낼 수 있지만, 그 필요성에 불확신이 가미될수록 어떻게 아키텍쳐를 구성해야되는지 구분하기 어려워진다는 것입니다. 따라서 고수분들의 필요성을 파악하고 정의해내는 능력을 우선 배우고 있습니다. 그렇게하면 코드 구조는 각 상황에서 어느정도 최선의 것이 존재한다는 것을 알았습니다.
ㅋㅋㅋ 이번 영상은 클린코드라는 책의 문제점을 정확하게 지적해 주셨네요. 특히 함수 부분 너무 시원합니다. 쭉 한 번 보면 그냥 알 수 있음에도 불구하고 함수를 무조건 나누려는 인간들이 있어요. 정말 광신도들은 답이 없어요. 더 한심한 건 너무 많아진 함수들이 관리되지 않아서 같은 기능의 함수들을 또 만드는 미친 인간도 있더군요. 환장합니다.
그건 잘못 이해한 사례인데
@@silver33412님이 그렇다고 말하는 것은 절대 아님을 미리 말하고요. 진짜 잘 하는 사람들도 해당 안 됩니다. 가장 큰 문제는 실력도 없는 사람들이 광신도처럼 맹신을 하는 바람에 현업에 방해가 되는 경우가 엄청 많다는 거죠. tdd도 마찬가지. 맹신을 하면 절대 안 되고 상황에 따라 내가 활용한다는 생각으로 접근을 해야 하는데 아무 생각없이 함수를 다 나눠서 나중에 자신이 그 함수들을 관리 못 하고 또 똑같은 함수들을 만들기도 하더군요. 나중엔 마땅한 함수명 고르는데도 시간 낭비... 이 영상도 그런 부분이 지나침을 말하는 거죠. 병적으로 함수를 나누려고 하지 마라...
@@심심하다능-r6w 뭔 말인지 모르겠는데 난 그냥 그 광신도 들이 잘못 이해한 사례라고 말하는건데 오해한듯?
@@silver33412 ㅋㅋㅋ 그렇군요 나의 실수.. 그리고 님 말씀이 맞죠. 제대로 이해를 못하고 맹신한 결과죠.
훌륭하십니다.❤
1:07
함수로 감싸놓음으로서 동작이 의도하는바가 뭔지 알기쉽고 동작들을 구분하기 쉬움
문제 생긴곳 파악도 쉬움
1:51
주석의설명과 코드의 실제작동방식이 일치하는것은 보장할 수 없음 좋은 코멘트의 예시들은 괜찮지만 실제코드의 작동방식이나 사이드이펙트에대한 주석은 지양하는게 좋음 차라리 변수명이나 함수명을 잘지어서 코드에 들어나게하는게 정답임
3:11
길고복잡한 변수명과 함수명은 하나가 너무큰역할을 하기때문임 분리해서 쪼개야함
4:15
공통된 부분을 우선묶는게 좋음 . 후에 if나 switch문 같은걸로 쪼개는게 아니라 각동작을하는 함수를 만들어서 공통된함수를 사용하도록 래핑하면됨 주의해야할건 문맥상 완전 다른 위치에서 완전 다른의도로 운이좋아서 닮은 코드가 있는데 이건 구분을잘해서 따로둬야함
세상에 정답이 참 많아서 좋으시겠어요~
주석 부분이 이상한 이유에 대해 생각해봤는데 언어적 차이도 있는 거 같아요
영어가 모국어인 사람들은 그냥 코드만 읽어도 어느 정도 순식간에 이해할 수 있으니까요
근데 한국인들은 아무리 영어를 잘한다고 해도 미세한 속도 면에서 한국어 주석으로 읽을 때 코드를 더 빨리 이해할 수 있더군요
3:04 전설의 Quake 3 inverse square root...
f(x)=1/sqrt(x)를 나누기 혹은 루트 연산 "없이" 비트쉬프트만으로 계산하는 미친 함수죠
절대적인건 앖습니다. 상황에 맞게 선택할 뿐이죠. 상황판단의 통찰은 경험을 통해 만들어 지기에 결국 초보시절엔 그냥 따라하고 어느정도 경험쌓이면 자기에 맞게 판단하는 방법이 가장 빠르게 성장하는 길이라 생각합니다.
No Silver Bullet
제가 클린 코드 작성하면서 정말 느낀 부분들이네요. 코드 피드백 주고받으면서 제가 느끼기에는 주석이 있는게 훨씬 가독성이 좋아지는데 이걸 구지 없애고, 하나의 기능만 담아야 된다면서 엄청 나누는데 결국 가독성은 가져다 버리는... 잘 보고 갑니다
깨끗한 코드는 결국 추상화인데 과도한 추상화는 안좋다고도 하죠. 함수 이름에 동사넣으라는건 참 좋은 말이네요
본인이 의심하고 생각해야 한다는 것을 초기에 선배가 알려줬는데… 같은 말을 여기서 듣네요. 감사합니다
함수 메서드 네이밍은 정말 중요하다고 느낀게 함수명만 봐도 그 함수가 어떤 기능을 하는지 알 수 있다는게 가장 큰듯.
그럴려면 단일 책임 원칙이 지켜져야함 클린 코드 책내용이 대전제가 그렇다는거지 예외 케이스 없이 모든 상황에 적용하라는 말은 아님
오늘, 내 세상이 무너졌다
대학생으로서 공감되네요
항상 주석 달라고 하시고 과제에서 주석 없으면 감점이라고 하는 교수님들이 계실 정도
가장 좋은 것은 한눈에 보고 어떤 코드인지 알 수 있게 짜는 것이지만 우리들은 그렇게 못하기 때문에 주석을 무조건 달아야 한다고 하심
혼자하는 프로젝트라면 상관없지만 공동소유하는 코드에 주석은 유지보수가 되지않습니다.
과제 주석은 코드에 대한 이해도를 높이기 위해 쓰라고 하는 경우가 많음.
아무 생각 없이 짜던 코드도 주석 달아서 남에게 설명하다 보면 강제로 이해도가 올라가니까
@@garciakarim3544 주석이 있어서 거슬린다면 지워버리면 되며, 있으면 대부분 도움이 됩니다. 그냥 원래 코드를 개판으로 짜놓거나 혼자만 알아보게 짜놓고 주석에만 의존하고 주석에 떠넘기는 행태가 잘못된 거지 주석 자체가 문제가 아니란 말입니다. 대개는 주석 걸고 넘어지는 분들은 그냥 주석 없어도 전체적 코드 구조를 알아보는 눈이 없는 분이 많습니다. 주석이 방해만 되는 레벨에서는, 이미 아키텍쳐 수준이므로 주석이고 뭐고 짜증이 나지도 않고 별 대수가 안 됩니다. 한마디로 유난 떠는 사람들은 그냥 훌리건에 불과하다는 거에요.
와 오늘 서점에서 클린코드 찾다가 없어서 집에 왔는데 이런 영상이라니 아주 기가막힌 타이밍입니다.
구글은 다 보고있습니다.
ㅋㅋㅋ 이번 영상 극 공감합니다.
아닠ㅋㅋㅋㅋㅋ 짤이랑 말하는거 왤케 웃기죠. 빵빵 터지면서 보는 중
와우! 거부감 들었던부분 시원하게 말씀해주셨네요.
뭔가 속이 시원해지는 영상 이네요
저도 이 영상을 보고 말을 재미있게 하는 방법을 배웠구요
책 내용도 내용이지만 이름을 너무 잘지었어. 클린코드라니
항상 적당한게 좋다
이거 보고 유지보수 하기 어렵게 코딩하는 법 한권만 읽으러 갑니다.
혼자 취미로 코딩 하는거면 상관없는데
트레이드 오프라는 말이 괜히 있는게 아니죠
당연한 얘기겠지만 아키텍처나 디자인 패턴을 실무에 적용 하려고 노력하면 됨
정답은 없겠지만 이때 이런건 하면 안돼 라는건 분명 있어요 많이 적용해봐야 합니다
나는 주석이 필요없을 정도로 명쾌한 코드를 짜라는 걸로 이해하고 개발하고 있네요.
함수는 한가지 일만 하라는 것도 함수 이름에 포함되는 작업만 하라는 뜻으로 이해하면 좋은 방향이라고 생각해요.
주석을 달지 않음으로써 나만 알아봄으로 내 가치를 높이라는 깊은 뜻 일리가 없죠
상남자는 메인 함수에 다 때려넣고 주기적으로 리팩토링한다 이말이야
개추
상남자 ㅇㅈ
상남자는 리팩토링 하지 않는다
이게 맞다
@@redcomet150이건 미친놈이잖아요..
1:12 함수부분에 있어서
1. 협업을 할때 클린코드 따라가세요.
2. 혼자작업할때 한 함수에 다 적는게 가독성 더 좋습니다.
쓰는 상황에 따라 좀 다른거같습니다.
추상화단계를 어디까지 밟을 것인가는 매우 중요한 논점입니다. 동료개발자의 시간을 아껴주기위해서 최대한 선언형으로 작성할 필요가 있습니다.
코딩 안하고 모르는데 이영상을 그냥 보고있음
끝까지 다 봤다!!
뭔가 초보가 짠듯한 느낌의 코드인데 딱히 문제는 없고 물흐르듯 읽혀지면 그게 정말 좋은 코드 입니다.
괜히 복잡하게 있어보이게 중첩에 중첩에 추상화에 캡슐화에 최신 패턴 접목하면...그거 누가 봅니까?...자기만 볼려는거 아니면... 같이 일하는 사람 모두가 쉽게 쉽게 읽고 고칠 수 있어야 합니다.
주석은 쓰랄데기 없이 길게 쓰는 것보단 간결하게 쓰는게 좋아보임
어차피 코드도 한 번 읽어야하니까
이 부분에 정말 고만이 많았는데 결국 제 주관을 가지고 정보를 비판적으로 바라보는게 중요한것 같네요
코딩의 신 코딩애플이시여....
요즘 모던자바 인 액션을 읽고, 점점 클린코드 책에 대해 관심이 생겨가고 있었던 와중에 해당 영상을 통해 모던 자바 인 액션도 무작정 학습이 아닌, "왜?" 라는 생각을 좀 더 하게 되었으며, 모든 책에 대한 관점을 좀 더 유연하게 바꿔주는 영상인 것 같아 감사합니다.
솔직히 그냥 상식만 적혀있음. 이 것 처럼 대충 요약한 영상만 보면 됌
2:59 이 코드는 봐도봐도 쓴 놈이 미친놈임...
ㅋㅋㅋㅋ clean code에 대한 균형잡힌 관점을 알 수 있어서 좋았네요. 저도 약간 종교처럼 숭배했던 것 같으면서도... 뭔가 이렇게 까지 해야돼...? 라는 느낌을 지울 수가 없었거든요
대부분 동의합니다. 나중에 의견이 다를 때 참고용으로 쓰면 좋을거 같네요.
특히 간단한 코드인데 중복된다고 나누는 것보다 수정시에 노가다 해서 일일이 고치는 게 빠를거라면 중복해서 두는 것이 유지보수 면에서 더 나은 선택이라 생각합니다.
기본적으로 영어를 잘해야 네이밍을 잘하고,
네이밍을 잘해야 주석도 없앨 수 있는 거죠.
네이밍 잘하고 펑셔널 프로그래밍 잘하면
굳이 함수의 속까지 매번 뜯어볼 필요 없이 잘 읽히는 코드 되는 거고.
한참 유행했던 clean code 네요. 다만, 시니어급과 인터미디어급 개발자들이 해당 도서의 문제점도 언급하면서 함정 면접을 보는 경우도 많았고, 비판도 많이 받은 동시에 과거의 MS엔지니어들이 냈던 Code Complete가 다시 재조명을 받기도 했던게 기억나네요.
개발자는 아니어서 저 책을 많이 따라 했는데 ㅎㅎ 역시 두루두루 읽어 봐야 하군요.
입문자들을 위한 책은 아니고
장인을 향해나아가는 수준의 중니어들에서 시니어들에게 적절한 책입니다❤
펑션이야기도 클래스장과 이어진내용입니다
난 코딩애플만 본 개발자다
엄랭으로 취준을 하고 있지
와아 클린코드 두꺼워서 읽어야지 읽어야지 하다 안 읽었는데 한권다봤다 개꿀
4:30 이거 진짜 실무할때 많이 발생합니다.
어설프게 모듈화하는건 오히려 나중에 뜯어고치려면 더 복잡해져요
몇가지 팁..1. 변수를 줄여라..변수가 많다면 뭔가 잘못된거다. 변수를 줄여라 2. 함수이름은 전부 소문자로..헝가리 어쩌구하면서 대소문자 섞어쓰는데..대소문자 구분안하는 언어도 많다. 그런 언어 만나면 고생하니 그냥 전부 소문자로. 3. 탭으로 줄맞추기 잘해라. 가독성이 많이 올라감. 4. 람다함수 많이써라..코드가 짧아짐
클린코드 보면 20자 이상의 아름은 인지비용이 높아진다고 지양하라고 합니다. 3:10 쯤 나오는 예시는 부적절한 것 같네요.
좋은 영상이네요
사실상 개발 팁 끄적여 놓은 책 아닐까 싶네요.
저는 참고 도서로만 취급해야겠습니다.
하나하나 나름 다 요지는 있는 주장들임. 종교처럼 무조건 적용하려고 하니 문제지.
오늘 영상 정말 마음에 듭니다! 좋은 영상 만들어 주셔서 감사합니다.
중복 코드 허용은 진짜 맞는 말임
전혀 다른 기능에서 당장 똑같이 생긴거 있다고 함수로 묶은다음에 미묘하게 달라지면 if문 난사하게댐
기능이 다르면 각자 써야함 나중에 코드최적화 할때 판단해도 늦지 않음
책이든 어떤 글이든 항상 그 글에서 말할려고 하는 핵심내용이 뭔지를 파악하는게 중요한데 항상 결론만 가지고 와서 과대해석하는게 무섭죠
신입땐 최대한 지키려 노력했는데 ㅋㅋㅋ
하나하나공감되네요
세상 만사에 통용될 수 있는 말이네요.
속이 시~원합니다
포큐형님한테 들었던 내용이네요 ㅋㅋ
선생님 영상 좀 자주 올려 주십쇼
본인이 짠 코드를 다시 유지보수하고 또 유지보수를 하다보면 저 책, 이 영상과 거의 비슷한 생각을 하시게 될거에요..ㅎㅎ
진짜 맞는말인게 유독 하나만 읽고 그걸 맹신하는 사람들이 많음.. 읽으면서 무조건 받아들이지말고 비판적인 시각을 유지해야하는데.. 자기가 실력이 없다면 관련 서적을 읽으면서 잘은 모르겠지만 이 부분은 대체 왜 이렇게 해야하는거지 하면서 다른 관련 문서들도 찾아봐야하는데 그냥 유명한 책에서 맞다고하니까 의심없이 받아들이는 그런
자기 코드를 유지보수 하다보면, 중복 작성해둔 코드가 여기 저기 흩어져 있으니, 이걸 좀 더 실수를 줄이고, 신속하게 수정할 수 없을까 생각이 들 때, 힌트를 얻는 정도로 읽는게 좋은것 같아요
저는 개발 업무 10년 넘게 해본 사람으로서 한 가지 원칙에만 충실합니다.
"가독성"
이것만 좋으면 되요. 개발은. 근데 가독성이 좋으려면 결국 클래스, 함수 이름 및 구조, 변수 셋팅, api 호출 방식 등등 몽땅 잘 해야 한다는게 함정...
2번에 변론하자면 순수함수를 지향하란거 아닌가요?
함수가 순수하먼 내용을 안봐도 되면 좋죠
1:02 ...와 미친... 내 무습다... 함수 포장지 미쳤네...
디스같지만 중요한 책 내용은 잘 설명해주셨네요 ㅎㅎ 읽지말라는 거 정말인가요
함수 남발한 코드 보면 토 쏠려요..
함수 소스 찾아가다가 어 내가 왜 여기까지 왔지?? 합니다
3:00 부동소수점 역제곱근 알고리즘 아닌가요?
융통성과 비판적 사고의 중요성
1:13
JetBrains의 AI Assistant에서 리펙토링 시키면 딱 우측거대로 나옵니다 ㅋㅋㅋ
그리고 조용히 창을 닫죠
지능이 있으면 스스로 의문을 느끼고 고침
24년차 사골개발자인데... 잘보고 갑니다 공감이 많이 가네요 많이 배우고 갑니다 ㅋㅋ
주석에 할말이 많은데... 주석은 꼭 필요합니다. 나는 고수지만 초보가 봐도 이해를 해야하고 왜 이렇게 썼는지 어떻게 응용이 가능한지 정도 적어줘야 다음사람이 비판도 하고 가져다 쓰고...
이형 영상편집을 코딩처럼 짜고 있었어...
와... 이 형님 이제 10시간 만에 5만을 돌파하네.
감사합니다.. 혹시 전기장판같은건 안파시죠..?
강의같은건 팔던데요
오버 하지말란말을
클린코드는 틀렸다 라고 이해를 하시나 다들..
책에서 말하는 모든 것을 맹신하지 말고 이런 부분도 있으니 비판적 사고를 가지고 읽어라는 영상을 클린코드 책은 쓰레기다로 받아들이는 인간들이 댓글에 보이는데 한권만 읽고 맹신하는 자나 영상 하나 보고 전부까기 하는 자나 다를 바 없는 듯