[파이썬클린코드]3장. 좋은코드의 일반적인 특징

파이썬 개발지침 약어

중복금지 (DRY, OAOO)

• Do not Repeat Yourself, Once only once
• 코드에 있는 지식은 단 한번, 단 한곳에 정의되어야한다.
• 그렇지 않을경우
  • 오류 발생이 쉬워진다 (여러 반복중에 하나라도 빠트리면 버그발생)
  • 비용이 비싸다 (변경에 더 많은 시간이 쓰이게 될 것)
  • 신뢰성이 떨어진다 (여러 코드를 변경해야하는 경우 사람이 모든 인스턴스의 위치를 기억해야하게 됨)

과잉 엔지니어링 금지 (YAGNI: You ain’t gonna need it)

• 유지보수가 가능한 소프트웨어를 만드는 것은 미래의 요구사항을 예측하는 것이 아니다
• 오직 현재의 요구사항을 잘 해결하기 위한 소프트웨어를 작성하고 가능한 나중에 수정하기 쉽도록 작성하는 것이다.

KIS(keep it simple)

• 디자인이 단순할수록 유지 관리가 쉽다.

EAFP(Easier to ask forgiveness than permession) vs LBYL(Look before you leap)

• 실제로 동작하지 않을때 대응한다 vs 도약하기 전에 무엇을 사용하려고 하는지 확인한다.
• 파이썬은 EAFP 방식으로 만들어졌고, 그렇게 사용할 것을 권한다

#이것보단
if os.path.exists(filename):
  with open(filename) as f:
    ...

#이렇게 쓸 것.
try:
  with open(filename) as f:
    ...
except FileNotFoundError as e:
  logger.error(e)

계약에 의한 디자인

• 관계자가 기대하는 바를 암묵적으로 코드에 삽입하는 대신 양측이 동의하는 계약을 먼저 한 다음 계약을 어겼을 경우는 명시적으로 왜 계속할 수 없는지 예외를 발생시키라는 것.
• 계약 작성이 필요하고 단위테스트 추가해야할 수도 있으나 품질은 장기적으로 보장된다.

방어적 프로그래밍

• 에러핸들링
  - 값대체
  • 예외처리
    • 함수에 예외가 많을수록 호출자가 호출하는 함수에 대해 더 많은 것을 알아야만한다(호출할때마다 발생가능한 부작용을 염두에 두고 문맥을 유지해야하기 때문)
    • 처리할 예외가 많다는건 응집력이 약하고 너무 많은 책임을 가지고 있다는 의미인 것. → 함수를 분리한다 (event connection 맺는 일과 send를 하면서 event parameter value 를 확인하는 함수)
    • The zen of python
      • 예외는 조용히 처리되어선 안된다, 보다 구체적 예외를 사용해야한다.

관심사의 분리

• 책임이 다르면 컴포넌트, 계층 또는 모듈로 분리되어야한다.
• 파급효과를 최소화하여 유지보수성을 향상시키기 위한 것.
  • 파급효과 : 어느 지점에서의 변화가 전체로 전파되는 것.
• 나머지 부분에 대한 영향성을 최소화하면서 코드를 수정하거나 리팩토링 하고싶다면 적절한 캡슐화가 필요하다
• 응집성과 결합성
  • 응집성 : 객체가 작고 잘 정의된 목적을 가져야하며 가능하면 작아야한다.
  • 결합성 : 두 개 이상의 객체가 어떻게 의존하는지를 나타냄. (객체 또는 메서드의 두 부분이 서로 너무 의존적이라면 바람직하지 않다)
    • 너무 의존적일경우의 부작용
      • 낮은 재사용성 : 만약 어떤 함수가 특정 객체에 지나치게 의존하는 경우 또는 너무 많은 파라미터를 가진 경우 이 함수는 해당 객체에 결합되게 된다. 즉 다른 상황에서는 이 함수를 사용하기가 매우 어렵다.
      • 파급효과 : 너무 가깝게 붙어 있게 되면 두 부분 중 하나를 변경하면 다른 부분에도 영향을 미친다.
      • 낮은 수준의 추상화 : 두 함수가 너무 가깝게 관련되어 있으면 서로 다른 추상화 레벨에서 문제를 해결하기 어렵기때문에 관심사가 분리되어있다고 보기 어렵다.