Five Lines of Code - 11. 코드 구조 따르기

주제: 제어 흐름에 행위(동작)를 인코딩하고, 활용되지 않는 구조를 식별하기

🔖 11.1 범위와 출처에 따른 구조 분류

책의 내용

사용자의 행위 또한 코드 구조에 영향을 미칩니다. 일부 코드 구조의 변경은 사용자 행위의 변경을 필요로 합니다. 사용자는 코드의 또다른 부분으로 볼 수 있습니다. 사용자와 상호작용할 수 없으면 사용자는 외적인 요인입니다. 따라서 리팩토링 관점에서 볼 때 사용자를 신경써야 하는데, 이것은 리팩토링을 제약합니다.

(중략) 따라서 우선 모든 비효율성을 포함해 사용자 행위를 있는 그대로 모델링한 다음, 훈련 및 교육과 함께 점차적으로 더 효율적인 기능을 제공해서 사용자의 행위를 리팩토링하는 것이 유용합니다.

나의 생각

위의 내용에서 '사용자의 행위를 리팩토링한다' 라는 관점과 단어 선택이 흥미로웠다. 리팩토링이란 코드에만 어울리는 단어라고 생각했기 때문이다. 생소한 관점이어서 어떤 경우가 있을지 생각해 보았다.

사용자의 행위가 코드 구조에 영향을 미치는 경우는 아마.. UI 설계와 상호작용에 관련된 변경이 필요할 때 빈번하지 않을까? 사용자가 개발자가 예상한대로 행동하지 않을 때 기존 코드를 수정하거나 새로운 기능을 추가해야 할 수 있을 것 같다.

예를 들어, 웹 페이지에서 사용자는 댓글을 달기 위해 댓글 입력란에 텍스트를 입력하고 "댓글 달기" 버튼을 클릭해야 한다. 하지만 사용자는 마우스를 사용하지 않고 빠르게 댓글을 입력하고 싶다. 이때, 개발자는 사용자의 피드백을 바탕으로 기존 코드를 수정해 댓글 입력 기능을 더 편리하게 만들 것 같다.

다른 사람들의 생각

나는 책에서 말하는 '사용자'를 엔드유저로 해석했는데, 스터디원 몇몇 분들은 '개발자'로 해석했다. 즉, 코드를 다루는 사용자라는 관점.

위에서 내가 예시로 든 기능 수정을 위한 코드 수정은 리팩토링의 관점보다 오히려 서비스 디벨롭에 가깝다는 것이다. 일반적으로 리팩토링은 엔드유저가 경험하는 기능은 유지한 채, 코드나 구조만 변경하는 것이니까. 오히려 개발자들이 특정 라이브러리나 프레임워크에 본인들의 행위를 리팩토링하는 예시가 더 와닿는 것 같다.

듣고보니 다른 분들의 관점이 책에서 말하는 것과 더 가까운 것 같다.

🔖 11.2 행위를 코드화하는 세 가지 방법

책의 내용

행위의 출처가 어디인지와 상관없이 행위를 코드에 반영하는 데는 세 가지 방법이 있습니다.

  • 제어 흐름: 단순히 열거된 코드의 줄을 통해 행위를 텍스트로 표현 (e.g. 제어 연산자, 메서드 호출 등)

  • 데이터 구조: 데이터 조직 및 저장하기 위한 구조로, 성능 최적화와 데이터 관리의 효율성을 증대 (e.g. 이진 검색 트리, 해시, 스택, 큐 등)

  • 데이터 자체: 데이터를 분석하여 그 안에서 패턴을 찾고, 이를 기반으로 데이터 구조를 만듦 (e.g. ML 등)

나의 생각

11장에서는 주로 행위를 코드화하는 방법에 대해 설명한다. 즉, 코드를 작성하고 구조화하는 데 있어 다른 접근 방식을 설명한다.

이는 소프트웨어의 본질과도 맞닿아 있는 것 같다. 많은 사람들이 소프트웨어란, 사용자들을 위해 현실 세계의 복잡한 프로세스를 자동화하거나, 비즈니스의 어려운 문제를 해결하는 데에 있다. 따라서 복잡하고 어려운 비즈니스 도메인을 소프트웨어로 구현하기 위해서는 해당 도메인을 바르게 이해해야 한다고 말한다. 더불어, 이 책에서도 현실 세계의 관계가 코드로 표현되어야 하며, 코드는 현실 세계로부터 성문화된 구조라고 말한다.

🔖 11.6 활용되지 않는 구조 이용

책의 내용

일반적으로 기본 도메인은 소프트웨어보다 오래된 경향이 있으므로 더 성숙하고 급격한 변화가 덜 발생합니다. 따라서 도메인으로부터 온 구조는 흔히 안전하게 활용할 수 있습니다.

나의 생각

왜 도메인으로부터 온 구조가 안전하게 활용될 수 있을까? 여러 이유를 생각해 보았다.

(신기술을 제외한 금융, 커머스 등) 대부분의 도메인은 오랜 시간 동안 발전해왔고, 그 과정에서 특정한 규칙과 관행이 잘 정립되어 왔다. 이렇듯 검증된 규칙과 관행을 바탕에 두고 코드로 구현하면 리스크가 줄어들 수 있을 것 같다.

더불어, 각 도메인의 전문가들이 그 분야의 복잡한 문제를 해결하는 데 필요한 깊은 이해를 가지고 있기도 하다. 이러한 전문 지식을 소프트웨어 설계에 반영함으로써, 보다 정확하고 효율적인 시스템을 구축할 수도 있을 것이다. (e.g. 금융 도메인에서 필요한 예외 처리, 이자 계산법 등)

📚 참고 자료

Last updated