그래서 어플리케이션 하나를 완성하지 못하는 사람한테 클린 코딩은 의미가 없는 것 같더라구요. 그런 사람한테 클린 코딩하라고 하면 "완성이냐 vs 클린이냐"가지고 자기 혼자 머릿속에서 이해충돌 시간의 비용이 길기 때문에 오히려 자유분방하게 뛰어놀게 만드는게 더 나은거같더라구요.
회사 상황에 따라 다르겠지만 실리콘밸리의 초고속 승진 신화는 새로운 아이디어로 매출을 확 끌어올릴 돌파구를 만들어 내는 사람들이 만들어갑니다. (예: 인스타그램 스토리, 스냅챗 AR 필터 등) 남들이 못 보는 것을 보는 안목도 필요하고 아이디어를 증명해내는 끈기와 구현 능력도 필요하겠죠. 운은 사람으로부터 나오는 거니까 좋은 사람들을 끌어들이는 친화력도 필수!
영상을 통해 위로와 자신감을 얻습니다 :) 서비스를 개발하고싶은, 단순 코드 개발자에서 프로그래머로 거듭나기 위한 사람들 한테는 너무 많은 생각은 오히려 해가 되는거 같더라구요! 저도 왜 이렇게 막상 돌아보면 완성까지 경험해본게 그렇게 많지 않고, 왜 그렇게 각각 오래 걸렸지를 고민했는데 영상처럼 좋은 이론들, 내 가치관에 매몰되어 정작 내 수준 및 현실에 맞게 구현하지 않아 일정을 맞추지 못하고 있더라구요... 그래서 머리를 가볍게 하여 1. 일정을 맞추기 위해 내가 할 수 있는 수준에서 다음 행동 찾기 2. 시작부터 배포까지의 완성 경험 3, 얕지만 넓은 시야에 집중하기로 합니당 :)
저의 경우는 미구현된 코드는 일정상 문제로 못한채로 제출한적이 많았습니다. 보통 이직할때 여러곳에 서류들을 넣기 시작하는데 과제 전형이 있는지 모르는 상황에서 갑자기 몇곳에서 과제를 언제까지 제출하라는 일방적인 상황이 있었기도 했었구요.. (동시에 과제전형이 두곳 이상 오면 멘붕입니다....) 야근이 많고 개인적인 일들이 많은 상황에서 과제를 하는것도 쉽지 않더라구요 그래서 날자를 정해서 언제부터 과제를 할 수 있는 상황임을 인지하고 그 이후에 과제를 내주는게 좋겠다는 생각을 많이 했었습니다.
AI 코드 인터프리터 등장으로 인해 코드의 국소적이고 정말 디테일한 부분은 중요하지 않은것 같고 전체적인 구현이 가장 중요하며 나무보다는 숲을 볼수 있는 개발자의 필요성이 점점 대두 되는거 같습니다. 클린코드도 예전의 들여쓰기 컨벤션 이런부분이 중요하지 않고 설계를 어떻게 했나. 어떤 프레임웍 라이브러리를 적재적소에 선택하고 그부분이 성능상 이점이 있고 없고의 판단. 확장성의 용이함. 즉, 클린코드의 기준 자체가 이젠 달라지는것 같습니다.
좋은 아키텍쳐는 장기적인 관점에서 스케일업과 유지보수 등을 용이하기 위함이지 초창기에 빠른 개발을 하기 위한 용도는 아니라고 봅니다. 뭐 숙달되면 더 빠를 수도 있겠지만.. 막코딩하다보면 소프트웨어를 버려야하는 경우도 많습니다. 과제같은 경우 당연히 다 구현을 해야하는게 맞고, 아키텍쳐는 하면 좋고 안 해도 뭐 정도인데, 너무 막코딩이면 음..
조금 프레임을 벗어나서 생각해볼수도 있어요. 과연 그 과제 스팩이 적정한가. 질문이 실제 업무에 쓰일수 있는 사례인가. 지금 시험범위 없는 시험기간을 지내는 사람 입장에서는 시험을 의심할수 있다는 가정도 못할수 있습니다. 테스트 별로면 가지마세요. 다만, 내가 구현하지 못한거는 반드시 테스트 후에 리뷰는 해보면 좋습니다. 모의고사처럼 사용하는거죠. 두 사례일 뿐입니다. 보편 타당한건 아니기에 신입/주니어 분들은 절대로 바이블로 삼지 말고 의견의 일부로 받아 들이세요.
결과론 적으로만 따지면 저도 막코딩 하는 사람 후자를 선택하긴 할 것 같습니다. 프로젝트 데드 라인이라는 건 무척이나 중요하죠.. 그거 맞추겠다고 날밤 새는 거니까요.. 이 일정이 나 혼자만의 문제가 아니라 사업적인 일정에 차질이 생기거나 클라이언트와의 신뢰도도 연결되어 있으니까요.. 그런데 이 후자 스타일의 사람을 절대 쉽게 말할 수는 없습니다. 경험담 이구요.. 세살버릇 여든 간다는 말처럼.. 습관 절대 쉽게 안고쳐 집니다. 코딩도 막코딩인데 주석 조차도 거의 안달고 심지어 시간 좀 지나면 본인도 기억을 못합니다. 본인도 기억 못하는데 그 소스를 봐야 하는 다른 개발자들은 지옥 입니다. 심지어 git 에 commit 할때 조차 메모 없이 그냥 날립니다.. 이정도면 거의 맥이는 건가 싶은 생각도 듭니다. 후우... 달래도 보고 화도 내봐도 절대 쉽게 안 고쳐 진다는 점.. 😡😡😡
미완성된 코드는 완성된 프로그램이 아닙니다. 결국 막 개발한 코드여도 완성된 프로그램이 현업에서는 맞는거고... 시간적, 상황적 여유가 있다면 미완성된 것이어도 고민을 해봐야겠지만 사실 대부분의 상황에서 옳은 선택이 아닐 가능성이 높습니다. 예전에 개발자 농담 중에 1년, 2년, 3년, 5년, 10년차 개발자가 헬로월드를 작성하는 방법이 유머 글로 본 적이 있었는데, 비유적으로 표현되어 있지만 핵심이 있다고 봅니다.
주니어 개발자 입니다~ 요즘 실무에서 고민하던 내용인데 주제로 나왔네요~ 전 일단 그래도 기조는 8~ 90점 대의 프로그램을 기한내에 만드는게 가장 중요하다라는 걸 (누가 이야기 한 건지는 잘 몰?루) 듣고나서 일단은 실천 중입니다. 요새 TDD부터 시작해서 DDD, 헥사고날 아키텍쳐 공부를 하면서 실무에서도 실천하고 있고, 그러다보니까 예전보단 확실히 개발 속도가 늦더군요.. 물론 기한 내 정해진 일정이 있기 때문에 초반에는 나름 좋은 구조를 짠 것 같다고 생각 했다가도 나중에는 코드 짜면서도 이건 벌써 단일 책임 원칙을 좀 벗어나고 있는데? or 의존성을 너무 타고 있어서 테스트 하기에 힘들 것 같은데란 생각이 드는데도 불구하고 일단은 기능 먼저 구현하고 리팩토링은 나중에~ 라고 생각 해 놓고는 결국은 리팩토링은 못하고 있는 상황의 개발 환경에 놓여 있습니다. 주니어 개발자긴 하지만 개인적인 성장 때문에 욕심이 있기도 하고.. 선임이나 후임들에게도 제가 만든 코드가 부끄럽고 싶지는 않아서 노력 중이긴 한데.. 결국은 실무에서는 윗분들 한테는 기한안에 기능을 구현했는지 안했는지로 제 역량을 판단하기 때문에 기능 구현이 역시 1순위라고 생각하며 공감했습니다~
혹시 이 부분에 대해서는 어떻게 생각하시나요? 물론 기능 구현은 두 케이스다 된다는 가정 하에 시간이 좀 더 걸리더라도 클린코딩을 하는 사람 vs 시간이 조금 덜 걸리더라도 클린코딩을 안하는 사람 제 생각은 시간이 좀 더 걸리더라도 미래의 생산성을 위해 리팩토링 하는 과정이 필요하다고 생각하는데 다른 분들은 어떻게 생각하시는지 궁금합니다. 복잡한 로직 일수록 시간이 지나고 리팩토링을 하지 않는다면 들어가는 비용이 더 높아지지 않을까요? (소스코드를 파악하는 시간 + 난해한 코드에 내 로직을 끼워넣기 위한 시간)
”시간이 더 걸린다“ 는건 기한을 초과하는걸 말씀하시는걸까요? 어떤 직업이던 해야하는 일을 주어진 기한안에 해내는게 가장 중요합니다. 내 역량상 기한안에 기능구현+클린코딩을 할 수 없다고 판단되면 당연히 클린코딩을 포기해야한다고 생각합니다. 그리고 가능하다면 배포 이후에 리팩토링해서 클린코딩까지 달성하면 좋겠지요.
ㅋㅋㅋㅋ 식칼 만들때 예리히고 단단한 칼날을 만들었지만 손잡이는 못만들었어요. 라는거랑 뭐가 다를까라는 생각이 드네요. 손잡이를 완벽하지는 못하더라도 헝겁이나 가죽으로 둘둘말아서 잡기는 할수있게 만들어야 식칼로 쓸수있지않을까요. 기능구현끝나고 주석으로라도 todo로 개선하고싶은 내용을 언급하고 거기에 대해서는 면접에서 풀어도 되지않을까 생각합니다. 과제할때 최소 몇몇 기능은 필수로 완료시켜야합니다 등등으로 과제를 강제하는게 서로 좋지않을까라는 생각을 하게 되네요.
상황마다 다르죠. 예시로 나왔던 두 지원자중 전자(클린코딩이지만 기능구현X) 가 만일 클린 코딩 버리고 개발새발 구현했더라면 기간내에 끝내지 않았을까? 를 고려해봐야하고 또 반대로 후자(스파게티지만 기능구현O) 에게 왜 그렇게 코드를 짰고 개선할 방법에 대해 물어봤더니 어버버하기만하고 디자인 패턴에 대한 개념이 전혀 없는 경우면 어떡할까요?
구현이 우선인 상황이 있고, 클린코드가 우선인 상황이 있을겁니다. 상황에 따라 유연한 전략을 선택해야겠지만, 기본적으로 구현 먼저가 최우선순위에 들어가는건 좋은 전략은 아니라고 생각합니다. 클린코드에 나오는 기술부채라는 좋은 표현이 있는데, 해당 용어를 곁들여서 설명해주셨으면 좋았을 것 같습니다. 점점 쌓이는 기술부채를 고려해보면 구현을 먼저하는 것이 결국 더 느리게, 더 어렵게 돌아가는 길이 되는 경우들이 많습니다. 그렇기에 클린코드의 1장에서부터 그 중요성을 강조한다고 생각합니다.
핵사고날 아키텍처의 핵심은 인터페이스를 통해 결합도를 낮추고 도메인별로 응집성을 높이는데 있는데 향후 유지보수의 유리함 때문이라 생각합니다. 내가 다루고 있는 소프트웨어 어플리케이션의 크키에 따라 면접에서 중점으로 봐야할 기준이 달라지지 않을까요? 작은 규모라면 기능구현에 더 초점을...
간혹 요구사항이 지나치게 짧게 주는 회사들이 있을 수 있는데 그런 회사는 걸러야 하는거구요. 영상 사례처럼 2주나 줬는데 완성못하는 거면 쓸데 없는 오버엔지니어링으로 시간이나 처 잡아 먹는건데, 그정도 능지와 실력이 없다면 걍 불합격! 해야지 무슨 시간이 없다고 궁시렁궁시렁 ㅋㅋㅋㅋ 님들 없어도 지원자 3자리수로 넘쳐나요. 어차피 뽑는건 2,3명 정도인데 징징거리지나 마세요 ㅋ 꼬우면 취업했어야지! 루져들 같으니 ㅋㅋ
클린 코드 뒤에 숨는 동료보다 피투성이가 되더라도 구현하는데 목숨을 건 동료가 먼 길을 같이 갈 수 있을 거라 생각합니다
구현해서 피흘려본 다음에 사용되는 클린코드 기법이야말로 진짜이기도 함, 어디서 책에 몇글자 나온걸 문제도 없는상황에 발라봐야 코드 유지보수성만 나빠지고 아무소용없음
@@lunar1593근데 그때가서 귀찮아서 클린코드 기법을 적용을 할까요? ㅋㅋㅋㅋ
@@ujty207 꾸준히 리펙토링하지 않은 코드들이 여러사림 손타면서 결국 수정불능으로 망가지더라구요.
구현후 리팩토링 거쳐서 좋은코드로 가야쥬 ㅎ
그래서 어플리케이션 하나를 완성하지 못하는 사람한테 클린 코딩은 의미가 없는 것 같더라구요. 그런 사람한테 클린 코딩하라고 하면 "완성이냐 vs 클린이냐"가지고 자기 혼자 머릿속에서 이해충돌 시간의 비용이 길기 때문에 오히려 자유분방하게 뛰어놀게 만드는게 더 나은거같더라구요.
프로그래밍의 데드라인은 항상 중요하다고 봅니다. 오픈일자에 못 맞추면 ...
그리고 많이 만들어봐야... 패턴도 클린코드도 고민할수 있다고 봅니다.
해본적이 없는데 패턴이나 클린코드를 적용하려면... 그게 더 어려울듯 합니다.
전 주니어때는 클린코드를 굳이 안보는게 더 좋다고 생각해요
구현능력이 어느정도 올라가고 보면 시너지가 생기지 구현도 못하는데 클린코드에 목매는 분들이 너무 많은거같아요
그럼 과제 탈락 해버리는걸
회사 상황에 따라 다르겠지만 실리콘밸리의 초고속 승진 신화는 새로운 아이디어로 매출을 확 끌어올릴 돌파구를 만들어 내는 사람들이 만들어갑니다. (예: 인스타그램 스토리, 스냅챗 AR 필터 등) 남들이 못 보는 것을 보는 안목도 필요하고 아이디어를 증명해내는 끈기와 구현 능력도 필요하겠죠. 운은 사람으로부터 나오는 거니까 좋은 사람들을 끌어들이는 친화력도 필수!
먼가 그런 느낌 받을때 있어요...기능을 자기 클린코드에 맞추는 느낌ㅎㅎ
역시... 완전히 잘못된 오답을 내지않은 이상... 코드가 어지럽더라도 제한 시간내에, 기능 구현을 잘 해낸 분이 나을것 같아요. 영상 잘 보았습니다 👍
영상을 통해 위로와 자신감을 얻습니다 :)
서비스를 개발하고싶은, 단순 코드 개발자에서 프로그래머로 거듭나기 위한 사람들 한테는 너무 많은 생각은 오히려 해가 되는거 같더라구요!
저도 왜 이렇게 막상 돌아보면 완성까지 경험해본게 그렇게 많지 않고, 왜 그렇게 각각 오래 걸렸지를 고민했는데 영상처럼 좋은 이론들, 내 가치관에 매몰되어 정작 내 수준 및 현실에 맞게 구현하지 않아 일정을 맞추지 못하고 있더라구요...
그래서 머리를 가볍게 하여
1. 일정을 맞추기 위해 내가 할 수 있는 수준에서 다음 행동 찾기
2. 시작부터 배포까지의 완성 경험
3, 얕지만 넓은 시야에 집중하기로 합니당 :)
저의 경우는 미구현된 코드는 일정상 문제로 못한채로 제출한적이 많았습니다.
보통 이직할때 여러곳에 서류들을 넣기 시작하는데
과제 전형이 있는지 모르는 상황에서 갑자기 몇곳에서 과제를 언제까지 제출하라는 일방적인 상황이 있었기도 했었구요..
(동시에 과제전형이 두곳 이상 오면 멘붕입니다....)
야근이 많고 개인적인 일들이 많은 상황에서 과제를 하는것도 쉽지 않더라구요
그래서 날자를 정해서 언제부터 과제를 할 수 있는 상황임을 인지하고 그 이후에 과제를 내주는게 좋겠다는 생각을 많이 했었습니다.
AI 코드 인터프리터 등장으로 인해 코드의 국소적이고 정말 디테일한 부분은 중요하지 않은것 같고 전체적인 구현이 가장 중요하며 나무보다는 숲을 볼수 있는 개발자의 필요성이 점점 대두 되는거 같습니다. 클린코드도 예전의 들여쓰기 컨벤션 이런부분이 중요하지 않고 설계를 어떻게 했나. 어떤 프레임웍 라이브러리를 적재적소에 선택하고 그부분이 성능상 이점이 있고 없고의 판단. 확장성의 용이함. 즉, 클린코드의 기준 자체가 이젠 달라지는것 같습니다.
다음 주제: 구현을 잘하는 방법
구현못하는 클린코드 지향자 = 곱하기를 알긴하는데 덧셈이 느리거나 틀리고 이제는 미적분까지 욕심냄
구현꼼꼼히 잘해둔 막코드 지원자 = 아직 곱하기는 모르지만 덧셈은 확실하게 잘함
-> 후자가 기본기가 충실한 상태이므로 곱하기 가르치는데 비용이 덜 들것이라고 보인다
결론이 이런 느낌으로 생각되네요
좋은 아키텍쳐는 장기적인 관점에서 스케일업과 유지보수 등을 용이하기 위함이지 초창기에 빠른 개발을 하기 위한 용도는 아니라고 봅니다. 뭐 숙달되면 더 빠를 수도 있겠지만.. 막코딩하다보면 소프트웨어를 버려야하는 경우도 많습니다. 과제같은 경우 당연히 다 구현을 해야하는게 맞고, 아키텍쳐는 하면 좋고 안 해도 뭐 정도인데, 너무 막코딩이면 음..
조금 프레임을 벗어나서 생각해볼수도 있어요.
과연 그 과제 스팩이 적정한가.
질문이 실제 업무에 쓰일수 있는 사례인가.
지금 시험범위 없는 시험기간을 지내는 사람 입장에서는 시험을 의심할수 있다는 가정도 못할수 있습니다.
테스트 별로면 가지마세요. 다만, 내가 구현하지 못한거는 반드시 테스트 후에 리뷰는 해보면 좋습니다. 모의고사처럼 사용하는거죠.
두 사례일 뿐입니다. 보편 타당한건 아니기에 신입/주니어 분들은 절대로 바이블로 삼지 말고 의견의 일부로 받아 들이세요.
안녕하세요, 프론트엔드 개발자가 되기 위해서 9개월동안 공부한 취준생입니다. 이 영상을 보고 시니어 개발자분들이 신입 개발자에게 어떤 점을 원하는지 좀 더 알 수 있었어요! 많은 도움이 되었습니다. 좋은 영상 감사합니다. ㅎㅎㅎ
호돌맨님 말씀처럼 과제 잘했으면 기능구현은 물론이고 코드도 잘짜야죠. 어느한쪽만 됐다면 그냥 현재 실력이 부족한 것..
실무에서 그 실력이라면 일단 스파게티라도 완성하는게 먼저고 그 다음에 리팩토링 하는게 맞다고 봐요.
17:22 개발에 한정 짓지 않아도 여러 일에 적용되는 띵언이네요
결과론 적으로만 따지면 저도 막코딩 하는 사람 후자를 선택하긴 할 것 같습니다. 프로젝트 데드 라인이라는 건 무척이나 중요하죠.. 그거 맞추겠다고 날밤 새는 거니까요.. 이 일정이 나 혼자만의 문제가 아니라 사업적인 일정에 차질이 생기거나 클라이언트와의 신뢰도도 연결되어 있으니까요..
그런데 이 후자 스타일의 사람을 절대 쉽게 말할 수는 없습니다. 경험담 이구요.. 세살버릇 여든 간다는 말처럼.. 습관 절대 쉽게 안고쳐 집니다.
코딩도 막코딩인데 주석 조차도 거의 안달고 심지어 시간 좀 지나면 본인도 기억을 못합니다.
본인도 기억 못하는데 그 소스를 봐야 하는 다른 개발자들은 지옥 입니다.
심지어 git 에 commit 할때 조차 메모 없이 그냥 날립니다.. 이정도면 거의 맥이는 건가 싶은 생각도 듭니다.
후우... 달래도 보고 화도 내봐도 절대 쉽게 안 고쳐 진다는 점.. 😡😡😡
그렇다면 지금 말한 안좋은 케이스의 반대는 클린코드다??? 이거완전 민주당 아니면 국힘이다 급이네여. 클린코드랑은 아무상관도 없는거 같은데
@@jillneleson2466하.. 어르신😅
기능구현이라는 대전제를 못 맞추는 주니어들 많은데, 이거보고 느끼는 게 많았으면 좋겠네요
미완성된 코드는 완성된 프로그램이 아닙니다. 결국 막 개발한 코드여도 완성된 프로그램이 현업에서는 맞는거고... 시간적, 상황적 여유가 있다면 미완성된 것이어도 고민을 해봐야겠지만 사실 대부분의 상황에서 옳은 선택이 아닐 가능성이 높습니다.
예전에 개발자 농담 중에 1년, 2년, 3년, 5년, 10년차 개발자가 헬로월드를 작성하는 방법이 유머 글로 본 적이 있었는데, 비유적으로 표현되어 있지만 핵심이 있다고 봅니다.
아 ㅋㅋ 기억나네요 ㅋㅋ
1년차 사수없이 개발하는 신입인대 여기보면서 성장방향을 올바르게 잡을수있습니다.
감사합니다
요즘 고민하고 있던 주제였는데, 이해하기 쉽게 설명해주셔서 감사합니다🥹❤️
주니어 개발자 입니다~ 요즘 실무에서 고민하던 내용인데 주제로 나왔네요~ 전 일단 그래도 기조는 8~ 90점 대의 프로그램을 기한내에 만드는게 가장 중요하다라는 걸 (누가 이야기 한 건지는 잘 몰?루) 듣고나서 일단은 실천 중입니다. 요새 TDD부터 시작해서 DDD, 헥사고날 아키텍쳐 공부를 하면서 실무에서도 실천하고 있고, 그러다보니까 예전보단 확실히 개발 속도가 늦더군요.. 물론 기한 내 정해진 일정이 있기 때문에 초반에는 나름 좋은 구조를 짠 것 같다고 생각 했다가도 나중에는 코드 짜면서도 이건 벌써 단일 책임 원칙을 좀 벗어나고 있는데? or 의존성을 너무 타고 있어서 테스트 하기에 힘들 것 같은데란 생각이 드는데도 불구하고 일단은 기능 먼저 구현하고 리팩토링은 나중에~ 라고 생각 해 놓고는 결국은 리팩토링은 못하고 있는 상황의 개발 환경에 놓여 있습니다. 주니어 개발자긴 하지만 개인적인 성장 때문에 욕심이 있기도 하고.. 선임이나 후임들에게도 제가 만든 코드가 부끄럽고 싶지는 않아서 노력 중이긴 한데.. 결국은 실무에서는 윗분들 한테는 기한안에 기능을 구현했는지 안했는지로 제 역량을 판단하기 때문에 기능 구현이 역시 1순위라고 생각하며 공감했습니다~
캬 주니어가 벌써 8 90점의 프로그램을 만들다니 패기에 지리것소
Imposter Symdrome 가면 증후군이라고 하죠,, 어렵네요. 나의 코드가 부끄럽고 이게 맞나?? 싶어서 1+1을 계속 보고 있는 느낌
기능구현을 잘하는 사람들은 개선할 생각만 열려있다면 클린코드 적용하는거 금방 적용할 수 있음
하지만 기능구현을 못한다? 이건 기본기 부족이라 상당한 시간이 걸림
저도 일을 해내는 사람이 더 좋다고 생각합니다~ 요구사항만 달성하고 좋은코드로 보여지지 않더라도 테스트코드를 잘 짜면 너어어무 좋을 것 같아요.
구현을 다 못한 사람이 시간 탓을 한다면, 막코딩을 한 사람도 시간 탓을 할 수 있습니다.
시간 탓을 똑같이 했으므로 제외한다면, 한명은 구현하지 못했고 한명은 구현했을 뿐입니다.
일단 맡은 일은 끝내야죠.
그리고 일반적으로는 둘 다 합격 못ㅎ......
혹시 이 부분에 대해서는 어떻게 생각하시나요?
물론 기능 구현은 두 케이스다 된다는 가정 하에
시간이 좀 더 걸리더라도 클린코딩을 하는 사람 vs 시간이 조금 덜 걸리더라도 클린코딩을 안하는 사람
제 생각은 시간이 좀 더 걸리더라도 미래의 생산성을 위해 리팩토링 하는 과정이 필요하다고 생각하는데
다른 분들은 어떻게 생각하시는지 궁금합니다.
복잡한 로직 일수록 시간이 지나고 리팩토링을 하지 않는다면 들어가는 비용이 더 높아지지 않을까요? (소스코드를 파악하는 시간 + 난해한 코드에 내 로직을 끼워넣기 위한 시간)
”시간이 더 걸린다“ 는건 기한을 초과하는걸 말씀하시는걸까요?
어떤 직업이던 해야하는 일을 주어진 기한안에 해내는게 가장 중요합니다.
내 역량상 기한안에 기능구현+클린코딩을 할 수 없다고 판단되면 당연히 클린코딩을 포기해야한다고 생각합니다.
그리고 가능하다면 배포 이후에 리팩토링해서 클린코딩까지 달성하면 좋겠지요.
그렇다면 예를 들어
개발자1 기한 때문에 클린코딩 못함.
개발자2 기한 떄문에 클린코딩 못함.
개발자3 기한...
이렇게 된다면 소스는 어떻게 될까요?
과제전형은 그런부분이 참 어려운거같아요 회사다니면서 과제하려니 시간이 모자라서 네이티브쿼리로 짜서 내게되구 ㅜ 6:16
구현해보고 거기서 불편함을 느끼는
과정이 없어서 개념을 이해하기도 어렵고 구현하기도 어렵지 않은걸까유?
ㅋㅋㅋㅋ 식칼 만들때
예리히고 단단한 칼날을 만들었지만 손잡이는 못만들었어요. 라는거랑 뭐가 다를까라는 생각이 드네요.
손잡이를 완벽하지는 못하더라도 헝겁이나 가죽으로 둘둘말아서 잡기는 할수있게 만들어야 식칼로 쓸수있지않을까요.
기능구현끝나고 주석으로라도 todo로 개선하고싶은 내용을 언급하고 거기에 대해서는 면접에서 풀어도 되지않을까 생각합니다.
과제할때 최소 몇몇 기능은 필수로 완료시켜야합니다 등등으로 과제를 강제하는게 서로 좋지않을까라는 생각을 하게 되네요.
상황마다 다르죠. 예시로 나왔던 두 지원자중 전자(클린코딩이지만 기능구현X) 가 만일 클린 코딩 버리고 개발새발 구현했더라면 기간내에 끝내지 않았을까? 를 고려해봐야하고 또 반대로 후자(스파게티지만 기능구현O) 에게 왜 그렇게 코드를 짰고 개선할 방법에 대해 물어봤더니 어버버하기만하고 디자인 패턴에 대한 개념이 전혀 없는 경우면 어떡할까요?
@@__sizeof__ 완성된 코드가 있어야 과제 평가를 할수있잖아요. 코드가 않좋거나 위에 말한 todo로 변경계획도 없다면 떨어뜨리면 되고 시간상 부족해서 todo로 변경계획정도 남겼다면 면접에서 검증하면 되지않을까요?
클린코드는 안 바라더라도, 제발 스키마를 dto로 냅다 쓰지말고, 1섹션 1 api 에 1dto 만들고, 어디서는 이미지 어디서는 썸네일 등등... 이렇게 네이밍 하지 않기를 바라요...😢
토비님 인프콘 강연보고 다시 보러 왔어요 🎉
개발자는 예쁜 코드를 만드는 직업이 아닙니다. 동작하는 프로그램을 만드는 직업입니다.
물론 제대로 동작하는 클린 코드를 작성하는게 최선이겠죠. 하지만 클린 코드를 작성 할 지 기한을 지킬 지 선택해야 한다면 언제나 후자를 선택하는게 옳습니다.
클린코드 하면서 납기를 맞출수 있으면 누가 나은지 이건 이야기거리도 될수가 없죠. 대부분 그게 안되니깐 이야깃거리가 되는거고 ㅋㅋㅋ
이런 내용 참 좋은거 같습니다!!!!
정답은 없음. 정답이 있는 문제였다면 인간보다 컴퓨터가 더 잘 하겠지. 트레이드 오프 사이의 선택만 존재
누구는 백엔드면 백엔드만 파도 몇십년이 걸리는데 프론트는 오바떠는거다 그러고... 요즘은 다 할 줄 알아야 한다 그래서 혼란이 오는거 같네요 ㅠㅠ
또 취준생 입장에서 시간은 한정적일텐데..
지피티활용잘하면1년만에 기존5년차경력의. 풀스택가능 물론열심히해야되긴하죠
향로님과 같은 고민을 하던 참에 좋은 영상 감사합니다
ㅋㅋㅋ SI는 만들면 운영은 SM이 하니까. 라이브서비스업체는 오늘 내가 짠 코드가 내일부터 내 발목 잡음
정말 맞는 말입니다. 그래서 대부분의 SI 코드품질이 개판이 될 수 밖에 없다고 봐요. 똥 싸놓고 나가면 끝이니까
와엄청공감되는주제네요 잘보았습니다
구현이 우선인 상황이 있고, 클린코드가 우선인 상황이 있을겁니다. 상황에 따라 유연한 전략을 선택해야겠지만, 기본적으로 구현 먼저가 최우선순위에 들어가는건 좋은 전략은 아니라고 생각합니다. 클린코드에 나오는 기술부채라는 좋은 표현이 있는데, 해당 용어를 곁들여서 설명해주셨으면 좋았을 것 같습니다. 점점 쌓이는 기술부채를 고려해보면 구현을 먼저하는 것이 결국 더 느리게, 더 어렵게 돌아가는 길이 되는 경우들이 많습니다. 그렇기에 클린코드의 1장에서부터 그 중요성을 강조한다고 생각합니다.
기술부채가 클린코드 따위 하면서 쉽게 나오는 상황이 아닐텐데 너무나 쉽게 언급되는군요. 어지간한 막코딩을 해도 겪기 힘들텐데 혹시 한번이라도 겪어보셧는지? 설명 가능할까요 ?
선개발 후리팩토링ㅎㅎ
개발 리드랑 영업 리드 채널이죠?
퇴근 길 최고의 선택!
핵사고날 아키텍처의 핵심은 인터페이스를 통해 결합도를 낮추고 도메인별로 응집성을 높이는데 있는데 향후 유지보수의 유리함 때문이라 생각합니다. 내가 다루고 있는 소프트웨어 어플리케이션의 크키에 따라 면접에서 중점으로 봐야할 기준이 달라지지 않을까요? 작은 규모라면 기능구현에 더 초점을...
클린코드 하기전에 메모리릭 발생해서
클린코드 하니까 권고사직 받으면요?
출근길 재밌는 주제 감사합니다. 😊😊
문제해결능력이 의심되니까 어쩔수 없을거같아요🤣
오늘 아침 최고의 선택😅
대부분의 개발자들은 클린코드를 염두에 두지 않는게 현실인듯
소설도 완결냈으면 상위5%인것처럼.
요즘 드는 고민이었는데 마침 이런 주제로 이야기해주셔서 감사합니다 ㅠ
책에나온 클린코드는 못하더라도 매번 다른방법으로 개발을 시도하는 친구가 역량이 훨씬 뛰어나다고 봅니다. 진짜 클린코드는 결국 후자가 하는거죠.
못해서 욕먹는 것보다 안하고 욕먹는게 낫겠죠??ㅎㅎ
공감합니다...
이기적이냐 아니냐 그 차이다 소스는
구현을 잘할려면 알고리즘 문제를 잘풀어야 할까요? 책이나 강의없이는 개발진도가 안나가요ㅠ
그냥해보셔야합니다 구현은 삽질에 비례한다고 생각합니다... 이하 3년차 백엔드...
알고리즘 문제 ㅋㅋㅋㅋㅋㅋㅋ ㅜㅜㅜ 이게 대한민국 코딩 교육, 입사 시스템 현실이네요
구현을 못하는데 개발자인가요?? 복붙러지;;
기능 != 코드 ? 텍스트 : 프로그래밍
클린코드는 제가보기엔 이등병들 직각식사 하듯한 어색함이 있습니다. 일단 코드는 짜야 잘짜는법을 고민하는거지 진짜 역량 자체가 딸리는데 클린코드를 시도하는 현상이 보이네요. 그래서 진짜 좋같은 코드가 나옵니다. 고쳐주는거보다 새로만드는게 더 빠른.
결국 tdd 든, ci/cd 든 많은 개발론은 제품을 빠르고 잘 만들기 위한 도구일 뿐. 도구에 매몰되면 안된다고 생각합니다...
좋은말이군요
요즘은 둘 다 충족한 사람만 뽑지 않나요?
퀄리티 좋게 만들고 멋있는 아키텍처에 집착하다보면 심리적으로 위축되서 진도가 안나가요.
동감합니다
(단어적 표현은 다르지만 같은 내용)
비교적 쉽게 빠질 수 있는게 자기만의 아키텍처라고 열심히 만든게 어느순간 자기 자신를 옥죄어 오는거죠
즉 자기가 만든 룰에 자기가 갇히는 구조
서비스업인데 기한 내 구현을 못하면 어떻게 되는 거죠? 아찔하네요😱
사람은 몰라도 못생긴 코드는 꾸미는 법 배우기만 하면 이쁜 코드가 될 수 있다는 거군요..
걍 실력이 없으니 다 못한거지
실력도 없는 지원자들 포장하느라 애쓰시네요 😂😂😂😂😂😂😂
너무해요
시간이 없는 걸수도 있죠. 지수님
간혹 요구사항이 지나치게 짧게 주는 회사들이 있을 수 있는데 그런 회사는 걸러야 하는거구요.
영상 사례처럼 2주나 줬는데 완성못하는 거면 쓸데 없는 오버엔지니어링으로 시간이나 처 잡아 먹는건데, 그정도 능지와 실력이 없다면 걍 불합격! 해야지 무슨 시간이 없다고 궁시렁궁시렁 ㅋㅋㅋㅋ
님들 없어도 지원자 3자리수로 넘쳐나요. 어차피 뽑는건 2,3명 정도인데 징징거리지나 마세요 ㅋ
꼬우면 취업했어야지! 루져들 같으니 ㅋㅋ
일단 실력은 모르겠고 인성은 파탄나신듯
@hyunjinkim5076 너같이 실력없는 동료만큼 인성 터진 인간은 없지. 같이 일해봐라 ㄹㅇ 개빡침
60프로 클린하냐 80프로 클린하냐 단지 그정도 차이일 뿐입니다. 대부분의 기술부채는 클린코드와 관계없이 일어남.
요구사항이 완벽하면 그것이 클린코드다!