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

OOP에서 정리정돈 잘하는 법을 알 수 있는 책입니다
코드짜는 법 codingapple.com
개별강의 10% 할인 쿠폰 : CP123 (맨날 바뀜 최신영상 참고)
0:00 인트로
0:14 1. 작명법
0:33 2. 함수
1:44 3. 주석
3:20 4. Class
3:52 5. Duplication
5:00 결론

[@drkim8425]

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

[@St__Y]

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

[@zikpzi9759]

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

[@makefuckinggoodcomments]

이 형의 멋있는 점은 겉으로 보면 정신이 나가있는거같은데 내용을 보면 이만큼 좋은 가르침을 주는 사람이 별로 없음.

[@sanghoonahn5410]

ㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋ 정신이 나간것같은데 개잘해!!

[@gooddevilgd]

맥이는건지 띄어주는건지 ㅋㅋ

[@Like_face]

원래 이런 일 하는 사람들은 나사 하나씩 빠져 있는 게 기본소양이기 때문

[@rendarcb1908]

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

[@St__Y]

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

[@user-dr6hp9lo6m]

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

[@codingapple]

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

[@user-eo4nc4qe9b]

개추 ㅋㅋ

[@Thj123]

개추

[@user-ry9xh8po9s]

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

[@lyueas]

엄준식 잘할 수 있음

[@2dubbing]

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

[@Milk_Caramell]

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

[@jihwaE22]

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

[@user-pu1ku9ln2d]

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

[@epro44ing3.1]

이거 인정하는 부분입니다

[@fxxkthatjeon]

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

[@user-ky7zo8mk9k]

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

[@leopoId]

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

[@실험맨]

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

[@user-wh6cd6ef1w]

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

[@enru2251]

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

[@user-ep1fy6yq2w]

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

[@vanillarootbeer]

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

[@CongNim]

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

[@s-saens]

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

[@jsl5073]

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

[@ABCABC._.ABCABC]

이건 정치색드러내는거랑 비슷한 개념같아요. 개인적으로 옳은 생각이란건 이거구나 하며 마음에만 품고 살아가면 별일없는데 그걸 누군가한테 얘기하거나 납득시키려면 필요한 자료나 내 사회적 위상 등, 따지고보면 짜증나는 과정을 거칠수밖에 없는거죠

[@실험맨]

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

[@추멘]

그분 포프님인가

[@bwshin413]

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

[@jkkim6928]

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

[@zaqxswc273]

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

[@iyj9152]

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

[@jmash6651]

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

[@kwj_nekko_6320]

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

[@bwshin413]

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

[@redsofakim]

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

[@giseokchoe]

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

[@user-sr1my6pm7d]

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

[@user-pf4se1hw8i]

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

[@7mandalorian]

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

[@davidlee0706]

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

[@user-fo4fr7fk9d]

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

[@user-tk9uj2sn7w]

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

[@user-ub3po6ev2r]

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

[@user-ep1fy6yq2w]

명서라고 부르는 책들은 한번만 읽어서는 그 의미를 완벽히 이해하기 힘들다고 생각합니다 책의 의미를 좀 더 잘 전달하기위해 다소 극단적인 예시를 드는 경우가 많고 처음에는 그걸 맹신하게 되는 함정이 있지만 경험치가 쌓이고 두번째 읽었을 때는 내포된 의미를 스스로 이해하면서 비판적인 시각을 가지는것이죠

[@loctite417]

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

[@Boy-qp7hw]

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

[@yangseungtoung]

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

[@pollinipill]

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

[@실험맨]

오버 하지말란말을 클린코드는 틀렸다 라고 이해를 하시나 다들..

[@user-rh1br1gl3t]

책에서 말하는 모든 것을 맹신하지 말고 이런 부분도 있으니 비판적 사고를 가지고 읽어라는 영상을 클린코드 책은 쓰레기다로 받아들이는 인간들이 댓글에 보이는데 한권만 읽고 맹신하는 자나 영상 하나 보고 전부까기 하는 자나 다를 바 없는 듯

[@tarakkyu]

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

[@jsysonjung]

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

[@user-de7yd9gv8z]

동의합니다

[@user-bx6xq7bs5l]

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

[@jsysonjung]

@@user-bx6xq7bs5l 맞아요 원댓글하고 같은 말씀

[@user-vh7fn5kb2i]

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

[@woojinlee8043]

영상에 나온 것처럼 이상한 점보다는 배울 점이 더 많은 책입니다. 안 읽어보신 분들은 꼭 읽어 보시길 바라요. 같이 일하는 입장에서는 읽는 데 시간 오래 걸리는 더러운 코드보다는 결벽증 코드가 차라리 더 낫습니다

[@dbsdbs17]

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

[@user-ep1fy6yq2w]

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

[@user-jl9iw5jy3u]

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

[@5dksdev767]

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

[@user-ndkLsruxgb]

진짜 맞는말인게 유독 하나만 읽고 그걸 맹신하는 사람들이 많음.. 읽으면서 무조건 받아들이지말고 비판적인 시각을 유지해야하는데.. 자기가 실력이 없다면 관련 서적을 읽으면서 잘은 모르겠지만 이 부분은 대체 왜 이렇게 해야하는거지 하면서 다른 관련 문서들도 찾아봐야하는데 그냥 유명한 책에서 맞다고하니까 의심없이 받아들이는 그런

[@sorieil]

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

[@billtrima]

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

[@devcode-kr]

중복 코드 허용은 진짜 맞는 말임 전혀 다른 기능에서 당장 똑같이 생긴거 있다고 함수로 묶은다음에 미묘하게 달라지면 if문 난사하게댐 기능이 다르면 각자 써야함 나중에 코드최적화 할때 판단해도 늦지 않음

[@chorong0824]

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

[@2ndintelligentWorld]

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

[@user-iu4dv3ij4b]

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

[@user-rm1uo5wk2w]

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

[@r3b00t3]

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

[@m1emili0]

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

[@user-tk9jy2jc1t]

가끔 보면 실제로 저런거 맹신하는 친구 하나쯤은 있음... 근데 그런놈들 막 거들먹거리면서 들어와서 꼭 공통적으로 하는 개소리가 있음. "코드가 X같아서 아무것도 할 수가 없다". 실제로 수석급 하나 뽑아서 들어온 놈팽이가 한 2010년부터 이어내려온 코드(개발 당시엔 실무에 SMP라던가 멀티쓰레딩이라던가 개념이 좀 제대로 정립되어있지 않았던 것으로 보임. 또한, 망한 회사꺼 줏어온거라 개발문서도 그 어느것도 참조할 수가 없었음. 게다가 해당 솔루션은 C 혹은 C++로 작성된 서버 프로세스만 7개고, 본인 혼자 담당중이었음. 그리고, 그런 시대에 예쁜 코드를 신경썼을 가능성은 적다고 보면 됨. 게다가 정말 골때리는건, "거의 모든 비즈니스로직 함수가 쿼리 한번씩 날리도록" 개발되어있었음.)를 구조분석도 안하고 "멀티쓰레딩을 도입하면 된다!" 라고 외침. 실제로 해당 프로세스는 본인이 어찌저찌 멀티쓰레딩을 어느정도 적용을 해놓았고, DB 데이터도 어느정도 메모리 내에서 캐싱도 되도록 개선작업중에 있었음. 근데 그걸 본인한테 물어보지도 않고 그냥 소켓 읽는부분을 무작정 쓰레드로 나누고 현장에 적용해서, 본인이 비동기처리로 개선작업중이던 DB 쿼리 코드가 데드락을 일으키며 4만명유저짜리 사이트의 서비스가 한시간정도 맛이 가는 기염을 토함. 추가적으로 웹파트가 개발중이던 DB 프로시져도 사이드이펙트로 DB 테이블 자체가 꼬여버림. 이게 들어온지 한달도 안된 "수석"이라는 놈팽이가 최소한 해당 프로세스 코드를 1년은 잡고있던 "주임"의 말을 귓등으로도 안듣고 그놈의 클린코드 나불대면서 나대다가 현장을 박살내는 매직이었음. 당장 서버랙에서 서버 하나 뽑아다가 뚝배기를 내리찍고 싶었는데 참았음. 보고있냐 Pent[::alpha::]+에서 오신 "자칭 개발자" 신모씨? 내 눈에는 개발조무사로밖에 안보인다만... 클린코드고 뭐고 다 좋다. 그렇지만, 그게 될 수 없는 상황의 코드도 있는 법임. 극단적 이상주의자는 그저 꿈속만 허우적댈 뿐. 당시 상황이 어느정도 급박했냐 하면, 사이트 들어간지 2개월만에 정식오픈했는데, 4만명짜리 사이트에 아주 옛날옛적 코드가 들어가서 700세션부터 아예 먹통이 되어버리는 현장이었고, 당장 해결 못하면 솔루션 바로 빼고 경쟁사꺼 구입한 다음 손해배상 청구한다는 소리 나오는 시점임. 그 700세션도 못받는걸 어찌저찌 고쳐놨더니 저딴놈이 들어와서 박살내고있더라... 그래서 급장떼고 "코드 제대로 안볼꺼면 손 떼세요" 하니까 지 직급들이밀면서 "어디 주니어따위가" 이러길래 그냥 사장한테 직빵으로 "저새끼좀 치워주세요" 하고 일함... 부수적으로 뭐 하나 더 이양반을 극혐하게 된 계기가 있었는데... 직장내 다른 최모씨(수석급)라고 자칭 신한은행 개발자 출신이라고 허언하던 친구랑 같이 영등포 집창촌 들낙거리는걸 자랑스럽게 얘기하고앉아있었음... 나중에 알고보니 신한은행 개발자가 아니고 신한은행에서 외주 준 웹 퍼블출신 html 잡부. 뭐... 이 신모씨 친구는 그걸 철썩같이 믿고있었겠지... 진짜 은행권 개발자라고...ㅋㅋㅋㅋㅋㅋ 멍청하게. 그래... 예쁜 코드, 리팩토링, 기술문서. 중요하지... 근데, 리팩토링 나불대는건, 회사 조때는거 면한 다음에나 합시다... 당연히 기술은 오래 지속될 수 있도록 만들어져야 하지만, 회사가 망하면 그게 무슨소용임... 10년도 넘게 버려져있던 코드가 애초에 그모양이었고, 사장이 줏어왔고, 그걸로 사이트 들어간것 뿐인데... 그 이후로 현재 프로젝트가 처해있는 상황같은거 고려도 안하고 "객체지향, 클린코드를 하지 않으면 그건 쓰레기다" 이딴 극단적인 소리 하는 친구들은 테라포마스마냥 보이더라... 커널이 어느정도 read/write같은거 죄다 소켓 열면 래핑해놔서 하나의 인터페이스로 처리하도록 만들어놓긴 하지만, 내부 들어가면 모두 다 그렇게 객체에 의존하지는 않는것이거늘... 커널 찔끔 내뱉다가 갑자기 생각났는데, 이새끼 아직도 기억나는게, "C라고 해서 C로 객체지향 안하면 그건 주니어다"ㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋ 아 진짜 지금 술김에 쓰는거긴 한데 당장 찾아가서 슈퍼마이크로 서버갖다가 대가리 으깨서 뇌수 쪽 뽑아다 매운탕해먹고싶네... 아 추가로 하나 더 씀. 뭐... 통신 패킷을 모르는건 둘째 쳐도... C에서 TLS연결해놓고, 세션 한쪽에서 암호 파라미터 네고가 다시 오거나, 노티 데이터 오는것 자체를 아예 모르는 무지랭이새끼더라... 그거 처리 안하고 바로 비즈니스로직으로 간주해서 처리하면 바로 세션 맛탱이 가는게 뻔한데. 여기서 명언 하나 추가. "세션 맺었으면 끝이지 거기서 그딴게 왜 와? 너 허언증 환자지?" 솔직히 얘한테 좀 진지하게 묻고싶음... 혹시 스위칭, 라우팅, TCP 세션 스테이트머신, 암호 파라미터 등... 하나라도 아는거 있으세요...? 혹시... 암호학에서 이산대수라던가... 아니... 산수는 할줄 아세요?;;; 라고...

[@user-ud9jz6bs1g]

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

[@silver33412]

그건 잘못 이해한 사례인데

[@user-ud9jz6bs1g]

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

[@silver33412]

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

[@user-ud9jz6bs1g]

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

[@user-be3wx8bf8n]

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

[@ResponseEntity]

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

[@SunnyKimDev]

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

[@Hcastle]

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

[@dhp5865]

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

[@enru2251]

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

[@haesungcho5655]

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

[@user-ee3qt2fb7i]

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

[@gim2origin]

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

[@dbdks123]

대학생으로서 공감되네요 항상 주석 달라고 하시고 과제에서 주석 없으면 감점이라고 하는 교수님들이 계실 정도 가장 좋은 것은 한눈에 보고 어떤 코드인지 알 수 있게 짜는 것이지만 우리들은 그렇게 못하기 때문에 주석을 무조건 달아야 한다고 하심

[@garciakarim3544]

혼자하는 프로젝트라면 상관없지만 공동소유하는 코드에 주석은 유지보수가 되지않습니다.

[@user-vj2sh1kc1x]

과제 주석은 코드에 대한 이해도를 높이기 위해 쓰라고 하는 경우가 많음. 아무 생각 없이 짜던 코드도 주석 달아서 남에게 설명하다 보면 강제로 이해도가 올라가니까

[@enru2251]

​@@garciakarim3544 주석이 있어서 거슬린다면 지워버리면 되며, 있으면 대부분 도움이 됩니다. 그냥 원래 코드를 개판으로 짜놓거나 혼자만 알아보게 짜놓고 주석에만 의존하고 주석에 떠넘기는 행태가 잘못된 거지 주석 자체가 문제가 아니란 말입니다. 대개는 주석 걸고 넘어지는 분들은 그냥 주석 없어도 전체적 코드 구조를 알아보는 눈이 없는 분이 많습니다. 주석이 방해만 되는 레벨에서는, 이미 아키텍쳐 수준이므로 주석이고 뭐고 짜증이 나지도 않고 별 대수가 안 됩니다. 한마디로 유난 떠는 사람들은 그냥 훌리건에 불과하다는 거에요.

[@dolfalf]

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

[@user-fs3tg7yz4j]

No Silver Bullet

[@user-kid3wjx5cg]

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

[@juneekim7]

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

[@vanillarootbeer]

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

[@jongmin0328]

사실 코딩 오래하다보면 저런 책 안읽어도 어떻게 하면 가독성 높은 코드가 되는지 자연스러게 알게 됨.. 초보땐 내가 짠 코드 나중에 보면 다시 해독해야함 . 추가로 개인적으로 클린코드보단 가독성이 훨씬 중요하다고봄. 펑션이 최소 단위여야 클린 코드라고 하지만 때론 나누지 않고 하나의 펑션에 넣는게 가독성이 더 좋을 때도 있음(많음)

[@msahn3722]

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

[@user-bp7lt9mb8b]

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

[@JL-zd9rg]

상남자는 메인 함수에 다 때려넣고 주기적으로 리팩토링한다 이말이야

[@sonojae4238]

나 상남잔데 개추 눌렀다ㅋㅋㅋ

[@deda766]

개추

[@user-dr6hp9lo6m]

상남자 ㅇㅈ

[@redcomet150]

상남자는 리팩토링 하지 않는다

[@hog2168]

이게 맞다

[@shoonch911]

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

[@user-wl2zf8ww6b]

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

[@danpyeong223]

이 영상이 한 달전에 나왔더라면 더 좋았을정도로 책과는 별개로 배운 게 많습니다 ㅠㅠ 특히 후반부에 나오는 중복코딩 몇 개 나온다고 나누는 부분에서 뼈져리게 느꼈습니다.. 최근 대학 팀플 과제 중 코드가 3~4개 중복되다보니 이걸 나눠야되겠지? 하는 생각에 나누고보니 진짜 영상에서 말한 것처럼 A에는 이게 필요한데 B에는 저것만 필요하고 하다보니 switch, if 문 등으로 오히려 더러워지더라구요.. 그쯤되니 머리론 아 이거 진짜 아닌 거 같은데.. 이게 진짜 효율적인게 맞나? 오히려 효율을 찾다가 비효율에 더러워진 것 같다 란 생각만 들었는데 그게 오늘 영상으로 확신이 되었습니다.. 쓸데없이 반복에 집착하지말고 뭐가 더 좋은지 한 번 더 생각하고 짜겠습니다! 너무 감사합니다 ㅠㅠ

[@jsysonjung]

"가짜 중복"이었던겁니다

[@user-mask23dssdcxz]

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

[@Mryourvideo]

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

[@user-bo5ex4zu3f]

다른 건 모르겠는데 중복 관련해서는 오히려 클린코드에 나온 내용이 더 맞는 것 같아요. 예시로 든 '안녕하세요' 코드의 세 부분이 각각 다르게 변하고 다른 기능을 수행하게 된다는 점에서 '가짜 중복'일 확률이 큽니다. 책에서도 겉보기엔 같아보이지만 실제로는 다른 책임을 가진 가짜 중복을 조심하라고 하고 있어요. 2번까진 중복이 괜찮다, 3번까지도 괜찮다는 식의 코드작성 기준은 좋지 않다고 생각합니다. 중복 제거의 기준은 중복의 양이 아니라, 코드가 같은 역할, 책임, 관심사를 가지고 있는지를 보고 판단하는 게 더 맞겠죠?? 이 부분은 책의 방향성이 더 맞다고 판단되네요

[@jsysonjung]

동의. 그리고 가짜 중복인걸 알게되어 변경이 필요하게 될 경우엔 그냥 새로운 함수를 만드는 게 심플한 해결책 같음. 영상에서처럼 if/switch 같은거 안쓰면 그만.

[@user-fs3tg7yz4j]

동의합니다. 가짜 중복일 경우 if/switch 를 안쓰고 새로운 함수를 만들 것 같네요

[@bomsbro]

문제는 가짜 중복이라는 것이 처음에는 아니었다는데 있습니다. 중간 중간에 조건문으로 땜빵해놓으면 프로젝트 규모가 커지면 돌이킬 수 없습니다.

[@user-bo5ex4zu3f]

@@bomsbro 나중에 가짜 중복으로 밝혀졌을 땐 다시 책임에 맞게 함수를 분리하면 해결됩니다. 중복 제거가 문제가 아니라 if문 땜빵이 문제인거죠

[@__yourspring]

저는 변수명과 함수명이 주석을 대체하는건 과하지만 않으면 오히려 클린코드쪽에 동의함 언리얼 및 유니티도 최신 도큐멘테이션 가이드라인 보면 저렇게 되어있기도 하고 현업 트렌드라서 주석 최신화도 필요없어서… 제 개인적인 소견일 뿐임다…ㅎ

[@G-Rim_Ester1z]

오.....제가 개발 하면서 개인적으로 철학화 시킨 사항들과 다 일치하네요. 대표적으로 코드 복붙 3개 정도 까지는 허용하는게 나중에 어떻게 서로 다르게 커스텀이 들어갈지 알 수 없는 경우 동일 코드로 두는 점이랑 구체적인 필요나 구조화 아이디어가 생기기 전 까지는 일단 하나에 때려넣는거랑 주석부분도 그렇군요. 주석은 생략하게 되는 경우가 많기는 하지만.......

[@HongLab]

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

[@yongwookim2761]

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

[@AlexanderDavis137]

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

[@kenji0q]

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

[@user-sg7jy8wj3j]

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

[@hkkun85]

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

[@user-zl2pl1tu6s]

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

[@lumina3914]

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

[@ssackteun]

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

[@user-di3ux1vj7z]

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

[@Ming_0322]

주석을 달지 않음으로써 나만 알아봄으로 내 가치를 높이라는 깊은 뜻 일리가 없죠

[@user-rb8gv7nq3x]

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

[@실험맨]

구글은 다 보고있습니다.

[@dgh06175]

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

[@chieryran8434]

인턴 시절 회사선배들이 주석에 대해 하신 말씀과 똑같네요. 그 회사 나와서 더 많은 시니어 분들을 만나다보니 지금은 그런말은 하지 않지만 주석이 없어서 신입시절부터 첫성과내는데 오래걸린거 생각하면…. (무려 첫직장인데..)

[@user-th6ib3qy7g]

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

[@MNBN87]

하나하나 나름 다 요지는 있는 주장들임. 종교처럼 무조건 적용하려고 하니 문제지.

[@kencidhan]

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

[@kenny-han]

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

[@yeominsu]

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

[@시]

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

[@youtina573]

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

[@gsrider7891]

함수 남발한 코드 보면 토 쏠려요.. 함수 소스 찾아가다가 어 내가 왜 여기까지 왔지?? 합니다

[@namjacksoncho8797]

이제 너 코딩애플 유튜브안봤어? 클린코드 책 쓰레기야라는 사람도 등장하겠네요😂

[@HJ-ri9fj]

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

[@user-xy5xv7yy5i]

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

[@user-in5qn7je3v]

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

[@tribela]

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

[@choi4624]

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

[@리노rino]

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

[@가시]

2:59 이 코드는 봐도봐도 쓴 놈이 미친놈임...

[@user-mw1hs7dv2u]

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

[@argent0218]

종교처럼 떠 받들지 말라는 말 너무 공감합니다. 가끔 책이나 블로그에서 봤다면서 맞다고 우기는 사람이랑 토론 하고 나면 너무 피곤해요

[@LunaGeonWoo]

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

[@hojin9626]

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

[@maybeSecret]

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

[@user-pw6un9my6t]

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