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 결론
이 형의 멋있는 점은 겉으로 보면 정신이 나가있는거같은데 내용을 보면 이만큼 좋은 가르침을 주는 사람이 별로 없음.
@sanghoonahn5410
7 ай бұрын
ㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋ 정신이 나간것같은데 개잘해!!
@gooddevilgd
4 ай бұрын
맥이는건지 띄어주는건지 ㅋㅋ
@user-xj5vv2sd3n
3 ай бұрын
원래 이런 일 하는 사람들은 나사 하나씩 빠져 있는 게 기본소양이기 때문
@rendarcb1908
7 ай бұрын
진짜 공감하는게 함수랑 주석부분보고, 엥? 이런게 너무 많아서 이게 맞나 싶기도 했습니다. 특히 어느기업은 과제조차 주석자체를 극혐하는 곳도 많고 애초에 클린코드를 넣어버린 곳도 많은데 클린코드에 대한 부분을 명확히 인지하고 쓰는건지 의구심이 들뿐입니다. 그래서 저는 '클린코드'보단 '좋은코드 나쁜코드' 이 책을 더 많이 추천해주는 편입니다. 오히려 구글 엔지니어가 작성하여 직접 경험에 의한 내용이라서 더 좋고 실무에도 적용시킬 내용이 많아서 오히려 이책이 더 좋은거 같네요
@drkim8425
7 ай бұрын
"주석이 거짓말을 한다" 라는 건 경험적으로 봤을때, 코드만 고치고 주석은 고치지 않은 사람들 때문이죠. 그러면 코드와 주석이 내용이 다르게 되고 주석이 거짓말을 하는 상황이 됩니다. 주석이 나쁜게 아닙니다. 코드를 고치고 주석은 고치지 않는 사람이 나쁜 거죠.
@redsofakim
7 ай бұрын
주도적 비판적 학습을 위해 꼭 필요한 말씀이네요. 감사합니다!
@2dubbing
7 ай бұрын
경력이 쌓이고 그 과정속에서 여러 프로젝트를 개발하다보면 본인만의 개발 철학이 생기는거 같아요. 저도 신입때는 함수의 파라미터들을 객체로 감싸서 넘길지 말지, 프로젝트 폴더구조를 어떻게 해야할지 등.. 그러다보니 기능구현을 하기도 전에 지쳐버리는 경우가 있었어요. 너무 체력을 소모하는거 같아 이 버릇을 고치려고 노력했던 기억이 나네요 나름 클린하게 리팩토링 해놓은 플젝 레포지토리를 몇년뒤 다시봤을때 내가 왜 이렇게 피곤하게 해놨을까 했던 기억도 나네요 ㅋㅋ
@billtrima
7 ай бұрын
와 개깔끔하네.. 5분만에 이 모든걸 이렇게 설득력있게 풀어내다니.. 항상 느끼지만 이번 영상은 더욱 걸작이네요. 모든 내용에 동의합니다.
@enru2251
7 ай бұрын
늘 그렇듯 깔끔하고 명쾌한 설명에 속이 시원하네요. 감사합니다.
@CongNim
7 ай бұрын
저도 처음 개발할 때 저 책읽고 광신도마냥 코딩 했다가 개욕먹었습니다 ㅋㅋㅋ 후에 고수분들이 해놓은 코드를 보면서 배운것을 요약하자면, 명확하게 장점이 더 큰 선택이 있기도 하지만, 작업의 깊이가 깊어질수록 이를 구분하기 점점 어려워진다는 것입니다. 필요성을 명확하게 파악한다면 아키텍쳐를 명확하게 만들어낼 수 있지만, 그 필요성에 불확신이 가미될수록 어떻게 아키텍쳐를 구성해야되는지 구분하기 어려워진다는 것입니다. 따라서 고수분들의 필요성을 파악하고 정의해내는 능력을 우선 배우고 있습니다. 그렇게하면 코드 구조는 각 상황에서 어느정도 최선의 것이 존재한다는 것을 알았습니다.
@user_no.10
7 ай бұрын
난 가끔 생각해.. 이 형은 개발보다 영상편집의 재능이 더 뛰어난게 아닐까? 하는..
@jihwaE22
7 ай бұрын
"정보미디어 전공 희망편"
@user-pu1ku9ln2d
7 ай бұрын
개발자로만 구독자 20만명인데 메이져 쟝르 유튜버였으면 최소 100만 이상 하셨을듯 싶습니다
@epro44ing3.1
7 ай бұрын
이거 인정하는 부분입니다
@s-saens
7 ай бұрын
중복에 대한 얘기는, 같은 저자가 쓴 클린 아키텍처 책을 보시면 알겠지만, 마틴님도 영상에 나온 예시와 같은 경우는 코드를 다 분리해서 쓰는게 좋다고 말합니다. 애초에 유스케이스를 제대로 분리하지 못해서 생긴 '가짜 중복'이라며, "중복은 없어야돼!"라는 강박때문에 함정에 빠져선 안된다고 저자도 얘기하더라구요.
@juneekim7
7 ай бұрын
오늘 영상 정말 마음에 듭니다! 좋은 영상 만들어 주셔서 감사합니다.
@user-ky7zo8mk9k
7 ай бұрын
클린코드 찬양하지 말라는 영상을 보고 무조건 부정적인 댓글 다는 아이러니한 사람이 많은듯... 극과 극은 통한다고 하더라고요
@chorong0824
7 ай бұрын
요즘 모던자바 인 액션을 읽고, 점점 클린코드 책에 대해 관심이 생겨가고 있었던 와중에 해당 영상을 통해 모던 자바 인 액션도 무작정 학습이 아닌, "왜?" 라는 생각을 좀 더 하게 되었으며, 모든 책에 대한 관점을 좀 더 유연하게 바꿔주는 영상인 것 같아 감사합니다.
@2ndintelligentWorld
7 ай бұрын
솔직히 그냥 상식만 적혀있음. 이 것 처럼 대충 요약한 영상만 보면 됌
@user-dr6hp9lo6m
7 ай бұрын
코딩애플 유튜브채널 하나만 보면 코딩 잘 할 수 있음
@codingapple
7 ай бұрын
코딩이아니라 어그로 잘끌 수 있음
@user-eo4nc4qe9b
7 ай бұрын
개추 ㅋㅋ
@Thj123
7 ай бұрын
개추
@user-ry9xh8po9s
7 ай бұрын
나 코딩애플인데 개추눌렀다
@lyueas
7 ай бұрын
엄준식 잘할 수 있음
@gmd317
7 ай бұрын
뭔가 속이 시원해지는 영상 이네요
@user-th6ib3qy7g
7 ай бұрын
아닠ㅋㅋㅋㅋㅋ 짤이랑 말하는거 왤케 웃기죠. 빵빵 터지면서 보는 중
@user-bp7lt9mb8b
7 ай бұрын
감사합니다ㅠ 늘 고민 했던 부분이였습니다! 함수가 최소한의 기능만 담당하게 하라는데 쪼개면 쪼갤수록 좋은게 맞는건가? 하는 의문을 항상 가졌던거 같아요! 오늘 어느정도 그 궁금증을 해소할 수 있었던거 같습니다! 좋은 영상 감사합니다ㅎㅎ
@youtina573
6 ай бұрын
와우! 거부감 들었던부분 시원하게 말씀해주셨네요.
@user-tv3xd4sz3l
7 ай бұрын
항상 적당한게 좋다
@dbsdbs17
7 ай бұрын
현업자들의 조언을 듣고 싶음.. 사수가 없음.. 이 영상 같은 영상 꿀임....
@user-ep1fy6yq2w
7 ай бұрын
그래도 책은 읽어보세요 읽고나서 책에서 지향하는대로도 해보시고 시행착오도 겪으시면서 개발 철학을 쌓아나가시는게 중요합니다 명서는 명서인 이유가 있는거예요
@user-jl9iw5jy3u
3 ай бұрын
이 영상도 이 책은 구리니까 읽지 마라 라는 말이 아니라 책을 읽되 하나의 책을 맹신하지 말고 여러 책을 읽어보며 직접 어떤 코드가 좋은지 생각해보자 라는 의도인 것 같습니다
@zaqxswc273
7 ай бұрын
이제 유지보수하기 어렵게 코딩하는방법만 읽으면 완벽하군요
@iyj9152
7 ай бұрын
인수인계자를 ㅅㅏㄹ...
@hkbayarea365
7 ай бұрын
ㅋㅋㅋ 이번 영상 극 공감합니다.
@user-zl2pl1tu6s
7 ай бұрын
개발자는 아니어서 저 책을 많이 따라 했는데 ㅎㅎ 역시 두루두루 읽어 봐야 하군요.
@kwj_nekko_6320
7 ай бұрын
실무자 입장에서 특정 책에 대한 맹신을 경계하게 하는 아주 좋은 영상 같습니다. 거의 전적으로 동의합니다! Clean code는 개념도 그렇고, 저 책의 출간 목적도 그렇고, 결국은 "나랑 전혀 관계없던 사람"이 와서 봤을 때도 내 코딩 의도가 완전히 전달되어야 한다는 게 지상목표이고, 이런저런 '팁'은 전부 그걸 달성하기 위한 수단 중 하나에 불과하지요. 극단적으로 얘기했을 때 우리 팀 전원이 어느 날 갑자기 해고되거나 비행기사고로 몰살당하거나 해도 프로젝트가 계속될 수 있어야 합니다. 그 목표를 위해서 때로 다양한 기능을 한 클래스에 몰아넣거나, 주석에 약간 구질구질한 설명을 넣거나 하는 일이 필요하다면, 그렇게 하는 게 더 우선되어야 하는 거죠.
@bwshin413
7 ай бұрын
책에서 이랬는데 라고 권위믿고 맹신하기엔 진짜 개발이 영역마다 프젝마다 케바케가 심해서 참고는 하면 좋지만 실제 생산성 떨어지고 불편함 많고 이런데도 맹목적으로 룰을 따라야 좋아 하는건 다시 생각해볼만...
@Mryourvideo
Ай бұрын
본인이 의심하고 생각해야 한다는 것을 초기에 선배가 알려줬는데… 같은 말을 여기서 듣네요. 감사합니다
@loctite417
7 ай бұрын
깨끗한 코드는 결국 추상화인데 과도한 추상화는 안좋다고도 하죠. 함수 이름에 동사넣으라는건 참 좋은 말이네요
@yydmm5761
7 ай бұрын
좋은 영상이네요
@user-ee3qt2fb7i
7 ай бұрын
ㅋㅋㅋㅋ clean code에 대한 균형잡힌 관점을 알 수 있어서 좋았네요. 저도 약간 종교처럼 숭배했던 것 같으면서도... 뭔가 이렇게 까지 해야돼...? 라는 느낌을 지울 수가 없었거든요
@haesungcho5655
7 ай бұрын
하나의 메소드만 ㅋㅋㅋㅋ 이 부분에 제 생각을 추가 해 본다면 공통 기능을 뽑아 쓴다고 할때 확장성이나 특수성을 고려 해야 하는게 더 중요할 것 같고 이는 곳 자신이 개발하는 서비스에 대한 이해도가 높아야 알 수 있는 부분이라고 봅니다. 코드를 잘 짜는 것도 물론 중요하지만 개발은 그 외에도 확장해서 생각해야 될 부분이라고 생각합니다.
@progress0407
4 ай бұрын
후.. 형 멋잇어요.. ㅠㅠ 맞는 말이에요
@giseokchoe
7 ай бұрын
동의합니다. 뭐든지 적당히 받아들이는 유연함이 필요하죠. ㅎㅎ 클린을 강조했다고 해서 결벽증 환자가 되라는 말은 아닙니다.
@gim2origin
7 ай бұрын
대부분 동의합니다. 나중에 의견이 다를 때 참고용으로 쓰면 좋을거 같네요. 특히 간단한 코드인데 중복된다고 나누는 것보다 수정시에 노가다 해서 일일이 고치는 게 빠를거라면 중복해서 두는 것이 유지보수 면에서 더 나은 선택이라 생각합니다.
@bomsbro
4 ай бұрын
속이 시~원합니다
@leopoId
7 ай бұрын
클린 코드라는 책이 오래됐기도 하고 어느정도 걸러서 들어야 하는건 사실입니다. 그런데 결국 저자가 하고 싶은 말은 코드 그 자체가 의도를 충분히 설명할 수 있어야 한다는 것 같아요. 함수 부분에서 "왔다갔다 하느라 훨씬 읽기 어렵다" 하신 부분도 사실 원래 의도대로라면 왔다갔다 할 필요가 없죠. "왔다갔다" 하지 않아도 뭘 하는지 알 수 있도록 함수 이름을 지으라는 뜻이니까.
@Y-NOT-
7 ай бұрын
네 이영상은 그런 말을 합니다.
@user-wh6cd6ef1w
7 ай бұрын
@@Y-NOT- 몇초 부근인지 남겨주시면 감사하겠습니다 제가 놓쳤는지 안보이네요😅
@enru2251
7 ай бұрын
코드는 깔끔하게, 함수 네이밍도 알맞게 지어 놨어도 주석을 달았다는 이유만으로 배격하는 사람들이 있습니다. 그걸 실제로 당해보면 사실 약간 어이가 없죠.
@user-ep1fy6yq2w
7 ай бұрын
결국 책에서 얘기하고자 하는 의미도 그게 맞죠 단순히 다 쪼개야한다는 맹목적인 의견이 아니라 절차지향적인 코드로 인해서 가독성이 떨어지는 코드를 지양하고 선언적인 형태로서 줄글쓰듯이 하는걸 권장하는거니까요
@7229swkang
6 ай бұрын
@@Y-NOT- 혹시 어디서 나오나요?? 1:20 에서 동영상은 가독성은 작게 분리해놓은거보다 합쳐놓은게 가독성이 더 좋다고 하던데요. 개인차가 있겠지만 저는 따로 분리해놓은게 더 가독성이 있다고 느낍니다. 적어도 함수 이름과 실제로 동작하는게 동일하다면요.
@user-ndkLsruxgb
7 ай бұрын
진짜 맞는말인게 유독 하나만 읽고 그걸 맹신하는 사람들이 많음.. 읽으면서 무조건 받아들이지말고 비판적인 시각을 유지해야하는데.. 자기가 실력이 없다면 관련 서적을 읽으면서 잘은 모르겠지만 이 부분은 대체 왜 이렇게 해야하는거지 하면서 다른 관련 문서들도 찾아봐야하는데 그냥 유명한 책에서 맞다고하니까 의심없이 받아들이는 그런
@captainlennyjapan27
7 ай бұрын
동감합니다. 뭐든 과유불급 같아요. 클린코드 집착하느라 비즈니스 밸류가 안 나오기 시작하면 의미 없는 거 같아요.
@jsl5073
7 ай бұрын
C++로 유명한 유튜버 분도 2년 전에 클린 코드 책 엄청 깠던 거 보고, 클린 코드에 대해서 비판적으로 접근하기 시작했는데, 정작 제가 이런 말 하니깐 주위에서는 절 이상한 사짜 취급하더라구요. 한 번 신랄하게 까주셔서 감사합니다.
@ABCABC._.ABCABC
7 ай бұрын
이건 정치색드러내는거랑 비슷한 개념같아요. 개인적으로 옳은 생각이란건 이거구나 하며 마음에만 품고 살아가면 별일없는데 그걸 누군가한테 얘기하거나 납득시키려면 필요한 자료나 내 사회적 위상 등, 따지고보면 짜증나는 과정을 거칠수밖에 없는거죠
@Y-NOT-
7 ай бұрын
비판을 하면 좋은 경험을 가졌던 사람에게서 반박이 따를수밖에 없죠 그런 경험적 부분은 서로 설득도 안되니 권위가없다면 사짜취급은 감수할수밖에..
@myut-il
7 ай бұрын
그분 포프님인가
@bwshin413
7 ай бұрын
보통 저런책들 박사들이 내니까 바이블 삼는 사람들은 니가 그 박사들보다 잘알아? 대단해? 이런식으로 걍 권위에 맡기기 하는...
@jkkim6928
4 ай бұрын
클린 코드를 비판해서 욕 먹은 게 아니라 비판을 제대로 된 논리와 근거 없이 해서 욕 먹은 걸 거라는 게 댓글을 통해서 짐작이 되네 ㅋ
@yeominsu
7 ай бұрын
저도 이 영상을 보고 말을 재미있게 하는 방법을 배웠구요
@user-pw6un9my6t
27 күн бұрын
신입땐 최대한 지키려 노력했는데 ㅋㅋㅋ 하나하나공감되네요
@dgh06175
7 ай бұрын
이 부분에 정말 고만이 많았는데 결국 제 주관을 가지고 정보를 비판적으로 바라보는게 중요한것 같네요
@시
7 ай бұрын
책 내용도 내용이지만 이름을 너무 잘지었어. 클린코드라니
@sorieil
7 ай бұрын
진찌 맞는말임 ㅋㅋ 요즘 주니어 중급 개발자들이 이책대로 하면 좋은줄알고 코드를 이렇게짜서 ... 하.... 맞춰주기.너무 힘든 시니어의 넉두리... 그냥 경험밖에 답이 없으니...
@Boy-qp7hw
7 ай бұрын
기술면접에서 클린코드로 함정질문을 파놓는다는 영상을 본적이 있는데 이걸 너무 신봉해서 주변사람들 피곤하게 만드는 사람인가 아닌가 확인할라고 하는거였네요 역시 너무 과하지도 덜하지도 않는게 좋은거같습니다
@yangseungtoung
7 ай бұрын
김포프님 채널 아닌가요. 그건 저도 동감입니다.
@r3b00t3
6 ай бұрын
코드의 의도를 분명하게 담아내는 주석 작성방법만 익혀도 이사람 배려할 줄 아는 사람이구나 느낄수 있어요, 괜히 시니어들이 주석 활용 잘하는게 아님
@creatorstoryx
7 ай бұрын
사실상 개발 팁 끄적여 놓은 책 아닐까 싶네요. 저는 참고 도서로만 취급해야겠습니다.
@ssseist
7 ай бұрын
세상 만사에 통용될 수 있는 말이네요.
@LeviathanTomo
4 ай бұрын
포큐형님한테 들었던 내용이네요 ㅋㅋ
@user-be3wx8bf8n
7 ай бұрын
함수를 가볍게 짧게 만드는 것은 메서드명을 통해서 가독성을 개선하는 것에 있는데요. 일일이 한줄 한줄 다 읽어가지 않아도 어떤 내용인지 직관적으로 파악함에 있어요. 책으로 치면 목차같은 느낌으로... depth가 너무 깊어지는 것도 가독성에 방해가 되니 적절하게 나누는 게 짬바이브 아닐까요?
@user-rm1uo5wk2w
7 ай бұрын
한참 유행했던 clean code 네요. 다만, 시니어급과 인터미디어급 개발자들이 해당 도서의 문제점도 언급하면서 함정 면접을 보는 경우도 많았고, 비판도 많이 받은 동시에 과거의 MS엔지니어들이 냈던 Code Complete가 다시 재조명을 받기도 했던게 기억나네요.
@dkdndjdndjd
4 ай бұрын
디스같지만 중요한 책 내용은 잘 설명해주셨네요 ㅎㅎ 읽지말라는 거 정말인가요
@G-Rim_Ester1z
7 ай бұрын
오.....제가 개발 하면서 개인적으로 철학화 시킨 사항들과 다 일치하네요. 대표적으로 코드 복붙 3개 정도 까지는 허용하는게 나중에 어떻게 서로 다르게 커스텀이 들어갈지 알 수 없는 경우 동일 코드로 두는 점이랑 구체적인 필요나 구조화 아이디어가 생기기 전 까지는 일단 하나에 때려넣는거랑 주석부분도 그렇군요. 주석은 생략하게 되는 경우가 많기는 하지만.......
@user-ep1fy6yq2w
7 ай бұрын
명서라고 부르는 책들은 한번만 읽어서는 그 의미를 완벽히 이해하기 힘들다고 생각합니다 책의 의미를 좀 더 잘 전달하기위해 다소 극단적인 예시를 드는 경우가 많고 처음에는 그걸 맹신하게 되는 함정이 있지만 경험치가 쌓이고 두번째 읽었을 때는 내포된 의미를 스스로 이해하면서 비판적인 시각을 가지는것이죠
@Hcastle
7 ай бұрын
제가 클린 코드 작성하면서 정말 느낀 부분들이네요. 코드 피드백 주고받으면서 제가 느끼기에는 주석이 있는게 훨씬 가독성이 좋아지는데 이걸 구지 없애고, 하나의 기능만 담아야 된다면서 엄청 나누는데 결국 가독성은 가져다 버리는... 잘 보고 갑니다
@hj11111
7 ай бұрын
본인이 짠 코드를 다시 유지보수하고 또 유지보수를 하다보면 저 책, 이 영상과 거의 비슷한 생각을 하시게 될거에요..ㅎㅎ
@jmash6651
4 ай бұрын
1:19 왔다갔다하는게 아니라 함수 이름으로 읽고 그런 일을 하는구나하고 자세히 분석하지 않고 그냥 넘어가면 됩니다. 잘 짜져 있는 코드라면 그렇게 하면 됩니다. 왔다갔다하라고 저렇게 하는거 아니에요. 주석처럼 함수 이름 만드는거에요
@user-rb8gv7nq3x
7 ай бұрын
와 오늘 서점에서 클린코드 찾다가 없어서 집에 왔는데 이런 영상이라니 아주 기가막힌 타이밍입니다.
@Y-NOT-
7 ай бұрын
구글은 다 보고있습니다.
@ResponseEntity
7 ай бұрын
함수 메서드 네이밍은 정말 중요하다고 느낀게 함수명만 봐도 그 함수가 어떤 기능을 하는지 알 수 있다는게 가장 큰듯. 그럴려면 단일 책임 원칙이 지켜져야함 클린 코드 책내용이 대전제가 그렇다는거지 예외 케이스 없이 모든 상황에 적용하라는 말은 아님
@user-le6co3fj4y
3 ай бұрын
코딩의 신 코딩애플이시여....
@danpyeong223
7 ай бұрын
이 영상이 한 달전에 나왔더라면 더 좋았을정도로 책과는 별개로 배운 게 많습니다 ㅠㅠ 특히 후반부에 나오는 중복코딩 몇 개 나온다고 나누는 부분에서 뼈져리게 느꼈습니다.. 최근 대학 팀플 과제 중 코드가 3~4개 중복되다보니 이걸 나눠야되겠지? 하는 생각에 나누고보니 진짜 영상에서 말한 것처럼 A에는 이게 필요한데 B에는 저것만 필요하고 하다보니 switch, if 문 등으로 오히려 더러워지더라구요.. 그쯤되니 머리론 아 이거 진짜 아닌 거 같은데.. 이게 진짜 효율적인게 맞나? 오히려 효율을 찾다가 비효율에 더러워진 것 같다 란 생각만 들었는데 그게 오늘 영상으로 확신이 되었습니다.. 쓸데없이 반복에 집착하지말고 뭐가 더 좋은지 한 번 더 생각하고 짜겠습니다! 너무 감사합니다 ㅠㅠ
@jsysonjung
7 ай бұрын
"가짜 중복"이었던겁니다
@klopp433
7 ай бұрын
융통성과 비판적 사고의 중요성
@msahn3722
4 ай бұрын
나는 주석이 필요없을 정도로 명쾌한 코드를 짜라는 걸로 이해하고 개발하고 있네요. 함수는 한가지 일만 하라는 것도 함수 이름에 포함되는 작업만 하라는 뜻으로 이해하면 좋은 방향이라고 생각해요.
@LunaGeonWoo
7 ай бұрын
애플님 VSCode 대체 가능성있는 Code Editor Cursor도 한번 다뤄주십쇼
@dolfalf
7 ай бұрын
절대적인건 앖습니다. 상황에 맞게 선택할 뿐이죠. 상황판단의 통찰은 경험을 통해 만들어 지기에 결국 초보시절엔 그냥 따라하고 어느정도 경험쌓이면 자기에 맞게 판단하는 방법이 가장 빠르게 성장하는 길이라 생각합니다.
@user-fs3tg7yz4j
4 ай бұрын
No Silver Bullet
@hkkun85
7 ай бұрын
2번에 변론하자면 순수함수를 지향하란거 아닌가요? 함수가 순수하먼 내용을 안봐도 되면 좋죠
@kenny-han
7 ай бұрын
아 좋은 영상입니다. ㅎㅎㅎ. 옛날에 처음 프로그래밍 배울때 변수명 글자수 8자리인가?? 암튼, 정해진 숫자로만 만들라고도 했었습니다. 그때는 그것이 정답이라고 했지요. 안그러면 초짜 취급 받는 ... 핵심은 쓰기 편하고 보기 편하게 딱봐서 뭔지 알게 코딩하는 것일 겁니다. 그걸 하기위한 방법은 환경이 바뀌면 언제든 바뀔 수 있습니다.
@1Rino1
7 ай бұрын
이거 보고 유지보수 하기 어렵게 코딩하는 법 한권만 읽으러 갑니다.
@kenji0q
7 ай бұрын
클린코드 책을 읽고있었는데 이 영상을 보고 다시끔 생각을 하게되네요 다행인 것은 적절한 수준을 유지하면서 클린코드를 지향하고있었습니다 신입 개발자들과 일하려면 가이드가 있어야해서 클린코드 내용을 지향점 삼아 개발을 했습니다 어느정도는 도움이 되었네요
@user-sr1my6pm7d
7 ай бұрын
저희 학원 쌤은 딱 이 정도 강요합니다. 1. 코드를 더 함축적으로 쓸 수 있는거 아니면 풀어 짜라. 2. 주석 없애고 싶으면 야근은 각오해라. 3. 변수명은 기존 팀원들 코드를 둘러보고 알잘딱 따라가라. 그게 시간 단축이다. 4. 이동이 3회 이상 벌어지는 코드는 재활용 하지 말고 그냥 새로 써라.
@kenny_130
7 ай бұрын
코딩애플님 코드 컴플릿트 책도 리뷰해주세요~
@lasercho4338
7 ай бұрын
선생님 영상 좀 자주 올려 주십쇼
@tarakkyu
7 ай бұрын
코드의 중복 제거 여부는 명확한 기준이 있다고 생각해요. 중복된 코드가 논리적으로 같은 의미이고 둘중 하나가 바뀌었을 때 다른 하나도 같이 바뀌어야 한다면 무조건 함수로 빼야합니다. 변경을 누락하는 실수를 방지할 수 있기 때문이죠. 하지만 중복 코드간 구현이 같더라도 논리적인 의미가 다르면 함수로 추출해선 안 됩니다. 한 부분의 수정이 다른 부분에 의도치 않은 사이드 이펙트를 줄 수 있기 때문이에요. 좋은 영상 감사합니당 굿
@jsysonjung
7 ай бұрын
@@arisa3364ㅎㅎ 그래도 기준은 있어야죠.
@user-de7yd9gv8z
7 ай бұрын
동의합니다
@user-bx6xq7bs5l
6 ай бұрын
코드의 중복이 아니라 논리의 중복이죠 사실 ㅎㅎ 예를 들어 세금 10% 계산로직과 팁 10% 계산로직이 우연히 같다고 해서 하나의 함수로 빼버리는 순간 지옥이 시작되는거죠. 팁이 5%로 바뀐순간 세금이 바뀌는 버그가 생기고, 이걸 해결하겠다고 세금/팁 타입을 넣고 분기를 넣기 시작하면 만든사람만 아는 레거시가 되는거죠 ㅋㅋ 이땐 코드가 아니라 한걸음 물러서서 추상화된 개념을 생각해야 하고 그냥 분리해야합니다. 코드만 보고 단순하게 리팩터링하면 걸리기 쉬운 함정입니다 ㅎㅎ
@jsysonjung
6 ай бұрын
@@user-bx6xq7bs5l 맞아요 원댓글하고 같은 말씀
@user-vh7fn5kb2i
3 ай бұрын
주저리주저리 조건 달아 놓고 무조건이라는 말을 쓰는건 무조건이라는 뜻을 모르나? 코딩 공부 전에 국어공부부터 다시해야할 듯 ㅋ
@user-gq4hw2bs9t
7 ай бұрын
와... 이 형님 이제 10시간 만에 5만을 돌파하네.
@user-sg7jy8wj3j
6 ай бұрын
입문자들을 위한 책은 아니고 장인을 향해나아가는 수준의 중니어들에서 시니어들에게 적절한 책입니다❤ 펑션이야기도 클래스장과 이어진내용입니다
@pollinipill
2 ай бұрын
지금 나이 오십. 프로그래머 34살까지 하고 그만뒀는데 지금 봐도 재밌네. 나 때 이런 사람 있었으면하고 감탄하고 갑니다.
@ro_oa
7 ай бұрын
코딩애플님같은 친구 있으면 좋겠당...
@chieryran8434
7 ай бұрын
인턴 시절 회사선배들이 주석에 대해 하신 말씀과 똑같네요. 그 회사 나와서 더 많은 시니어 분들을 만나다보니 지금은 그런말은 하지 않지만 주석이 없어서 신입시절부터 첫성과내는데 오래걸린거 생각하면…. (무려 첫직장인데..)
@user-ud9jz6bs1g
7 ай бұрын
ㅋㅋㅋ 이번 영상은 클린코드라는 책의 문제점을 정확하게 지적해 주셨네요. 특히 함수 부분 너무 시원합니다. 쭉 한 번 보면 그냥 알 수 있음에도 불구하고 함수를 무조건 나누려는 인간들이 있어요. 정말 광신도들은 답이 없어요. 더 한심한 건 너무 많아진 함수들이 관리되지 않아서 같은 기능의 함수들을 또 만드는 미친 인간도 있더군요. 환장합니다.
@silver33412
5 ай бұрын
그건 잘못 이해한 사례인데
@user-ud9jz6bs1g
5 ай бұрын
@@silver33412님이 그렇다고 말하는 것은 절대 아님을 미리 말하고요. 진짜 잘 하는 사람들도 해당 안 됩니다. 가장 큰 문제는 실력도 없는 사람들이 광신도처럼 맹신을 하는 바람에 현업에 방해가 되는 경우가 엄청 많다는 거죠. tdd도 마찬가지. 맹신을 하면 절대 안 되고 상황에 따라 내가 활용한다는 생각으로 접근을 해야 하는데 아무 생각없이 함수를 다 나눠서 나중에 자신이 그 함수들을 관리 못 하고 또 똑같은 함수들을 만들기도 하더군요. 나중엔 마땅한 함수명 고르는데도 시간 낭비... 이 영상도 그런 부분이 지나침을 말하는 거죠. 병적으로 함수를 나누려고 하지 마라...
@silver33412
5 ай бұрын
@@user-ud9jz6bs1g 뭔 말인지 모르겠는데 난 그냥 그 광신도 들이 잘못 이해한 사례라고 말하는건데 오해한듯?
@user-ud9jz6bs1g
5 ай бұрын
@@silver33412 ㅋㅋㅋ 그렇군요 나의 실수.. 그리고 님 말씀이 맞죠. 제대로 이해를 못하고 맹신한 결과죠.
@MOJELE
7 ай бұрын
똑똑한 청년.
@user-ub3po6ev2r
4 күн бұрын
혼자 취미로 코딩 하는거면 상관없는데 트레이드 오프라는 말이 괜히 있는게 아니죠 당연한 얘기겠지만 아키텍처나 디자인 패턴을 실무에 적용 하려고 노력하면 됨 정답은 없겠지만 이때 이런건 하면 안돼 라는건 분명 있어요 많이 적용해봐야 합니다
@BlackSkyUploadTube
7 ай бұрын
결론: 그냥 코딩애플님에게 외주를...(?!)
@kencidhan
4 ай бұрын
책이든 어떤 글이든 항상 그 글에서 말할려고 하는 핵심내용이 뭔지를 파악하는게 중요한데 항상 결론만 가지고 와서 과대해석하는게 무섭죠
@juuser732
7 ай бұрын
Code complete 은 어떻게 생각하시나요?
@user-xw2zz2wv2x
4 ай бұрын
클린코드를 감히 의심하다니! 이단이다!!!!
@spring22
7 ай бұрын
신성 모독이다!
@HongLab
7 ай бұрын
스펀지밥 절하는거 보고 안들어올 수가 없었다
@user-fo4fr7fk9d
7 ай бұрын
사실 리팩토링을 자주 해보는 습관을 들이면 어느정도 앞으로 어떻게해야될지 답이 보임. 근데 그런거 없이 저런책하나 정독하고 지가 싸놓은 똥 한번 안치워본 인간이 저게 바이블이라면서 지하고 싶은데로만 빠득빠득 우기면 피가 꺼꾸로솟는거임. 제발 그러지 맙시다...
@5dksdev767
16 күн бұрын
주석 부분이 이상한 이유에 대해 생각해봤는데 언어적 차이도 있는 거 같아요 영어가 모국어인 사람들은 그냥 코드만 읽어도 어느 정도 순식간에 이해할 수 있으니까요 근데 한국인들은 아무리 영어를 잘한다고 해도 미세한 속도 면에서 한국어 주석으로 읽을 때 코드를 더 빨리 이해할 수 있더군요
@user-pr2oy2nd4f
7 ай бұрын
주석이 중요하구나 ㄷㄷㄷㄷ 역시 시진핑
@devcode-kr
7 ай бұрын
중복 코드 허용은 진짜 맞는 말임 전혀 다른 기능에서 당장 똑같이 생긴거 있다고 함수로 묶은다음에 미묘하게 달라지면 if문 난사하게댐 기능이 다르면 각자 써야함 나중에 코드최적화 할때 판단해도 늦지 않음
@AlexanderDavis137
7 ай бұрын
클린코드 보면 20자 이상의 아름은 인지비용이 높아진다고 지양하라고 합니다. 3:10 쯤 나오는 예시는 부적절한 것 같네요.
@dimplenop6400
7 ай бұрын
디미터의 법칙은 어떻게 생각하시나요?
@user-pj2cm7wv7f
7 ай бұрын
감사합니다
@user-oj4lc2wv7q
7 ай бұрын
와아 클린코드 두꺼워서 읽어야지 읽어야지 하다 안 읽었는데 한권다봤다 개꿀
@user-wl2zf8ww6b
7 ай бұрын
함수나 클래스가 있어서 들어가 보면 거의 아무 것도 안 하고 다음 함수로 넘기고, 또 거기 들어가 보면 약간의 기능만 더해서 다음 함수로 넘기고.. 이런 식으로 끝없이 반복하는 코드들 보면 진짜 열불나더라고요.. 심지어 반복되는 코드도 아니라 그냥 다섯 줄로 이어서 적으면 될 걸 함수 다섯 개로 만들어 놨어.. 지금 보니 저 책이 만악의 근원이었군요.
@pauljung2435
7 ай бұрын
약간 유지보수에 좋은 것들이네여
@pipoket
7 ай бұрын
1:02 ...와 미친... 내 무습다... 함수 포장지 미쳤네...
@m1emili0
4 ай бұрын
기본적으로 영어를 잘해야 네이밍을 잘하고, 네이밍을 잘해야 주석도 없앨 수 있는 거죠. 네이밍 잘하고 펑셔널 프로그래밍 잘하면 굳이 함수의 속까지 매번 뜯어볼 필요 없이 잘 읽히는 코드 되는 거고.
Пікірлер: 495