기본적으로 보일 수 있지만, 소프트웨어 개발자로서 여러분의 주요 임무는 프로그램의 예측 가능성을 극대화하는 것입니다. 생각해 보면 지금까지 경험한 버그(bugs)를 유발하는 근본적인 원인은 개발자의 기대가 실제 작동하는 프로그램과 달랐기 때문입니다. 즉, 프로그램을 예측할 수 없었기 때문입니다.
이것이 사실이라면, 프로그램을 보다 예측 가능하게 만들 수 있는 방법에 대해 적어도 어느 정도 시간을 들여 생각해볼 필요가 있습니다. 결과적으로 애플리케이션이 완전히 예측 가능한 세상은 버그가 더 이상 존재하지 않는 세상이기도 합니다. 이를 더 잘 파악하려면 범위를 좁히는 것이 큰 도움이 될 것이라고 생각합니다.
하지만 앱을 더욱 예측 가능하게 만드는 것은 실제 사용하기에는 목표가 너무 광범위합니다. 대신, 앱을 구성하는 개별 부분을 더 예측 가능하게 만들어서 앱을 더욱 예측 가능하게 만들 수 있다고 가정하는 것이 안전합니다.
그렇다면 앱을 구성하는 개별 부분이란 무엇입니까? 일반적으로는 함수(function)를 말합니다. 함수는 입력을 취하고, 출력을 계산하는 프로세스를 말합니다. (함수: 인수 → 반환 값)
정의에 따르면 함수는 간단합니다. 당신도 잘 알고 있듯이 문제는 현실의 복잡성 만큼 정의의 단순성을 망치는 것도 없다는 것입니다. 실제로 함수는 앱의 잡다한 물품 보관함(정크 서랍, Junk Drawer)인 경우가 많습니다.
간단하고 구성 가능한 함수로 시작하는 경우가 많지만, 조금만 부주의 해도 애플리케이션이 성장함에 따라 예측할 수 없는 혼란을 야기할 수 있습니다.
우리는 현실 세계에서 엄격한 규칙을 설정하고 이를 부지런히 준수함으로써 이러한 종류의 "혼란스러운" 시나리오를 해결할 수 있습니다. 프로그래밍에서도 동일한 접근 방식을 취하면 어떻게 될까요? 시간이 지남에 따라 함수를 예측할 수 없게 되는 것을 방지하기 위해 만들 수 있는 일련의 규칙이 있나요?
이에 대한 더 나은 답변을 위해 다른 질문을 해보겠습니다. “무엇이 함수를 예측할 수 없게 만드는가?” 이 질문에 답할 수 있다면 이러한 시나리오를 방지하기 위한 일련의 규칙을 만들 수 있습니다.
일반적으로 함수를 예측할 수 없게 만드는 요인은 다음의 2가지 입니다.
앞서 함수를 입력인 인수를 취하고, 출력인 반환 값을 계산하는 프로세스로 정의했습니다. 함수가 수신한 입력 값이 아닌 상태에 의존하거나 프로그램 자체에 관찰 가능한 변경을 생성하는 등 이 외에 다른 작업을 수행할 때마다 부수적인 효과(side effects)가 일어날 수 있습니다. 몇가지 예를 살펴보겠습니다.
아래 코드는 외부의 todoList와 todo에 의존하므로 코드의 결과를 예측할 수 없습니다.