객체 찾기: 카드가 통하지 않을 때 해야 할 일

복잡한 문제에 대한 훌륭한 분해(decomposition)는 협력하는 객체들 사이에 책임(responsibilities)을 할당함으로써 찾을 수 있습니다. 우리는 평범한 인덱스 카드를 사용하여 그러한 할당을 수행하는 비공식적인 방법을 제시한 바 있습니다(1). 이 방법의 핵심은 카드를 소품으로, 동료들을 심사위원으로 삼아 계산 시나리오를 훑어가며 그 적절성을 평가하는 것입니다. 이 과정은 실제로 문제를 해결할 수 있는 충분한 집단적 경험이 그룹 내에 존재하는지에 달려 있습니다. 처음 객체 지향 프로그래밍을 하는 사람들은 이 조건을 확실히 하기 위해 문제의 범위를 조정하거나 팀의 폭(구성원)을 조정할 것을 권장합니다.

실제 프로그래밍 상황에서 이러한 조정이 항상 가능한 것은 아닙니다. 때로는 그룹이 문제를 해결할 준비가 단순히 되어 있지 않을 때도 있습니다. 이는 시나리오 심사위원들이 아무런 의견을 내지 못할 때 분명해집니다. '의견 없음'은 일반적인 상황과는 반대되는 것이며, 대개 뱃속이 불편한 느낌(불안감)을 동반합니다. 인덱스 카드로 작업을 계속하는 것은 근거 없는 추측이 되어버립니다.

카드가 항상 통하는 것은 아닙니다. 카드는 경험이 부족한 부분이 어디인지 정확히 짚어내기는 하지만, 그런 경우에 항상 좋은 분해로 이어지지는 않습니다. 숙련된 프로그래머라면 엉성한 분해라도 작동하게 만들 수 있다는 사실, 그리고 곧 많은 경험을 얻게 될 것이라는 사실에 위안을 얻을 것입니다. 그렇다면 제 조언은 어떤 객체라도 가지고 밀고 나가라는 것입니다. 단순히 그만두는 것이 대안이 아닐 때는, 가진 것이 무엇이든 그것을 가지고 진행하십시오. 프로그래밍 과정이 그 강점과 약점을 드러낼 것입니다.

객체를 잘못 선택하면 개발이 느려지고, 코드가 비대해지며, 재사용이 제한될 것이라 예상할 수 있습니다. 이것들은 모두 추가적인 혁신이 필요하다는 신호입니다. 창의적인 프로그래머는 객체를 찾겠다는 희망을 품고 그런 프로그램에 착수할 것입니다. 특히, 그는 '누락된 객체(missing objects)'를 찾을 것입니다. 일단 찾아내면, 그렇지 않았으면 결함이 있었을 프로그램에 적은 노력으로도 삽입하여 극적인 결과를 얻을 수 있습니다.

만약 객체 지향 프로그래밍에 진정으로 뛰어난 프로그래밍 환경이 동반되지 않았더라면 저는 이런 제안을 하지 않았을 것입니다. 최고의 환경들은 거의 모든 구조적(organizational) 실수로부터 회복할 수 있는 충분한 메커니즘을 제공하며, 우리는 이러한 특성을 배포 단계까지 확장할 수 있음을 발견했습니다.

구조적 실수를 프로그램 오류(버그)와 혼동해서는 안 됩니다. 후자는 명세(스펙)를 충족하지 못한 것이고, 전자는 단지 효율성을 위한 기회를 놓친 것일 뿐입니다. 구조적 실수는 프로그램 개발의 경제성을 따질 때 반드시 고려해야 할 상당한 비용을 발생시킵니다. 그것들은 개발을 늦추고, 코드를 늘리며, 재사용을 제한합니다. 이는 모두 누락된 객체가 있다는 징후입니다.