1:17 첫번째 습관: 코드에 대한 애착이 없음 2:34 두번째 습관: 인간을 위한 코드 작성 3:26 세번째 습관: 간단한 코드 작성 4:43 네번째 습관: 일관된 표준 사용 5:40 다섯번째 습관: 예측 가능한 코드 작성 6:29 여섯번째 습관: 자주 소통하기 7:32 일곱번째 습관: 빠르게 그리고 느리게 코딩 (중간에 편집 오류가 있어서 잘라냈습니다 죄송합니다)
비전공 40대 후반인데, 앱과 웹을 번갈아 가며 찍먹하는 취미 코더입니다. 경제적 문제를 떠나, 이 일이 적성에 맞아서 앞으로는 직업삼아 더 많이 하고 싶은데, 코딩으로 취업하기 힘든 입장에 있는 사람들이 현실적으로 소규모 프로젝트 의뢰를 수행하는 프리랜서 활동을 할 수 있으려면 어떤 준비과정이 필요할까요?
왜 읽기 쉬운 코드를 작성해야하는가 에 대해서.. 저도 100%동의 합니다. 그런데, 왜 읽기 쉬운 코드를 작성하는게 중요한가에 대해서도 생각해본적이 있는데요. 저는 비용의 문제가 아닐까 생각합니다. 예전에는, 그러니까 한 50-60년전에는, 빨리 도는 코드, 그리고 짧은 코드가 중요했던거 같습니다. CPU도 비싸고, 메모리도 비싼 시대였으니까요. 그런데, Moore의 법칙에서도 알 수 있듯이, CPU는 겁나게 빠른 속도로 발전했고, 메모리도 엄청 싸져서, 프로그램을 만드는데 이제는 컴퓨터보다, 프로그래머가 훨씬 비싼 시대가 된거 같아요. 결국 프로그래머의 손이 덜가게 하는 방식이 중요한거 같고, 그래서 실행 속도는 느려도 유지보수 쉬운 코드, 다시 말해 읽기 쉬운 코드가 중요해진거 같습니다. 이런 이유때문에 파이썬 같은 언어가 많이 쓰는거 같고요. 아시다시피 파이썬 같은 interpreting 방식은 C보다 말도 안되게 느리지만, 생산성이 굉장히 좋으니까요. 실제로 저도 서비스를 만들다 보면, 인프라 비용보다 인건비가 훠~~~얼씬 크더라구요. 그리고, 코드 실행 자체가 느린 거는 이제는 코드 자체로 해결하기보다 아키텍처적으로 해결하는거 같고요 (horizontally scaling)
잼있네요. 제가 junior 개발자들한테 하는 이야기가 많이 들어있네요. 특히나 7번은 깜짝 놀랐습니다. 제가 평소 다른 개발자들한테 늘 하는 이야기 거든요. 프로그램은 짜는게 아니라 논문이나 에세이 쓰듯 독자 (자기 자신 포함)를 위해 쓰는 겁니다. 논문작성시 단어하나하나에 신경써야하듯 변수명에도 사람들이 이 변수명을 보고 어떤 의미로 해석할까를 깊게 생각하고 결정해야 합니다. 변수명 결정에만 한두시간이 넘어갈 수 있습니다. 저는 중요한 컨셉의 변수같은 경우 하루이틀 이상의 시간을 사용하기도 합니다. 경우에 따라서 몇개의 후보를 두고 동료들을 방문해서 그들의 선호도 조사도 합니다. If문 작성도 컨디션들이 많을때 이걸 하나의 if로 작성할찌 여러개의 if로 쪼개야할지. 각각의 개념이 다른 컨디션은 좋은 이름으로 변수를 만들어 할당하고 if에서는 이들 변수로만 구성된 컨디션을 사용할 수도 있구요. 무수히 많은 고려사항이 있죠. 특히 많은 개발자들의 실수(?)는 너무 성능 최적화를 하려 한다는 겁니다, 가독성을 깨면서 까지도요. 학교에서나 학문적으로는 1나노라도 cpu path를 적게 사용하는것이 좋은 프로그램이겠으나 실제 소프트웨어 개발에서 가장 비싼 비용은 사람입니다.
2, 3번에 공감이 되네요. 같이 프로젝트를 진행하고 있는데 어느 특정 기능을 사용하기 위해서 기능 구현 코드를 엄청 복잡하게 적어 놓고 주석처리로 설명이 하나도 없이 작성하는 팀원이 있어서 (심지어 제가 코드를 작성한 부분에 필요에 의해 수정해도 주석으로 설명안함) 매번 코드를 보고 어떤 기능을 하는지 자세히 봐야 하고 "인간이 이해할 수 있는 코드"에 가깝기 보다는 기능만을 위주로한 가독성 없는 코드를 작성하는 경우가 있어서 이게 맞나라는 고민을 항상 했는데....
2, 3번이 많이 중요하긴 합니다. 일 하면 할수록 좋은 문서(혹은 주석, 읽기 쉬운 코드 등) 하나가 팀 전체 시간을 얼마나 많이 벌어주는지 알 수 있더라고요. 처음에 문서화 잘 해두면 계속해서 물어보고 & 답변하고 할 일도 없고, 실수로 다르게 할 일도 없고... 참 유리합니다
@@KKKKKK-oc8mx막 코드를 짜는게 문제가 아니라 효율적인 코드를 위해 100% 에너지를 쏟아부울수 없다는거임 회사에선 그럴 시간도 안줄 뿐 더라 기간이 한달을 주면 그 한달새 그 프로젝트만 하는게 아니라 다른 사이트 프로젝트도 동시에 진행 되기때문에 심지어 그 한달도 줄여버리는 경우가 있음
추가적으로 더 생각해보니 코딩 스타일은 기본이고(놀랍게도 이걸 안 지키는 사람이 더 많고) 그 코딩이라는 기술을 어디에 사용했는가가 그 사람의 연봉인거 같습니다. 내가 똑같은 자바 기술력 있어도 그 기술로 뭘 만들어서 얼마를 벌었으니 나에게 이만큼 달라는 맞는데 내가 그 기술을 아니 이만큼 달라는 뭐가 안 맞네요
자매품: 에피 디스코드 discord.gg/QqRrykr5K9 (무한 질답방)
1:17 첫번째 습관: 코드에 대한 애착이 없음
2:34 두번째 습관: 인간을 위한 코드 작성
3:26 세번째 습관: 간단한 코드 작성
4:43 네번째 습관: 일관된 표준 사용
5:40 다섯번째 습관: 예측 가능한 코드 작성
6:29 여섯번째 습관: 자주 소통하기
7:32 일곱번째 습관: 빠르게 그리고 느리게 코딩
(중간에 편집 오류가 있어서 잘라냈습니다 죄송합니다)
제가 보기엔 모든 모습이 일관되고
한 표현으로 요약 가능할 것 같네요.
목표지향적...
덧붙이면 '오직' 목표, 결과 지향적
저희 교수님이 항상 강조하시는 것 중에
1.독서를 통한 인문학적 소양 기르기
2.코드작성 하기 앞서 전체적인 방향과 프레임을 글로 풀어서 정리해보기
인데 그 이유가 영상에 나오는 것 같네용..
지나가던 대학생 많이 배워갑니다
개발자한테 독서는 정말 중요한 것 같아요.
역시 교수 클라스 어디 안 가네 ㄷㄷ
와 알고리즘에 뜨다니!! 좋은 내용이네요
감사합니다! 더 열심히 하겠습니다!
정말 좋은 내용입니다. 감사합니다.
저도 감사드립니다 😸
상사 잘못 만나면 저렇게 하고 싶어도 할 수 없는게 너무 많은듯... ㅠㅠ
그냥 머리가 좋은거 아닐까요? 업무해보면 코드의 90%를 날리고 다시 한다는건 일정 맞추기도, 신뢰성 확보하기도, 고객사의 동의 받기도, 품질검가 다시 받기도 업무량이 장난이 아닐텐데 한다는거보면
기본적으로 영어를 회화수준으로 한다는게 전제가 되어야 할 듯 합니다.
내가 영어를 못하니까 ㅠㅠ; 너무 힘듭니다.
국어라도 잘 하면 좋을 듯... 글쓰기.... 객체 지향언어에 맞춰 코딩하려면 필수 같습니다.
영상들 잘 보고 있어요
감사합니다!!!
제가 더 감사합니다 🙇
비전공 40대 후반인데, 앱과 웹을 번갈아 가며 찍먹하는 취미 코더입니다.
경제적 문제를 떠나, 이 일이 적성에 맞아서 앞으로는 직업삼아 더 많이 하고 싶은데,
코딩으로 취업하기 힘든 입장에 있는 사람들이 현실적으로
소규모 프로젝트 의뢰를 수행하는 프리랜서 활동을 할 수 있으려면 어떤 준비과정이 필요할까요?
먼저 포트폴리오를 만드시고, 이것들을 프리랜서 사이트에 올리시면 의뢰가 점점 들어오시기 시작하실거에요. 그리고 후기를 달아달라고 꼭 부탁하시면 점점 상위 노출되실겁니당
@@에피코딩 알려주셔서 감사합니다. 그래도 길이 없진 않은 것 같아 다행이네요^^
왜 읽기 쉬운 코드를 작성해야하는가
에 대해서..
저도 100%동의 합니다.
그런데, 왜 읽기 쉬운 코드를 작성하는게 중요한가에 대해서도 생각해본적이 있는데요. 저는 비용의 문제가 아닐까 생각합니다.
예전에는, 그러니까 한 50-60년전에는, 빨리 도는 코드, 그리고 짧은 코드가 중요했던거 같습니다.
CPU도 비싸고, 메모리도 비싼 시대였으니까요.
그런데, Moore의 법칙에서도 알 수 있듯이, CPU는 겁나게 빠른 속도로 발전했고, 메모리도 엄청 싸져서,
프로그램을 만드는데 이제는 컴퓨터보다, 프로그래머가 훨씬 비싼 시대가 된거 같아요.
결국 프로그래머의 손이 덜가게 하는 방식이 중요한거 같고, 그래서 실행 속도는 느려도 유지보수 쉬운 코드, 다시 말해 읽기 쉬운 코드가 중요해진거 같습니다.
이런 이유때문에 파이썬 같은 언어가 많이 쓰는거 같고요. 아시다시피 파이썬 같은 interpreting 방식은 C보다 말도 안되게 느리지만, 생산성이 굉장히 좋으니까요.
실제로 저도 서비스를 만들다 보면, 인프라 비용보다 인건비가 훠~~~얼씬 크더라구요.
그리고, 코드 실행 자체가 느린 거는 이제는 코드 자체로 해결하기보다 아키텍처적으로 해결하는거 같고요 (horizontally scaling)
ppassa1님 덕분에 고급 인사이트를 얻고 갑니다 감사합니다
읽기 어렵지만 컴퓨터를 더 효율적으로 다루게 커맨드라인 툴 보면 읽기 어려운 C로 되어있고 반면 컴퓨터가 아닌 외적 문제 해결에 도움을 주면서 읽기 쉬운 코드는 인터프리터 언어로 작성하는 것과 유사하네요
이제 무어의법칙이 끝났기 때문에 미래는 다시 성능을 고려하는 컴퓨팅이 더 각광을 받을겁니다. 성능과 인간공학을 동시에 생각하는 프로그래밍이 중요해지고있습니다.
확실히 3번 5번은 함수형 프로그래밍 하는 분들이 잘하는 부분같아요
잼있네요. 제가 junior 개발자들한테 하는 이야기가 많이 들어있네요. 특히나 7번은 깜짝 놀랐습니다. 제가 평소 다른 개발자들한테 늘 하는 이야기 거든요. 프로그램은 짜는게 아니라 논문이나 에세이 쓰듯 독자 (자기 자신 포함)를 위해 쓰는 겁니다. 논문작성시 단어하나하나에 신경써야하듯 변수명에도 사람들이 이 변수명을 보고 어떤 의미로 해석할까를 깊게 생각하고 결정해야 합니다. 변수명 결정에만 한두시간이 넘어갈 수 있습니다. 저는 중요한 컨셉의 변수같은 경우 하루이틀 이상의 시간을 사용하기도 합니다. 경우에 따라서 몇개의 후보를 두고 동료들을 방문해서 그들의 선호도 조사도 합니다. If문 작성도 컨디션들이 많을때 이걸 하나의 if로 작성할찌 여러개의 if로 쪼개야할지. 각각의 개념이 다른 컨디션은 좋은 이름으로 변수를 만들어 할당하고 if에서는 이들 변수로만 구성된 컨디션을 사용할 수도 있구요. 무수히 많은 고려사항이 있죠. 특히 많은 개발자들의 실수(?)는 너무 성능 최적화를 하려 한다는 겁니다, 가독성을 깨면서 까지도요. 학교에서나 학문적으로는 1나노라도 cpu path를 적게 사용하는것이 좋은 프로그램이겠으나 실제 소프트웨어 개발에서 가장 비싼 비용은 사람입니다.
저도 아주 공감가네요 미래에 영향력이 큰데 결정하는 비용은 작을때(예: 변수명 짓는 행위 자체, 다수의 집약적인 조건문 작성 순간 등) 이걸 잘 해내는 사람이 능력자 같더라고요
좋은 영상잘보고갑니다
앞으로도 더 좋은영상 올리도록 할게요 자주 찾아와주세요
2, 3번에 공감이 되네요. 같이 프로젝트를 진행하고 있는데 어느 특정 기능을 사용하기 위해서 기능 구현 코드를 엄청 복잡하게 적어 놓고
주석처리로 설명이 하나도 없이 작성하는 팀원이 있어서 (심지어 제가 코드를 작성한 부분에 필요에 의해 수정해도 주석으로 설명안함)
매번 코드를 보고 어떤 기능을 하는지 자세히 봐야 하고 "인간이 이해할 수 있는 코드"에 가깝기 보다는 기능만을 위주로한 가독성 없는 코드를 작성하는 경우가 있어서 이게 맞나라는 고민을 항상 했는데....
2, 3번이 많이 중요하긴 합니다. 일 하면 할수록 좋은 문서(혹은 주석, 읽기 쉬운 코드 등) 하나가 팀 전체 시간을 얼마나 많이 벌어주는지 알 수 있더라고요. 처음에 문서화 잘 해두면 계속해서 물어보고 & 답변하고 할 일도 없고, 실수로 다르게 할 일도 없고... 참 유리합니다
딴거 없고 운좋게 회사 오너 잘 만나면 됨
oH sH!+
백엔드 말고
완전 초기단계인
프론트엔드 및. 퍼블리셔 코딩 관련도 알려주세요 ㅜㅜ
아주 좋습니다. 제 채널에 관련된 영상이 있으니 그것도 참고해보셔요.
거의 해당되넴
저는 안젤라유 파이썬공부하고있는데 한가지 문제에 뭔가 풀지못하면 다음스탯 못넘어갈거같고 이전에서 배운것들 다 기억하고싶은데 이건 무리겠져
스멀스멀 하면 되나여??
아니에요 그게 되게 좋은 공부법인게 모르는게 나왔을때 이전에 배운 것들 중 지식의 빈틈을 발견한거라, 돌아가서 그 부분만 채우고 오시면 됩니다
코드가지고 예술하는 순간 생산성이 떨어짐..
리팩토링 하면댐
연봉 상위 1%만 지적 가능
@@KKKKKK-oc8mx회사에선 그게 쉽지 않죠
@@KKKKKK-oc8mx막 코드를 짜는게 문제가 아니라 효율적인 코드를 위해 100% 에너지를 쏟아부울수 없다는거임 회사에선 그럴 시간도 안줄 뿐 더라 기간이 한달을 주면 그 한달새 그 프로젝트만 하는게 아니라 다른 사이트 프로젝트도 동시에 진행 되기때문에 심지어 그 한달도 줄여버리는 경우가 있음
@@KKKKKK-oc8mx대기업이 아니고 보통 중소기업 다닐건데 자서비스 운영하는 it 기업이 아니면 공기업 프로젝트 si 가 많을건데.. 제가 한 말이 거짓 1도 안보태고 심하면 심했지 덜하진 않음
코딩을 잘하는 것 도 있지만, 사실 자신의 가치를 잘 알고 그걸 레버리지로 연봉 협상, 이직할때 유리하게 사용하는 사람들이 상위 1%죠.
심금을 울리네요..
오 좋은 포인트 감사합니다!
미국에서는 팽이라고 부르는데 한국에서는 팡이라고 부르나 보내요 ㅋㅋㅋ
아하 미국에선 팽이라 하는군요?
@@에피코딩 네네 ㅋㅋ 요즘은 이제 사람들이 맹이라고 부르죠 메타로 바뀐이후에는
저는 이제 회사 신입인데, 저는 어느정도 이런 습관이 있으나 제 동료 개발자가 이런 습관과 거의 다 반대입니다. 근데 이 분과 협업 할 일이 많다 보니 너무 힘드네요 ㅠ
이런... 피드백 드리기 쉽지 않을거라 많이 힘드시겠네요. 제 경험상 그럴때는 모범 사례를 먼저 보여드리고 이를 학습하도록 유도하는것도 먹히는 방법이긴 합니다
신입이라 없는걸수도 있습니다 처음이니깐요 부디 그 습관 계속 유지하시길 바랍니다!
계속해서 피드백을 주는 방법밖에 없을듯요
이직하세요. 일년 이상만 채우시고요. 진심입니다.
ㅋㅋㅋㅋㅋㅋㅋ 왜 나랑 맞는게 없냐 큰일이네
저는 일주일도 안된 인턴인데 학교에서 자신감 넘치다가 막상 현업에 와보니 스케일이 달라서 심적으로 조금 불안해진 상태인데 원래 이런걸까요? ㅠㅠ 열심히 퇴근후,주말시간 투자하며 공부하고 있긴한데 빨리 적응하고 프로젝트 참여하고 싶은 마음에 조급해지네요..
아마.. 안그런사람 없을거에요 조급해하지마세요 금방 적응됩니다
일주일만에 퇴근 후 공부라니 이미 성공하셨네요... 주변보다 잘하고 싶은 욕심이 있으신거 같은데 전 좋은 태도라고 생각해요.
와 나는 맞는게 하나도얷음
7개 해당
1%의 개발자 ㄷㄷ
국내 기업 개발자의 현실은 혼자 개발하고 혼자 테스트하고 회사에 사람 뽑아 달라하면 배워서 하라고 함.
oh sh!t
전공출신이신가용?
네 전공 출신입니다 (F학점 다수)
읭 그냥 클린코드 책 한 권 내용인거 같아보이는데요?
추가적으로 더 생각해보니 코딩 스타일은 기본이고(놀랍게도 이걸 안 지키는 사람이 더 많고) 그 코딩이라는 기술을 어디에 사용했는가가 그 사람의 연봉인거 같습니다. 내가 똑같은 자바 기술력 있어도 그 기술로 뭘 만들어서 얼마를 벌었으니 나에게 이만큼 달라는 맞는데 내가 그 기술을 아니 이만큼 달라는 뭐가 안 맞네요
소통 하는거 싫어해서 개발자 된건데.. ㄷㄷ
이제부터 솟통 하시면 되죠!
@@에피코딩 저는 소통자체에 스트레스 받는 체질인지라 쉽지 않더라고요
다시짜는건하지... 문제는 다시짜는 시간은 없음😅
그것도 맞죵
연봉 넘적네요
sh1t