오늘 TIL 3줄 요약

• 결합도가 낮은 코드가 바꾸기 쉽다.

• 프로그램은 입력을 출력으로 바꾸는 것일 뿐이다.

• 상태를 쌓아 놓지 말고 전달하라.

• TIL (Today I Learned) 날짜

2022. 05. 21

오늘 읽은 범위

5장. 구부러지거나 부러지거나

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

• 5장의 주제는 다음과 같다.

  • 열차 사고(train wreck) : 연쇄 메서드 호출

  • 글로벌화 : 정적인(static) 것의 위험함

  • 상속 : 왜 클래스 상속이 위험한가?

• 결합은 두 개의 코드 조각이 무언가를 공유하면 언제나 일어날 수 있다. 여러분의 코드에서 나타나는 다음과 같은 결합의 증상을 놓치지 않도록 주의해야 한다.

  • 관계없는 모듈이나 라이브러리 간의 희한한 의존 관계

  • 한 모듈의 '간단한' 수정이 이와 관계없는 모듈을 통해 시스템 전역으로 퍼져 나가거나 시스템의 다른 곳에서 무언가를 깨뜨리는 경우

  • 개발자가 수정하는 부분이 시스템에 어떤 영향을 미칠지 몰라 코드의 수정을 두려워 하는 경우

  • 변경 사항에 누가  영향을 받는지 파악하고 있는 사람이 없어서 결국 모든 사람이 참석해야 하는 회의

• 묻지 말고 말하라. 이 원칙은 다른 객체의 내부 상태에 따라 판단을 내리고 그 객체를 갱신해서는 안 된다는 것이다. 객체의 내부 상태를 묻는 것으로 인하여 캡슐화의 장점은 완전히 사라지고, 또 그 과정에서 구현에 대한 지식이 코드 여기저기로 퍼져 버린다.

• Pp.185-187 코드 참조. 모든 애플리케이션에는 보편적인 최상위 개념들이 있기 마련이다. 예시한 애플리케이션에서는 고객과 주문이 최상위 개념이다. 주문을 고객 객체 안에 완전히 숨기는 것은 좀 이상하다. 따라서 주문 객체를 노출하는 API를 만들어도 문제 없다.

• '데메테를 법칙(Law of Demeter, LoD)'. 데메테르라는 프로젝트를 수행하는 도중 개발자들에게 보다 깨끗하고 결합도가 낮은 함수를 작성하는 방법을 알려주기 위해 만들어진 법칙

• 메서드 호출을 엮지 말라. 무언가에 접근할 때 "."을 딱 하나만 쓰려고 노력해 보라. '무언가에 접근'한다는 건 중간 변수를 사용하는 경우까지 포함해야한다.

• 여러분의 애플리케이션에 있는 것은 모두 바뀌리라 생각해야 한다. 외부의 라이브러리 역시 불안정하다고 여겨야 한다. 특히 라이브러리 관리자가 릴리스와 릴리스 사이에 API를 바꾼다고 알려져 있으면 더욱 더 그렇다.

• 코드를 처음 작성하는 시점의 제 1관심사가 코드 재사용이어서는 안 될 것이다. 그러나 코드를 재사용할 수 있도록  해야 한다는 생각이 코딩 습관의 일부가 되어야 한다. 코드를 재사용할 수 있게 하려면 깨끗한 인터페이스를 만들고 나머지 코드와의 결합을 없애야 한다. 그래야 나머지 것들이 우르르 딸려 들어오는 일 없이 메서드나 모듈을 뽑아낼 수 있다. 여러분의 코드가 전역 데이터를 사용한다면 나머지로부터 떼어 내기 힘들어질 것이다.

• 싱글턴(Singleton)도 전역 데이터다. 외부 리소스도 전역 데이터다.

• 결합된 코드는 바꾸기 힘들다. 코드의 한 곳을 바꾸면 다른 곳에 여파가 미칠 수 있다. 직접적으로 아는 것만 다루는 부끄럼쟁이 코드를 계속 유지하라. 그러면 애플리케이션의 결합도를 낮게 유지할 수 있을 것이고, 결과적으로 코드를 바꾸기 쉬워질 것이다.

• 이벤트는 무언가 정보가 있다는 것을 의미한다. 정보는 사용자가 버튼을 클릭하거나, 주가 정보가 갱신될 때처럼 외부에서 올 수 있다. 정보는 내부에서 생길 수도 있다. 어디에서 온 것이든 애플리케이션을 이런 이벤트에 반응하도록, 그리고 그에 기반해서 하는 일을 조절하도록 만들면, 진짜 세상에서 더 잘 작동하는 애플리케이션이 탄생할 것이다. 사용자들은 애플리케이션의 상호 작용이 더 원활하다고 느낄 것이고 애플리케이션 자체는 리소스를 더 효율적으로 사용할 것이다.

  • 유한 상태 기계

  • 감시자(observer) 패턴

  • 게시-구독

  • 반응형 프로그래밍과 스트림

• 자신이 하고 있는 걸 하나의 과정으로 서술할 수  없다면, 자기가 뭘 하고 있는지 모르는 것이다. - W. 에드워즈 데밍(W. Edwards Deming)

• 모든 프로그램은 데이터를 변환한다. 받은 입력을 출력으로 바꾼다. 하지만 우리는 설계를 고민할 때 변환을 만드는 것에 대해서는 거의 생각하지  않는다. 오직 클래스와 모듈, 자료 구조, 알고리즘, 언어, 프레임워크에 대해서만 걱정할 뿐이다. 우리는 이렇게 코드에만 집중하면 핵심을 놓칠 수 있다고 본다. 프로그램이란 입력을 출력으로 바꾸는 것이라는 사고방식으로 돌아갈 필요가 있다. <P.207>

• 프로그래밍은 코드에 관한 것이지만, 프로그램은 데이터에 관한 것이다.

• 상태를 쌓아 놓지 말고 전달하라.

• 데이터를 전체 시스템 여기저기의 작은 웅덩이에 흩어 놓는 대신, 데이터를 거대한 강으로, 흐름으로 생각하라. 데이터는 기능과 동등해진다. 파이프라인은 코드 -> 데이터 -> 코드 -> 데이터......의 연속이다. 데이터는 더 이상 클래스를 정의할 때처럼 특정한 함수들과 묶이지 않는다. 대신 우리 애플리케이션이 입력을 출력으로 바꾸어 나가는 진행 상황을 데이터로 자유롭게 표현할 수 있다. 이 말인즉슨 결합을 대폭 줄일 수 있다는 것이다. 어떤 함수든 매개 변수가 다른 함수의 출력 결과와 맞기만 하면 어디서나 사용하고 또 재사용할 수 있다.

• 상속도 일종의 결합이다. 자식 클래스가 부모 클래스, 부모의 부모, 또 그 부모에게 연결되는 것은 물론이요, 자식 클래스를 사용하는 코드도 이 클래스의 모든 조상과 얽히게 된다.

• 상속은 개발자들이 점점 더 메서드가 많은 클래스를 만들도록 유도한다. 부모 클래스에 메서드가 20개 있으면 하위 클래스는 그중 딱 두 개만 사용하고 싶더라도 필요 없는 18개의 메서드까지 함께 따라와서 자리를 차지하고 호출되기만을 기다린다. 클래스가 자신의 인터페이스를 제어할 수 없게 되는 것이다.

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

• 5장의 내용들은 2장에서 설명한 직교성과 큰 연관성이 있다고 느껴졌다. 5장의 예시들은 다소 과장되거나 극단적인 예시들이 아닌가 하는 의문이 있었다. 그러나 5장의 내용을 읽으면서 드는 생각은 종이 한장 한장은 유연할지 몰라도 그것들이 쌓이면 종이는 구부러지지 않고 찢어지는 것과 같다는 느낌이다.

• 데이터가 적을 때는 처리하는데 어떠한 방법이든 상관이 없어 보인다. 그러나 데이터가 점점 누적되어서 쌓였을 때는? 우리가 한 눈에 파악할 수 없을 만큼 데이터가 누적되었을 때는 어떻게 해야하는가? 우리가 파악하거나 추정할 수없는 부분에 대해서는 어떻게 해야 대처할 수 있는가?

• 책에서도 5장의 첫 부분에서 이야기 한다. "결합은 두 개의 코드 조각이 무언가를 공유하면 언제나 일어날 수 있다." 5장에서 받은 소감은 결합을 어떻게 하면 느슨하게 유지할 것인가. 보다 큰 문제를 예방하기 위해서는 우리는 어떻게 코드를 짜는 습관을 들여야 하는가에 대한 보다 상세한 조언이라고 느껴진다.

• P.183의 그림들을 참고하자. 두 개의 부품을 연결하는 것은 쉽다. 또 다른 부품과 다른 부품을 연결하는 것도 쉽다. 이 쉬운 작업들을 전체적인 맥락에서 어떻게 연결되는것인가 바라보는 것은 어렵다. 우리는 이 결합들이 어떻게 유기적으로 연결되고, 어떤 부분에서 결합되는지에 대해 프로그램의 덩치가 커질 수록 점점 파악하기 힘들어진다.

• 자바를 공부하면서 클래스를 배우고 상속에 대해서 배우면서도 상속이 훌륭한 방법의 일종이라는 생각은 했었지만, 부모 클래스에 대한 자식 클래스의 상속이 연속적으로 이어진다면 해당 코드들을 어떻게 파악해야 하는가라는 의문이 있었다. 특히 자식 클래스가 부모 클래스의 속성이나 메서드들을 재정의 한다면, 그것이 숨겨져 있다면 어떻게 파악해야 할 것인가 라는 개인적인 의문이 있었다.

• 5장을 읽으면서 느낀 것은 프로그래밍을 하면서 어떻게 보다 방어적으로 코딩할 수 있는 가에 대한 방법이라고 느꼈다. 4장에서 이야기한 DBC, 계약으로 코딩하라. 해당 방법이 상속에 대한 대안이 바로 인터페이스와 프로토콜이라는 생각이 들었다. 자식이 부모에게 물려받는 것 보다 해당 속성들을 가질 것을 명시해 두고, 해당 계약을 준수한 객체들을 활용해 프로그램을 만드는 것이 보다 안전하고, 결합을 줄일 수 있다는 방법이라는 생각이 들었다.

• 물론 한창 프로그래밍에 대해 배우고 있는 입장에서는 내가 경험하지 못한 부분이 있고, 내가 아직 몰라서 잘못 이해하는 것일거라는 생각이 든다. 그럼에도 불구하고 이 책이 내게 의미가 있는 것은 프로그래밍을 대하는 나의 태도에 있다는 생각이 든다. 보다 방어적으로 코딩하고, 주기적으로 큰 맥락에서 파악하라는 것. 그리고 관계에 대해서 고민하라는 것. 어떤 것이 보다 많은 상황에서 유연하게 대처할 수 있을까에 대한 고민하는 방법. 그리고 보다 나은 방법에 대해서.

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

• 5장의 예시 코드들에 대해서는 조금 더 시간을 들여 한번 실제로 프로그램을 짜 보거나 언급된 언어들에 대해서 간략하게나마 공부해봐야겠다는 생각이 든다.

• 무엇보다, 앞 장의 내용들과 5장의 내용들을 연관지어 한번 정리해보는 것이 내게는 조금 더 도움이 될 것 같다는 생각이 든다.

오늘 읽은 다른사람의 TIL