Introduce

• 감사하게도 우아한 테크러닝에 참여할 수 있게 되었다! 그동안 리액트, 타입스크립트 관련한 내용들을 배워보고 싶었는데, 좋은 기회인 만큼 잘 따라가야 되겠다는 생각이 가장 컸다. 🙂 👍
• 첫번째 시간에는 코딩 자체를 다루진 않았고, 아이스브레이킹, Q&A와 아래 질문 4개를 답하며 진행이 되었다.

Start

• 과정 자체가 더 중요하다고 생각하여 기획한 측면이 있다. 어떤 식으로 개발할 것인가?
• 한달 동안 회사에 다닌다고 생각하자! 시니어 개발자는 오직 한명인!
• 뽑아온 4개의 질문에 대해서 질답하는 시간을 가져보자
  • 4개 모두 추상적인 질문일 것이다. 일종의 던지는 화두라고 생각하자.

Topic

참고로 질문에 대한 답변은 교육생들의 답변과 김민태님의 답변이 섞여있습니다 :)

1. 시니어 개발자가 왜 필요할까?

• 주니어 개발자는 에너지와 힘은 넘치지만 주변을 보지 못한다. 이런 주니어 개발자들에게 방향성을 알려주는 시니어 개발자가 필요하다.
• 타짜에서 만약 고니가 화투를 다른 사람에게 배웠다면? 좋은 습관을 배웠기 때문에 전국을 휘두르는 도박자가 되었을 것이다.
• 시니어 개발자와 함께 있는 것만으로도 생각하는 관점이 바뀌지 않을까 싶다
• 우리가 부르는 시니어 개발자는 누구인가? - 우아한형제들 기술 블로그

2. 실무적 코드란 무엇일까?

이 동작이 정말 실무에서 쓰이는 코드가 맞는지 모르겠고, 다 나랑 비슷하고 꾸역꾸역 하고 있을 때 생기는 불안, 개발자 입장에서 중요한 생각하는 방식인 것 같다. 막연하게 이야기 하는 경우가 많기 때문이다.

• 나는 성장하고 싶어요! 성장해야 한다는 이야기를 많이 들어봤을 것이다. 하지만 성장 이 도대체 무엇이고, 추상적인 이야기들을 많이 하는데, 실무적 코드 역시 많은 주니어들이 갖고 있는 고민인 것 같다. 프로페셔널 하게, 월급을 받지 않고 일하는 학생들이 기대하는 것 같다. 요구사항을 만족시키는 코드가 실무적 코드라고 생각한다. 실제로 구현하는 사람의 생각과 철학이 코드 안에 담겨있기 때문이다.

• 라이프 사이클을 생각하는 코드가 실무적 코드인 것 같다. 모든 코드에는 생명력이 있다. 코드 시간의 흐름, 생명력이 있다는 것은 내가 온전히 그 코드의 오너가 될 일이 없다. 내가 짠 코드를 남이 볼 수도 있고, 내가 고치게 될 수도 있다. 그걸 기본적으로 맥락상 고려하고 작성하는 코드가 실무적 코드가 아닐까 싶다. 이들이 가독성, 유지보수성, 원칙 등을 지키는 것으로 이어지는 것 같다.

2. Hands On 은 누가 잘하는가? (하루에 다루는 코드량)

• 사용하지 않으면 녹슬게 된다. 요리사가 칼을 사용하지 않으면 녹이 쓰는 것 처럼 말이다. 시니어와 가장 왕성하게 개발을 하고 있는 상황에서 누가 더 날카롭게 갈려져 있는 칼인가? 물리적으로 그렇지만 열심히 하시는 분들이 상대적으로 더 많이 본인이 많든 코드에 자신이 없는 경우도 많이 봤다.

• Hands On 시간을 많이 들이는 사람이 잘한다고 생각한다. 날이 서있는 것들, 핸드드립을 좋아하는데 그것도 일종의 process가 있다. 속도가 빠른 게 능사가 아니지만, 무의식적으로 하는 좋은 행동이 많아지면 의식적으로 해야 하는 행동에 더 많은 시간을 쏟을 수 있으므로 내가 하는 일에 담금질이 잘 되어 있는게 중요하다.

• 이는 개발 문화 관련 질문과 일맥상통한다. 왕성하게 개발하는 분들의 의견을 자유롭게 낼 수 있는 조직이 좋은 조직의 터전이라고 생각한다. 이들의 의견 교환이 자연스럽고 왕성하게 되는 게 개발 문화의 터전이 되어있는 것 같다고 생각한다.

• 개발 리더가 실제로 같이 개발을 하는 경우도 있을 것이고, 피드백을 주면서 올바른 방향으로 목적하는 방향으로 가는 조언자 역할을 할 수 도 있다. 현실적으로 100분과 함께 코드를 섞어서 하는게 어렵다 라고 생각해서, 시니어 경험을 어떻게 드릴 수 있을까? 라고 생각했다. 제안하고 싶은 방법이 있다. 각각의 목표로 한 스텝이 있을 것이다. 화, 목 두번을 한다.시간이라는 것은 늘 마음대로 되지 않는다. 최소한 주 단위로 큰 목표를 하나 세우고, 그 목표를 갖고 조금씩 좁히면 된다. pull request(pr)을 만들어서 contribute 를 하는 형태면 좋지 않을까?

4. (막연히) 개발을 잘한다는 것은 무엇일까?

To Be Continued!

Q&A

Q. 프론트 엔드로 커리어 패스를 어떻게 나아가면 좋을지 잘 모르겠어요. 백엔드의 경우에는 데브옵스라던지 서버 개발자, 인프라 등 세분화가 되어지는데 프론트 영역은 세분화가 덜 되어있다 보니, 어떻게 성장해야 할지 직무적으로 고민이 되요.
→ 굳이 only 프론트 엔드에만 집중하지 않았으면 좋겠다. 개발이라는 영역은 다들 알아야 한다. 본인의 직무에 대한 한계를 선명하게 지어서는 안된다. 개발자로서 공통된 영역들이 있다. 어떤 개발자라도 많이 아는 것은 좋다. 처음부터 한정짓는 건은 좋지 않다고 생각한다.

Q. 시니어 개발자 입장에서는 어떤 주니어 개발자를 원하시나요?

→ 여러분 같은 ... ㅎㅎ 💝

사람마다 다른 생각을 갖기 때문에 다른 해결책을 제안할 수 있다. 리액트를 만든 사람은 리액트 방식의 해법을 제시한 거고, 뷰를 만든 것은 뷰 방식의 해법을 제시한 것이다. 다른 해법으로 웹 애플리케이션이라는 같은 문제를 해결한 것이다. 목적은 같으므로 두 가지를 맏든 그 의도를 이해하는 게 더 중요한 것 같다.

Q. 리액트 책 추천

→ 인상깊게 본 책은 별로 없다. 뷰도 .. 리액트나 뷰의 변화 속도를 책이 쫒아가지 못하는 것 같다고 느낀다.

Q. 개발 문화가 좋다는 게 무엇인지, 그런 회사에 대한 정보를 어디서 구할 수 있을지 잘 모르겠습니다.

→ 막연한 측면들이 있네요. 개발문화가 좋다는 건 뭘까요?

Q. 처음에는 한 스펙정도 던지고, 그 후 종합하는 코드를 볼 수 있겠는데 정확한 과정이 진행이 될지 궁금합니다.

→ github 계정에 오픈으로 올려놓고, 좋은 형태로 발전할 수 있는 구성할 수 있는 타입들을 공감하고 발전시키는 것이다. 일종의 이슈같은 것으로 이슈를 등록해놓고 그것들을 create 하는 식으로 되지 않을까? 코드 리뷰 형식이 될 수도 있고, history 가 남아 있을 수도 있다. 완성 단계로도 만들어나갈 수도!

Q. 리액트, 타입스크립트 개발 경험이 없어서 지식 쌓는 것도 필요할 것 같은데, 비슷한 상황에 있는 사람이 연습을 하거나 지식을 쌓을 수 있을까?

→ 현실적으로 굉장히 짧은 기간이다. 보면서 따라오면 좋지 않을까 싶다. 과정 자체가 언어 수업이 아니니까 거기에 맞춰서 하기는 힘들다. 조금 다양한 방법으로 참여해보자. 그럼에도 불구하고 실무적 관점에서 ..! 프로그램 언어나 프레임워크를 완전히 잘 아는 게 중요한 게 아니니까....?! 시간을 더 내서 미리 학습을 하는 것도 좋다.

Q. repo issue 등록? 기능을 나눠서?

→ 기본적으로 얼마나 많은 repo가 생성되느냐에 따라 달라질 것이다. 웹앱 형태 자체가 완전히 다 다르게 표현할 수는 있겠지만 어느정도 형태의 공통성이 나올 것 같다고 생각했다. 두가지 타입에 대해 브랜치로 따로 할 수 있고, 나대로 개발하면서, 선택된 레포들의 진행 개발을 볼 수 있다. 참여 방법은 많다. merge 를 하면서도 하면 된다. 선택하면서 하면 된다.

→ repo 20개 생성된 걸 다 2-3일 단위로 만나면서 follow up 하기는 현실적으로 어렵다. 추리 선택

Q. 시니어 개발자가 없는 환경입니다. 약 1년차 된 입장에서 코딩 캠프를 가도 될까요?

→ 스스로 생각하는 역량에 따라 달라질 것 같다. 불안감, 두려움, 나를 어느정도 가이드 해주고 피드백 해주는 사람이 필요할 것 같다고 생각하면 괜찮은 코딩 캠프를 찾아서 시도해보는 것도 좋은 것 같다.

→ 주니어분들이 가장 개발을 잘하는 것 같다. 배우자고 하는 의지도 크고 그럼 스펀지 처럼,

→ 좋은 환경에 있는 게 좋다. 가능하면 좋은 환경으로 가보자. 디딤돌 삼아 도전해보는 것도 좋다고 생각한다.

Q. 2년차 개발자, 공공 SI 특성상 구현하기 급급하고, 일정에 쫓긴다. 기술적인 부족한 부분을 채우기 위해 책을 읽고 있다. 어떻게 보면 이론적인 것만 담고 있는데 이론과 실무의 갭,

Q. 모두가 동의하는 아름답고 잘 짜여진 코드도 정답이라고 부를 수 없는 걸까요? 개발에 정답이 없다고 생각하시는 이유가 궁금하다.

→ 굉장히 다양한 상태의 맥락을 보고, 다차원적으로 고민해야 한다.

Todo

→ github repo 만들기 , node.js 서버를 사용 .
→ 포함되는 기술들 react, typeScript)
→ 기술 선택의 시작
→ 마크다운? 라이브러리 필요한 라이브러리? 최소 2-3개 선택해서 이 중에서 어떤 것들을 선택해서 가야할지 다음 시간에 논할 화두라고 생각한다.
→ slack channel 에 공유해보자. 상대적으로 보기가 어려워질 수도 있다.
→ next nest?
→ README.md 자세하게 적어놓기