리팩토링 2판 - Chapter 9 (데이터 조직화)

이번에는 데이터 구조에 집중한 리팩토링을 다룹니다.

image_credit — Educative

데이터 구조는 단순히 값을 담아두는 공간이 아니라 프로그램을 더 잘 이해할 수 있도록 유도하는 역할을 해줍니다. 데이터 구조를 잘 선택하는 것만으로도 프로그램의 이해도를 높일 수 있다고 합니다. 알고리즘 문제를 풀다 보면 큐나 스택을 적절히 고르는 것만으로 문제가 쉽게 해결되는 것을 경험한 적이 있는데 실무에서도 동일하게 적용될 수 있을 것으로 기대됩니다.
데이터 구조가 중요한 만큼 반드시 깔끔하게 관리해야 한다. 다른 요소와 마찬가지로 개발을 진행할수록 데이터를 더 잘 이해하게 된다. 따라서 그 깊어진 이해를 프로그램에 반드시 반영해야 한다. p.334
앞선 챕터에서도 동일한 방향으로 저자는 말고 있는데, 깊어진 이해를 코드에 즉시 반영해야 한다는 것입니다. 아 저 구조는 다르게 하면 더 깔끔하게 이해할 수 있고 버그를 줄일 수 있겠구나 하고 뒤늦게 발견한 적이 있었는데, 시간이 부족하다는 이유로 리팩토링을 멈추게 되었던 경험이 있습니다. 더 많은 오류를 만들어내지 않을까 하는 두려움 때문인데 테스트 코드가 절실하다는 것을 다시 깨닫게 되었습니다.

가변 데이터 유효 범위를 가능한 한 좁여야 한다고 힘주어 주장해본다. p.338
가변 데이터를 다룬다는 것은 객체에 긴장감을 조성하는 행위라고 생각합니다. 코드를 변경했을 때 가변 데이터도 변경되지 않았는지 체크를 해줘야 하기 때문에 신경을 곤두세워서 프로그래밍을 하게 됩니다. 신경이 곤두서면 작업하고자 했던 본래의 목적을 잊어버리게 되는 경우가 있습니다. 그래서 이런 가변 데이터를 가능한 줄이는 것이 좋은데, 데이터를 변경하는 것 대신에 함수 안에서 계산해서 return 값으로 처리하는 것이 좋습니다.

필드를 값으로 다룬다면 내부 객체의 클래스를 수정하여 값 객체(Value Object)로 만들 수 있다. 값 객체는 대체로 자유롭게 활용하기 좋은데, 특히 불변이기 때문이다. p.343
Value Object를 알게된 것은 작년쯤이었던 것 같습니다. 이전까지는 객체지향에 대해 깊이 있게 공부를 해보지 못해서 그랬는지 존재조차도 알지 못했었습니다. 실무에서 네이버 카페 코드를 다루면서 카페마다 유니크한 값이 있는데 그것을 Int로 다루고 있었습니다. CafeId 라는 Value Object로 감싸서 다루는 코드를 시니어 분이 작업해주셨고 그것을 통해서 안정성이 키워지는 것은 물론이고, 다양한 기능을 할 수 있는 것을 알게 되었습니다. Value Object를 기준으로 파생될 수 있는 기능들을 해당 객체에 몰아넣을 수 있기 때문에 흩어져 있던 코드가 간결해지는 경험을 할 수 있었습니다.

9.4 소챕터에서 설명하는 값 객체는 불변성에 좀 더 집중하고 있습니다. 가변 데이터인 경우 다른 곳에서 값을 변경하지 않을까 걱정해야 하는 반면 값 객체를 통해서 불변 상태로 만들어두면 안심할 수 있습니다.

논리적으로 같은 데이터를 물리적으로 복제해 사용할 때 가장 크게 문제 되는 상황은 그 데이터를 갱신해야 할 때다. 모든 복제본을 찾아서 빠짐없이 갱신해야 하며, 하나라도 놓치면 데이터 일관성이 깨져버린다. 이런 상황이라면 복제된 데이터들은 모두 참조로 바꿔주는 게 좋다. P.347
앞의 소챕터와 반대로 이번에는 값을 참조로 바꾸고 있습니다. 데이터의 일관성이 필요한 경우에 참조로 바꿔야 할 수 있습니다. 불변성을 유지하는 것이 항상 정답은 아니라는 것을 알 수 있습니다.

우노스