2018 GDG Campus Korea 새해 밋업
작성일 | In

2018년 GDG(Google developer group)Campus Korea 새해 밋업(Meetup).

GDG Campus Korea에 대한 소개

5가지 세션과 네트워킹으로 진행.

함께 일하고 싶은 개발자 나름 큰 회사에서 반년동안 배운 것 - (한재엽님, Jbee)

  • 개발 프로세스
  • 이슈발생 (할일) » 유지보수 or hotfix » 스펙분석 » 일정산정 » 코딩 » 커뮤니케이션 » 문서화
  • 이슈 = Task, 일거리 - 신규, 유지보수, hotfix, 디자인 개편, 추가 스펙 등 여러 종류의 이슈가 있다.
  • Zenhub를 통한 Issue 할당, 자신으 일정을 고려하여 issue를 가져 가는 방식
  • 자신이 감당할 만한 issue , 함께 일하고 싶은 개발자, step1. 자신의 실력을 객관적으로 판단할 줄 아는 개발자
  • 유지보수 or 핫픽스 - 레거시와 맞짱
  • 스펙분석
  • 스펙은 사용자에 요구에 따라, 디자인 변경에 따라, 상부 지시에 따라 변한다.
  • 스펙 협의 회의에서 많은 커뮤니케이션을 통해 스펙 fix 그래도 변경될 여지가 있는 부분 미리 고려하여 정확한 분석을 바탕으로 확장 가능한 설계를 한다!
  • VSCode 전에 Evernote 스펙 분석과 설계에 대한 꾸준한 (의식적인) 연습 스펙 리스트업과 스케줄(task) 관리
  • VSCode 후에 Evernote 놓친 스펙에 대한 (의식적인) 회고 무엇을 빠뜨렸는가, 그 이유는 무엇이었는가
  • 함께 일하고 싶은 개발자, step2. 꼼꼼한 스펙 분석 습관을 가진 개발자
  • 일정산정 ‘워라벨’을 위한 한 걸음
  • 자신이 assign한 이슈를 처리하는데 얼마나 걸리는지를 측정하고 공유하는 행동
  • 계획오류 (Planning Fallacy) 작업을 완료하는데 필요한 시간을 낙관적으로 예상하는것
  • 일정 - 할당된 이슈를 어느 날짜에 시작해서 어느 날짜까지 마친다.
  • 공수 - 이 이슈를 해결, 완료하는데 하루 n시간 기준 몇 일이 소요된다.
  • 분석한 스펙을 토대로 공수를 설정한 다음, 일정을 잡는다.
  • 우린 사람이기 때문에 회사에 있는 9시간 동안 내내 컴퓨터앞에서 앉아서 개발하는게 아님.( 커피 마시기 점심먹기 메일쓰기 화장실 가기 전화받기 회의 들어가기 교육듣기 세미나 참석하기 개발 아티클 읽기 전에 배포된 이슈 대응하기 문의 대응하기 스터디하기)
  • 나는 회사에서 개발하는데 하루에 몇 시간을 사용할 수 있는가?
  • 스펙 분석한 내용을 바탕으로 공수를 계산하게 되는데, 공 수가 4일나왔다고 가정하고 아까 정리한 내용을 가 지고 일정을 산정한다.
  • 함께 일하고 싶은 개발자, step3. 신뢰가는 일정을 공유할 수 있는 개발자
  • 코딩
  • 실제 코드에 반영되기 까지는 꾸준한 의식적인 연습이 필요
  • 커뮤니케이션
  • 하나의 프로젝트에 기획, 디자인, 마크업, 클라이언트 ,서버, 운영 모두가 커뮤니케이션을 하게 된다.
  • 저는 주로 typora를 사용해서 코드 하이라이팅 처리를 하구요, giphy라는 툴을 사용하여 gif 만들고 인터랙션 디자이너 분과 협 의를 할 때 유용하게 사용하고 있습니다. - Tool을 사용하여 커뮤니케이션 효율 향상
  • 함께 일하고 싶은 개발자, step4. 대화가 잘 통하는 개발자
  • 문서화
  • 양날의 검, 코드 내 주석 정돈된 코드와 함께 잘 작성해두면, 이 또한 문서화
  • GitHub 프로젝트의 얼굴, README.md
  • GitHub에서 제공하는 README.md Guide 프로젝트 성격에 따라 취사선택 https://guides.github.com/features/wikis/
  • 정돈된 Commit History는 프로젝트를 이해하는 길잡이
  • 수많은 Best Practice. commit log guide 이 또한 프로젝트 성격에 따라 취사선택https://chris.beams.io/posts/git-commit/
  • git hook을 사용한 commit message 형식 강제https://github.com/typicode/husky husky
  • version이 중요한, 라이브러리 또는 모듈인 경우, git tag 기능과 GitHub의 Release 기능 활용하여 ChangeLog 기록하기
  • jsdoc을 통한 API document 관리
  • 프로젝트 시작할 때부터 협의 프로젝트가 진행되는 동안 꾸준히
  • 함께 일하고 싶은 개발자, Step 5. 문서화를 체계적으로 잘하는 개발자

Suggestion

  • 함께 하기를.
  • 완주 하기를 ( 개발프로세스 전체를 경험 - 작게 시작해서)
  • 유저 피드백 받아보기를.
  • 기술 스택에 대한 이유를 생각해보기를 ( 왜 이 라이브러리, 프레임웍인지 )
  • github와 함께 하기를.

Github, 블로그 관리, 커뮤니티, 개발하면서 고민했던 부분 해결한 부분 생생하게 기록해두기 - (김은향 님)

  • 착각 1. 개발자는 기능 구현만 한다?
  • 구현은 개발과정 중 하나일 뿐
  • Gitlab에서 이슈만들고 » 브랜치 따고 » 테스트 작성 » 구현 » git push » CI통과 » Merge Request 보내기 » 코드리뷰 » Merge
  • 착각 2. 그럼 딱 한 번 구현하면 끝이다?
  • CI 통과 실패, 코드리뷰 하며 끊임 없이 도돌이표

  • 착각 3. 내 코드만 잘 알면 된다? 놉! 코드리뷰하며 공유, 실수 방지 ~

  • 9-10: TDD, Django Rest Framwork환경에서 후기 게시판 백엔드 만들기
  • 10-11: Vue + Vuex 프론트 프레임워크 학습하며 공지사항, 질문과답변 게시판 만들기
  • 12: Django amdin버리고 새로 관리 시스템 만들기
  • 12월 파이썬 연말 세미나에서 로 발표 -> 주니어 개발자 되다!
      1. 미래의 나를 위한 기록을 잘하자 (개발일지, 블로그, 발표자료 등등)
    • 2.Github 관리하자
    • 3.정도를 걷자(뭐든 금방 이워지는 것은 없다)

2018년, 플레이윙즈(팀장)

  • 개발자가 통상적으로 가지는 커리어길은 무엇이 있을까 - 코더 / 매니저
  • Coder : 코드를 작성하는 사람 (코드 생산 능력, 유지 보수 능력, 학습 능력)
  • service part, system part, data part, etc …
  • Manager : 기획, 기술, 사람들을 관리하는 사람 (프로젝트 매니징 능력, 팀 매니징 능력, 위기 대응 능력 )
  • Lead Developer, project Manager, CTO, etc …

회사 밖에서 성장하기 (권민재님)

(1) 개발자로서의 성장

  • 개발자로서의 성장이란 ? 개발/프로그래밍 실력과 지식 및 경험을 쌓아가는 것.
  • 두가지의 경로 1. 현업개발(회사 안) 2. 자발적 활동(회사 밖)
  • 회사 밖에서 스스로 성장할 수 있었던 경험들 - 지식 네트워킹, 개발 블로그, 오픈소스 활동

(2) 다양한 지식 네트워킹

  • 지식 네트워킹 - 모각코, 컨퍼런스, 스터디, 소모임, 밋업, 워크샵, 세미나, 온라인 등
  • 본인의 관심외 주제를 다루는 밋업은 큰 도움이 되지 못한다.(연관 분야 제외)
  • 관심 분야/기술 네트워킹 자리에 능동적 참여가 중요
  • 네트워킹을 하며 얻을 수 있는 것 - 1. 지식/경험 공유 2. 기술적 대화 3. 피드백
  • 괜찮은 주제가 있다면 발표도 한번 해보자!
  • AWS 아키텍처 모임, PyCon Korea, DEView, Python 격월 세미나, GDG Meetup …
  • 정말 다양한 기술과 경험을 지는 개발자들을 만날 수 있다.
  • 현재 직면한 문제를 해결하는 실마리를 찾는 기회도 존재
  • 관심분야의 다양한 지식과 기술적 인사이트를 얻을 수 있음
  • 개발자 인맥도 넓힐 수 있는 기회
  • 자극

(3) 개발 블로그

  • 기술 포스팅에서 중요한건 기술 혹은 정보의 하자가 없어야 한다는 것
  • 이미 알고 있던 지식이나 기술도 재검토가 필요
  • 따라서 특정기술에 대한 글을 쓸 경우 해당 기술을 완벽히 이해하기 위한 공부가 필요
  • 반대로 말하면, 관심 주제에 대한 공부를 위한 수단으로 블로그를 활용
  • 글을 작성하는 도중이나 퍼블리싱 후에 몰랐던 것들을 더 알게됨.
  • 지식 공유 해볼까나 -> 내가 정확하게 알고 있는게 맞나? -> 기술적으로 틀린 부분이 있나? -> 제대로 알아보자.
  • 이 주제로 글을 쓰고 싶은데.. -> 한 번 공부해봐야겠다. -> 나부터 정확히 이해하자 -> 정확한 이해를 한 상태로 포스팅
  • 알고있던 지식에 구멍이 발견되면서 포스팅이 막힘 -> 공부를하자! -> 깨달음과 동시에 새로 알게된 지식들을 글로 작성해나감 ->기쁜 마음으로 퍼블리싱을 하고 피드백을 받자
  • 솔직히 좋은건 알겠는데 몸소 실천하기 어려움 -> 데드라인을 정하자! ->적어도 언제까지는 꼭 퍼블리싱을 하겠다.
  • 본인이 알던 지식과 기술을 한 번 더 검토 해 볼 수 있고, 본인이 직접 글로 남기면 해당 지식은 기억에 오래남음 또한 지식 정리 및 글쓰기 능력도 기를 수 있음.

(4) 오픈소스 활동

  • 여기 좀 이상한데? -> 이슈를 제보하자! ->직접 해결해볼까나
  • 이런 기능이 없다니 -> 기능 제안을 해볼까나 -> 기능을 직접 추가하자
  • 이 내용 괜찮은데? -> 번역을 해볼까나 -> 허락은 받고!
  • 본인이 사용하는 툴이나 라이브러리에 기여
  • 정 어렵다면 마음에 드는 저장소나 문서의 번역으로 시작
  • 다른 개발자의 코드를 읽는 능력을 키울 수 있음, 버그를 해결하기 위한 코드 분석 능력을 키울 수 있음, 현업이 아니더라도 다른개발자와의 협업을 경험해 볼 수 있음, 나의 코드가 모두 공개되기에 코드 퀄리티에 신경을 쓰게됨, 정말 좋은 코드들을 많이 들여다 볼 수 있음, 부가적으로 기여 자체로 자신만의 포트폴리오가 됨.

(5) 마무리

  • 이제 까지 봤던 모든 활동들의 공통점 : 관심있는 분야와 기술에 대한 관심과 공부에 대한 의지

후기

  • 주니어들을 위한 최고의 자리였다.
  • 정말 많은 것을 얻었고 평소에 중요하다고 들었던 내용은 거의 모든 분이 중복해서 말씀을 해줬다.
  • 위에 작성한 내용대로 꾸준히 실천해서 나도 언젠간 꼭 이런 세미나에서 후배 개발자들에게 많은 것을 베풀고 싶다는 생각이 들었다.
  • 이런 자리를 만들어준 GDG 구성원들과 발표자분들 감사합니다 :)
facebook share twitter share
0%