#
@M

『실용주의 프로그래머』

word 
|> all_subsets_longer_than_three_characters()
|> as_unique_signatures()
|> find_in_dictionary()
|> group_by_length()

요구 사항을 달성하기 위해 필요한 것은 하나로 연결된 변환들뿐이다. 각각은 앞의 변환에서 입력을 받아 처리한 결과를 다음 변환으로 넘겨준다. 이보다 글처럼 읽기 쉬운 코드는 만들기 어려울 것이다.

하지만 더 깊은 의미도 있다. 객체 지향 프로그래밍 경험이 많다면 반사적으로 데이터를 숨기고, 객체 안에 캡슐화해야 한다고 느낄 것이다. 이런 객체들은 서로 이리저리 이야기하며 서로의 상태를 변경한다. 이런 방식은 결합을 많이 만들어 내고, 이는 결국 객체 지향 시스템이 바꾸기 어려워지는 큰 요인이 된다.

Tip 50: 상태를 쌓아 놓지 말고 전달하라.

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

과거에 앤디와 데이브 모두 요구 사항을 엄청나게 상세하게 작성하는 프로젝에서 일했던 적이 있다. 의뢰인이 2분 정도 원하는 것을 설명하면, 그것을 확장하여 그림과 표로 가득 찬 손가락 한 마디 두께의 걸작을 만들어 냈다. 구현하면서 모호한 부분이 거의 없을 정도로 모든 것을 상세하게 정의했다. 충분히 강력한 도구만 있었다면 정말로 문서를 프로그램으로 변환할 수도 있었을 것이다.

이런 문서를 만든 것은 두 가지 면에서 틀렸다. 첫째는 우리가 논의했듯이 의뢰인은 자신이 원하는 것을 처음에는 잘 모른다. 따라서 의뢰인이 말한 것을 확장하여 법률 문서에 준하는 수준으로 만든 문서는 그저 사상누각에 불과하다.

여러분이 이렇게 항변할지도 모르겠다. “하지만 우리가 의뢰인에게 요구사항 문서를 가져갔더니 도장을 찍어 주었단 말입니다. 우리는 피드백을 받았어요.” 이것이 바로 요구 사항 명세의 두 번째 문제다. 의뢰인은 절대 그걸 읽지 않는다.

의뢰인이 프로그래머를 고용하는 이유는 의뢰인은 고차원적이고 모호한 측면이 있는 문제를 풀고 싶어 하는 반면, 프로그래머는 세부 사항과 미묘한 차이 하나하나에 관심을 두기 때문이다. 요구 사항 문서는 개발자를 위해서 쓰는 것이다. 의뢰인이 보기에는 이해하기 어려운 부분도 많고, 온통 지루하기만 한 정보와 세부 요소들을 담고 있다.

200쪽짜리 요구 사항 문서를 건네 보라. 의뢰인은 중요하다는 느낌이 들만큼 무거운지 한번 들어는 볼 것이다. 처음 한두 문단만 읽어본 다음 (그래서 늘 첫 두 문단에 '경영진 요약’을 넣는 것이다.) 나머지는 휙휙 넘겨볼 것이다. 멋진 그림이 있으면 가끔 멈출 수도 있겠지만.

이 문서를 인용한 문서