2 분 소요

범위

~7장 코딩하는동안

내용

요약

  • 테스트를 안하면 처음 코드를 사용하는 사용자가 유저일 수있다.
  • 끊임없이 노력하라
  • 리팩터링

7장. 코딩하는동안

적극적으로 자기코드에 대해 생각하라

파충류의 뇌에 귀 기울이기

우리 뇌는 프로그래머로서 경험이 늘어갈 수록 암묵적인 지식이 켜지며, 본능으로 인지하게 되어있다.

백지의공포

첫번째의 일을 하기 어려워한다.

  • 본능적인 의심
  • 실수에 대한 합리적인 두려움

자신과 싸우기

파충류와 이야기하는법

  • 하고있는 일을 멈춤
  • 일을 표면으로 끄집어 내어 프로토 작성

놀이시간이다!

프로토타이핑 후 코드를 반영

여러분의 코드 뿐만 아니다

다른사람들의 패턴을 참조하라

코드뿐이 아니다

직감이 이상하면 분석하고 귀를 기울여라

우연에 맡기는 프로그래밍

우리는 지뢰밭에서 일하기 때문에 잘못된 결정을 내리지 않게 주의해야된다

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

근거 없는 확신을 하지말고 코드가 왜 돌아가는지 이해하여야 한다.

구현에서 생기는 우연

우연으로 돌아가는 코드들일 수 있다. 문서화된 동작에만 의존하라

비슷하다고 괜찮을 리는 없다

유령패턴

가정하지마라, 증명하라

상황에서 생기는 우연

암묵적인 과정

확고한 사실에 근거하지 않은 가정은 어떤 프로젝트에서든 재앙의 근원이 된다.

의도적으로 프로그램이 하기

  • 하는 일을 정확히 인지
  • 코드를 설명하기
  • 자신도 잘 모르는 코드를 만들지 말라
  • 계획을 세우고 바탕으로 진행
  • 신뢰할 수 있는 것에만 기대라
  • 기록으로 남겨라
  • 세운 가정들도 테스트해보아야 한다
  • 노력을 기울일 대상의 우선순위를 정하라, 먼저 시간이다.
  • 과거의 노예가 되지말라. 즉 언제라도 리팩터링할 자세가 되어야 한다

알고리즘의 속도

알고리즘을 추정한다는 의미

대문자O표기법

상식으로 추정하기

글에 담기 어려워 읽었으나, 다시 한번 읽어야겠다

리팩터링

소프트웨어 개발은 건축보단 정원가꾸기다.

리팩터링: 밖으로 드러나는 동작은 그대로 유지한 채 내부 구조를 변경함으로써 이미 존재하는 코드를 재구성하는 체계적 기법

  • 이 활동은 체계적이다. 아무렇게나 하는 것이 아니다.
  • 밖으로 드러나는 동작은 바뀌지 않는다. 기능을 추가하는 작업이 아니다.

리팩터링은 언제하는가?

  • 무언가를 알게되었을때
  • 장애물에 부딪혔을때
    • 중복
    • 직교적이지 않은 설계
    • 더이상 유효하지 않은 지식
    • 사용사례
    • 성능
    • 테스트 통과

현실세계의 복잡한 문제들

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

리팩터링이 코드에 미칠 영향을 인지하여야 한다.

리팩터링은 어떻게 하는가?

  • 리팩터링과 기능 추가를 동시에 하지말라
  • 리팩터링을 시작하기 전 든든한 테스트가 있는지 확인하라
  • 단계를 작게 나누어서 신중하게 작업하라

테스트로 코딩하기

테스트는 버그를 찾기 위한 것이 아니다.

테스트에 대해 생각하기

테스트가 코딩을 주도한다

테스트가 코드의 첫번째 사용자다.

다른코드와 긴밀하게 결합된 함수나 메서드는 테스트하기 어렵다.

테스트하기 좋게 만든 코드는 결합도도 낮아진다.

테스트 주도 개발

TDD 기본주기

  • 작은 기능 하나를 결정
  • 기능이 구현되었을 때 통과하게 될 테스트를 하나 작성
  • 테스트를 실행
  • 실패하는 테스트를 통과시킬 수 있는 최소한의 코드 작성
  • 코드 리팩토링

TDD: 목표가 어디인지 알아야한다.

다시 코드로

단위테스트

계약을 지키는지 테스트하기

테스트 할 수 있도록 설계하라

임시테스트

테스트 접점 만들기

테스트 문화

속성기반테스트

계약,불변식,속성

코드에 존재하는 계약과 불변식을 뭉뚱그려서 ‘속성’이라고 부르며, 속성을 찾아내 테스트하 자동화에 사용할 수 있는데 이것을 속성기반 테스트라 한다.

테스트 데이터 생성

잘못된 가정 찾기

속성기반테스트는 우리를 자주 놀래킨다

속성기반테스트는 설계에도 도움을 준다

바깥에서는 안전에 주의하라

  • 공격 표면을 최소화하라
    • 코드의 복잡성은 공격 매개채를 유발한다
    • 입력데이터는 공격매개채다.
    • 인증이 없는 서비스는 공격 매개채다.
    • 인증을 요구하는 서비스도 공격 매개채다
    • 출력 데이터는 공격 매개채다
    • 디버깅 정보는 공격 매개차다
  • 최소 권한 원칙
  • 안전한 기본값.
  • 민감한 정보를 암호화하라
  • 보안 업데이트를 적용하라

이름 짓기

끊임없이 노력하라

문화를 존중하라

일관성

이름바꾸기는 더 어렵다

마치며

7장은 개발자한테 실제로 도움이 많이 되는 내용들이 적혀있다. 프로젝트 유지보수 하는 중에 소스 리팩터링을 끊임없이 지속하여 소스를 개선한 적이 있었다. 리팩토링하면서 제일 힘들었던 것은 우연으로 돌아가는 코드를 고치는게 제일 힘들었다. 부분적으로는 정상적이나 오류로 인해 정상으로 돌아갔던 코드들이 문제를 일으켰었다. 그로인해 장애도 한 번 경험했었는데 그때는 진짜 소스가 하나의 폭탄 같이 느껴져서 너무 만지기가 싫었다. 그때 이 책을 읽었으면 좀 더 수월하게 하지 않았을까 생각이 들었다.

그리고 정말 공감이 가는건 테스트하기 좋은 코드는 정말 좋은 코드이다. 무엇보다도 책에서는 현실적으로 말해주는게 정말 좋았다. 나에게 필요한건 시간이다. 프로젝트 기한내에서 구상하여 변경한다는것이 많은 도전이 된다.

댓글남기기