책과 영화,음악이야기/책

[책] 훌륭한 프로그래머 되는 법 - 경로 탐색하기

버리야 2016. 3. 2. 00:27
반응형

최근 환경이 바뀌어 새로운 환경, 시스템에 적응할 일이 있어 코드를 분석할때 느낀점을 '훌륭한 프로그래머 되는 법'(Becoming a Better Programmer) 책을 읽으며 공감한 부분이 있어서 정리해 봅니다.


'훌륭한 프로그래머 되는 법'(Becoming a Better Programmer) 6장 경로탐색하기 에서 발췌한 내용입니다..



경로 탐색하기. 

- 새로운 프로젝트에 투입되었을때 코드를 둘러볼 계획을 어떻게 세워야 했을까? 

  프로젝트에 투입된 최초 시점에서, 성과를 낼 수 있는 상태에 빠르게 도달하기 위해 어떻게 해야했을까?

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

  그래야 작업한 첫 번째 변경 사항이 다른 이들에게 당황스럽게 보이거나, 이미 있는 기능을 중복 구현하거나, 혹은 어딘가의 무언가에서 오작동을 발생시키지 않을 수 있다.

 

1. 친구들의 작은 도움

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

없다면, 온라인 포럼, 메일링 리스트, 커뮤니티를 찾아봐라.


2. 단서 찾기

도와주는 사람 없이 소프트웨어 시스템의 깊은 부분을 알아내야 한다면 코드 속 방향을 가늠하게 해주는 단서를 찾을것. 좋은 단서로는 다음과 같은 것이 있다.


- 소스 획득의 용이성

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

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

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


- 코드 빌드의 용이성

코드를 빌드하기 어렵다면 해당 코드를 이용해 일하기도 어렵다.

코드를 처음부터 빌드하기는 얼마나 쉬운 일인가? 코드 자체에 적저라고 간결한 문서가 있는가? 

소스 관리 시스템에서 코드를 받자마자 바로 빌드할 수 있는가? 아니면 빌드 전에 수많은 자잘한 설정 작업을 수작업으로 수행해야 하는가?

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


- 테스트

테스트를 찾아보라. 얼마나 많은 코드베이스가 테스트되고 있는가? 테스트는 자동으로 수행되는가? 아니면 추가적인 빌드 단계가 필요한가?

얼마나 자주 테스트가 수행되는가? 얼마나 넓은 범위에 적용되는가? 테스트들은 적절하며 잘 구성되어있는가?

좋은 테스트를 포함하는 코드는 일반적으로 적절히 분류되고, 심사숙고되며, 제대로 설계된다. 이 테스트들은 대상이 되는 코드에 대한 훌륭한 가이드를 제공해줄 수 있다.

코드의 인터페이스나 사용 패턴을 쉽게 이해시켜줄 수 있다. 게다가 오류 수정 작업을 시작하기에 좋은 위치에 있다.

예를 들어 실패하는 단위 테스트를 추가하고, 다른 부분을 망가뜨리지 않으면서 해당 테스트가 성공하도록 코드를 수정하면 된다.


- 파일 구조

디렉터리 구조를 살펴보라. 


- 문서

프로젝트 문서를 살펴보라. 실제로 존재하는가? 잘 작성되었는가? 최신 정보를 반영하고 있는가?


- 정적 분석


- 요구사항

최초의 프로젝트 요구사항 문서나 기능 명세서가 있는가? 이런 문서들은 최종 결과물과 거리가 먼 경향이 있으나 흥미로운 역사적 문서. 그밖에 공통적 개념들을 모아 둔 프로젝트 위키가 있는가?


- 프로젝트 의존성

코드에서 특정 프레임워크와 서드파티 라이브러리를 사용하는가? 

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

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


- 코드 품질

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


- 구조

주요 계층들을 구분할 수 있는가? 그 계층들이 간결하게 나뉘어 있는가?...

의문이 드는 코드에 대해서는 소프트웨어 고고학을 수행하라. 버전 관리 도구의 로그를 확인하라.


3. 실행을 통해 배우기

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


- 낮게 매달려 있는 과일

간단하고 사소한 일부터 도전해보라. 사소하고, 재현 가능하며, 위험성이 적은 오류 보고부터 시작하자.


- 코드 조사하기.

코드 검증 도구들로 코드 베이스를 확인하라.


- 확인한 뒤에 행동하라

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


- 테스트부터 하라.

테스트를 찾아보라. 새로운 단위 테스트를 어떻게 추가하는지, 새 테스트 파일을 어떻게 추가하는지 확인하라. 테스트를 어떻게 실행하는가?


- 잡다한 일을 처리하라.

사용자 인터페이스를 다듬어보라. 몇가지 간단한 UI 개선 작업을 수행함으로써, 핵심 기능을 변경하지 않고도 사용하기 좀 더 즐겁게 만들라. 

소스 파일을 정리하라. 디렉터리 구조를 적절하게 변경하라.


- 알아낸 것을 기록하라.

시스템에 대해 이해해나가면서, 코드의 주요 부분에 대한 계층 다이어그램을 작성하라. 최신 정보에 맞게 시스템을 계속 보완하라. 

시스템 계층이 제대로 분리되어 있고, 계층 간에 명확한 인터페이스가 있으며 필요없는 결합을 하지는 않는가? 

불필요하게 상호 연결된 코드 부분들이 있는가? 

기존 기능을 변경하지 않으면서 인터페이스가 상호 종속적이지 않도록 할 방법을 찾아보라.


구조에 관해 설명하는 문서가 없다면 지금 작성되는 문서가 그것이 될 수 있다.

이를 통해 새로 들어오는 직원에게 시스템에 대한 설명을 해줄수 있다.


4. 마치며

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




반응형