ABOUT ME

-

Today
-
Yesterday
-
Total
-
  • 실용주의 프로그래머 22-28
    Study/실용주의 프로그래머 2021. 12. 8. 15:44
    반응형

    22. 죽은 프로그램은 거짓말을 하지 않는다

    일찍 작동을 멈추게 하라

    이번 장에서는 문제되는 코드가 계속 동작을 하는 것보다 일찍 종료되는 것이 낫다는 내용을 담고 있다.

    대다수의 프로그래머가 성공 케이스와 몇가지 정상 실패 케이스만을 생각하기 때문에 예상치못한 에러를 만날 수 있다.

    에러가 발생했을 때는 프로그램은 더이상 유효하지 않다고 보며, 잘못된 코드가 다른 문제를 일으키 전에 빠르게 멈추는 것이 최선이다.

    (자바 언어와 라이브러리에서는 이 철학을 포용하여 RuntimeException을 던져 시스템을 멈춘다. )

     

    +) 책에서는 이 내용을 "죽은 프로그램이 입히는 피해는 절름발이 프로그램이 끼치는 것보다 훨씬 덜한법이다" 라고 한줄로 정리한다.

     

    23. 단정적 프로그래밍

    단정문을 사용해서 불가능한 상황을 예방하라.

    어떤 변수에 자릿수나 범위를 가정할 때, 프로그래머의 임의로 생각하고 설계하는 경우가 있다. (예를 들면 연도의 자릿수나 count 변수에 음수 등)

    책에서는 이런 경우에 사용하는 가장 간단한 방법으로 단정문(assertion)을 소개한다.

    단정문은 값의 범위를 확인하거나 알고리즘의 동작을 검사하는 데 유용하다.

    단, 에러 처리용으로는 절대 사용하면 안되며, 단정문으로 다른 코드에 에러가 발생하지 않도록 주의하자.

     

    24. 언제 예외를 사용할까

    예외는 예외적인 문제에 사용하라.

    이펙티브 자바에서도 다룬 적이 있는 내용이다.

    예외는 정상적인 흐름에 사용하지 않고 정말 예외적인 상황에서만 사용해야 한다.

    책에서는 파일을 읽을 때 파일 존재 여부를 두고 아래와 같이 예시를 들고 있다.

    • 유닉스 시스템에서 반드시 존재해야하는 /etc/passwd의 경우는 예외를 던지는 것이 맞다.
    • 단순히 사용자가 지정한 파일을 열때는 파일이 없는 것이 가능한 상황이기 때문에 예외적인 경우가 아니다.

     

    25. 리소스 사용의 균형

    시작한 것은 끝내라.

    • 리소스는 할당한 루틴이나 객체가 리소스를 해제하는 책임도 져야한다. 리소스를 할당한 곳과 해제하는 곳이 다를 경우 각 루틴의 결합도가 올라가게 되고, 수정 시에 순서가 꼬여 리소스를 해지하지 못할 수 있다.
    • 리소스는 할당한 순서 반대로 해제하라 다른 곳에서 리소스를 참조하는 경우에도 리소스를 고아로 만들지 않는다.
    • 할당한 순서를 같게하면 데드락의 가능성이 줄어든다.

    +) 메모리릭을 탐지하는 라이브러리를 사용해서 참고하면 좋다 :)

     

    26. 결합도 줄이기와 디미터 법칙

    모듈간의 결합도를 최소화 하라

    스파이, 반체제자, 혁명가들은 종종 셀 (Cell)이라는 작은 그룹으로 조직을 만들고, 다른 세포와의 상호작용을 줄이고 각 세포를 보호한다.

    코딩에서도 코드를 셀(모듈)로 구성하고, 이들 간의 상호작용(결합도)을 줄이는 것이 좋다.

    그러면 한 모듈이 변경되거나 교체되더라도 다른 모듈들은 변경하지 않고 수행할 수 있다.

    결합도(의존도)가 올라간다면 시스템 어딘가의 무관한 변화가 코드에 영향을 미칠 수 있는 위험이 커진다.

    그러나 위에서 언급한 것 처럼 결합도가 낮다면 한 모듈에 이상이 생겨도 다른 모듈에는 영향을 끼치지 않는다.

    따라서 우리는 의존도를 최소화 하기 위하여 디미터 법칙을 사용하여 설계할 수 있다.

     

    디미터 법칙

    디미터 법칙에 따르면 객체의 모든 메서드는 다음에 해당하는 메서드만 호출해야한다.

    • 자신
    • 메서드로 넘어온 인자
    • 자신이 생성한 객체
    • 직접 포함하고 있는 객체

    디미터 법칙은 위임자에게 단순히 요청을 전달하는 메서드를 상당수 만들어야하는데,

    이는 성능저하와 메모리 과부화와 같은 문제를 야기할 수 있다.

    따라서 데이터베이스 스키마 설계시 반정규화를 통해 성능을 높이듯,

    디미터 법칙을 사용하지 않고 여러 모듈의 결합도를 높여 성능향상을 노릴 수 있다.

    그러나 이런경우가 아니라면 유연하지 않은 미래가 그려지기 때문에 결합도를 낮추는 설계를 연습하자.

     

    27. 메타프로그래밍

    통합하지말고 설정하라 = 세부 사항을 코드에서 몰아내고, 설정 가능하게 만들어야 한다.

    배경색, 프롬프트 텍스트, 알고리즘 선택, DB, 인터페이스 스타일 등 아이템들을 통합하지 말고 설정 옵션으로 구현해야한다.

    이는 메타데이터를 이용하여 어플리케이션 설정 옵션을 기술할 수 있다.

    메타데이터 주도 어플리케이션

    코드에는 추상화를, 메타데이터에는 세부 내용을

    책에서는 가능한 많은 메타데이터를 써서 어플리케이션을 설정하고 실행시키라고 한다.

    이로써 더 동적이고 적응가능한 프로그램을 만들고 많은 이점을 얻을 수 있다.

    (이점들은 비슷한 내용들이라 책을 참고하자.)

     

    28. 시간적 결합

    이 챕터에서는 시간에는 동시성. 순서라는 두가지 측면이 있으나,

    개발을 할때 직선적인 사고로 설계를 하게 되고 시간적 결합을 만든다고 설명한다.

    시간을 다룰때는 동시성을 허용해야하고 시간이나 순서에 따른 결합을 낮춘다면

    유연하고 여러 측면에서 의존성이 낮은 프로그램을 만들 수 있다.

    댓글