코딩 책 한 권만 읽으면 이렇게 됩니다

[@이종엽-z4n]

클린코드 찬양하지 말라는 영상을 보고 무조건 부정적인 댓글 다는 아이러니한 사람이 많은듯... 극과 극은 통한다고 하더라고요

[@rendarcb1908]

진짜 공감하는게 함수랑 주석부분보고, 엥? 이런게 너무 많아서 이게 맞나 싶기도 했습니다. 특히 어느기업은 과제조차 주석자체를 극혐하는 곳도 많고 애초에 클린코드를 넣어버린 곳도 많은데 클린코드에 대한 부분을 명확히 인지하고 쓰는건지 의구심이 들뿐입니다. 그래서 저는 '클린코드'보단 '좋은코드 나쁜코드' 이 책을 더 많이 추천해주는 편입니다. 오히려 구글 엔지니어가 작성하여 직접 경험에 의한 내용이라서 더 좋고 실무에도 적용시킬 내용이 많아서 오히려 이책이 더 좋은거 같네요

[@St__Y]

@@rendarcb1908 함수 시그내처와 주석에 관한내용은 클린코드와 무관합니다. 훨씬 오래전부터 it업계 전반에 통용되던 것이며, 분야를 막론하고 구루급 개발자들이 공통적으로 하는 말입니다

[@drkim8425]

"주석이 거짓말을 한다" 라는 건 경험적으로 봤을때, 코드만 고치고 주석은 고치지 않은 사람들 때문이죠. 그러면 코드와 주석이 내용이 다르게 되고 주석이 거짓말을 하는 상황이 됩니다. 주석이 나쁜게 아닙니다. 코드를 고치고 주석은 고치지 않는 사람이 나쁜 거죠.

[@St__Y]

대부분은 주석만 안고치게 됩니다..... 주석을 달더라도 문단 제목을 달듯 간략한 코드 흐름정도만 표현하는게 낫다고 봅니다

[@zikpzi9759]

클린코드 제대로 안보셨네요. 그 안고치는 사람이 주석을 지양하는 이유 중 하나로 설명합니다...쩝...

[@St__Y]

덧붙여 주석 지양은 클린코드책과 별개로 원래 대부분의 it업계서 하던 말입니다. 왜 이걸 책한권만 읽고 모든걸 판단한다고 호도해버리는지 모르겠네요

[@pro-akpler]

그렇게 치면 이 세상에 나쁜 물건이 어딨음? 핵무기는 나쁜게 아닙니다. 쏘는 사람이 나쁜거죠.

[@junkman9010]

ㄹㅇ. 코드만 고치고, 주석 안 고치는 사람이 문제인거.

[@미르-h8m]

코딩애플 유튜브채널 하나만 보면 코딩 잘 할 수 있음

[@codingapple]

코딩이아니라 어그로 잘끌 수 있음

[@구민성-n7g]

개추 ㅋㅋ

[@Thj123]

개추

[@이지수-o2s]

나 코딩애플인데 개추눌렀다

[@lyueas]

엄준식 잘할 수 있음

[@Milk_Caramell]

난 가끔 생각해.. 이 형은 개발보다 영상편집의 재능이 더 뛰어난게 아닐까? 하는..

[@코딩할땐역시음악]

"정보미디어 전공 희망편"

[@슈퍼카2020]

개발자로만 구독자 20만명인데 메이져 쟝르 유튜버였으면 최소 100만 이상 하셨을듯 싶습니다

[@epro44ing3.1]

이거 인정하는 부분입니다

[@fxxkthatjeon]

코딩커뮤니케이터 ㅋㅋㅋㅋ

[@완곡한_욕]

코딩의 C도 모르는데 재밌어요

[@Springfield990]

C++로 유명한 유튜버 분도 2년 전에 클린 코드 책 엄청 깠던 거 보고, 클린 코드에 대해서 비판적으로 접근하기 시작했는데, 정작 제가 이런 말 하니깐 주위에서는 절 이상한 사짜 취급하더라구요. 한 번 신랄하게 까주셔서 감사합니다.

[@실험맨]

비판을 하면 좋은 경험을 가졌던 사람에게서 반박이 따를수밖에 없죠 그런 경험적 부분은 서로 설득도 안되니 권위가없다면 사짜취급은 감수할수밖에..

[@추멘]

그분 포프님인가

[@bwshin413]

보통 저런책들 박사들이 내니까 바이블 삼는 사람들은 니가 그 박사들보다 잘알아? 대단해? 이런식으로 걍 권위에 맡기기 하는...

[@jkkim6928]

클린 코드를 비판해서 욕 먹은 게 아니라 비판을 제대로 된 논리와 근거 없이 해서 욕 먹은 걸 거라는 게 댓글을 통해서 짐작이 되네 ㅋ

[@codex-oe3xu]

포프도 딱히 잘 알고 말하는거는 아니라...

[@jmash6651]

1:19 왔다갔다하는게 아니라 함수 이름으로 읽고 그런 일을 하는구나하고 자세히 분석하지 않고 그냥 넘어가면 됩니다. 잘 짜져 있는 코드라면 그렇게 하면 됩니다. 왔다갔다하라고 저렇게 하는거 아니에요. 주석처럼 함수 이름 만드는거에요

[@s-saens]

중복에 대한 얘기는, 같은 저자가 쓴 클린 아키텍처 책을 보시면 알겠지만, 마틴님도 영상에 나온 예시와 같은 경우는 코드를 다 분리해서 쓰는게 좋다고 말합니다. 애초에 유스케이스를 제대로 분리하지 못해서 생긴 '가짜 중복'이라며, "중복은 없어야돼!"라는 강박때문에 함정에 빠져선 안된다고 저자도 얘기하더라구요.

[@2dubbing]

경력이 쌓이고 그 과정속에서 여러 프로젝트를 개발하다보면 본인만의 개발 철학이 생기는거 같아요. 저도 신입때는 함수의 파라미터들을 객체로 감싸서 넘길지 말지, 프로젝트 폴더구조를 어떻게 해야할지 등.. 그러다보니 기능구현을 하기도 전에 지쳐버리는 경우가 있었어요. 너무 체력을 소모하는거 같아 이 버릇을 고치려고 노력했던 기억이 나네요 나름 클린하게 리팩토링 해놓은 플젝 레포지토리를 몇년뒤 다시봤을때 내가 왜 이렇게 피곤하게 해놨을까 했던 기억도 나네요 ㅋㅋ

[@다루루]

근데 그런 노력이 쌓여서 더 최적의 코드를 만들 수 있는 것 같아요 ㅎㅎ

[@redDotStory]

주도적 비판적 학습을 위해 꼭 필요한 말씀이네요. 감사합니다!

[@닉네임-y5f9e]

저희 학원 쌤은 딱 이 정도 강요합니다. 1. 코드를 더 함축적으로 쓸 수 있는거 아니면 풀어 짜라. 2. 주석 없애고 싶으면 야근은 각오해라. 3. 변수명은 기존 팀원들 코드를 둘러보고 알잘딱 따라가라. 그게 시간 단축이다. 4. 이동이 3회 이상 벌어지는 코드는 재활용 하지 말고 그냥 새로 써라.

[@postgres2981]

이게 코딩이 영어라고 영어로 쓰인 것들 맹신하는 사람들 있는데 실상은 한국인들이 코드 겁나 잘 짬

[@postgres2981]

근데 5번의 경우는 어떤걸 말하는건가요?

[@윤빈-u4w]

1:07 함수로 감싸놓음으로서 동작이 의도하는바가 뭔지 알기쉽고 동작들을 구분하기 쉬움 문제 생긴곳 파악도 쉬움 1:51 주석의설명과 코드의 실제작동방식이 일치하는것은 보장할 수 없음 좋은 코멘트의 예시들은 괜찮지만 실제코드의 작동방식이나 사이드이펙트에대한 주석은 지양하는게 좋음 차라리 변수명이나 함수명을 잘지어서 코드에 들어나게하는게 정답임 3:11 길고복잡한 변수명과 함수명은 하나가 너무큰역할을 하기때문임 분리해서 쪼개야함 4:15 공통된 부분을 우선묶는게 좋음 . 후에 if나 switch문 같은걸로 쪼개는게 아니라 각동작을하는 함수를 만들어서 공통된함수를 사용하도록 래핑하면됨 주의해야할건 문맥상 완전 다른 위치에서 완전 다른의도로 운이좋아서 닮은 코드가 있는데 이건 구분을잘해서 따로둬야함

[@7mandalorian]

세상에 정답이 참 많아서 좋으시겠어요~

[@giseokchoe]

동의합니다. 뭐든지 적당히 받아들이는 유연함이 필요하죠. ㅎㅎ 클린을 강조했다고 해서 결벽증 환자가 되라는 말은 아닙니다.

[@leopoId]

클린 코드라는 책이 오래됐기도 하고 어느정도 걸러서 들어야 하는건 사실입니다. 그런데 결국 저자가 하고 싶은 말은 코드 그 자체가 의도를 충분히 설명할 수 있어야 한다는 것 같아요. 함수 부분에서 "왔다갔다 하느라 훨씬 읽기 어렵다" 하신 부분도 사실 원래 의도대로라면 왔다갔다 할 필요가 없죠. "왔다갔다" 하지 않아도 뭘 하는지 알 수 있도록 함수 이름을 지으라는 뜻이니까.

[@실험맨]

네 이영상은 그런 말을 합니다.

[@김재훈-z9v]

​@@실험맨 몇초 부근인지 남겨주시면 감사하겠습니다 제가 놓쳤는지 안보이네요😅

[@enru2251]

코드는 깔끔하게, 함수 네이밍도 알맞게 지어 놨어도 주석을 달았다는 이유만으로 배격하는 사람들이 있습니다. 그걸 실제로 당해보면 사실 약간 어이가 없죠.

[@검바위길]

결국 책에서 얘기하고자 하는 의미도 그게 맞죠 단순히 다 쪼개야한다는 맹목적인 의견이 아니라 절차지향적인 코드로 인해서 가독성이 떨어지는 코드를 지양하고 선언적인 형태로서 줄글쓰듯이 하는걸 권장하는거니까요

[@vanillarootbeer]

@@실험맨 혹시 어디서 나오나요?? 1:20 에서 동영상은 가독성은 작게 분리해놓은거보다 합쳐놓은게 가독성이 더 좋다고 하던데요. 개인차가 있겠지만 저는 따로 분리해놓은게 더 가독성이 있다고 느낍니다. 적어도 함수 이름과 실제로 동작하는게 동일하다면요.

[@그루브-i3i]

주석이 거짓말을 하는 경우 -> 먼저 써놓고 나중에 코드를 수정했는데, 까먹거나 귀찮아서 주석을 수정 안했음

[@kwj_nekko_6320]

실무자 입장에서 특정 책에 대한 맹신을 경계하게 하는 아주 좋은 영상 같습니다. 거의 전적으로 동의합니다! Clean code는 개념도 그렇고, 저 책의 출간 목적도 그렇고, 결국은 "나랑 전혀 관계없던 사람"이 와서 봤을 때도 내 코딩 의도가 완전히 전달되어야 한다는 게 지상목표이고, 이런저런 '팁'은 전부 그걸 달성하기 위한 수단 중 하나에 불과하지요. 극단적으로 얘기했을 때 우리 팀 전원이 어느 날 갑자기 해고되거나 비행기사고로 몰살당하거나 해도 프로젝트가 계속될 수 있어야 합니다. 그 목표를 위해서 때로 다양한 기능을 한 클래스에 몰아넣거나, 주석에 약간 구질구질한 설명을 넣거나 하는 일이 필요하다면, 그렇게 하는 게 더 우선되어야 하는 거죠.

[@bwshin413]

책에서 이랬는데 라고 권위믿고 맹신하기엔 진짜 개발이 영역마다 프젝마다 케바케가 심해서 참고는 하면 좋지만 실제 생산성 떨어지고 불편함 많고 이런데도 맹목적으로 룰을 따라야 좋아 하는건 다시 생각해볼만...

[@CongNim]

저도 처음 개발할 때 저 책읽고 광신도마냥 코딩 했다가 개욕먹었습니다 ㅋㅋㅋ 후에 고수분들이 해놓은 코드를 보면서 배운것을 요약하자면, 명확하게 장점이 더 큰 선택이 있기도 하지만, 작업의 깊이가 깊어질수록 이를 구분하기 점점 어려워진다는 것입니다. 필요성을 명확하게 파악한다면 아키텍쳐를 명확하게 만들어낼 수 있지만, 그 필요성에 불확신이 가미될수록 어떻게 아키텍쳐를 구성해야되는지 구분하기 어려워진다는 것입니다. 따라서 고수분들의 필요성을 파악하고 정의해내는 능력을 우선 배우고 있습니다. 그렇게하면 코드 구조는 각 상황에서 어느정도 최선의 것이 존재한다는 것을 알았습니다.

[@zaqxswc273]

이제 유지보수하기 어렵게 코딩하는방법만 읽으면 완벽하군요

[@iyj9152]

인수인계자를 ㅅㅏㄹ...

[@pollinipill]

지금 나이 오십. 프로그래머 34살까지 하고 그만뒀는데 지금 봐도 재밌네. 나 때 이런 사람 있었으면하고 감탄하고 갑니다.

[@Boy-qp7hw]

기술면접에서 클린코드로 함정질문을 파놓는다는 영상을 본적이 있는데 이걸 너무 신봉해서 주변사람들 피곤하게 만드는 사람인가 아닌가 확인할라고 하는거였네요 역시 너무 과하지도 덜하지도 않는게 좋은거같습니다

[@yangseungtoung]

김포프님 채널 아닌가요. 그건 저도 동감입니다.

[@youropinioncomment]

진찌 맞는말임 ㅋㅋ 요즘 주니어 중급 개발자들이 이책대로 하면 좋은줄알고 코드를 이렇게짜서 ... 하.... 맞춰주기.너무 힘든 시니어의 넉두리... 그냥 경험밖에 답이 없으니...

[@billtrima]

와 개깔끔하네.. 5분만에 이 모든걸 이렇게 설득력있게 풀어내다니.. 항상 느끼지만 이번 영상은 더욱 걸작이네요. 모든 내용에 동의합니다.

[@r3b00t3]

코드의 의도를 분명하게 담아내는 주석 작성방법만 익혀도 이사람 배려할 줄 아는 사람이구나 느낄수 있어요, 괜히 시니어들이 주석 활용 잘하는게 아님

[@tarakkyu]

코드의 중복 제거 여부는 명확한 기준이 있다고 생각해요. 중복된 코드가 논리적으로 같은 의미이고 둘중 하나가 바뀌었을 때 다른 하나도 같이 바뀌어야 한다면 무조건 함수로 빼야합니다. 변경을 누락하는 실수를 방지할 수 있기 때문이죠. 하지만 중복 코드간 구현이 같더라도 논리적인 의미가 다르면 함수로 추출해선 안 됩니다. 한 부분의 수정이 다른 부분에 의도치 않은 사이드 이펙트를 줄 수 있기 때문이에요. 좋은 영상 감사합니당 굿

[@jsysonjung]

@@arisa3364ㅎㅎ 그래도 기준은 있어야죠.

[@아니야응-k5s]

동의합니다

[@이름-y8i]

코드의 중복이 아니라 논리의 중복이죠 사실 ㅎㅎ 예를 들어 세금 10% 계산로직과 팁 10% 계산로직이 우연히 같다고 해서 하나의 함수로 빼버리는 순간 지옥이 시작되는거죠. 팁이 5%로 바뀐순간 세금이 바뀌는 버그가 생기고, 이걸 해결하겠다고 세금/팁 타입을 넣고 분기를 넣기 시작하면 만든사람만 아는 레거시가 되는거죠 ㅋㅋ 이땐 코드가 아니라 한걸음 물러서서 추상화된 개념을 생각해야 하고 그냥 분리해야합니다. 코드만 보고 단순하게 리팩터링하면 걸리기 쉬운 함정입니다 ㅎㅎ

[@jsysonjung]

@@이름-y8i 맞아요 원댓글하고 같은 말씀

[@이동훈-f6q]

주저리주저리 조건 달아 놓고 무조건이라는 말을 쓰는건 무조건이라는 뜻을 모르나? 코딩 공부 전에 국어공부부터 다시해야할 듯 ㅋ

[@초콜릿바나나-e1v]

사실 리팩토링을 자주 해보는 습관을 들이면 어느정도 앞으로 어떻게해야될지 답이 보임. 근데 그런거 없이 저런책하나 정독하고 지가 싸놓은 똥 한번 안치워본 인간이 저게 바이블이라면서 지하고 싶은데로만 빠득빠득 우기면 피가 꺼꾸로솟는거임. 제발 그러지 맙시다...

[@계란찜-j8x]

1:12 함수부분에 있어서 1. 협업을 할때 클린코드 따라가세요. 2. 혼자작업할때 한 함수에 다 적는게 가독성 더 좋습니다. 쓰는 상황에 따라 좀 다른거같습니다. 추상화단계를 어디까지 밟을 것인가는 매우 중요한 논점입니다. 동료개발자의 시간을 아껴주기위해서 최대한 선언형으로 작성할 필요가 있습니다.

[@HongLab]

스펀지밥 절하는거 보고 안들어올 수가 없었다

[@SunnyKimDev]

3:04 전설의 Quake 3 inverse square root... f(x)=1/sqrt(x)를 나누기 혹은 루트 연산 "없이" 비트쉬프트만으로 계산하는 미친 함수죠

[@바사삭-r2x]

혼자 취미로 코딩 하는거면 상관없는데 트레이드 오프라는 말이 괜히 있는게 아니죠 당연한 얘기겠지만 아키텍처나 디자인 패턴을 실무에 적용 하려고 노력하면 됨 정답은 없겠지만 이때 이런건 하면 안돼 라는건 분명 있어요 많이 적용해봐야 합니다

[@davidlee0706]

편집과 설명 ..... ..우리 여고생님 짱이야

[@enru2251]

늘 그렇듯 깔끔하고 명쾌한 설명에 속이 시원하네요. 감사합니다.

[@shoonch911]

1:13 JetBrains의 AI Assistant에서 리펙토링 시키면 딱 우측거대로 나옵니다 ㅋㅋㅋ 그리고 조용히 창을 닫죠

[@chorong0824]

요즘 모던자바 인 액션을 읽고, 점점 클린코드 책에 대해 관심이 생겨가고 있었던 와중에 해당 영상을 통해 모던 자바 인 액션도 무작정 학습이 아닌, "왜?" 라는 생각을 좀 더 하게 되었으며, 모든 책에 대한 관점을 좀 더 유연하게 바꿔주는 영상인 것 같아 감사합니다.

[@2ndintelligentWorld]

솔직히 그냥 상식만 적혀있음. 이 것 처럼 대충 요약한 영상만 보면 됌

[@namedmaster1842]

01:14 둘 다를 만족하기는 힘들죠. 왼쪽은 가독성이 좋고. 오른쪽 책 대로면 코드의 안정성이 높습니다. 보고 설명하고 말하려면 왼쪽 코드가 좋고, 한번 짜고 튼튼하게 더 안 보려면 오른쪽 책 스타일이 좋으니 코드 짜 놓고 왜 문제인지 여러 방법으로도 잘 해결 안되면 오른쪽 책 스타일처럼 코드 다 바꿔 버리면 찾는데 도움이 될 겁니다. ( 그런데...이거 근본은 80년대 c , 90 년 c++ 로 가면서 컴파일 , 빌드 느리던 시절 사람 능력으로 커버하는 관점이 좀 들어간 거 같기는 합니다. ) 02:08 이것도 책 내용이 틀리지는 않았습니다. 주석으로 사실 거짓말도 쓸 수 있죠. 내가 나에게 잘못 남기기도 합니다. 그러나 코드는 거짓말을 하지 않죠. 오히려 주석을 남기고 활용하는 건 프로그래밍 실력이 꽤나 안정적인 사람들에게만 해당한다고 봅니다. 프로젝트를 넘겨 받는 경우 앞 선 담당자의 실력이 나쁘면 주석만 믿고 분석하면 힘들어집니다. ( 코딩 실력이 낮은데 과연 주석이 제대로된 설명일까요? ) 반대로 앞 선 담당자가 상당한 실력자면 거의 주석만 보고 넘겨도 될 경우도 많죠. 02:23 그 사람들이 이런 책보고 코드만으로 가독성을 높이려는 거 아니고 오랜 경험으로 하는 소리입니다. 그리고 개발할때 이렇게 해야한다 이렇거 사실 다 무시하고 개발해도 잘 돌아갑니다. 이 사람 저 사람 의견이 다르죠. 다 맞는 얘기는 아닐거고 적당히 내 취향에 따라서 필요에 따라서 적당히 적용하면 될 겁니다. 이런거 저런거 코드 다 봤는데 모든 상황에 다 좋은 방식은 없는 거 같습니다. 필요에 따라서 선택해서 일정 부분 개발에 적용하는 게 좋을 거 같습니다.

[@임지후-q6s]

좋은 내용입니다👍

[@실험맨]

영상에선 틀렸다 라고 한적도 없는데. 심지어 님이랑 같은결로 말해요 ㅋ

[@tamatama1]

음소거 상태로 보셨나요? or 영상 넘기면서 보셨나요..?? 코멘트에서 하시는 말씀이 영상 내용하고 똑같아요

[@user-yeasewaasfe]

코드의 안정성이 높은만큼 유지보수성이 떨어지죠 무슨 전자레인지에 들어가는 펌웨어같은 한번 짜고 튼튼하게 더 안볼 수 있는 코드라면 모르겠지만 os가 바뀌고 사용 기기가 바뀌는 요즘의 프로그램 구동 환경에서 코드만 안정성이 높으면 뭐하나요. 업데이트 한번에 프로그램 전체가 망가져버리기나 할텐데

[@namedmaster1842]

@@실험맨 글쎄요. 막 책 내용 까고 내 말도 비판없이 받아들이진 마라가 같은 내용이라니요.

[@ResponseEntity]

함수 메서드 네이밍은 정말 중요하다고 느낀게 함수명만 봐도 그 함수가 어떤 기능을 하는지 알 수 있다는게 가장 큰듯. 그럴려면 단일 책임 원칙이 지켜져야함 클린 코드 책내용이 대전제가 그렇다는거지 예외 케이스 없이 모든 상황에 적용하라는 말은 아님

[@user-kid3wjx5cg]

뭔가 초보가 짠듯한 느낌의 코드인데 딱히 문제는 없고 물흐르듯 읽혀지면 그게 정말 좋은 코드 입니다. 괜히 복잡하게 있어보이게 중첩에 중첩에 추상화에 캡슐화에 최신 패턴 접목하면...그거 누가 봅니까?...자기만 볼려는거 아니면... 같이 일하는 사람 모두가 쉽게 쉽게 읽고 고칠 수 있어야 합니다.

[@AlexanderDavis137]

클린코드 보면 20자 이상의 아름은 인지비용이 높아진다고 지양하라고 합니다. 3:10 쯤 나오는 예시는 부적절한 것 같네요.

[@5dksdev767]

주석 부분이 이상한 이유에 대해 생각해봤는데 언어적 차이도 있는 거 같아요 영어가 모국어인 사람들은 그냥 코드만 읽어도 어느 정도 순식간에 이해할 수 있으니까요 근데 한국인들은 아무리 영어를 잘한다고 해도 미세한 속도 면에서 한국어 주석으로 읽을 때 코드를 더 빨리 이해할 수 있더군요

[@조용현-f2t]

ㅋㅋㅋㅋ clean code에 대한 균형잡힌 관점을 알 수 있어서 좋았네요. 저도 약간 종교처럼 숭배했던 것 같으면서도... 뭔가 이렇게 까지 해야돼...? 라는 느낌을 지울 수가 없었거든요

[@dbsdbs17]

현업자들의 조언을 듣고 싶음.. 사수가 없음.. 이 영상 같은 영상 꿀임....

[@검바위길]

그래도 책은 읽어보세요 읽고나서 책에서 지향하는대로도 해보시고 시행착오도 겪으시면서 개발 철학을 쌓아나가시는게 중요합니다 명서는 명서인 이유가 있는거예요

[@최민석-x7c]

이 영상도 이 책은 구리니까 읽지 마라 라는 말이 아니라 책을 읽되 하나의 책을 맹신하지 말고 여러 책을 읽어보며 직접 어떤 코드가 좋은지 생각해보자 라는 의도인 것 같습니다

[@dhp5865]

초기 프로그래밍 언어, 예를 들면 초기 basic 언어에서는 function과 subroutine이 구분 되었고, function은 정말 단순하게 인수들을 이용해서 결과값를 넘겨주는 역할을 하고, subroutine에서 function의 결과값 등을 처리하는 일을 하도록 기능이 분화되어 있었음. 이렇게 기능이 분화된 언어에서는 function이 단순 명확하면 좋고, subroutine에서 복잡한 처리를 하는 게 나았음. 그런데... C 언어처럼 function과 subroutine을 구분 않는 언어가 대세가 되어버림. 편한 면도 있지만, 구분 않고 사용하면서 발생하는 난잡함은 프로그래밍 산업화와 규모가 커치면서 감당하기 힘들어짐. 그렇게 문제가 있는 대세를 따르면서, 그렇게 구분 못하는 언어를 쓰면서, function을 function/subroutine 구분하는 언어처럼 사용하라고 하면? 무지한 소리하고 할 수 밖에...

[@hkkun85]

2번에 변론하자면 순수함수를 지향하란거 아닌가요? 함수가 순수하먼 내용을 안봐도 되면 좋죠

[@nyaaaaaru]

3:00 부동소수점 역제곱근 알고리즘 아닌가요?

[@퇴근언제하늬]

함수를 가볍게 짧게 만드는 것은 메서드명을 통해서 가독성을 개선하는 것에 있는데요. 일일이 한줄 한줄 다 읽어가지 않아도 어떤 내용인지 직관적으로 파악함에 있어요. 책으로 치면 목차같은 느낌으로... depth가 너무 깊어지는 것도 가독성에 방해가 되니 적절하게 나누는 게 짬바이브 아닐까요?

[@leesangbin]

훌륭하십니다.❤

[@yeominsu]

저도 이 영상을 보고 말을 재미있게 하는 방법을 배웠구요

[@vanillarootbeer]

모든 일이 그렇듯이 책 하나만 읽고 맹종하는게 문제. 비슷한 예로 디자인패턴 배웠다고 모든걸 디자인패턴으로 만드려고 하는 사람들이 있음. 나도 그랬거든ㅋㅋ 취미로 프로그래밍하는 초보라서 업계에서는 어떻게 하는지 모르겠지만 적어도 나한테는 클린 코드는 유용했음. 개인적으론 주석은 별로 안좋아하는데, 쓰면 안된다는 정도는 아니지만 코드는 주석없이 이해할 수 있게 작성하는게 자신과 다른 사람들을 위해 좋은 것 같음. 물론 개인적인 의견임. 옛날에 작성한 코드 주석 적은거 봐도 솔직히 도움 안되던데ㅋㅋ 코드 협업하는게 참 어렵다는걸 이것만 봐도 알겠는게, 코드는 자기 철학이 들어가기 마련임. 다른 사람 사소한 띄어쓰기까지 거슬린다ㅋㅋ 코딩을 업으로 하는 사람들은 당연히 여러 책을 읽어야겠지만, 취미로 하는 사람에게는 이 책을 기준으로 삼아도 나쁘지 않음. 어차피 나중에 코드 개판인건 마찬가지라ㅎㅎ 여기서 좀 더 깊이 들어가는 사람은 다른 책도 읽어보는거고, 그거 아니면 그냥 그 개판 자체를 즐기는 거고. 동영상은 비판하고 있긴 하지만, 개인적으론 책 읽으면서 함수 이름 짓는거, 매개변수 개수 정하는거 도움 많이 받았음. 아 그리고 번역서는 내용이 약간 이상해서 원서 읽는걸 추천.

[@skybeeee]

1:50 여기서 육성으로 육두문자가 튀어나오는 걸 참을 수 없었습니다. 주석을 쓰지 말라고요? 뭐요 C++bal?

[@강민모-n9p]

오늘, 내 세상이 무너졌다

[@gim2origin]

대부분 동의합니다. 나중에 의견이 다를 때 참고용으로 쓰면 좋을거 같네요. 특히 간단한 코드인데 중복된다고 나누는 것보다 수정시에 노가다 해서 일일이 고치는 게 빠를거라면 중복해서 두는 것이 유지보수 면에서 더 나은 선택이라 생각합니다.

[@윤보영-n1y]

아닠ㅋㅋㅋㅋㅋ 짤이랑 말하는거 왤케 웃기죠. 빵빵 터지면서 보는 중

[@비동기식딜미터기]

와 오늘 서점에서 클린코드 찾다가 없어서 집에 왔는데 이런 영상이라니 아주 기가막힌 타이밍입니다.

[@실험맨]

구글은 다 보고있습니다.

[@하이젠버그-b3b]

한참 유행했던 clean code 네요. 다만, 시니어급과 인터미디어급 개발자들이 해당 도서의 문제점도 언급하면서 함정 면접을 보는 경우도 많았고, 비판도 많이 받은 동시에 과거의 MS엔지니어들이 냈던 Code Complete가 다시 재조명을 받기도 했던게 기억나네요.

[@zetware1]

24년차 사골개발자인데... 잘보고 갑니다 공감이 많이 가네요 많이 배우고 갑니다 ㅋㅋ 주석에 할말이 많은데... 주석은 꼭 필요합니다. 나는 고수지만 초보가 봐도 이해를 해야하고 왜 이렇게 썼는지 어떻게 응용이 가능한지 정도 적어줘야 다음사람이 비판도 하고 가져다 쓰고...

[@juneekim7]

오늘 영상 정말 마음에 듭니다! 좋은 영상 만들어 주셔서 감사합니다.

[@시]

책 내용도 내용이지만 이름을 너무 잘지었어. 클린코드라니

[@junkman9010]

코드는 글 쓰는거랑 비슷한 것 같음. 잘 모르겠으면 일단, 다 때려넣은 다음에 다시 다듬는 작업이 필히 있어야 됨. 그 다듬는 작업을 중간에 할 수 있는가? 가 얼마나 깔끔한 코딩을 만들 수 있는가의 차이인 듯.

[@심심하다능-r6w]

ㅋㅋㅋ 이번 영상은 클린코드라는 책의 문제점을 정확하게 지적해 주셨네요. 특히 함수 부분 너무 시원합니다. 쭉 한 번 보면 그냥 알 수 있음에도 불구하고 함수를 무조건 나누려는 인간들이 있어요. 정말 광신도들은 답이 없어요. 더 한심한 건 너무 많아진 함수들이 관리되지 않아서 같은 기능의 함수들을 또 만드는 미친 인간도 있더군요. 환장합니다.

[@silver33412]

그건 잘못 이해한 사례인데

[@심심하다능-r6w]

​@@silver33412님이 그렇다고 말하는 것은 절대 아님을 미리 말하고요. 진짜 잘 하는 사람들도 해당 안 됩니다. 가장 큰 문제는 실력도 없는 사람들이 광신도처럼 맹신을 하는 바람에 현업에 방해가 되는 경우가 엄청 많다는 거죠. tdd도 마찬가지. 맹신을 하면 절대 안 되고 상황에 따라 내가 활용한다는 생각으로 접근을 해야 하는데 아무 생각없이 함수를 다 나눠서 나중에 자신이 그 함수들을 관리 못 하고 또 똑같은 함수들을 만들기도 하더군요. 나중엔 마땅한 함수명 고르는데도 시간 낭비... 이 영상도 그런 부분이 지나침을 말하는 거죠. 병적으로 함수를 나누려고 하지 마라...

[@silver33412]

@@심심하다능-r6w 뭔 말인지 모르겠는데 난 그냥 그 광신도 들이 잘못 이해한 사례라고 말하는건데 오해한듯?

[@심심하다능-r6w]

@@silver33412 ㅋㅋㅋ 그렇군요 나의 실수.. 그리고 님 말씀이 맞죠. 제대로 이해를 못하고 맹신한 결과죠.

[@Mryourvideo]

본인이 의심하고 생각해야 한다는 것을 초기에 선배가 알려줬는데… 같은 말을 여기서 듣네요. 감사합니다

[@haesungcho5655]

하나의 메소드만 ㅋㅋㅋㅋ 이 부분에 제 생각을 추가 해 본다면 공통 기능을 뽑아 쓴다고 할때 확장성이나 특수성을 고려 해야 하는게 더 중요할 것 같고 이는 곳 자신이 개발하는 서비스에 대한 이해도가 높아야 알 수 있는 부분이라고 봅니다. 코드를 잘 짜는 것도 물론 중요하지만 개발은 그 외에도 확장해서 생각해야 될 부분이라고 생각합니다.

[@msahn3722]

나는 주석이 필요없을 정도로 명쾌한 코드를 짜라는 걸로 이해하고 개발하고 있네요. 함수는 한가지 일만 하라는 것도 함수 이름에 포함되는 작업만 하라는 뜻으로 이해하면 좋은 방향이라고 생각해요.

[@BSSeo-u3k]

개발자는 아니어서 저 책을 많이 따라 했는데 ㅎㅎ 역시 두루두루 읽어 봐야 하군요.

[@목부]

코딩의 신 코딩애플이시여....

[@user-mask23dssdcxz]

보통실무 경험이 부족한 어린 개발자들 중 저런 케이스가 많죠 맹신론적으로 클린코드네 클린아키텍처네 하면서, 실제 비즈니스 요구사항에 맞게 일하지도 못하고... 결국 개발자에게'코딩'을 잘하기 전에 상황에 맞게 '일'을 잘하는 역량이 필요한데 그런 유연성이 부족한 친구들이 많습니다.

[@dolfalf]

절대적인건 앖습니다. 상황에 맞게 선택할 뿐이죠. 상황판단의 통찰은 경험을 통해 만들어 지기에 결국 초보시절엔 그냥 따라하고 어느정도 경험쌓이면 자기에 맞게 판단하는 방법이 가장 빠르게 성장하는 길이라 생각합니다.

[@wooz-e7z]

No Silver Bullet

[@리노rino]

이거 보고 유지보수 하기 어렵게 코딩하는 법 한권만 읽으러 갑니다.

[@juuser732]

Code complete 은 어떻게 생각하시나요?

[@Eastwol]

코딩 안하고 모르는데 이영상을 그냥 보고있음 끝까지 다 봤다!!

[@loctite417]

깨끗한 코드는 결국 추상화인데 과도한 추상화는 안좋다고도 하죠. 함수 이름에 동사넣으라는건 참 좋은 말이네요

[@m1emili0]

기본적으로 영어를 잘해야 네이밍을 잘하고, 네이밍을 잘해야 주석도 없앨 수 있는 거죠. 네이밍 잘하고 펑셔널 프로그래밍 잘하면 굳이 함수의 속까지 매번 뜯어볼 필요 없이 잘 읽히는 코드 되는 거고.

[@Hcastle]

제가 클린 코드 작성하면서 정말 느낀 부분들이네요. 코드 피드백 주고받으면서 제가 느끼기에는 주석이 있는게 훨씬 가독성이 좋아지는데 이걸 구지 없애고, 하나의 기능만 담아야 된다면서 엄청 나누는데 결국 가독성은 가져다 버리는... 잘 보고 갑니다

[@안수형-i1u]

몇가지 팁..1. 변수를 줄여라..변수가 많다면 뭔가 잘못된거다. 변수를 줄여라 2. 함수이름은 전부 소문자로..헝가리 어쩌구하면서 대소문자 섞어쓰는데..대소문자 구분안하는 언어도 많다. 그런 언어 만나면 고생하니 그냥 전부 소문자로. 3. 탭으로 줄맞추기 잘해라. 가독성이 많이 올라감. 4. 람다함수 많이써라..코드가 짧아짐

[@dgh06175]

이 부분에 정말 고만이 많았는데 결국 제 주관을 가지고 정보를 비판적으로 바라보는게 중요한것 같네요

[@최기환-y1n]

감사합니다ㅠ 늘 고민 했던 부분이였습니다! 함수가 최소한의 기능만 담당하게 하라는데 쪼개면 쪼갤수록 좋은게 맞는건가? 하는 의문을 항상 가졌던거 같아요! 오늘 어느정도 그 궁금증을 해소할 수 있었던거 같습니다! 좋은 영상 감사합니다ㅎㅎ

[@Dkwjsiiiaiwi]

감사합니다.. 혹시 전기장판같은건 안파시죠..?

[@실험맨]

강의같은건 팔던데요

[@모모-e8b]

와아 클린코드 두꺼워서 읽어야지 읽어야지 하다 안 읽었는데 한권다봤다 개꿀

[@gmd317]

뭔가 속이 시원해지는 영상 이네요

[@youtina573]

와우! 거부감 들었던부분 시원하게 말씀해주셨네요.

[@왈왈-d7l]

신입땐 최대한 지키려 노력했는데 ㅋㅋㅋ 하나하나공감되네요

[@lumina3914]

ㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋ 이거 언어에도 많이 갈리는게 c에서는 변수를 줄이라는건 포인터 하나 쓰고 모든 변수를 처리할 수 있어서... 어떻게 구조화 시키냐가 도 중요하지 않나 생각되내요. 진짜 아무리 생각해도 코드룰이나 방식은 참고는 할 수있을지언정 그때그때 최선의 선택을 하기위해서는 절대로 그 룰에 매몰되어선 안됨. 일예로 우리나라에 가장 흔한 속설중에 goto쓰지 말라는거 커널에서 goto 투성이임. 어떤 룰을 지키는거 보다 왜 그래야 하는지을 알아야 하는게 중요한거 같내요. 이게 시험으로 확인하기 어려운 부분이라 우리나라에선 좀 취약점이긴 하지만.

[@ZombieWars4]

주석은 쓰랄데기 없이 길게 쓰는 것보단 간결하게 쓰는게 좋아보임 어차피 코드도 한 번 읽어야하니까

[@ssackteun]

자기 코드를 유지보수 하다보면, 중복 작성해둔 코드가 여기 저기 흩어져 있으니, 이걸 좀 더 실수를 줄이고, 신속하게 수정할 수 없을까 생각이 들 때, 힌트를 얻는 정도로 읽는게 좋은것 같아요

[@용산급행]

TDD도 언제 한번 다뤄주시죠. 클린코드급 종교.

[@용산급행]

오해들 하실까봐 덧붙이면 테스트 코드를 작성하는 것과 TDD(테스트 주도형 프로그래밍)는 엄연히 다른 것이고, 제가 비판하는건 TDD에 대한 맹목적인 찬양입니다.

[@yongwookim2761]

영상 전반적으로 공감하며, 제가 클린코드를 읽던 주니어 때 항상 의문이었던 부분을 잘 짚어주신 것 같습니다. 코드의 반복과 관련해서는 특히 그런데, 동일한 코드가 두 번 내지 세 번 정도 반복되는 것만으로도 리뷰 지적을 받을때가 많았습니다. 타당한 의견이면 수정해야 맞으나, 그 이유는 대체로 "당연히 그래야 한다" 였던 것 같아요. 동일한 코드라도 함수 단위로 묶을 "가치" 가 있을 때 전 함수로 묶는 편입니다. 결국 재사용성이 얼마나 있는지를 보고 판단하는 거죠. 그런데 처음 개발할 때는 개발한 코드가 얼마나 그러할지는 알기 어렵기에 일단 직관적으로 이해할 수 있도록 적절히 블랭크로 나누어 로직을 코드로 설명하고, 이후 유지보수 단계에서 해당 코드가 여러 군데에서 사용될 법 할 때 비로소 코드를 분리하여 적절한 함수로 정의합니다. 극단적으로는 아예 함수 단위로 나누지 않고 하나의 큰 기능을 하나의 함수 내에서 모두 구현해보는 방법도 취해봅니다. 경우에 따라서 구현을 하면서 아 어느 구간에서 어떻게 역할 분담을 해야하고, 그럼 이렇게 함수와 클래스를 정의해서 파라미터로 넘기면 되겠다 라는게 얼추 보일 때가 있습니다. 그렇게 해서 전체 구조를 잡아갈 때도 있습니다. 다만 사람마다 지향하는 바는 달라서, 영상에서 나온 함수로 막 쪼갰을 때 모습이 직관적인 (제 기준에선 약간 변태적인..) 사람이 있을 수도 있겠습니다. 그래서 전 이런 내용으로는 리뷰를 잘 안하긴 합니다. (개취 존중이랄까요..) 클린코드를 찬양한 적은 없습니다만, 그래도 꽤나 괜찮은 가이드라고 생각했을 때가 있었는데요, 지금은 사실 이런 책 보다는 개발 업무를 하면서 스스로 지향(양) 해야 할 습관을 생각하는 게 더 좋더라구요. 최근에는 업무로 주어지는 리뷰가 아니더라도, 다른 팀원이 짠 코드를 10분 정도 리뷰하는 습관을 가지려고 합니다. 대부분 개발자 분들이 그러하신지는 모르겠습니다만, 전 남의 코드를 보는게 매우 힘들더라구요. (제 능력 부족일 수도 있겠습니다.) 업무 능력과 스킬을 맹목적으로 배우는 것도 중요할 때가 있지만, 업무와 스킬 능력 향상을 위해 스스로 고민해보는 것도 매우 중요한 것 같아요. 그러한 고민에 대한 참고로 영상에 나온 책들이 도움이 될 가능성은 충분히 있습니다. (클린코드도 그 중 하나이지요.)

[@폭풍딸기맛]

함수나 클래스가 있어서 들어가 보면 거의 아무 것도 안 하고 다음 함수로 넘기고, 또 거기 들어가 보면 약간의 기능만 더해서 다음 함수로 넘기고.. 이런 식으로 끝없이 반복하는 코드들 보면 진짜 열불나더라고요.. 심지어 반복되는 코드도 아니라 그냥 다섯 줄로 이어서 적으면 될 걸 함수 다섯 개로 만들어 놨어.. 지금 보니 저 책이 만악의 근원이었군요.

[@HJ-ri9fj]

궁금한 게 있는데요. 1:11 에서 *주로 Compile Language* 에서 리버스를 하면 어느 쪽이 가독성을 낮출까요? *바이트 코드* 를 작성하는 언어도 궁금하고요. 먼 과거에 패키지를 뜯어봤을 때 *주석까지 컴파일* 되는 것을 봤었어요. 그래서 어느 쪽이 더 난독에 도움이 될지 궁금하네요.

[@김하하-f9p]

컴파일옵션에 따라 다를지 모르겠지만 주석까지 컴파일되는 언어는 없습니다

[@민기-q1v]

디컴파일러가 주석을 붙여주는게 아닐까 싶은데

[@tribela]

자바에서 docstring이 jar파일에 들어가는 걸 말씀하신 걸지도 모르겠습니다

[@choi4624]

기계어 (바이트코드) 레벨에선 저런 작업은 컴파일 기반 언어라면 다 똑같은 결과물이 나오는게 일반적인 PL(프로그래밍 언어론) 입니다만, 리버스 관점에서 바라본다면 소스 코드의 가독성을 낮추려고 노력하지 말고 베포판에 필요한 정보들은 난독화를 하는게 더 낫지 않나 싶습니다.

[@백승권-p6y]

저는 개발 업무 10년 넘게 해본 사람으로서 한 가지 원칙에만 충실합니다. "가독성" 이것만 좋으면 되요. 개발은. 근데 가독성이 좋으려면 결국 클래스, 함수 이름 및 구조, 변수 셋팅, api 호출 방식 등등 몽땅 잘 해야 한다는게 함정...

[@kenny-han]

아 좋은 영상입니다. ㅎㅎㅎ. 옛날에 처음 프로그래밍 배울때 변수명 글자수 8자리인가?? 암튼, 정해진 숫자로만 만들라고도 했었습니다. 그때는 그것이 정답이라고 했지요. 안그러면 초짜 취급 받는 ... 핵심은 쓰기 편하고 보기 편하게 딱봐서 뭔지 알게 코딩하는 것일 겁니다. 그걸 하기위한 방법은 환경이 바뀌면 언제든 바뀔 수 있습니다.

[@hojin9626]

미국 빅테크 SW엔지니어 인턴쉽햇는데 ㄹㅇ 원칙적으로 배웟던 클린코드랑은 먼 개판인데 다 딱딱 맞고 이해하기 쉬워요

[@LunaGeonWoo]

애플님 VSCode 대체 가능성있는 Code Editor Cursor도 한번 다뤄주십쇼

[@creatorstoryx]

사실상 개발 팁 끄적여 놓은 책 아닐까 싶네요. 저는 참고 도서로만 취급해야겠습니다.

[@lasercho4338]

선생님 영상 좀 자주 올려 주십쇼

[@Cinnamon_Cannonn]

여러개 팀이 하나의 프로젝트를 만드는걸 수업에서 진행했는데 시부럴 중앙서버를 왜 만드냐는 소리 들었음,,, 그냥 각 부문에서 직접 통신하면 되는거 아니냐고, 그게 클린코드에 의미가 있냐고

[@kencidhan]

책이든 어떤 글이든 항상 그 글에서 말할려고 하는 핵심내용이 뭔지를 파악하는게 중요한데 항상 결론만 가지고 와서 과대해석하는게 무섭죠

[@kenji0q]

클린코드 책을 읽고있었는데 이 영상을 보고 다시끔 생각을 하게되네요 다행인 것은 적절한 수준을 유지하면서 클린코드를 지향하고있었습니다 신입 개발자들과 일하려면 가이드가 있어야해서 클린코드 내용을 지향점 삼아 개발을 했습니다 어느정도는 도움이 되었네요

[@yoossecret7768]

좀 더 깊이 있게 왜 그런지, 해결책은 무엇인지 알려주었으면 좋을 것 같네요. 뭔가 어디서 분노 쌓고 영상에 분풀이 하는 것 같아서 혼란만 더 생기네요. 종교엔 종교로 대항한다는 느낌을 받았습니다. ㅋㅋ;;

[@maybeSecret]

난 코딩애플만 본 개발자다 엄랭으로 취준을 하고 있지

[@dkdndjdndjd]

디스같지만 중요한 책 내용은 잘 설명해주셨네요 ㅎㅎ 읽지말라는 거 정말인가요

[@asd236678able]

함수부분은 그 모든 함수를 보라는 뜻이 아니라 추상화 레벨을 맞춰서 그 디테일을 안보게 하는게 목적이라 영상내용에 동의는 크게 안되네요. 모든코드를 보려면 가독성이 떨어져도 추상화된 상위 함수만 본다면 가독성이 올라가죠. 로그인 함수라면 로그인 함수에 모든 디테일을 if문 처리해서 if문 여러개의 의미를 해석하는거 보다는 재사용 하지 않더라도 함수로 나눠서 인증 검증 유저 정보 가져오기 가입 안되어 있으면 회원가입 유도 이런 함수로 나누는게 더 읽기 좋겠죠. 모든 함수의 디테일을 읽을 필요는 없습니다. 우리가 보려는건 이 함수가 무슨 동작을 하느냐이지 함수를 어떻게 구현했는지 정밀검사하려는게 아니니까요

[@원컬러]

그 부분은 중괄호로 감싸고 주석다는 것으로 해결 할 수 있습니다. - 함수는 하이퍼링크처럼 이 페이지 저 페이지 왔다 갔다 하게 하는 불편한 점을 - 중괄호 치고 IDE에서 접어버리면 문서에서 대,중,소단원 나누는것처럼 접어버릴수 있어요. 함수로 추상화해서 가독성을 챙기는 목적도 해결되고 함수 호출에 대한 비용도 아끼고 이 함수 저 함수 넘나드는 것에 대한 불편함도 해결되더라고요. 추가적으로 함수로 추출했으면 이 함수는 재사용이 될 것이다라는 명확한 기준이 생겨서도 좋구요.

[@lIlIIl-w1j]

입문자들을 위한 책은 아니고 장인을 향해나아가는 수준의 중니어들에서 시니어들에게 적절한 책입니다❤ 펑션이야기도 클래스장과 이어진내용입니다