GDG Campus Korea 2월 meetup !

GDG Campus Korea 2월 meetup 멋진 발표자 분들의 따끈따끈한 발표내용을  정리해보겠습니댜!

(빠진 부분은 이해바랍니다..ㅎ)

<행사일정>

14:15 ~ 14:30 등록확인
14:30 ~ 14:40 Keynote
14:40 ~ 15:00 세션1 : 한재엽 "함께 일하고 싶은 개발자 - 나름 큰 회사에서 반년동안 배운 것"
15:00 ~ 15:20 세션2 : 김은향 "새해에 일어난 일 - 고군분투한 인턴 개발자, 백수되다"
15:20 ~ 15:30 쉬는시간
15:30 ~ 15:50 세션3 : 구민석 "새해를 맞아 Google Firebase를 알아보자"
15:50 ~ 16:10 세션4 : 신호석 "플레이윙즈, 2017년, 팀장이 된 나"
16:10 ~ 16:20 쉬는시간
16:20 ~ 16:40 세션5 : 권민재 "회사 밖에서 성장하기"

세션1 : 한재엽 "함께 일하고 싶은 개발자 - 나름 큰 회사에서 반년동안 배운 것"

개발프로세스와 커뮤니케이션

개발프로세스는 아래와 같은 과정을 거친다!

이슈발생-유지보수-스펙분석-일정신청-코딩-커뮤니케이션-문서화

1.이슈발생

신규프로젝트, 유지보수, 추가스펙, 디자인 이슈, hotfix (바로 고쳐야하는 이슈)

자신의 일정을 고려하여 issue를 가져가는 방식을 취하고있다.

함께 일하고 싶은 개발자가 되는STEP1

자신의 실력을 객관적으로 판단할 줄 아는 개발자.

2.스펙분석

• view 기반으로 컴포넌트를 분리한다.

• 성능적인 부분고려(이미지 ,애니메이션)

• 백엔드,앱 개발자와의 인터페이스 협의 (api호출에 따른 실패로직)

• ux적인 부분 고려 (routing, page hide and restore)

• 각 기능 구현을 위한 모듈 검토

스펙협의 회의에서 많은 커뮤니케이션을 통해 스펙 fix

변경될 여지가 있는 부분 fix

but, 변하는 스펙을 따라가다 보면 스파게티코드가 만들어짐

스펙 분석과 설계 (list up)

놓친 스펙에대한 회고

함께 일하고 싶은 개발자가 되는STEP2

꼼꼼한 스펙 체크를 하는 개발자.

3.일정산정

1.타 부서 또는 다른 개발자와 협업

2.배포 일정 fix

3.예측 가능한 팀 내 resource 관리

• 계획오류 (작업을 완료하는데 필요한 시간을 낙관적으로 예상하는것)
• 90대90법칙

-첫 90%가 초기 개발시간, 나머지 10%를 하려고 또 90% 만큼의 투자비용 ->스펙분석과도 연관

• 공수를 4일(20시간)이라고 가정 [하루 5시간정도 밖에 개발을 못함...] (커피마시기,회의하기,등등,,,)

4일(개발시간)+2일(이슈대응,배포)+1일(공휴일)+1일(etc)+1일(etc2) =9일

너무 길게 잡으면 월급루팡 짧게 잡으면 야근지옥

->일정 산정이 중요함...

함께 일하고 싶은 개발자가 되는STEP3

신뢰가는 일정을 공유할수 있는개발자.

4.코딩

말할게너무많음..

5.커뮤니케이션

• 기획,디자인 -개발용어 사용 자제
• 마크업,서버- as-is , to-be 방식으로 커뮤니케이션

(마크다운 에디터)

giphy, typora 추천!!!

함께 일하고 싶은 개발자가 되는STEP4

커뮤니케이션 잘하는 개발자.

6.문서화

• 양날의 검, 코드 내주석
• history 작성할때도, 정돈되게 commit하면 좋음(커밋 메시지)
• git hook을 사용하면 커밋 메시지 형식을 강제할수 있다고한다.
• version이 중요한 라이브러리,모듈인경우 태그사용
• jsdoc을 사용하면 API DOCUMENT를 관리 할수있다.

프로젝트 시작할때부터 협의, 프로젝트가 진행되는 동안 꾸준히 문서화 해야함!

함께 일하고 싶은 개발자가 되는STEP5

문서화를 체계적으로 잘하는 개발자

마지막으로..

함께하고, 완주하고, 유저의 피드백을 받아보고, 기술 스택에 대한 이유를 생각해보기를 (면접에서도 왜썼어요? 라는 질문이 많이 들어옴), github과 함께하기를

 

세션2 : 김은향 "새해에 일어난 일 - 고군분투한 인턴 개발자, 백수되다"

신입개발자 지망생의 진로고민?

선택의 갈래: 대기업, SI, 스타트업

착각

• 구현은 개발과정 중하나!..ㅎ
• 딱 한번 구현하면 끝? no..
• 내 코드만 잘알면 된다? no...(혼나기 위해 리뷰하는 듯한 기분..)
• 구현은 되는데 이렇게 하면안될것 같은 느낌적인 느낌 

(개발자의 소리)

-회사볼때 무얼보나요?

1.정보탐색 : 개발자 만나보기

같이 일하는 사람들과 신뢰를 쌓음 ->서로간의 성장 ->선순환

회사를 볼때도 자신의 가치와 맞는..

(예시)

1.동료

2.성장

3.워라벨 (work and life balance)

4.대표

5.돈

2.코딩테스트

3.github 

깃헙 블로그 만들어서 알고리즘 문제 푼것 포스팅

커밋+블로그+알고리즘공부

일석 삼조

4.일단 이력서

1.화려한 이력서

화려한 이력을 가진개발자를 따라하기 위해, 양식에 맞춰

빽뺵히 써본다..?

but, 양식화 되면 읽히지도 않음

so! 썰위주로,.ㅎ

2.재밌는 이력서

but, 필요없는 내용적힐 가능성 있음..

so! 사소한 문제라도 어떻게 풀었는지 그런과정을 적기

이력서는: 작은문제라도 푼 경험을 어떤 고민을 거쳤는지 생생하고 일상적인 용어로 서술!!!

다 지나와서 무리하게 작성하려니까 슬픈 이력서ㅠ

쌓아왔던 당시의 생생한 블로그, github, 발표자료 그자체가 이력!!

결국 고민했던 내용은 면접으로 돌아옴.

중요한것

1.미래의 나를 위한기록

2.github관리

3.정도를 걷자 (금방이뤄지는건 없음...)

세션3 : 구민석 "새해를 맞아 Google Firebase를 알아보자"

• Realtime database
• 토이 프로젝트에 적합
• 서버 비용 x
• 백엔드 개발 시간 경감

플랫폼 별로 firebase 기능을 제공한다.

1.실시간 데이터베이스

2.오류보고

3.인증

(구글로 로그인,페이스북으로 로그인)

4.안드로이드용 test lab

실시간 데이터베이스

json구조 nosql 실시간으로 클라우드 동기화

firestore 라는 것도 있음.

세션4 : 신호석 플레이윙즈, 2017년, 팀장이 된 나"

개발자가 통상적으로 가지는 커리어길은 무엇이 있을까?

코더/매니저

• 유저 클러스터링

좀더 정확한 사용자의 니즈 파악 및 상품 분배

• 서버 고도화

사용자들에게 안정적이면서 민첩한서버

주니어라면 포커스가 코더에 머물러있겠지만, manager적 측면이 중요해지기 시작할 때가있다.

• Coder done list

코더로서, 코드생산능력, 유지보수능력, 학습능력 으로 한일들을 구분해보자!

• Manager done list

(못 적었씁니다..헤헤)

회사에서 직급이 올라갈수록 역할이 모호해진다.

혼자 coder로서 연구만 하지않는 이상....

경력 관리 목표 정비 방법

1.본인이 가고싶은 회사를 골라보자.

2.본인이 그안에서 하고 싶은 직업을 골라보자.

3.description을 확인하고 필수 조건으로 적혀있는 항목들을 확인하자.

4.다른 회사들도 한번 열람을 해보자.

직접한번 체크-> 현재를 알고 미래를 생각하면 지피지기 백전백승!

중간에 나온 질문

Q) 코딩과 매니징의 balance를 어떻게 유지하는가?

A)스타트업은 인력부족.. 허덕이기 일수다..매우 어려운건 사실이다. 사실대로 말하면 맞춰나가진 못했다 .

task가 워낙 많다보니 노트북 들고가서 집에서...ㅠ 

따라서 가지고있는 task 들을 나눠주는 것에 집중 jira point 배분

일정규모의 회사가 되어서,인력이있어서 디자인부분은 돕지않고, pr체크, 코더로서의 역할을 조금은 놓게 되었다...

세션5 : 권민재 "회사 밖에서 성장하기"

현업개발(회사 안)+자발적활동(회사 밖)

주니어가 빠르게 성장할 수 있는 방법은 현업개발..ㅎ

스스로 성장할 수 있었던 경험

1.지식 네트워킹

2.개발 블로그

3.오픈소스 활동

성장의 단계나 중요도로 보면,

지식 네트워킹<개발블로그<오픈소스활동

지식네트워킹

다양한 종류의 네트워킹 모임이존재한다.

같은 밋업이라고 해도 주제의 관심도에 따라 많이 상이하다.

본인이 관심있는 분야의 네트워킹 자리를 능동적으로 참여하자!

얻을수있었던 것

1.지식/경험 공유

2.기술적대화(다른사용자의 경험을 들어볼 수 있으며 본인이 직면한 문제에 대해 토론할 수 있는 기회이기도 하다.)

3.피드백 (참여자로서의 피드백도 있지만, 발표자로서의 피드백도 존재함.)

어려웠던 점

1.어떻게 참여할 수 있을까? -> 다른개발자들과 티타임도 네트워킹!ㅎㅎ

2.내가 관심있는 기술을 다루는 컨퍼런스/밋업 찾자 ->공유하고싶은 경험이 있다면 발표도 지원

개발블로그

글의 구성, 말투와 전달력 ,기술적 하자, 고려 정보의 정확성

->고려해야 할점이 많다.

힌트는 주로 기술 포스팅이올라가는 개발 블로그 라는 것이다.

 기술 포스팅에서 중요한건 기술 혹은 정보의 하자가 없어야 한다는 것이다. 

-> 이미 알고있던 지식이나 기술도 재검토 필요

-> 모호하게 알고있는 것들이 드러남

->특정 기술에 대한 글을 쓸 경우 해당 기술을 완벽히 이해하기 위한 공부가 필요할수도,,

-> 반대로 말하면, 관심 주제에 관한 공부를 위한 수단으로 블로그 

->글 작성 도중이나 퍼블리싱 도중 알게되는것도 많음

• 몰랐던 부분을 알려주는 경우, 
• 관심있는 주제에 관한 아티클번역 도중 새로운 사실을 알게되는경우 (잘못된 의역은 NO!!), 
• 잘알거라고 생각했던 기술에 대한 무지도 알게되는 경우

성장포인트

1.자신이 알고있는 지식 검토

2.피드백으로 인한 선순환

3.글쓰기능력

4.몰랐던것 알게됨

5.기억에 오래남음

오픈소스활동

동기와 과정은 항상 동일했었다.

1.좀 이상한데? -> 이슈를 제보하자! -> 직접 해결하자.

2.이런 기능이 없다니 ->기능을 제안해보자 ->기능을 직접 추가하자

3.이 내용괜찮다 ->번역을 하자->원작자에게 허락은 필수

4.이런 툴없나->직접 만들자->기여는 언제나 환영

계기는 단순!

소소한 기여부터 시작한다면 오픈소스 활동은 생각보다 어렵지 않다!

어려웠던점

프로젝트를 어떻게선택?

억지로 하나를 선택할 필요는 없고, 동기 부족

성장포인트

다른개발자의 코드를 읽는 능력 키울수있음

버그 해결 위한 코드 분석능력

협업의경험

포트폴리오가됨

모든활동의 공통점

관심있는 분야와 기술에 대한 관심과 공부에 대한의지

마무리

위 발표내용들과 같이, 멋짐뿜뿜한 개발자 분들로부터 생생하게 다양한 내용들을 직접 듣고 나에게 체화시키고, 또 네트워킹 하는 과정 속에서 하루동안 정말 많은것을 얻었다!!!! 

결론은..

여러분GDG MEETUP 무조건가세요!