Recommandé
Recommandé
Contenu connexe
Tendances
Tendances (20)
Similaire à [네이버오픈소스세미나] egjs-view360 개발기 - 김희재
Similaire à [네이버오픈소스세미나] egjs-view360 개발기 - 김희재 (20)
Plus de NAVER D2
Plus de NAVER D2 (20)
Dernier
Dernier (8)
[네이버오픈소스세미나] egjs-view360 개발기 - 김희재
- 1. View360 개발기 -오픈소스화로 기술부채 청산한 이야기- 네이버 FE플랫폼 김희재
- 2. 내용 소프트웨어 개발 과정에서 기술부채가 왜 발생했고 프로젝트에 어떤영향을 주었으며 오픈소스화로 어떻게 문제상황을 벗어날 수 있었는지 오픈소스로 공개하면 어떤 장점이 있지? 내 프로젝트로 오픈소스로 할때는 어떤 점에 신경쓰면 좋지?
- 7. 현재는 네이버TV에 열심히 적용 중… 360영상도 모바일 브라우저에서 곧!
- 8. FE 플랫폼 • 네이버의 FE 기술 지원 조직 • 사내 서비스들을 위한 WEB UI 라이브러리 개발 • 경쟁력 있는 컴포넌트는 오픈소스로 공개 • egjs, billboard.js, jindo.js > 여러 서비스들의 이슈를 압축적으로 경험하면서 빠르게 성장 할 것을 기대하고 입사
- 9. “360도 뷰어 만들어 보실 분?” < -- 오너쉽에 목마른 2년차 FE개발자
- 10. 요구사항 • 네이티브 WEBGL로 직접 구현 • 안드로이드 등 모바일 브라우저 호환성 확보 • 디바이스 모션 컨트롤 > 정점 쉐이더, 프래그먼트 쉐이더, OpenGL 렌더링 파이프라인 > 오일러각, 짐벌락, 쿼터니언, 센서퓨전, 칼만 필터, LERP, SLERP … “음 .. 이해하고 구현해 내면 일단 성공”
- 11. 기술부채 발생이 불가피했던 상황 • 콘셉트 증명 단계로 간주 • 요구사항만 만족하면 됨 • 관련 지식과 경험이 부족하여 구현 하는 것이 1순위 • 1인 개발 • 협업을 위해 코드의 품질을 신경 쓸 필요가 없음(!) • 문서화? 나중에… • 테스트코드? 일단 돌아가야 하지 않을까… • CI? 빨리 일단 돌아가게 만들어야 ㅠㅠ
- 12. 라이브러리를 서비스 부서에 전달했는데… > 버그를 수정하면 다른 버그가 발생 > QA 사이클로 감당하기 힘들게 연속해서 발생하는 수정 부작용 > 두번의 배포연기
- 14. 기술부채(Technical Debt) • 빠르지만 지저분한 방식으로 일하면 기술 부채로 압박 받게됨 • 기술부채를 지고 빠른 출시를 할 수 있음 • 하지만 기술부채 를 청산하지 않으면 이자가 계속 커짐 • 이자: 유지보수, 기능추가를 위해 추가적으로 들여야 하는 개발시간 • 따라서 시기 적절하게 부채 원금을 청산하지 않으면 이자 복리의 효과까 지 더해서 망하는 소프트웨어가 됨
- 15. View360 에서의 초기 기술부채 • 테스트 코드 X • 하나를 고치면 어디서 부작용이 생길지 알 수가 없습니다. • 따라서 기능 추가를 하기 힘들어짐 • 공감할 수 없는 구조설계 • 남이 공감할 수 없는 구조라면 미래의 나도 이해할 수 없습니다. • "여기 왜 이렇게 짰지...." • 코드만 봐도 구조설계가 납득될 수 있도록 구조를 잘 짜야합니다 • 군더더기가 많은 API • 어떤 기능까지 필요하게 될 지 예측해가면서 개발 • 문서화 • 설계문서, 스펙문서: 최소한 만 수행 • 핵심기술 원리: X
- 16. 처음부터 다시 둘이서 만들기 • 새로운 시니어 멤버! • 둘이서 개발진행 • 와! 이제 코드 리뷰하고 받을 수 있다! • WebGL과 센서신호처리관련 이론을 공부하여 출발선 맞춤 • 구조 설계 함께 진행
- 17. 오픈소스화 기준에 맞춰 부채청산 시작
- 18. 구글의 사례: 텐서플로 “많은 분들이 구글이 하는 모든 프로젝트가 철저한 계획 아래 깔끔하고 효 율적으로 진행될 걸로 생각하십니다. 사실 항상 그렇지 않습니다. 많은 프 로젝트가 처음엔 엉망진창이며, 관련된 문서는 찾기 힘듭니다. 같은 일을 여러 번 반복하기도 하죠. 그런데 기술을 오픈소스화하면 (외부에 공개되 기 때문에) 문서 작성나 작업을 체계화하는 데 많은 노력을 들입니다. 이 건 과정에서 팀 전체가 일주일 동안 문서화 작업에 집중하기도 합니다. 이 건 구글에게 매우 좋은 영향을 끼칩니다.” 구글 브레인 팀 - 마이크 슈스터 http://www.bloter.net/archives/254962
- 19. 이슈/커밋메시지/문서는 영어로 작성 • 지나가던 개발자는 웬만하면 영어를 씀 • 작성하다보면 익숙해짐 • 비슷한 표현을 스택오버플로우나 다른 깃허브 프로젝트 이슈에서 찾아 보면서 응용하면 더 쉽다
- 20. 커밋메시지 잘 쓰기 • 이 코드는 왜 이렇지? 를 해결 • 정해진 포멧 준수 ${작업의 종류}(${작업대상 모듈}): 작업 내용 Ref #${해당 이슈번호}
- 21. Pull Request 단위를 줄이기 • 리뷰를 의미있게 하기 위한 조건 • 되도록이면 1이슈 1PR 이 좋다고 봄
- 22. 테스트의 중요성 • 기능 추가 전후 두려움이 줄어든다 • 문제 없을거에요! 테스트 통과했으니까! 라고 말할 수 있게된다. • 문제 생기면 해당 이슈를 테스트로 추가하면 되니 개꿀! • PR을 받을 수 있는 최소한의 준비 • 테스트 없는 오픈 소스의 경우 PR 을 넣어도 • 이것저것 테스트 해보고 응답드릴게요 라고 핑계를 대면서 외부PR을 잘 안받는 경우가 있음
- 23. 테스트 작성 • 구조와 API 설계가 어느정도 안정되고 나서 테스트 작성시작 • 테스트가 작성이 힘들면 테스트 가능성 높아지도록 리팩토링. • 특정기능을 모듈로 분리하거나 • Mocking 을 용이하게 리팩토링 하거나 • WebGL 렌더링 테스트 방법 적용 • 캡쳐한 이미지와 정답 이미지의 diff 를 비교 • 디바이스 모션은 테스트 헬퍼 구현
- 24. PR 단계에서 CI 활용 • CI 지속적 통합 • PR 을 날렸을때, 해당 코드 품질 체크 1. 빌드가 되어야함 2. 코드컨벤션이 맞아야함 3. 단위 테스트를 모두 통과해야함 4. 테스트 커버리지가 감소하지 않아야함(!) Travis CI+ coveralls 좋아요 느슨해지지 않도록 제3의 감독관이 있는 느낌
- 26. 시맨틱 버저닝 • X.Y.Z (Major.Minor.Patch) • Major: 업데이트 시 기존 코드를 수정해야하는 경우 (breaking change) • Miner: 기존 API 변경없는 기능추가 • Patch: API 변경이 전혀없는 버그수정
- 27. 릴리즈 시 시맨틱 버저닝을 따르기 • 기존 라이브러리 전달 방식 • A서비스- a기능 에 이슈가 있어요 고쳐주세요 (1월 20일) • 수정 후 A_0120 이라는 태그를 따서 전달 • A_1023, B_1120 이라는 태그가 남발. • 수정사항 어떻게 합치지... • 사내 버전을 따로 두지 않고 외부 공개된 단일 패키지만 제공하기 • 시맨틱 버저닝을 적용하여, 빠른 이슈 수정요청이 들어올 경우 • 해당 내용을 외부 공개 이슈로 등록 하고 수정반영 하여 바로 릴리즈 후 해당 부 서에 제공 • 관리되는 브랜치가 하나라서 합칠 고민 안해도 된다.
- 28. 가이드 문서 작성하기 • 메이저 업그레이드를 대비한 마이그레이션 문서(!) • 메이저 버전 변경 릴리즈 시에는 breaking change 에 대한 문서를 꼭 써야함 (없으면 사내 개발자도 새 버전으로 업그레이드 못해줌…) • https://github.com/naver/egjs-view360/wiki/3.0.0-rc-Change-Notes
- 29. 소개페이지 만들기 • 라이브러리에 대한 이해를 도울 수 있음 • 소개페이지를 안 만들면 특히 비개 발자는 소외됩니다 • https://naver.github.io/egjs-view360
- 30. 커뮤니티에 기여하기 이 때 부채청산과정에서 나온 결과물을 활용할 수 있다. • 기술 블로그 글 작성 • 내가 해결한 문제를 겪고 있는 프로젝트에 PR 날리기 • 내가 해결한 문제와 관련된 스택오버 플로우 질문에 답변달기 • 내 프로젝트 진행 중 타 깃허브 프로젝트 이슈들 레퍼런스 걸기(!) • 연구 결과 공유하기 • 컨퍼런스나 개발자 밋업에서 발표 • DEVIEW 2017 밑바닥부터 시작하는 360뷰어
- 31. 오픈소스화 과정을 통해 얻은점 • 포지셔닝 작업을 통해 존재이유가 생김 • 빠르고 가벼운 모바일웹에서도 잘 돌아가는 360 동영상/이미지 뷰어 • 라이브러리 품질이 올라감 • 테스트 작성 및 API 설계 완성도 확보 • 품질이 떨어질 수 있는 여지를 최대한 줄여놓아서 외부개발자 참여를 받 기 용이 naver/egjs-view360 저장소를 방문하시면 발표내용에 언급된 내용들이 실제로 적용된 모습을 참고하실 수 있습니다.
- 32. 오픈소스화 과정을 통해 느낀점 • 타인을 고려하면 할 수록 가치가 더해지는 소셜코딩의 힘 • 나, 미래의 나, 같이 일하는 동료개발자, 타 부서의 개발자/기획자, 사외 개발자/기획자, 내 오픈소스를 이용해 다른것을 개발하는 개발자, 경쟁 오픈소스의 개발자, 스택오버플로우에서 나와 같은 문제로 질문을 올린 개발자, 답변을 단 개발자. • 다양한 방식의 활동을 통해 내 프로젝트의 품질도 올라가고, 내 지식과 경험도 확장되는 경험 • 소셜코딩으로 다같이 폭풍성장 해요.
- 36. 끝! 감사합니다.