6. 경로 탐색

개발자 라면 더  많은 코드를 둘러봐야 하고 더 자주 새로운 프로젝트에 투입되어야 하낟. 하나의 팀에서 영원히 하나의 코드베이스만 다루다가 고인 물이 되지 말아야 한다

이미 존재하는 거대한 코드베이스에 적응하기란 어려운 일이다. 적응을 위해서는 다음과 같은 작업을 빠르게 해내어야 한다.

• 코드의 어느 부분부터 보아야 하는지 파악하기
• 코드의 부분별 기능을 알아내고, 그 기능을 어떻게 수행할지 살펴보기
• 코드의 품질을 가늠하기
• 시스템 내부를 어떻게 탐색할 것인지 계획하기
• 코딩 관례를 이해하고, 본인의 수정 사항이 그것과 어울리도록 만들기
• 특정 기능이 있을 법한 위치를 파악하고, 그 기능에 의해 발생하는 버그 찾아보기
• 코드와 함께 그것의 주요한 부속 부분들의 테스트 코드 및 문서 등의 관계를 이해하기

1. 친구들의 작은 도움

코드에 정통한 누군가와 함께 일을 할 수 있다면 그 점을 활용하라.  질문하기를 주저하지 말라. 할 수만 있다면 페어 프로그래밍을 하고, 자신의 작업을 검토해줄 것을 요청하라.

도움을 요청할 때는 언제나 공손해야 하고 감사해야 한다. 합리적이고 적절한 질문을 하라. 

"제 숙제를 대신해 주실 수 있을까요? " 와 같은 질문을 통해서는 좋은 대답을 들을 수 없다.

도움을 받았다면 그에 대한 답례로서 언제든 다른 이를 도울 준비를 해라. 상식적으로 행동하고, 질문 하기에 앞서 구글을 통해 검색하라.

혼자 쉽게 알아낼 수 있는 바보 같은 질문을 하지 않는 것은 최소한의 예의다.

2. 단서 찾기

혼자서 소프트웨어 시스템의 깊은 부분을 알아내야 한다면, 코드 속에서 방향을 가늠하게 해주는 단서들을 찾아야 한다.

소스 획득의 용이성

얼마나 쉽게 소스를 얻을 수 있는가?

버전 관리 시스템을 통해 체크아웃 통해 소스를 내려 받은뒤, 개발 머신의 디렉터리 위치에 상관 없이 아무 데나 그냥 두어도 되는가? 

아니면 여러 부분을 따로 체크아웃 한 뒤, 컴퓨터의 특정 위치에 설치해 주어야 하는가?

파일 경로를 하드 코딩하는 행위는 나쁜 짓이다. 하드 코딩된 파일경로로 인해 여러 버전의 코드를 쉽게 빌드할 수 없기 때문이다.

       다만 여런 단계의 체크아웃을 거치거나 하드 코딩된 위치에 코드를 두어서는 안 된다.

소스 코드 자체의 획득 용이성뿐만 아니라 코드의 건전성에 대한 정보를 어떻게 획들할 수 있는지에 대해서도 고민하라. 지속적인 통합 CI빌드 서버를 통해 코드의 모든 부분이 성종적으로 빌드되는지 지속해서 확인할 수 있는가? 자동화된 테스트들의 결과가 공개되어 있는가? 등도 확인 하여야 한다.

※건전한 프로젝트에서는 전체 코드베이스를 얻기 위해 코드를 하 번만 체크아웃해도 된다. 또 빌드 머신의 그 어떤 디렉터리에 두어도 상관없다.

코드 빌드의 용이성

코드를 빌드하기 어렵다면 해당 코드를 이용해 일하기도 어렵다. 빌드 과정에서 익숙하지 않은 도구가 필요하다면 그 도구를 설치해야 하는가? 그 도구들을 어떻게 최신 버전으로 유지 하는가?

코드를 처음부터 빌드하기는 얼마나 쉬운 일인가? 코드 자체에 적절하고 간결한 문서가 있는가? 소스 관리 시스템에서 코드를 받자마자 바로 빌드할 수 있는가? 아니면 빌드 전에 수많은 자잘한 설정 작업을 수작업으로 수행 해야 하는가?

하나의 간단한 단계를 통해 전체 시스템을 빌드할 수 있는가? 아니면 수많은 빌드 단계가 필요한가? 빌드 과정에 사용자가 개입해야 하는가? 코드의 일부분에 대해 작업한 후 해당 부분만 빌드할 수 있는가? 아니면 전체 프로젝트를 다시 빌드해야 하는가?

리리스 빌드는 어떻게 만들어 지는가? 개발 빌드와 동일한 과정인가? 아니면 다른 단계를 거쳐야 하는가? 빌드 수행 시 별다른 경고는 없는가? 아니면 지나치게 많은 경고를 노출하다가 정작 중요한 문제를 가릴 가능 성이 높은가?

※ 건전한 빌드는 하나의 단계만으로 수행되며, 사용자의 개입을 필요로 하지 않는다.

테스트

얼마나 많은 코드베이스가 테스트되고 있는가? 테스트는 자동으로 수행되는가? 아니면 추가적인 빌드 단계가 필요한가? 얼마나 자주 퇴스트가 수행되는가? 얼마나 넓은 범위에 적용되는가? 테스트들은 적절하며 잘 구성되어 있는가? 테스트 범위에 포함된 것처럼 보이기만 하는 코드는 없는가?

좋은테스트를 포함하는 코드는 일반적으로 적절히 분류되고, 심사숙고되며, 제대로 설계된다. 이 테스트들은 대상이 되는 코드에 대한 훌륭한 가이드를 제공해줄 수 있다. 코드의 인터페이스나 사용 패턴을 쉽게 이해시켜줄 수 있다. 게다가 오류 수정 작업을 시작하기에 좋은 위치에 있다.

파일 구조

코드 형태와 어울리는가? 여러 영역, 하부 시ㅡ템들, 혹은 코드의 여러 계층을 명확하게 보여주는가? 간결한가? 서드파티 라이브러리들이 프로젝트 코드에서 간결하고 분리되어 있는가?

문서

실제로 존재하는가? 잘 작성되어 있는가? 최신 정보를 반영하고 있는가? 문서가 얼마나 이해하기 쉽게 최신 정보를 반영하고 있는 가?

정적 분석

코드의 건전도를 확인하고 코드 간의 관계를 확인하기 위해 도구를 사용하라. 

요구사항

최초의 프로젝트 욕사항 문서나 기능 명세서가 있는가? 공통적인 개념들을 모아둔 프로젝트 위키가 있는가?

프로젝트 의존성

코드에서 특정 프레임워크와 서드파티 라이브러리를 사용하는가? 그들에 대해 알기 위해 얼마나 많은 정보가 필요한가? 

코드에서 언어의 표준 라이브러리를 충분히 사용하고 있는가? 아니면 많은 부분을 직접 만들었는가?

직접 만든 콜렉션 클래스나 스레드관련 기능이 있다면 신중하게 살펴보아야 하낟. 시스템에서 제공하는 핵심 코드는 한결 견고하고, 잘 테스트되어 있으며, 버그가 없을 가능성이 크다.

코드 품질

코드상의 주석의 양이나 품질을 살펴보라. 죽은 코드가 많은가? 코드를 코멘트 처리해 작동하지 않게 썩혀두었는가? 코딩 스타일이 전반적으로 일관되어 있는가?

구조

주요 계층 들을 구분할 수 있는가? 그 계층 들이 간결하게 나뉘어 있는가? 아니면 서로 엉켜있는가? 데이터베이스 계층ㅇ이 있는가?

얼마나 적절해 보이는가? 스키마를 확인할 수 있는가? 그것은 적절한가? 앱은 외부 세계와 어떤 방법으로 대화 하는거? 어떤 GUI기술을 쓰는가? 어떤 파일 I/O 기술을 쓰는가? 어떤 네트워크 기술을 사용하는가

의문이 드는 코드에 대해서 소프트웨어 고고학을 수행하라. 버전 관리 도구의 로그를 확인하고, 똥 덩어리 코드들의 원천과 진화가정을 확인해 보자

과거의 코드와 관련해 작업했던 사람들이 얼마나 되는지, 얼마나 남아있는지 확인해 보자

3. 실행을 통해 배우기

코드를 올라타고, 운전해보고, 실수하며 떨어져 봐야 코드베이스에 대해 알 수 있다. 나태함에 발이 묶여 앞으로 나아가지 못해서는 안 된다. 코드를 다루지 못하게 만드는 심리적 장벽을 머릿속에 세워서는 안된다.

※ 코드를 배우는 가장 좋은 방법은 수정해보는 것이다. 그런 다음 실수를 통해 배워나가자

낮게 매달려 있는 과일

간단하고 사소한 일부터 도전해보자. 바로 확인해볼 수 있고 코드와 직접 관련이 있는 작은 버그를 찾아내는 것이다.

어마어마하게 복잡한 오류보다는 사소하고, 재현 가능하며, 위험성이 적은 오류 보고부터 시작하다.

코드 조사하기

코드 검증 도구들로 코드베이스를 확인하자. 컴파일러 경고가 꺼져 있는지 확인하자.

기능과 무관한 코드 변경 작업을 통해 코드의 각 요소가 어떻게 서로 들어 맞고 어울리는지 알 수 있다. 또 한 기존 개발자들의 근면성에 대한 멋진 가상을 얻을 수 있고, 코드의 어느 부분이 문제이고 특별히 살펴야 하는지도 확인할 수 있다.

확인한 뒤에 행동하자

코드의 작은 부분부터 확인하라. 그것을 비평하라. 취약한 부분이 있는지 확인하자. 가차 없이 리팩토링하자. 변수 명을 적절하게 변경하자. 들쭉날쭉 작성된 코드 부분을 더 작고 어울리는 이름의 함수들로 바꾸라.

이러한 실스블 통해 코드가 얼마나 수정하기 용이한지에 대한 감을 얻을 수 있다.

신중하자. 코드를 작성하는 것이 읽는 것보다 쉽다. 많은 프로그래머들은 기존 코드를 읽고 이해하기 보다는 "이런 코드라니, 우습군 " 하며 코웃음 치며 다시 만들어버리는 걸 선호한다. 이를 통해 더 깊이 있게 코드를 이해할 수도 있지만, 수많은 불필요한 코드 변동, 시간 낭비, 새로운 버그를 초래한다.

테스트부터 하라

테스트를 찾아보고 새로운 단위 테스트를 어떻게 추가 하는지 새로운 테스트 파일을 어떻게 추가 하는지 확인하자.

잡다한 일을 처리하자

사용자 인터페이스를 다듬어 바자. 몇 가지 간단한 UI개선 작업을 수행함으로써, 핵심 기능을 변경하지 않고도 사용하기 좀 더 ㅈ르겁게 만들라. 소스 파일을 정리하자. 디렉토리 구조를 적절하게 변경하자. IDE나 ㅍ로젝트 파일 내에서의 구성에 어울리도록 만들자

기록하라

최상위 수준의 READE문서가 존재 하는가? 

많은 프로그래머에게 README 문서 리뷰를 요청하자. 이를 통해 자신의 지식이 얼마나 정확한지 확인할 수 있고 새로운 사람들에게 도움을 줄 수 있다.

시스템에 대해 이해해 나가면서 코드의 주요 부분에 대한 계층 다이어그램을 작성하자. 

최신정보에 맞게 시스템을 계속 보완하자. 시스템 계층이 제대로 분리되어 있고, 계층 간에 명확한 인터페이스가 있으며, 필요없는 결합을 하지 않는가? 불필요하게 상호 연결된 코드 부분들이 있는가? 기존 기능을 변경하지 않으면서 인터페이스가 종속적이지 않도록 할 방법을 찾아보자

구조에 관해 설명하는 문서가 없다면, 지금 작성되는 문서가 그것이 도리 수 있다. 이를 통해 새로 들어오는 직원들에게 시스템에 대 한 설명을 해줄 수 있다.

경험이 쌓일수록 고통은 줄어들고 이득은 커진다. 코딩도 마찬가지이다. 새로운 코드베이스에서 더 많이 작업해볼수록 새로운 코드를 더 효과적으로 이해할 수 있다.