와 해떴당🌞
반년이 다되도록 준비해 온 프로젝트로 첫 공모전 제안서 제출을 끝냈다. 그것도 마감 3분 전에. 잘려고 누웠는데 잠이 안 들더라.
근 일주일간 커피, 콜라 다 끊고 디카페인만 찾아먹다가 모처럼 마신 500ml 제펩 하나에 잠이 다 달아나버렸고, 그 김에 읽어내린 아티클 중 하나인 해외 소프트웨어 엔지니어 Gunnar Morling의 글을 살펴보았다.
주제는 '코드리뷰 피라미드'
The Code Review Pyramid
When it comes to code reviews, it’s a common phenomenon that there is much focus and long-winded discussions around mundane aspects like code formatting and style, whereas important aspects (does the code change do what it is supposed to do, is it perfor
www.morling.dev
당신은 코드리뷰 할 때 신경 쓰는 것이 무엇인가?
당신은 코드리뷰시에 무엇을 보는가, 표면적으로 보이는 코드 포맷과 코드 스타일인가? 아니면 코드 변경 가능성이 있거나, 효율적인 성능에 대한 판단이 되거나, 기존 클라이언트를 위한 호환 가능성이 존재하는 등의 보이지 않는 것에 집중하는가?
보통은 전자(포맷, 스타일)에 집중하는 경향을 가졌을 것이다.
맥락상 눈치챘을 테지만, 이에 대하여 Gunnar Morling은 후자에 집중해 보기를 권하며 따라서 이런 소소한 시야를 전달하고 싶다고 한다. 그건 바로 "Code Review Pyramid".
코드리뷰 진행시에 위에서 말한, 바로 보이지 않는 사항들에 관심을 두기 위한 가이드라인 및 지침을 공유하고싶다며 함께 첨부된-아래의 그림을 한 번 봐보자.
전체적인 피라미드의 특징
위로 갈수록 나중에 고쳐도 괜찮은(영향력이 작은 것)이지만, 아래로 내려갈 수록 변경하기 어려운(영향력이 큰 것)들이다.
최하위의 기반, API Semantics
- API as small as posiible, as large as needed?
가능한 작게, 필요한 만큼만 제작한 것이 맞는가? - Is there one way of doing one thing, not multiple ones?
한 가지의 동작을 위해 복잡하게 쓰인 것은 아닌가? - Is it consistent, does it follow the *principle of least surprises?
일관성 있고 *principle of least surprises 을 따르고 있는가?
*principle of least surprises: 놀람 최소화 원칙, 인터페이스 및 소프트웨어 설계에 적용되는 원칙 - clean split of API/internals, without internals leaking in the API?
API의 내부의 유출 없이, API와 내부요소들이 깔끔하게 분리되었는가? - Are there no *breaking changes to user-facing parts (API classes, configuration, metrics, log formats, etc.)?
유저와 직면하는 부분에 대한 변경사항은 없는가? (API 클래스, 설정, 측정, 로그 포맷, 그 외)
*breaking change: 기존 Application의 구성 모듈 등에 대하여 새 버전으로 import, 혹은 add, remove 등의 변화 - Is a new API generally useful and not overly specific?
새 API가 일반적으로 유용한 것인지, 혹은 지나치게 구체적인 것은 아닌가?
다음 차순의 기반, Implementation Semantics
- Does it satisfy the original requirements?
기존의 요구사항을 만족하고 이있는가? - Is it logically correct?
논리적으로 타당한가? - Is there no unnecessary complexity?
불필요하게 복잡성을 갖고 있진 않은가? - Is it robust (no concurrency issues, proper error handling, etc.)?
견고하게 작성되었는가? (동시성 문제가 없고, 적절한 오류 처지를 하였는지 등) - Is it performant?
기능성을 갖추었는가? - Is it secure (e.g. no SQL injections, etc.)?
안전성을 갖추었는가? (SQL주입이 없는지 등) - Is it observable (e.g. metrics, logging, tracing, etc.)?
관찰이 가능한 것인가? (측정, 로깅, 추적 등) - Do newly added dependencies pull their weight? Is their license acceptable?
새로 추가된 종속성이 가치가 있는 것인가? 허용되는 라이센스들인가?
... 그다음은 문서화(Readme, api Docs, 유저가이드, 레퍼런스 등)와 테스트 통과, 최상위의 코드 스타일이 존재한다.
즉 알고보니 우리가 외관적으로 보는 코드 스타일이 실은 가장 중요치 않은 부분이라는 의견이다.
물론 여기까지 Cunnar Morling의 한 의견임을 본문에 언급되어있다.
일단 이제껏 내가 프로젝트에서 만든 API 중 몇몇개가 위의 기준선을 토대로 개선/삭제의 필요성이 있음을 알았다. 검토해봐야겠는데...
그것과 별개로. 해외식 유머
🤔 : 님, 이건 피라미드가 아니라 삼각형인데요?
😶: .. 정면이라 그래~ 옆에서 보면 피라미드임.