주간회고 #4
19.9.2 - 9.8
#이해가 안되는 이슈 디버깅
이전에 팀내에서 리포팅된 이슈가 하나 있었다. 로그를 보면 Java Collection API의 size()를 호출할때 NPE가 발생하고 있었는데, 그 array 객체는 NotNull임을 코드상에서 보장하고 있어서 도저히 발생할 수 없는거라 생각됐다. 조금더 고민하다가 프로덕션에서는 안발생하겠지하고 넘겼었다. 그리고 몇주뒤.. 몇몇 유저에게서 동일한 이슈로 펑펑 터지고 있었다.. -_- 부랴부랴 다시 로그를 확인하고 당연하다고 생각한 것들부터 의심해보았다. 몇 시간 삽질결과 API 단에서 non-optional로 정의된 줄 알았던 녀석이 optional로 오고 있었고 Kotlin Data Class에서 NonNull로 정의한 Property일지라도 파서에서 null로 바인딩되는 경우가 있는 것으로 확인되었다.
...
당연하다고 여겨지는 것들을 의심해볼 수 있어야 한다. 그때, 당연한 것들에 대하여 논리적으로 추론할 수 있도록 도와주는 스킬을 알아두는 것이 좋다. 이 경우에는 Kotlin Decomplie을 해본 것이 굉장히 큰 도움이 됬다.
#팀 OKR 회고
1. 팀의 목표를 정할 때는 더 많은 시간을 투자하여 신중히 결정할 필요가 있다. 형식에 맞는 목표를 빠르게 정한다고 해서 제대로 working하지는 않는 듯( 적고 보니 굉장히 당연한 소리다.)
2. 팀 차원에서 하기로 한 것에 대해 제대로 마무리되었는지 팔로업이 안되면, 시스템 전체적인 회의감으로 커지는 것 같다. 무언가를 정하고 하기로 했다면 그 의사결정을 관련자들끼리 하더라도 그 마무리에 대한 팀원 공유는 적절하게 이루어져야하는 것 같다.
3. 팀 차원에서 하기로 한 것에 대해서 피드백 없이 넘어가게 되는 경우가 지속될 경우, 시스템이 잘 돌아가고 있는지에 대해 의문을 품게 되는 것 같다. 함꼐 하기로 합의한 시스템이라면 인풋에 대해 적절한 피드백( 확인했다는 간단한 피드백이라도) 있는게 좋은 듯. 만약 지속하는게 무의미하다고 생각된다면 그 즉시 빠르게 팀 안건으로 올리고 의사결정하는 하는게 좋은 것 같다.
4. 개인의 감정상태를 공개적으로 공유하는 것은 무의미한 것 같다. 일단 힘들때 힘들다고 말하는 것 자체가 쉽지 않고 많은 용기를 필요로 하는데 회의 시간에 말하는건 거의 불가능할 듯. 이런 팀원 개인에 대한 케어는 좀더 private하게, 1:1 미팅을 통해서 주기적으로 확인해야되는 것 같다.
#Google Code Review Guide
1. 구글 내부적으로 이런 룰을 기반으로 Strict하게 코드리뷰를 하는 문화를 갖고 있다는 것과 그러한 문화를 통해 코드 퀄리티의 향상시키고 회사의 성장과 개인의 성장을 연결한다는 점이 인상 깊었다.
2. 지금 마인딩에서는 딱히 코드리뷰를 잘하고 있지않다. 슬슬 클라이언트 앱을 RN으로 갈아엎을 준비를 하고 있는데, 그것에 맞추서 마인딩 코드리뷰 그라운드룰을 정하고 그걸 엄격하게 지켜보면 좋지않을까하는 욕심이 들었다. ㅎㅎ
---
The primary purpose of code review is to make sure that the overall code health of Google’s codebase is improving over time. All of the tools and processes of code review are designed to this end.
A CL that, as a whole, improves the maintainability,readability, and understandability of the system shouldn’t be delayed for days or weeks because it isn’t “perfect.”
Sharing knowledge is part of improving the code health of a system over time.
A particular type of complexity is over-engineering, where developers have made the code more generic than it needs to be, or added functionality that isn’t presently needed by the system
Did the developer pick good names for everything? A good name is long enough to fully communicate what the item is or does, without being so long that it becomes hard to read.
Usually comments are useful when they explain why some code exists, and should not be explaining what some code is doing.
Look at every line of code that you have been assigned to review. If it’s too hard for you to read the code and this is slowing down the review, then you should let the developer know that and wait for them to clarify it before you try to review it.
If you see something nice in the CL, tell the developer, especially when they addressed one of your comments in a great way
If you are not in the middle of a focused task, you should do a code review shortly after it comes in. One business day is the maximum time it should take to respond to a code review request (i.e. first thing the next morning).
https://google.github.io/eng-practices/review/reviewer/
#관계
아리스토텔레스가 우정론에서 말한 우정의 분류가 인상 깊었다.
1. '효용성'을 추구하는 우정 - 실리, 이해관계
2. '즐거움'을 추구하는 우정 - 취미, 관심사
3. '선'을 추구하는 우정 - 상대방이 목적이 되는
공감이 가면서도 약간은 헷갈리는 것 같다. 어느 정도는 서로 결합되어있는 느낌이 들기도 하고. 완전히 '선'을 추구하는 관계가 있을 수 있는지 살짝은 회의적인 것 같기도 하다. 정말 몇 사람 없는 것 같지만, 그래도 생각나는 사람이 몇 명은 있는 것 같아 다행이다.
문득, 나에게 소중한 사람은 어떤 사람일까 생각해보았다.
1. 내가 사랑하는 사람
2. 내가 의지할 수 있는 사람
3. 함께 있으면 기분이 좋아지는 사람
4. 함께 있으면 기분이 편안해지는 사람
5. 나의 이야기를 들어주는 사람
6. 나의 관심사와 취미를 공유할 수 있는 사람
7. 목적없이 나에게 연락해주는 사람
8. 나에게 많은 영감을 주는 사람
9. 나를 좋아해주는 사람.
이렇게 정의를 하는 것만으로도 나에게 주어진 관계에 감사한 마음을 가질 수 있는 것 같다. 소중한 사람들에게 나의 감사한 마음을 잊지말고 표현할 수 있기를 :)
#책 #안티프래질
말하고자 하는게 굉장히 추상적이라 이해하는데 어려움이 많았다. 난해한 번역도 한 몫한 듯. 뒤로 갈수록 대강대강 읽었다. 마지막 부분부터는 몰입이 잘 안되서 아쉬움이 많은 책인 것 같다. 그래도 이 책 전반에서 소개하는 '안티프래질'이라는 개념은 삶을 설계해나가는데 있어서 빛나는 통찰을 주는 것 같다. 현대의 교육, 의료, 정치, 경제 등 전반적인 사회 시스템의 모순을 '안티프래질' 관점에서 통렬히 비판하는 것도 되게 인상 깊다.
- 감당하지 못할 리스크를 안고 있는 행동은 무의미하다.
- 바벨 전략을 통해 안티프래질해져라 : 리스크를 극단적으로 수용하는 전략과 리스크에 대해 완전히 보수적인 전략을 적절히 혼용하라
- 잃는 것에 대한 마인드셋을 수련함으로써 하강국면에 대한 리스크를 최소화할 수 있다. 하강국면이 상승국면보다 우리에게 미치는 심리적 영향이 더 크므로.
- 너무 과한 개입은 프래질한 상태를 만든다. 목적을 명확히하고 꼭 필요한 간섭만 하도록 하자.
- 지적 활동의 본질은 손실의 고통을 제거하기 위해서 정신을 가다듬는 것이다.
어떤 대상이 프래질해질 때 깨질 수 있는 리스크를 줄이지 않는다면, 그 대상을 개선하거나 효율적으로 만들기 위해 할 수 있는 모든 노력이 무의미해진다.
- 더 많이 연구할수록, 명백하고 기본적인 것은 잘 보이지 않는다. 반면 해동은 가장 단순한 모델로 옮겨놓는다.
- 실천적 결론으로 이어지지 않는 회고는 인과의 오류에 빠져있을 확률이 크고, 그것은 어떠한 성장포인트도 만들어주지 못할 것이다.
- 이해는 중요하지 않다. 다만, 더 나은 옵션을 행사하기 위해 두 가지 결과를 비교할때 합리성을 유지해야 한다.
#인상 깊게 읽은 아티클들
