문서의 선택한 두 판 사이의 차이를 보여줍니다.
양쪽 이전 판 이전 판 다음 판 | 이전 판 다음 판 양쪽 다음 판 | ||
독서:나는_line_개발자입니다 [2019/11/28 09:22] kwon37xi |
독서:나는_line_개발자입니다 [2019/12/03 09:17] kwon37xi |
||
---|---|---|---|
줄 6: | 줄 6: | ||
> 라인에서는 장애가발생한 직후부터 이미 장애 리포트가 작성되고 근거 자료의 취합이 진행될 뿐만 아니라, 장애 리포트를 공유하는 미팅도 가능한 한 많은 사람과 함께 갖는 문화가 있다. 메일로 장애 리포트가 담긴 위키 주소를 공유하고 장애 공유 미팅을 하면서 사람들은 새로운 아이디어를 내고 장애가 반복되지 않도록 시도할 만한 아이디어들을 제시한다. 같은 배를 타고 있는 동료로서 목적지까지 더 잘 갈 수 있도록 서로를 돕는 이상적인 모습이라고 느꼈다. p. 27 | > 라인에서는 장애가발생한 직후부터 이미 장애 리포트가 작성되고 근거 자료의 취합이 진행될 뿐만 아니라, 장애 리포트를 공유하는 미팅도 가능한 한 많은 사람과 함께 갖는 문화가 있다. 메일로 장애 리포트가 담긴 위키 주소를 공유하고 장애 공유 미팅을 하면서 사람들은 새로운 아이디어를 내고 장애가 반복되지 않도록 시도할 만한 아이디어들을 제시한다. 같은 배를 타고 있는 동료로서 목적지까지 더 잘 갈 수 있도록 서로를 돕는 이상적인 모습이라고 느꼈다. p. 27 | ||
+ | |||
+ | > 기존에 근무시간 위주로, 이메일 중심으로 이뤄졌던 비동기 커뮤니케이션에서, | ||
+ | |||
+ | > 여러 국가에서 서비스를 출시하면서 얻은 가장 중요한 교훈을 결론부터 말하자면, | ||
+ | |||
+ | > 효율적인 테스트를 위해 유저의 반응을 즉각 파악할 수 있을 정도의 기능을 최소화한 서비스를 빠르게 출시한다. 유저의 반응을 다시 데이터를 통해 분석하고, | ||
+ | |||
+ | > 기능 출시 후 반드시 측정이 뒤따라야 한다는 생각도 팀 전체에 공유되었다. -p. 65 | ||
+ | |||
+ | > 팀으로서 같이 따를 원칙과 실천을 정리해놓은 방대한 문서였다. | ||
+ | >> 누구든 팀의 프로세스와 프로젝트의 기술적인 얼개를 이해하고 체득할 수 있도록 도와주기 위한 신입 가이드 문서 | ||
+ | >> 실제 코드나 기술을 도입하는 데 필요한 배경, 설계, 구현 계획을 담아놓은 테크 스펙 | ||
+ | >> 코드를 고치고 정기적으로 배포할 때의 모든 절차를 나열한 가이드 | ||
+ | >> 비상 상황에서 참고할 지표(metric) 대응 범위, 행동 방침을 합의해서 규정해 놓은 팀 문서 | ||
+ | > ... 가이드들에 담긴 원칙을 끊임없이 참고하고 회고 한다. 지표를 설정해서 지난 실천을 수치화하고 반성하며, | ||
+ | |||
+ | > ' | ||
+ | > ... 내 스타일에는 최대한 풀어서 설명하는 쪽이 낫다는 결론에 도달했다. 개인적인 이야기를 할 때야 그럴 필요는 없겠지만, | ||
+ | > 어떤 방법을 선택하더라도 상대방이 내 의도를 이해했는지 한 번 더 확인하는 과정을 거치도록 하자. 업무 진행 과정에서 한쪽은 다 설명했다고 생각했는데 받아들이는 쪽은 설명이 부족하다고 느끼는 상황은 자주 일어난다. .. 내가 생각하는 내용을 정확하게 전달하는 데에만 몰두해서 상대방 이양기를 제대로 이해하지 않고 넘어가는 일이 없도록 항상 조심하자. p. 115~117 | ||
+ | |||
+ | > CHANGELOG에는 이전 버전과 지금 버전의 차이가 풀 리퀘스트 혹은 이슈 단위로 기록되어 있어 구체적으로 어떤 변경이 있었는지를 확인하는게 가능하다. 매일 작업을 하며 젠킨스를 이용해 여러 가지 리포트를 생성하고 있다. Dependency-Check를 통해 혹시 보안 문제가 있는 라이브러리 버전을 이용하고 있는 건 아닌지, 테스트가 실패하는지 등을 확인한다. 테스트가 주요한 로직을 커버하면 새 라이브러리를 적용할 때도 부담이 덜하다. -p 122 | ||
+ | |||
+ |