사진
대충 멘토님 폰 바꿀 때가 된 것 같다는 이야기..
- 노트 10인데 커버가 분리된다..ㅠ.ㅠ
- 어떤 폰으로 바꿀까 고민중이다.
- 승훈님은 맥북이 불편해서… 윈도우로 갈 것 같다.
- 멘토님 왈 : 리눅스는 어떠신가?
- 점유율 1%…
멘토님 첫 출근
- 인지부조화..
- 개인의 처우는 인상이 되었지만, 회사 업무 환경이 하락된 듯한 느낌.. (건물 시설, 노트북, 모니터 등..)
- 팀원들이 순수하다!
- 며칠 적응해야할 것 같다..
(승훈) Node 해 두면 취업할 때 도움이 될까?
- 그렇다!
- 한국에서는 java가 대세가 맞지만 외국에서는 그렇지 않다.
- 국가에서 Spring 프레임워크 기반이기 때문에 Java를 많이 수요로 한다.
- 80~90%가 Java가 차지한다. 나머지 Python, Go, Node..
- 백엔드는 언어의 환경에 영향을 많이 받는다.
- Vue, React는 결국 JS인데, 백엔드는 언어 자체가 바뀌어버린다.
- ML 서빙 → Python
- 데이터 중심 → Go
- FE와의 언어를 맞추기 위해 → Node
- 공통적으로 쓸 수 있는 모듈, 인터페이스를 잘 만들어두면 프론트/백 둘다 사용할 수 있다.
- 이것이 굉장히 큰 장점, 생산성이 훨씬 높아진다.
- 웹 친화적이기 때문에 크롤링도 그래서 JS가 훨씬 편해졌다.
- 그래서 Node가 죽진 않을거다.
- 멘토님은 Node로 넘어가고 싶다!
- 백엔드는 에러가 발생한다면, 치명적일 확률이 높다.
(은아) 프론트엔드가 C++로 작성하면 회사에서 이상하게 볼까?
- 이사람은 인재다! 라고 볼 것 같다.
- 하지만 프론트엔드 환경에서는 JS를 강제하는 곳이 많다.
- 로우 레벨의 언어를 다룰 수 있는 사람은 엔지니어로써 굉장히 매력적이라고 생각하지만 현실과 괴리가 생길 수 있다. (언어 하나가 추가될 때 마다 출제자는 검수를 해야한다.)
- 결론
- JS - 51 : C++ - 49
- 가고 싶은 기업을 정해라.
- 스타트업 계열일 수록 JS를 뽑으려고 할 것 같다.
- JS로 코테를 보면 코드스타일을 볼 수 있다.
- 슬프지만..JS로 가잣….
프로젝트 진행 전 알아두면 좋을 꿀팁!
- 프로젝트가 무엇인지에 대한 정의
- 제한된 인력
- 제한된 시간
- 제한된 돈
- 위 3가지 중 하나도 갖추지 못하면 프로젝트가 아니다.
- 프로젝트 관리 측면에서 제한된 인력과 시간으로 어디까지 할 수 있는지를 산출해야 한다.
- 개인 관점에서 자신의 능력을 과대/과소 평가하는 것
- 협업 과정에서 서로가 자신은 1인분을 한다고 생각하는데, 이 둘이 협업을 진행할 때 5 / 3 / 1이 될 수 있다. (시너지 효과)
- 프로젝트 구성 단계에서 프로젝트를 잘 기획해라.
- 개발자도 기획 단계에 많이 참여하는 것이 좋다고 생각한다.
- 개발자 입장에서 기능 관점에서 “이 서비스의 승부 포인트” 1~3가지는 있어야 한다고 생각한다. (A.K.A. 스타트업 사고방식)
대기업에서는 이런 생각 가지면 안된다.. 하라는 것 해야 한다..- 얘 이거 아쉬운데? 불편한데? 하면서도 계속 쓰게 되는 것
- 이 서비스가 여러 단점에도 불구하고, 이 서비스를 놓지 못하는 요소. 이게 바로 경쟁력이다.
- ex) 리눅스
- 카카오 안된다… 그래서 카카오 싫어한다.ㅎ
- 도커가 네이티브로 돌아간다. 훨씬 빠르다.
- 클론 코딩을 해도 “여기에 이 요소가 있으면 더 좋을 것 같아!”
- 당근마켓도 이 중 하나
- 타겟팅을 축소해서 기존 서비스에 특색을 넣었다.
- 이런 포인트가 면접 때도 도움이 된다!
- 유사한 메신저 서비스지만 슬랙은 폐쇄적 / 디스코드는 개방적
- 서로 장단점이 다른데, 두 서비스의 장점만 합쳐서 “나는 이런 퀄리티까지 신경써서 개발해봤다”고 말할 수 있으면 좋다.
- 비지니스, 도메인 관점에서 메리트가 있는 개발자라고 어필할 수 있다.
- 2~3개는 돼야 이 고유한 특징들이 결합되어 무게중심이 생기고 서비스의 방향성이 생긴다.
- 뱅샐 : 금융이지만 건강까지?
- 배민 : 음식 배달로 시작했지만 lush, store 선물하기 등 사업이 확장된다.
- 경쟁사 분석을 하다 보면 방향성이 비즈니스(사업) 방향성이 보인다.
- 제한된 인력과 시간이 있으니.. 최소한 하나라도 잡아라!
- 프로젝트 규모를 넓게 설정하지 말고, 메인 기능을 중심으로 확장시켜나갈 수 있게 기획해라.
- ex) 로그인, 회원가입.. 뭐가 중요한가.. 기능 구현이 중요하다.
- 백엔드가 api가 안준다? 그러면 그 때는 만들 수 있다.
- 기타도 많다..
- R&R, 협업 문화, 코드스타일 및 도구 통일, 용어 통일 등
- 논의할 것이 많을 거다. 그렇지만 마라톤 회의를 하지마라!!
- 굉장히 생산성이 안좋다.
- 회의 시 agenda와 제한시간을 설정해라.
- 커피챗과 정반대로 하면 된다! ^_^!
- 회의를 시작하면 제한 시간 내에 agenda에 대한 결론을 내야한다.
- 짧게는 30분 ~ 쉬는시간 포함 2시간
- 아니면 아예 쪼개서 해라!
- agile이 이런 식이다. 필요 시에 진행한다.
- 차라리 필요하다면 1시간씩 하루에 회의 4번을 하는 것이 낫다.
- 모두가 동등한 목표를 지녀야 한다.
- 내린 결론을 구성원 모두가 이해하고 끝나야 한다. (모두에게 공유되어야 한다. 한 팀이기 때문에)
- 최소한 모두가 납득은 해야한다.
- 기획 시에 납득을 못하는 사람이 있다면 무조건 망하는 프로젝트이다.
- 그래야 지속할 수 있다.
- 비협조적인 팀원..
- 회의 시작 전에 말하고 시작한다.
- 무조건적인 안돼요는 안돼..
- 누군가의 아이디어에 반박하기 위해서는 더 개선된 새로운 아이디어를 내야한다.
- 회의가 정체된 느낌이라면 확실하게 자르고 다시 시작하는 것이 더 좋다.
- 개발자가 개발도 물론 잘해야하지만, 개발 외적인 이런 부분도 잘해야 한다!
- 잘하는 개발자일수록 커뮤니케이션 능력이 좋다.
- 능력있는 프로그래머일수록 성격이 더럽다는 말도 있다..
- 둘 다 맞는 말…
문제해결 프레임워크
- cynefin framework
- 문제에 대한 복잡도와 해결 방식
- 4가지로 구분한다.
- 원인과 문제가 인과관계가 명확하다.
- 원인은 알겠는데, 왜그런지 모르겠다.
- 그냥 모르겠다ㅋ
- 간단한 것
- 어려운 것
- 복잡한 것
- 혼란스러운 것
- 이렇게 문제를 바라보는 방식이 있다.
- 경험을 바탕으로 액션을 취해보는 방식으로 해결 방법을 찾아날 수 있다!