SmalltalkBestPracticePatterns:1.6

1.6 무엇이 빠졌는가?

무엇이 빠졌는가?

본문에서 다루지 않는 몇 가지 코딩 주제가 있다. 중요하지 않아서가 아니라 필자가 패턴으로 바꿀 만큼 아직 충분히 이해하지 못했기 때문이다. 2판에서 부디 이 패턴들을 다루길 바라며, 이번 책에서 포함하지 않은 주제들은 아래에 열거하겠다:

• 예외 처리 – 예외처리의 사용은 가능한 삼가는 편으로, 사용자 인터페이스로부터 객체 호출 수준이 최고일 때만 사용하는 편이다. 많은 처리기들이 디버깅(debugging)이 힘든 것이 사실인데, 코드가 완성될지라도 틀린 값을 제공하기 때문이다. 예외 처리를 사용할 때는 애플리케이션 개발자로서만이 아니라 새 프로그램 언어의 작성자로서 사고해야 한다.
• 복사하기 – 객체를 실행하기 전에 객체의 사본을 준비함으로써 버그(bug)를 수정하는 방법은 간단하면서 바람직하다. 아쉬운 점은, 복사가 습관이 되어 버리면 불필요한 복사본을 만들거나 변경이 필요한 객체를 변경하지 않아 버그를 초래함으로써 시스템의 속도를 떨어뜨리는 결과를 낳을 수 있다.
• Become – Become을 합리적으로 사용하는 경우도 있지만 이를 사용하는 코드의 디버깅은 이미 복잡하므로, 문제를 해결할 다른 방법이 있다면 그 방법을 취하길 바란다. 당신이 이 규칙에 예외가 될 만큼 숙련된 사용자라면 어차피 필자의 책을 복음서로 여기진 않을 테니 이 점에 관해서는 강하게 주장하겠다.
• 성능 개선 – 성능 개선(performance tuning)은 그 자체로 하나의 주제가 된다. 이 맥락에서 성능 개선의 가장 큰 문제점은 여기 모든 패턴들이 코드의 통신 값(communication value)을 최대화한다는 점이다. 성능 개선은 속도는 향상시키는 반면 명확성을 떨어뜨리곤 한다.

제 1장의 첫 문단에 "코딩"의 정의, 즉 전술적 프로그래밍 결정이라는 정의에서는 많은 주제들을 배제하는데, 향후 개정판에서 필자가 다루고 싶은 주제들을 꼽자면 다음과 같다:

• 디자인 – (필자 생각에) 여기서 다루는 대상보다 상위에 속하는 기법들이 있다. 하나보단 두 개의 객체가 훨씬 더 훌륭하게 작업하는 패턴들, 하나의 메소드 또는 메소드 집합을 하나의 객체로 만들면 지렛대 효과를 창출하는 패턴들이 있다. 현재로선 Gamma et al. 의 “Design Patterns”를 참고할 것을 권한다.
• 모델링 – 여기 실린 패턴들은 스몰토크를 이용 시 경험하는 제약들을 해결해준다. 당신이 내리는 중요한 결정들 중 대다수는 모델링 문제로 인한 제약까지 해결해줄 것이다.
• 요구조건 – 행해야 하는 작업에 대해, 그보다 더 중요한 것은 행하면 안 되는지 작업에 대한 고객과의 합의 결과는 개발의 성공에 엄청난 영향을 미친다. 필요한 작업을 하지 않으면 고객이 결과에 만족하지 않을 것이고, 필요하지 않은 작업을 행하면 비용, 시간 낭비는 물론이고 무엇보다 프로젝트를 위험에 빠뜨리기 마련이다.
• 사용자 인터페이스 설계와 구현 – 사용자가 중요하게 생각하는 인터페이스를 설계하는 것은 하나의 예술이다. 그리고 이것을 간단하고 유연하며 재사용이 가능하게 구현하는 것이 훌륭한 스몰토커를 시험하는 기준이 된다.