신입 개발자 생존의 기술 : 전문적인 프로그래밍

해당 게시글은 <신입 개발자 생존의 기술 : 지속적 성장을 위한 33가지 실천법>을 읽고 공부한 내용을 정리한 것입니다.

저작권 문제가 발생할 시 해당 글은 삭제됩니다 :<

개발자는 품질을 향한 두 가지 접근법 중 하나를 선택할 수 있다.

• 처음부터 품질을 고려하며 만들어 나가거나
  • 날마다 코드를 짜면서 많은 수련을 필요로 한다
• 일단 만들고 나서 다듬는 것
  • 많은 테스트를 필요로하며 일반적으로 선택되는 방법(폭포수 개발 방법론)

코드를 담금질하라

• 코드 검토
  • 짝 프로그래밍
• 단위 테스트
• 인수 테스트
• 부하 테스트

• 통제된 탐색적 테스트

  • 인수 테스트에서 놓친 부분들을 찾기 위한 테스트

• 기관 테스트

• 환경 테스트
  • 화이트 박스 테스트
    • 프로그램 내부를 보면서 모든 것이 제대로 작동하는지 지켜보기
  • 블랙 박스 테스트
    • 소비자 시각으로 제품을 바라보며, 외부적으로 올바르게 작동하는지만을 측정
• 호환성 테스트
• 장기 테스트
• 베타 테스트
• 지속적 테스트
• 행동 또는 마음가짐
  • 견고한 코드를 만드는 데 헌신하라
  • 품질을 위한 일련의 행위들은 수단일 뿐이다

정확성을 고집하라

격리와 사이드 이펙트

프로그램에는 두 개의 코드가 섞여있음을 명심

• 순수한 코드
• 순수하지 않은 코드

함수 하나는 단 하나의 작업만을 수행하도록 설계되어야 테스트가 쉽다

인터렉션

• 단위 테스트는 사용하지 않는 파일 핸들(ex.데이터베이스의 객체)을 남겨두어 시스템 상태를 오염시키면 안된다
• 목 객체
  • 시스템 상태를 오염시키지 않기 위해 사용하는 테스트 전용 객체
  • 프로그래밍하며 기대했던 것을 확인시켜 줌

타입 시스템

• 정적 타입은 함수의 적절한 사용 목적을 전달하는데 도움

• 부적절한 사용의 안전 장치 제공

  • 계약 주도 단위 테스트

• 언어 타입 시스템에 상관없이 각 파라미터의 예상 값을 문서로 기록해두길 권장

‘확인 범위 100%’의 오해

• 확인 범위
  • 단위 테스트를 실행하여 애플리케이션의 코드의 몇 %가 실행되었는지 파악하는 것
  • 100%가 되었다 하더라도 안심하지 말 것
  • 100%가 안된다는 것
    • 몇 가지 경우를 테스트하지 않았다는 것
      • 단위 테스트를 하기 극단적으로 어려운 경우

실천하기

• 단위 테스트 프레임워크 찾아보기
  • 기본 도구
    • 단정, 테스트 셋업, 해제
    • 가짜 객체를 위한 기능

테스트로 설계하라

• 테스트의 목적
  • 외부 컴포넌트와 상호 작용하는 코드를 위해 대충대충 모킹을 할 수 있어 손쉽게 변경할 수 있도록 함
  • 모듈 스타일의 설계를 자동으로 하게 한다
  • 실수로 어떤 것도 망가뜨리지 않게 보장

명세로서의 테스트

각 함수가 해야할 일에 대해 구체적인 생각이 생기는 시점에 명세하기

• 함수가 잘 작동하려면 정확하게 무엇을 해야 하는가?
• 무엇을 하면 안 되는가?
• 어떻게 실패하는가?

과도한 테스트

• 함수의 행위를 구체적으로 보여줄 수 있는 것들을 테스트할 것
  • 성공 사례
  • 에러
• 단위 테스트는 명세로서 가치가 있기 때문에 추가적인 잡동사니가 있다면 읽는 사람이 명세의 중요 부분을 파악하기 어려움
• 코드의 모든 라인은 잠재적으로 버거의 소지가 있기에 테스트 코드 디버깅은 하지 말 것
• 모듈 인터페이스를 바꾸기로 했으면 변경을 위한 테스트도 갖춰야 함

복잡성 다스리기

• 복잡성의 원인
  • 필연적인 것
    • 문제 도메인 영역 고유의 것
  • 우발적인 것

죽음의 복잡성 나선

제품 코드 베이스에서 우발적 복잡성이 필연적 복잡성을 서서히 압도하다 못해 어느 순간 스스로 증폭하는 현상

• 기능 추가
• 복잡도 증가
• 버그
• 임시 조치
• 복잡도 증가

• 코드의 크기가 너무 큰 경우
• 복잡하고 어지러운 아이디어
• 버그
• 임시 조치
  • 근본 원인을 찾는 것보다 문제를 해결하는데 급급

LOC

좋은 프로그래머는 특정 버그에 대해 우아한 해결책을 찾아내기 마련이고 단순 무식한 해결책에 비해 더 적은 LOC를 사용하는 경향이 있어 잘못된 측정 방법이다

LOC는 진행이 아닌 규모를 측정하는 것

LOC를 추가한다는 것은 앞으로의 개발에 부담을 준다

명확성을 향하여

명확한 사고

• 복잡성 격리나 모듈 요약 이용
  • 모듈식 설계
    • 프로그램 나머지가 시스템의 내부는 모르면서 명확한 방식으로 시간에 대응할 수 있게 함
• 제일 좋은 방법은 분리된 테스트와 함께 하는 것
  • 동료 검토, 명세 작성으로도 증명 가능

명확한 표현

• 만들어지는 프로그램의 목적을 명확히 할 것
• 문제 도메인을 다루는 코드는 문제 도메인에만 집중
  • 코드가 말하려고 하는 것은 무엇인가
  • 좀 더 분명하게 말할 방법은 없을까

실천하기

• 격리할 수 있고 엄격한 판단이 가능한 프로그래밍의 한 가지 측면에 초점
• 프로젝트 내에 모듈로 분리한다면 더 명확해질 수 있는 부분을 찾을 것
• 자세한 내용을 걱정하지 말 것
  • 필요한 비지니스 로직을 얼마나 명확하게 표현할 수 있는지에만 집중

우아하게 실패하기

코드가 실패하는 방법은 코드가 동작하는 방법만큼 중요하다. 실패를 고치지 못할 수도 있지만 적어도 코드가 우아하게 실패하도록 노력해야 한다.

• 작동순서
• 트랜젝션
• 실패주입
  • 자동화된 테스트 하네스를 이용해 실패를 주입
  • 목 오브젝트 프레임워크와 함께 쓸 것
• 테스트멍키

스타일에 신경 쓰라

스타일 있게

• 클래스, 메서드, 변수, 파일 등의 명명
• 파일과 파일 사이의 함수 배치
• 주석
  • 이 코드의 역할
  • 어떤 파라미터와 리턴 값을 예상하는가
  • 잠시 기억해야 할 일
  • 파일의 저작권과 라이선스
• 괄호와 대괄호
• 제어 구조 선택
  • 종료와 예외를 처리하는 관습
• 대문자 사용
• 들여쓰기와 기타 공백

레거시 코드를 개선하라

• 이음매 찾기
  • 기능을 조금씩 뜯어 모듈화
• 새로운 플랫폼과 언어로 전환
  • 가능하다면 이전 프로그램의 부속을 재사용해 마이그레이션 위험을 억제
• 버그 또는 형편없는 사양
  • 버그와 그냥 이상한 것을 분리할 것

처음부터 코드 검토를 자주 하라

• 코드리뷰
• 임시 검토
• 페어 프로그래밍
• 높은 수준의 검토
  • 설계와 그 설계를 코드로 어떻게 구현했는지 설명 후 코드의 주요 부분 검토
• 감사
  • 왜 이런 설계를 선택했나
  • 이 가정을 증명하기 위해 어떤 데이터를 갖고 있는가
  • 구현이 올바른지 어떻게 테스트할 것인가
  • 실전에서 얼마나 효율을 낼 수 있을까
• 코드 리뷰 정책
• 실천하기
  • 변경 사항을 스스로 살펴보고 모든 것을 설명할 수 있는지 확인