SmalltalkBestPracticePatterns:1.4
- 1.4 훌륭한 소프트웨어
훌륭한 소프트웨어
여기 실린 패턴들은 시스템을 형성한다; 이 시스템은 스몰토크 프로그래머로서 활동하던 다년간의 세월을 통해 필자가 개발한 것이다. 대부분은 필자 이전에 스몰토커였던 분들이 남긴 지혜의 잔여물로, 필자가 사실상 개발한 부분은 작은 부분에 불과하다. 필자는 스스로를 한 문화의 일부로 생각한다. 어떤 문화에서나 마찬가지로 문화를 훌륭하게, 또는 나쁘게 만드는 핵심 가치 집합이 있기 마련이다. 그러한 가치로는 무엇이 있을까?
그렇다면 무엇이 훌륭한 프로그램을 만들까? 훌륭한 프로그램을 만드는 것에 대한 정의, 그 중 타당한 정의가 꽤 있다. 텔레커뮤니케이션 또는 의료 기기에서는 완전히 신뢰할 수 있는 프로그램이 훌륭한 프로그램이다. 파생상품거래(derivatives trading)에서는 빠르게 전송되는 프로그램이 훌륭한 프로그램이다.
대부분 상용 소프트웨어는 그리 극단적이지 않은데, 대부분 프로그램의 라이프사이클은 다음과 같이 흘러간다:
- 개발자 팀이 급히 소프트웨어를 개발한다. 마케팅 시간이 신제품의 사업 위험도를 감소시키는 데 결정적이다. 제품 자체를 빌드하기란 기술적으로는 도전적이지만 많은 영역에서는 새로운 기반을 한 번에 무너뜨리지 않는다.
- 수년간 생존하고, 그 기간 동안 기능이 재정의 및 확장되는데 이는 대부분 본래 개발팀이 아닌 다른 개발자들에 의해 이루어진다.
- 제품의 조각조각이 새 프로젝트에 재사용되는데, 다시 본래 개발팀이 아닌 개발자들에 의해 이루어진다.
훌륭한 프로그램은 이러한 활동의 요구들 간에 균형을 유지한다. 위의 각 단계 중에서 시스템의 사업 타당성을 위험에 빠뜨리지 않고 나머지 단계들을 지배할 수 있는 단계는 없다.
때로는 모든 단계를 지원하는 패턴을 발견할 것이다 – 위험 요소는 줄이면서 빠르고, 관리와 재사용이 쉬운 코드를 발견할 수도 있을 것이다. 하지만 종종 A을 괴롭혀 B에게 좋은 일을 시키는 경우도 있다. 대부분 패턴들은 장기간 요구와 단기간 요구 간 균형을 유지하도록 설계된다.
개발 과정에 걸쳐 발생하는 병목현상은 인간의 의사소통 한계에서 비롯된다는 점은 아무리 강조해도 지나치지 않는다. "이렇게도 할 수 있고 저렇게도 할 수 있지만 여기서 가장 소통이 원활하니 이걸로 결정해야 한다."라는 메시지가 패턴에서 자주 읽힐 것이다. 급진적인 생각이 있다면 그것이다: 프로그래밍을 할 때는 컴퓨터가 그것을 어떻게 해석할 것인지를 생각할 뿐만 아니라 누군가 당신의 코드를 읽을 것이란 사실을 항상 유념해야 한다.
이러한 패턴들을 작성하면서 고려한 기준과 그에 대한 수정내용을 적자면 다음과 같다.
- 생산성 – 생산성은 원하는 대로 사용할 수 있다 – 짧은 마케팅 시간, 개발비용 감소, 기술적 위험 감소, 또는 품질 향상. 필자는 모든 기술단계에 있는 개발자들이 더 빠르게 학습하고, 스몰토크에 훌륭한 공학 소프트웨어 구조에 소요되는 시간을 줄일 수 있도록 돕기 위해 작성하였다.
- 라이프사이클 코스트 – 이러한 패턴들에 한 가지 원동력이 있다면 소프트웨어의 라이프사이클 코스트 감소가 되겠다. 너무나 많은 개발기관들이 사실상 자신들의 객체에서 교착 상태에 빠져서는 최신 시스템을 살리기 위해, 그리고 내일의 시장은 고사하고 오늘의 시장 욕구를 충족시키기 위해 너무나 많은 시간과 에너지를 소모하고 있는 현실이다. 필자가 이러한 패턴들은 쓴 것은 개발자들과 관리자들을 교육시키고 개발 및 문서에 사용되어, 프로젝트의 라이프사이클에 걸쳐 쉽게 향상되도록 남기기 위함이다.
- 마케팅 시기 – 제품의 마케팅 압력이 강해지면 절차를 생략하고 싶은 충동이 일기 마련이다. 하지만 어떤 절차를 생략할 것인지 결정하는 과정에서 개발이 지체됨을 잊지 말라. 이러한 패턴들을 사용하면 프로그램은 최상의 상태에서 손가락이 움직이는 속도대로 패턴을 적용할 수 있으며, 장기간 과도한 비용을 소비하지 않고 가능한 재빠르게 결과를 도출할 수 있을 것이다.
- 위험성 – 위험성은 소프트웨어에서 최대 금기에 해당한다. 많은 프로젝트가 실패로 돌아가는 것을 모르는 사람은 없다. 그리고 소프트웨어 개발의 계획을 확실하게 짜면서 흥미로운 제품을 생산할 수는 없음을 누구나 알고 있다. 소프트웨어 개발의 위험성이 높다는 것은 누구나 알지만 그것을 이야기하지는 않는다. 위험에 빠진 프로젝트를 검토할 때마다 전체적인 그림은 제자리에 있는데 엄청 작은 실수들이 작업을 망치는 일을 자주 목격한다. 필자는 프로젝트에 가장 해가 되는 이런 작은 실수들의 경험을 바탕으로 이러한 패턴들을 작성하였다.