Topic 30 변환 프로그래밍
데이비드 토머스, 앤드류 헌트
느낌표 ! (인상 깊은 문장 | 문맥)
자신이 하고 있는 걸 하나의 과정으로 서술할 수 없다면, 자기가 뭘 하고 있는지 모르는 것이다.
- W. 애드워즈 데밍(William Edwards Deming)p.207
누군가에게 자신의 업무나 일을 설명할 때 막히는 부분이나 잘못된 부분이 떠오르기도 한다. 이처럼 자신이 하고 있는 일에 대한 설명을 명확히 못하는데 실제로 일을 잘할 것이라는 기대를 하는 것은 무리다.
필자도 일을 할 때 바로 코드를 작성하려할 때가 많다. 기능을 만들 때 기능 명세를 나름 순서화하려 노력하기도 한다. 위처럼 단계별로 나누었을 때 장점은 큰 그림을 확실히 볼 수 있고 어떤 단계에서 난이도가 있는지 미리 파악할 수 있기도 하다. 또한 단계별로 나눌 때 명세를 보다 정확히 이해할 수 있다. 또 어떤 상황을 고려해야하는지도 떠오르기도 한다.
우리는 이렇게 코드에만 집중하면 핵심을 놓칠 수 있다고 본다. 프로그램이란 입력을 출력으로 바꾸는 것이라는 사고방식으로 돌아갈 필요가 있다. 이렇게 생각하면 그동안 고민하던 많은 세부 사항이 모두 사라진다. 구조는 명확해지고 더 일관적으로 오류를 처리하게 되어 결합도 대폭 줄어들 것이다.
p.207
프로그램을 입력을 출력으로 바꾸는 것이라는 사고방식은 꽤 어색한 방식으로 들린다. 그렇지만 생각해보면 정말 맞는 말이다.
사용자의 이벤트, 특정 데이터 가공, 애니메이션 등 모두 입력과 출력으로 이루어져있다.
『Mobx Quick Start Guide』 를 보면 UI = fn(state) 라고 적혀있다. 이와 같이 UI 도 결국 상태 즉 데이터라는 입력을 출력으로 변환한 것이 UI 라는 것이다.
이 수식을 보고 나서 통계들이 나와있는 대쉬보드를 보니 각 영역이 하나의 데이터 묶음으로 보이기도하였다.
코드를 접근할 때 객체지향적으로 생각하는 것이 정답이고 더 우아한 접근 방식이라고만 생각했는데 입력과 출력 관점도 살펴볼 필요가 있겠다는 생각이 든다.
입력과 출력의 접근 방식의 연장선으로 얻을 수 있는 장점은 테스트 케이스일 것이다. 특정한 데이터를 주고 특정한 결과값이 나오는지 결과값을 확인하는 것이기 때문이다. 이처럼 테스트 케이스를 즉 입력과 출력에 대한 검증이라고도 볼 수 있다.
이제 입력을 출력으로 바꿔 가는 단계들을 찾으면 된다. 일종의 ‘하향식’ 접근 방식이다.
p.210
입력을 출력으로 바꿔가는 것은 파이프라인의 연속이라고도 볼 수 있겠다. 파이프라인을 거치며 데이터가 변환되며 최종적으로 원하는 것을 만들어낼 것이다.
데이터는 더 이상 클래스를 정의할 때처럼 특정한 함수들과 묶이지 않는다. 대신 우리 애플리케이션이 입력을 출력으로 바꾸어 나가는 진행 상황을 데이터로 자유롭게 표현할 수 있다. 이 말인즉슨 결합을 대폭 줄일 수 있다는 것이다. 어떤 함수든 매개 변수가 다른 함수의 출력 결과와 맞기만 하면 어디서나 사용하고 또 재사용할 수 있다.
p.216
이번 챕터를 통해서는 OOP VS 함수형 이라는 논쟁의 답을 내리지 못했었는데 각각의 독특한 장점을 더 알 수 있게되었다. 결국 한 쪽만 사용하는 것이 정답은 아닐 것이고 과도하게 모든 것을 객체로 만들기보다 함수형으로 접근할 때 더욱 우아한 객체지향이 되지 않을까 싶다.
Topic 30 느낌
Topic 30 에서는 입력과 출력이라는 패러다임으로 더 좋은 코드를 위한 접근 방식을 다시금 상기시켜주었다.