[TIL] Chapter 5. 구부러지거나 부러지거나

기차의 모든 객차가 서로 연결되어 있듯이 메서드나 속성들이 모두 연결되어 있는 코드를 '열차 사고 (train wreck)' 라고 부른다. (이것은 train wrek은 엉망진창이라는 뜻도 있다)
묻지 말고 말하라 (Tell, Don't Ask):
다른 객체의 내부 상태에 따라 판단을 내리고 그 객체를 갱신해서는 안 된다.
메서드 호출을 엮지 말라.
좋지 않은 방식:
amount = customer.orders.left().totals().amount;
코드를 재사용할 수 있도록 해야 한다는 생각이 코딩 습관의 일부가 되어야 한다. 코드를 재사용할 수 있게 하려면 깨끗한 인터페이스를 만들고 나머지 코드와의 결합을 없애야 한다. 코드가 전역 데이터를 사용한다면 나머지로부터 떼어 내기 힘들어질 것이다.
모든 프로그램은 데이터를 변환한다. (...중략...) 프로그램이란 입력을 출력으로 바꾸는 것이라는 사고방식으로 돌아갈 필요가 있다.
결합을 대폭 줄이는 좋은 방법은, 데이터를 거대한 강으로, 흐름으로 생각하는 것이다.
프로그래밍의 다른 모든 것과 마찬가지로 여러분의 목표는 의도를 가장 잘 드러내는 기법을 사용하는 것이어야 한다.

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

'상속세'라는 표현이 인상깊었다. 현재 회사의 업무에서는 OOP를 사용하지는 않지만, 객체 지향 프로그래밍을 처음 배웠을 당시 상속이라는 개념은 필수적으로 배웠고, 상속으로 인한 부작용 혹은 단점 등은 따로 배우지 않았기 때문에 상속은 당연하고 자연스러운 것이라는 인식이 있었다. 책에서 상속을 사용하게 됨으로써 생기는 단점을 알기 쉽게 설명해줘서 유익했다.
수비적인 코딩을 하는데 타입스크립트가 유리한 언어라는 것을 책을 읽어나가면서 다시 한 번 느꼈다.
'이렇게 짜면 서로 의존성이 높아져서 유지보수가 힘들어진다' 라는 코드 리뷰를 예전에 받았던 것이 생각났다. 앞으로 코드를 짤 때 결합도를 줄이는 것을 더 의식하게 될 것 같다.