[장정훈] 6장 - 낯선 시스템에 빨리 친숙해지기

06장/장정훈.md

@@ -0,0 +1,61 @@
+# 06장 낯선 시스템에 빨리 친숙해지기
+
+1장에서 메이커스에 들어올 때 남이 작성한 코드 위에 내 코드를 올리는 일을 해보고 싶었다고 적었었다.
+
+이 장을 읽으며 그때 생각이 다시 떠올랐다. 새로운 코드를 작성하는것도 중요하지만 이미 운영되고 있는 시스템을 이해하고 안전하게 바꾸는 능력도 그만큼 중요하다고 생각한다.
+
+그렇다면 낯선 프로젝트를 마주했을 때 어디서부터 시작해야 할까.
+<br /><br />
+
+## 코드보다 먼저 프로젝트가 존재하는 이유부터
+
+책에서는 코드를 자세히 보기 전에 프로젝트의 목적과 사용자, 이해관계자를 이해하라고 설명한다. 이후 문서와 아키텍처, 프로젝트 구조를 살펴보는 순서다.
+
+처음 보는 코드에서 폴더 구조나 사용 중인 라이브러리는 눈에 바로 들어온다. 하지만 그것만으로는 왜 이런 구조가 되었는지까지 알 수는 없을것 같다.
+
+2장에서 이전 개발자의 관점으로 코드를 바라봐야 한다고 적었었다. 그때의 개발 기한이나 실험 목적을 모른 채 코드만 보고 판단하면 중요한 맥락을 놓칠 수 있다.
+
+`왜 이렇게 구현했지?`라는 질문을 비판으로 끝내지 않고 실제로 답을 찾아가는 질문으로 바꿔야겠다. 기존 개발자와 이야기하거나 PR, 커밋 이력을 읽는것도 코드 이해의 일부라고 생각한다.
+
+다만 문서도 항상 최신은 아니다. 책에서도 오래된 인증 문서를 읽느라 시간을 쓴 경험을 소개한다. 문서는 출발점으로 삼되 실제 코드와 실행 결과로 확인해야 할것 같다.
+<br /><br />
+
+## 파일을 전부 읽기보다 하나의 흐름을 따라가자.
+
+책에서는 애플리케이션의 진입점을 찾고 요청이 지나가는 경로를 추적하라고 설명한다. 브라우저 개발자 도구, 로그, 디버거를 이용하면 코드에 적힌 흐름과 실제 실행되는 흐름을 비교할 수 있다.
+
+프론트엔드라면 하나의 기능을 직접 사용해보는것부터 시작할 수 있을것 같다.
+
+예를 들어 게시글 작성 기능이라면 입력값이 어느 상태에 저장되는지, 제출할 때 어떤 검증을 거치는지, 어떤 API를 호출하고 성공이나 실패를 어떻게 화면에 반영하는지 따라가는것이다.
+
+이 과정에서 Network 탭의 요청과 응답도 같이 확인한다면 타입 선언이나 함수 이름만 보고 추측하는것보다 더 정확하게 이해할 수 있을것 같다. 정상적인 경우뿐 아니라 요청이 실패했을 때의 흐름도 확인하고.
+
+그리고 이 흐름은 해당 컴포넌트 안에서 끝나지 않을 수 있다. 공통 API 클라이언트의 인증 처리나 에러 처리, 외부 서비스 같은 의존 관계까지 확인해야 내가 바꿀 코드의 영향도 알 수 있을것 같다.
+<br /><br />
+
+## 머릿속 지도를 조금씩 만들어가기
+
+책에서는 시스템이 동작하는 방식에 대해 머릿속에 그린 그림을 `정신 모델`이라고 설명한다. 전체 시스템을 한번에 이해하려고 하기보다 하나의 경로부터 이해하고 점점 넓혀가라고 한다.
+
+처음부터 모든 코드를 알아야 기여할 수 있는것은 아니라는 점이 인상 깊었다. 지금 맡은 기능의 흐름을 이해하고 연결되는 기능을 보면서 지도를 확장하면 되는것 같다.
+
+여기서 내가 이해했다고 생각하는것과 실제로 이해한것은 다를 수 있다. 간단하게 흐름을 그려보고 팀원에게 설명해보면 빠뜨린 부분을 찾는 데 도움이 될것 같다. 그림을 예쁘게 만드는것보다 내가 생각한 흐름이 맞는지 확인하는게 더 중요하다.
+
+온보딩하면서 막힌 부분이나 문서와 달랐던 부분도 남겨두고 싶다. 다음 사람이 같은 부분에서 시간을 쓰지 않게 하는것도 1장에서 이야기한 `황금률`을 실천하는 방법이라고 생각한다.
+<br /><br />
+
+## 더 좋게 남기되, 한번에 다 고치려고 하지는 말자.
+
+> 코드를 처음 발견했을 때보다 항상 더 좋게 남겨둬라.
+
+책에서 설명하는 `스카우트 규칙`이다.
+
+3장에서 가독성 있는 코드와 네이밍의 중요성에 공감했지만 처음 보는 코드를 내 기준에 맞춰 전부 바꾸는것은 다른 문제인것 같다. 이해하지 못한 비즈니스 규칙까지 바꿀 수 있고 원래 해야 할 작업을 끝내지 못할 수도 있다.
+
+책에서도 잘 동작하고 거의 수정하지 않는 코드나 현재 범위를 크게 넘어서는 리팩터링은 미루는 편이 좋다고 설명한다. 더 좋게 남기라는 말에도 변경의 이득과 위험을 판단하는 과정이 필요하다.
+
+리팩터링이 필요하다면 먼저 현재 동작을 확인하는 테스트를 작성하고 통과하는지 확인한 다음 구조를 바꿔야겠다. 버그 수정과 구조 개선도 구분해서 진행하고.
+
+3장 PR에서 코드리뷰할 시간을 확보하면 좋겠다고 적었었다. 여기에 PR 자체를 작게 만드는것도 함께 필요할것 같다. 여러 목적의 변경이 섞여 있으면 리뷰할 시간이 있어도 맥락을 이해하기 어렵고, 문제가 생겼을 때 되돌리기도 어려워진다.
+
+내가 바꾼 이유와 확인한 내용을 설명할 수 있는 작은 변경부터 쌓아가는것. 낯선 시스템에 익숙해지는 과정도 결국 `이해 → 작은 변경 → 검증`을 반복하는 과정인것 같다.