[TIL 2] 실용주의 프로그래머 #2. 실용주의 접근법

오늘 TIL 3줄 요약

• 중복 코드는 악이다.
• 바꾸기 쉬운 코드를 작성하자.
• 직교성을 가진 코드를 작성하자.

TIL (Today I Learned)

2022.03.20

오늘 읽은 범위

2장 실용주의 접근법 p37 - p71

책에서 기억하고 싶은 내용을 써보세요.

좋은 설계의 핵심

• 좋은 설계는 나쁜 설계보다 바꾸기 쉽다.
• 바꾸기 더 쉽게 (Easier to Change)
• 단일 책임 원칙이 유용한가? 요구 사항이 바뀌더라도 모듈 하나만 바꿔서 반영할 수 있기 때문이다.
• 이름이 좋으면 코드가 읽기 쉬워지고, 코드를 바꾸려면 코드를 읽어야 하기 때문이다.

=> 프로그래밍을 하다보면 변하는 요구사항에 맞춰 기존의 설계를 다시 바꿔야 하거나, 추가하는 것만으로 끝나는 경우가 있다. 이런 상황에 대응하기 위해 설계나 코드를 작성하더라도 좀 더 와닿는 이름, 하나의 모듈은 하나의 책임만을 갖도록 설계해야겠다. 어떤 하나의 코드를 수정하더라도 다른 코드에 영향이 가지 않도록..

DRY 중복의 해악

• 소프트웨어를 신뢰성 높게 개발하는 유일한 길, 개발을 이해하고 유지 보수하기 쉽게 만드는 유일한 길은 우리가 DRY라 부르는 원칙을 따르는 것
• 모든 지식은 시스템 내에서 단 한 번만, 애매하지 않고, 권위있게 표현되어야 한다.
• DRY는 지식의 중복, 의도의 중복에 대한 것이다. 똑같은 개념을 다른 곳 두 군데에서 표현하면 안 된다는 것이다.
• 두 함수는 각각 서로 다른 것을 검증하고 있지만, 우연히 규칙이 같은 것뿐이다. 이것은 우연이지 중복이 아니다.
• 모듈이 자료 구조를 노출하면 언제 모듈의 구현과 그 자료 구조를 사용하는 코드 사이에 결합이 생긴다. 가능하다면 언제나 객체의 속성을 읽고 쓸 때 접근자(accessor) 함수를 사용하라.

=> 소스 코드를 작성하다보면 비슷한 일을 하는 곳에 코드를 붙여 넣는 경험을 한 적이 있을까? 책에서 코드가 동일하지만, 두 함수가 표현하는 내용이 다른
경우에는 중복이 아니라고 한다. 사실 나는 그동안 비슷한 일로 보이면 무지성으로 코드를 붙여 넣곤 했다. 앞으로는 우연일지라도 비슷해보인다면 코드를 복사+붙여넣기하는 습관을 없애야 겠다.

직교성

• 직교성은 설계와 빌드, 테스트, 확장이 쉬운 시스템을 만드는 데에 있어 매우 중요한 개념이다.
• 관련 없는 것들 간에 서로 영향이 없도록 하라.
• 직교적인 접근법은 재사용성도 촉진한다.
• 직교적인 접근법은 모든 개발 작업에 존재할 수 밖에 없는 위험의 크기를 감소시켜 준다.
• 계층 구조는 직교적 시스템을 설계하는 강력한 방법이다.

=> 직교성은 컴퓨터 과학에서 일종의 독립성이나, 결합도 줄이기를 의미한다고 한다. 하나가 바뀌어도 나머지에 어떤 영향도 주지 않으면 서로 직교한다는 것인데, 나는 처음에는 직교성을 가진 코드를 만들다가도 어느새 결합도가 높은 코드를 만들고 있는 자신을 발견한다. 항상 의식적으로 직교성을 생각하여 재사용성이 뛰어나고, 리스크 없는 코드를 만들도록 노력해야겠다.

코드를 작성할 때마다 여러분은 애플리케이션의 직교성을 떨어트릴 위험을 감수하는 셈이다.

• 부끄럼쟁이 코드를 작성하라. 즉, 불필요한 것은 다른 모듈에 보여 주지 않으며, 다른 모듈의 구현에 의존하지 않는 코드를 작성하라.
• 코드가 전역데이터를 참조할 때마다 코드는 해당 데이터를 공유하는 다른 컴포넌트와 묶이게 된다.
• 시작과 끝에서는 동일한 코드를 사용하지만, 중간의 알고리즘이 다를 것이다. 전략 패턴을 사용하여 더 낫게 구현할 수는 없는지 고민해 보기 바란다.

=> 코드를 작성할 때는 필요한 기능만을 외부에 노출시키고, 외부에서 필요한 데이터만을 공개하며, 중복되는 코드에 대해서 적용해 볼 만한 디자인패턴은 없는지 고민하고 실행해보아야겠다.

테스트

• 직교적으로 설계하고 구현한 시스템은 테스트하기 더 쉽다.
• 단위 테스트를 빌드하고 실행하기 위해 어떤 작업이 필요한가? 나머지 시스템 중 상당 부분을 불러와야 하지는 않는가? 만약 그렇다면 모듈과 나머지 시스템 사이의 결합도를 충분히 줄이지 못했다는 뜻이다.

=> 테스트는 빠르게 내가 만든 기능이 제대로 동작하는지 알 수 있는 좋은 방법이다. 하지만 기능 하나를 테스트 하기 위해 연관된 다른 모듈의 기능을 불러온 뒤에 한 경험이 많다.(대부분 그랬다.) 매번 이런 과정이 반복되다보니 테스트 하는 것은 항상 귀찮고 따분한 일이 되었다.(그렇다고 안 하지는 않는다.) 기능을 테스트 하기 위해 다른 모듈을 불러와야 한다는 것은 그만큼 그 모듈과의 결합도가 높음을 뜻한다. 결합도를 줄이는 방법으로는 무엇이 있을지 고민해보아야겠다.

유연한 아키텍처

• 여러분이 할 수 있는 것은 바꾸기 쉽게 만드는 것이다.
• 외부의 API를 여러분이 만든 추상화 계층 뒤로 숨겨라.
• 코드를 여러 컴포넌트로 쪼개라.

=> 내가 작성한 코드는 항상 변경에 유연하고, 인터페이스와 통신하여 클래스에 직접 의존하지 않으며, 기능을 만들 때는 그 세부 사항을 작은 여러개의 함수로 쪼개는 연습을 해야 겠다.

오늘 읽은 소감은? 떠오르는 생각을 가볍게 적어보세요

• 좋은 설계를 바탕으로 좋은 코드를 작성해야 한다는 생각이 든다. 사실 나는 그동안 프로그래밍을 하면서 직교성을 가진 코드를 작성해야 겠다는 생각은 많이 했었다.(생각만 했다.) 이번 장을 읽으면서 또 다시 생각만 하지 말고, 의식적으로 항상 직교성을 가진 코드를 작성하자는 다짐을 하게 되었다. 직교성을 가진 코드를 만든다면 지루하고 따분한 테스트 코드 작성도 즐거운일로 변하지 않을까하는 기대를 가져보면서..

궁금한 내용이 있거나, 잘 이해되지 않는 내용이 있다면 적어보세요.

• 우리 개발자는 매일같이 어제 요구한 사항과 오늘 요구하는 상황이 다른 현재를 살아가고있다. 결정이 바뀌지 않을 것이라 가정하고서 미래에 발생할지도 모를 우연한 사건에 대비하지 않은 데에서 실수가 나온다고 하는데, 다가오지 않을 미래를 대비하는 코드를 어떤것이 있을까? 또 어떻게 작성해야 할까? 오늘 고민해볼 필요가 있는 내용이다.