6장 : 코딩하는 동안 해야 할 일들

코딩은 기계적인 작업이 아니다.

프로그램이 정확하고 생산적으로 작동하기 위해 사려 깊은 생각과 판단을 통한 결정이 필요하다.

그렇지 않은 코드는 우연에 맡기는 프로그래밍으로 생산된 코드이다. 코드가 작동은 하지만 왜 작동하는지 설명을 못한다.

이 챕터에서는 프로그래머가 코딩 과정에서 더 적극적으로 행동하는 방법에 대한 내용이다.

 

📔우연에 맡기는 프로그래밍

행운과 어쩌다 오는 성공에 의존하는 프로그래밍을 하지 말아야 한다.

대신 의도적으로 프로그래밍을 해야 한다.

지금 잘 동작하는데 괜히 건드렸다 일을 만들 필요가 있을까?

 

건드려야 할 이유

1. 정말 제대로 돌아가는 것이 아닐지도 모른다.
   • 우리의 화면에서만 그런 것처럼 보일 수 있다.
2. 여러분이 의존하는 조건이 단지 우연인 경우도 있다.
   • 다른 상황(화면 해상도가 다른 경우)에서는 이상하게 작동할지도 모른다.
3. 문서화되지 않은 동작은 라이브러리의 다음 릴리스에서 변경될 가능성이 있다.
4. 불필요한 추가 호출은 코드를 더 느리게 만든다.
5. 추가로 호출한 루틴 때문에 새로운 버그가 생길 가능성이 있다.

 

우연에 맡기는 프로그래밍을 하지 말라.

애초부터 에러를 적게 하려면 의도적으로 프로그래밍하는 것이 도움이 된다.

• 자기가 지금 무엇을 하고 있는지 알아야 한다.
• 맹목적으로 코딩하지 말라.
  • 익숙하지 않은 기술을 사용하려고 시도하는 행위는 우연에게 맡기는 일이 될 가능성이 높다
• 계획을 세우고 그것을 바탕으로 진행하라.
• 신뢰할 수 있는 것에만 기대라.
  • 우연한 일이나 가정에 의존하지 말라
• 여러분의 가정을 문서로 남겨라
  • 다른 사람과 소통하는데 도움이 될 뿐만 아니라 자신의 가정을 명확하게 하는 데에도 도움이 된다.
• 코드만 테스트할 것이 아니라 여러분이 세운 가정도 테스트해봐야 한다.
  • 추측만 하지 말고 실제로 시험을 해보아라.
• 노력을 기울일 우선순위를 정하라.
  • 중요한 것들에 먼저 시간을 투자하라.
• 과거의 노예가 되지 말아라.
  • 기존의 코드가 앞으로 짤 코드를 억압하도록 하지 말아라.
  • 더 이상 적절하지 않은 코드라고 생각되면 어떠한 코드라도 교체할 수 있다.

 

📔알고리즘의 속도

일반적으로 입력의 크기는 알고리즘에 영향을 준다.

입력 크기가 클수록, 알고리즘의 수행 시간이 길어지거나 사용하는 메모리 양이 늘어난다.

대게 회사 일에서 정렬 루틴을 작성하는데 시간을 많이 쓰지 않는다.

왜냐면 이미 나와 있는 라이브러리에 들어있는 정렬 루틴이 여러분이 작성하는 것보다 성능이 좋을 것이다.

 

여러분 알고리즘의 차수를 추정하라.

입력값이 작을 경우 단순한 O(n²)가 복잡한 O(nlog(n))보다 더 좋은 성능을 내기도 한다.

 

여러분의 추정을 테스트하라.

가장 빠른 알고리즘이 언제나 가장 좋은 알고리즘은 아니다.

입력 데이터의 규모가 작을 경우 그 데이터를 준비하는 데 걸리는 시간이 알고리즘을 돌리는 시간보다 오히려 더 걸리는 일이 생기기도 한다.

 

 

📔리팩터링

프로그램이 발전해가면, 초기에 내린 결정을 다시 고려하고 코드의 일부분을 다시 작성하는 일이 점점 더 필요해진다.

이것은 지극히 자연스러운 과정이다

코드는 발전해야 한다

코드는 정적인 존재가 아니다.

리팩터링: 코드 다시 작성하기, 다시 설계하기를 총괄하는 단어 즉, 재설계

 

리팩터링은 언제 해야 하는가?

1. 중복되었을 때
2. 직교 성이 좋지 않을 때 더 좋게 만들 수 있는 코드 설계를 발견했을 때
3. 직교성 : 모듈 간의 독립성
4. 유효기간이 끝난 지식을 발견했을 때
5. 사물은 변하고 요구사항은 변경된다 코드는 지금 상황에 뒤 떨이지지 않게 유지되어야 한다.
6. 성능을 개선하기 위해서

 

잘 되던 코드를 변경하는 것은 고통스러운 작업이다!

하지만 리팩터링을 하지 않고 추가로 작업한다면 신경 써야 할 의존성이 더 많이 생기게 되고 결국 문제가 일어났을 때 고치기 위해서 훨씬 더 많은 시간을 투자해야 하기 때문이다.

리팩터링이 필요한 코드를 종양 이라고 생각하면 좋다.

종양이 작을 때 수술을 하는 것이 좋지 다른 곳으로 전이될 때까지 놓아두면 더 큰 문제가 일어나기 때문에 리팩터링은 중요하다.

 

일찍 리팩터링 하고, 자주 리팩터링 해라

천천히 신중하고 조심스럽게 해야 한다.

리팩터링은 손해보다 이득이 큰방향으로 가기 위함이다.

 

리팩토링 조언

1. 리팩터링과 새로운 기능 추가를 동시에 하지 말라.
2. 리팩터링을 시작하기 전 많은 테스트를 자주 돌려봐라 그러면 무엇이 망가졌을 때 재빨리 그 사실을 알 수 있다.
3. 단계를 작게 나눠서 신중하게 작업하라.

소프트웨어 엔트로피에서 배운 교훈인 "깨진 창문을 그대로 놓아두지 말라"라는 말을 명심해라.

 

 

📔테스트하기 좋은 코드

모듈을 통제된 환경에서 철저하게 테스트하고 나면 더 넓은 환경에서 그 모듈이 어떻게 행동할 것인지 더 감을 잡을 수 있다.

소프트웨어 단위 테스트란 어떤 모듈에게 이것저것 시켜보는 코드를 가리킨다.

일반적으로 단위 테스트는 일종의 인위적인 환경을 구축한 다음, 테스트할 모듈의 루틴들을 호출한다. 그런 다음 반환된 결과들을 이미 알고 있는 값과 비교해보는 것이다.

나중에 이런 모듈들을 모아서 조립할 때도 우리에게는 개별 부분이 기대대로 잘 동작할 것이라는 믿음이 있을 것이다.

 

계약을 잘 지키는지 테스트해보기

다양한 종류의 테스트 케이스들과 경계 조건들에서도 모듈이 약속한 대로 기능을 잘 수행하는지 테스트한다.

 

테스트를 염두에 두고 설계하라.

모듈을 설계할 때는 그것이 지켜야 할 계약과 계약을 지키는지 테스트하는 코드도 함께 설계해야 한다.

 

단위 테스트 작성하기

단위 테스트는 찾기 편한 곳에 위치해야 한다.

테스트 코드를 쉽게 접근할 수 있게 해 놓는 것은 후에 해당 코드를 사용할지도 모르는 개발자에게 좋은 자원 2가지를 주는 것이다.

1. 모듈의 모든 기능을 어떻게 이용해야 하는지 보여주는 예제
2. 후일 코드 변경 시 검증하기 위한 회귀 테스트를 구축할 수 있는 수단

테스트는 기술적이기라기보다는 문화적인 것이다.

 

 

📔사악한 마법사

자신이 이해하지 못하는, 마법사가 만들어준 코드는 사용하지 말라.

해당 코드의 주인은 자신이 아닌 것이다.

결국 유지보수도 못할 것이고 디버깅해야 할 때가 오면 고생하게 될 것이다.

누구든 자신이 완전히 이해하지 못하는 코드를 내놓아서는 안된다.