그냥 회사 분위기에 따라 다른 것 같습니다. 코드엔 모두 사연이 있지요. 어떤 회사 관리자들은 리펙토링을 왜 하냐고 합니다. 왜 업무 보고 시간에 왜 리펙토링을 보고 하냐고 말하고, 소프트웨어의 품질 개선보단 일 따오는거 빨리빨리 처리했냐 안 했냐에만 관심 있어합니다. 일 하나 처리하면 또 다른 일하게 되고 또 다른 일하게 되다보니 회사 내 전체 코드는 개판이죠. 코딩 스타일도 없고 그냥 이 사람 저 사람 코드 스타일 다 섞이고.. 그렇게 계속 혹사만 당하다가 인수인계도 못하고 퇴사하더라구요.
내가 이래서 이직 원서 넣기전에 그 회사에 CTO 존재 여부를 꼭 확인함 ㅋㅋ 전문적인 일에 비전문적인 사람들이 운용을 하니 당연히 🐕판이 됨. 흡사 병원에서 행정하던 인원이 의사들한테 일해라 절해라 하는 꼴과 비슷함. IT 경영은 IT에서 뽑혀야 하는게 마즘 ㅜ 경험에서 우러나온 얘기임… 초반에 더녔던 회사가 CTO도 없고 심지어 IT 부서장이 테크 쪽 사람이 아니라 PM출신 ㅋㅋㅋ
이제 신입인 개발 초짜입니다. 좋은 개발자가 되는 법에 대한 많은 고민이 있었는데, 명쾌히 알려주셔서 너무 감사드립니다. 특히, 빨리도 못만드는 개발자면 그것부터 해라. 뭔가가 부족하니까 빨리 못만드는거다. 라는 말이 참 와닿았습니다. 그 부족한 점도 채우고, 일정 수준 속도가 올라오면 말씀해주신 '덮는 습관'에 대해 깊이 고민해보겠습니다! 고맙습니다!
혹시 빨리 만드는 능력이라는게 조금은 모호한데, 동기중에 빠르게 만들긴하는데 타입정의도 안하고 네이밍도 대충하고 반복로직도 함수로 만들지도 않고 자신도 잘모르는 람다식과 연산자 기능을 남발해서 기능만 돌게하는데 이런경우는 어떻게 생각하시나요 ?.. 그럼에도 프로젝트 매니저는 빠르게 만든다고 어느정도 인정하는 분위기입니다.. 그렇게 비교하다보면 아 내가 좀느린가? .. 라는 생각을 하기도하고요. 혹시 포프님은 네이밍, 반복로직함수처리, 자신도 잘모르는 람다식 혹은 연산자 기능등을 남발해서 일단 동작만하게 하고 나중에 리팩토링하는 행위에 대해서 어떻게 생각하시나요 ?.. 저는 어느정도의 코드규격은 맞추려고 좀더근무하더라도 일정은 최대한 맞추기는 하는편입니다. 하지만 빠르게 개발하기에서는 밀리는느낌이 들어서 고민이됩니다..
@@포프티비 그럼 포프님은 리팩토링없이 처음 코딩할때 최소한의 원칙도 평소에 포프님이 준수해오던 혹은 포프님이 가지고 계신 코딩표준문서에 기반해서 작성하시나요 ? 아니면 다소 완화된 원칙으로 우선 기능을 돌리고 여러번의 리팩토링을 거치면서 포프님이 준수해오던 코딩방식으로 맞춰가시나요?
저같은 경우 3일(예시입니다)의 시간이 있다면, 하루 안에 개발을 해놓고 나머지 시간 동안 계속 테스트 하면서 버그가 안 나오도록 하는 편입니다. 빨리 개발을 하느니 제가 맡은 일에 한해서는 버그가 안나오게 하는 게 더 중요하다고 판단했거든요. 어떻게 보면 빠른 개발은 못한다고도 볼 수 있는데 적어도 기한 안에 못 맞추는 일은 없도록 하고 있어요. 시간이 조금 더 필요하면 이유를 설명하고 더 달라고 요구하기도 하는데 제가 발설한 시간은 반드시 지킵니다. 물론, 그렇다고 버그가 아예 발생하지 않는 것은 아니지만 버그로 큰 이슈 아닌 이상은 당일에 해결하는 편이고요.(물론 저연차 때 했던 작업들이라 그 정도로 시간 소요가 안 되는 수준이긴 했습니다.) 이런 케이스도 생산성이 안 나온다고 보는 걸까요? 그리고 이건 다른 질문입니다만... 포프님 혹시 책 같은 건 안 쓰시나요? 한국이라서 원서로 내신다면 아마존 킨들로 사는 것만 가능하겠지만.. 책을 내신다면 어떤 책을 내실지 궁금하기도 하고 꼭 읽어보고 싶습니다. 항상 영상 잘 보고 있습니다.
당연히 제품에 따라 구현보다 테스트를 더 해야하는 경우도 있어서 제가 그정도 이야기만 듣고는 판단이 어렵네요. 일반적인 제품은 구현시간에 비헤 테스트 시간이 적은게 일반적이라 생각합니다. 가장 좋은 판단기준은 동료들과 비교하는 거죠. 책은 한글로도 몇 권 쓴 게 있는데 대부분 특정 기술에 관한 거라 도움이 되실지는 모르겠네요. blog.popekim.com/ko/books.html
![BLACK BAG - Official Trailer [HD] - Only in Theaters March 14](http://i.ytimg.com/vi/Du0Xp8WX_7I/mqdefault.jpg)
1. 빨리 만드는 능력
2. 빨리 고치는 능력
3. 지속가능한 생산력(오히려 증가함)
그냥 회사 분위기에 따라 다른 것 같습니다. 코드엔 모두 사연이 있지요. 어떤 회사 관리자들은 리펙토링을 왜 하냐고 합니다. 왜 업무 보고 시간에 왜 리펙토링을 보고 하냐고 말하고, 소프트웨어의 품질 개선보단 일 따오는거 빨리빨리 처리했냐 안 했냐에만 관심 있어합니다. 일 하나 처리하면 또 다른 일하게 되고 또 다른 일하게 되다보니 회사 내 전체 코드는 개판이죠. 코딩 스타일도 없고 그냥 이 사람 저 사람 코드 스타일 다 섞이고.. 그렇게 계속 혹사만 당하다가 인수인계도 못하고 퇴사하더라구요.
ruclips.net/video/DfLpnKcYoDg/видео.htmlsi=DSoJrCbSOGhrkuis
@@포프티비 ㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋ
내가 이래서 이직 원서 넣기전에 그 회사에 CTO 존재 여부를 꼭 확인함 ㅋㅋ 전문적인 일에 비전문적인 사람들이 운용을 하니 당연히 🐕판이 됨. 흡사 병원에서 행정하던 인원이 의사들한테 일해라 절해라 하는 꼴과 비슷함. IT 경영은 IT에서 뽑혀야 하는게 마즘 ㅜ 경험에서 우러나온 얘기임… 초반에 더녔던 회사가 CTO도 없고 심지어 IT 부서장이 테크 쪽 사람이 아니라 PM출신 ㅋㅋㅋ
포프님께서 이런 말을 할 것 같다고, 내가 하고 있는 방식에 더욱 자신감을 가질 것입니다. 자기 계발 책중에서도 10배의 법칙이라는 책이 있는데, 그 책을 참 좋아합니다.
중요한 건 3번입니다!!
저또한 이 영상으로 제 방식에 확신을 가지게 됐습니다. 정말 좋은 영상입니다
이제 신입인 개발 초짜입니다. 좋은 개발자가 되는 법에 대한 많은 고민이 있었는데, 명쾌히 알려주셔서 너무 감사드립니다. 특히, 빨리도 못만드는 개발자면 그것부터 해라. 뭔가가 부족하니까 빨리 못만드는거다. 라는 말이 참 와닿았습니다. 그 부족한 점도 채우고, 일정 수준 속도가 올라오면 말씀해주신 '덮는 습관'에 대해 깊이 고민해보겠습니다! 고맙습니다!
제목보고 후다닥 달려왔습니다!
오. 슈퍼포비 선 공개 비디오였는데.. 감사합니다 🙏
걱정많아서 시작도 안하고 고민만 많은 답답한 동료들... 그럴거면 일단 하고 기한맞추고 리팩토링 하자고 해도 대안없이 안하다가 결국 벼락치기로 버그 투성이로 막구현하기 반복이라 답답합니다. 빨리 짬채워서 리드해야지 후...
감사합니다 말씀하신 3번 능력을 더욱더 키워야겠네여
제가 하고 있는 방식에 확신을 주셔서 감사합니다.
중요한건 3분입니다!!
코파일럿 활용 잘하면 넌 이미
로버트 다우니 주니어
혹시 빨리 만드는 능력이라는게 조금은 모호한데, 동기중에 빠르게 만들긴하는데 타입정의도 안하고 네이밍도 대충하고 반복로직도 함수로 만들지도 않고 자신도 잘모르는 람다식과 연산자 기능을 남발해서 기능만 돌게하는데 이런경우는 어떻게 생각하시나요 ?.. 그럼에도 프로젝트 매니저는 빠르게 만든다고 어느정도 인정하는 분위기입니다.. 그렇게 비교하다보면 아 내가 좀느린가? .. 라는 생각을 하기도하고요. 혹시 포프님은 네이밍, 반복로직함수처리, 자신도 잘모르는 람다식 혹은 연산자 기능등을 남발해서 일단 동작만하게 하고 나중에 리팩토링하는 행위에 대해서 어떻게 생각하시나요 ?.. 저는 어느정도의 코드규격은 맞추려고 좀더근무하더라도 일정은 최대한 맞추기는 하는편입니다. 하지만 빠르게 개발하기에서는 밀리는느낌이 들어서 고민이됩니다..
그런 사람들은 3번이 안되더라구요. 리팩토링은 당연히 하게되지만 그로인해 신규 업무가 느려질 정도라면 건 3번이 안되는 거니 결국 전문가는 안 될 겁니다
@@포프티비 그럼 포프님은 리팩토링없이 처음 코딩할때 최소한의 원칙도 평소에 포프님이 준수해오던 혹은 포프님이 가지고 계신 코딩표준문서에 기반해서 작성하시나요 ? 아니면 다소 완화된 원칙으로 우선 기능을 돌리고 여러번의 리팩토링을 거치면서 포프님이 준수해오던 코딩방식으로 맞춰가시나요?
코딩표준은 따르나 안따르나 단기 생산성에 큰 변화가 없고 장기 생산성에는 좋아서 첫 버전부터 95%정도는 따릅니다.
답변 항상 감사합니다.@@포프티비
@@포프티비성지순례 🙏🙏
저같은 경우 3일(예시입니다)의 시간이 있다면, 하루 안에 개발을 해놓고 나머지 시간 동안 계속 테스트 하면서 버그가 안 나오도록 하는 편입니다. 빨리 개발을 하느니 제가 맡은 일에 한해서는 버그가 안나오게 하는 게 더 중요하다고 판단했거든요. 어떻게 보면 빠른 개발은 못한다고도 볼 수 있는데 적어도 기한 안에 못 맞추는 일은 없도록 하고 있어요. 시간이 조금 더 필요하면 이유를 설명하고 더 달라고 요구하기도 하는데 제가 발설한 시간은 반드시 지킵니다. 물론, 그렇다고 버그가 아예 발생하지 않는 것은 아니지만 버그로 큰 이슈 아닌 이상은 당일에 해결하는 편이고요.(물론 저연차 때 했던 작업들이라 그 정도로 시간 소요가 안 되는 수준이긴 했습니다.) 이런 케이스도 생산성이 안 나온다고 보는 걸까요? 그리고 이건 다른 질문입니다만... 포프님 혹시 책 같은 건 안 쓰시나요? 한국이라서 원서로 내신다면 아마존 킨들로 사는 것만 가능하겠지만.. 책을 내신다면 어떤 책을 내실지 궁금하기도 하고 꼭 읽어보고 싶습니다. 항상 영상 잘 보고 있습니다.
당연히 제품에 따라 구현보다 테스트를 더 해야하는 경우도 있어서 제가 그정도 이야기만 듣고는 판단이 어렵네요.
일반적인 제품은 구현시간에 비헤 테스트 시간이 적은게 일반적이라 생각합니다.
가장 좋은 판단기준은 동료들과 비교하는 거죠.
책은 한글로도 몇 권 쓴 게 있는데 대부분 특정 기술에 관한 거라 도움이 되실지는 모르겠네요.
blog.popekim.com/ko/books.html
1번 코드를 빨리 짜는 능력을 기를 수 있는 공부법은 무엇이 있을까요? 포프님이 생각하기에 어떤 공부법이 이런 능력을 효율적으로 기를 수 있다고 생각하시는지 궁금합니다.
그건 사람마다 성향마다 다르죠. 오히려 그 사람이 빨리 못하는 이유 수백개를 찾아서 그걸 하나하나 고쳐나가야 할거에요. 그리고 그 중 많은 부분은 저희가 제도권에서 공부할때 나온 문제들을 거고요.
처음부터 잘하는 사람은 연차가 쌓이면 쌓일수록 더 잘하더라구요.
역은 못 본 것 같구요.
경력기술서만 보고 판단하신다 하면 네임벨류 있는회사 이직경험 꽤 있는 사람이랑 회사 네임벨류는 낮지만 한회사에 장기근속하는 경우랑 어떤경우를 더 좋게 좋게보시나요? (해온 일이나 경험은 비슷하다고 가정했을때요)
이직 경력 있되 이직한 회사에서 3년이상 일한 경력 있는 사람이요.
@@포프티비 구체적으로 설명해주셔서 참고가 됐습니다 감사합니다!
빠르게 많이 일을 처내다가 하늘나라도 빨리 갈것 같아요 😢
건강을 헤치시면 안됩니다!!
형님 사랑합니다❤
신규 업무가 점점 준다면 넌 주니어
버그를 적게 만드는게 항상 중요한듯...
ㄹㅇ..
버그로 인해 심각한 문제가 생기는 서비스가 아니라면 그보다는 버그를 빨리 고치는 게 더 가성비가 좋습니다.
빨리 고치고 빨리 뽀게고 빨리 고치기!
1번도 안되는 데...😢
그러니 차근차근...
개발자는 두번째 만들때 제대로 만든다는 말이 있어 다들 그런가 보다 생각했는데, 그 조차 안될 수 도 있다는 거군요. ㄷㄷㄷㄷ
그게 되는 사람을 못봤어요. 된다고 우기는 사람들은 기준이 되게 낮거나 거짓말 하는 사람들이었다는....
저는 3번이 안되는 것 같습니다. 그래서 개발자 안하고 있습니다 ㅋㅋ
훌륭하십니다!!
오우 새영상
오우 댓글... 🤗
아 200% 공감 …
나는야 0.001배속 전문가~~
쥬니어 나이제한에 걸려서 음의 배속을 걸었읍니다!! ㅋ ㅠ,,ㅜ
언더플로 안 걸릴까요...
그래도 넌 주니어!
네 깊게 마음 속에 새기겠습니다
@@포프티비 히익!?
개발실력은 중급인데 빨리 만들어서 시장 반응에 대응해서 연 20억 버는 사장보고서 생각이 바뀜.
전문 사업가
lean startup
안고치고 퇴사하던데요
전문가가 될 수 없는 사람이죠