Prefactoring

PrefactoringPrefactoring by Ken Pugh

오랜 경험을 통해서 소프트웨어 개발에 관한 통찰을 얻은 소프트웨어 개발자라면, 자신이 얻은 교훈을 세심하게 준비된 실제 사례를 곁들여 다른 사람에게 보여주고 싶은 욕구를 한번쯤은 느꼈을 것이다. 이 책은 바로 그러한 책이다.

이 책의 제목인 Prefactoring은 자신과 다른 사람들의 경험으로부터 얻은 통찰을 소프트웨어를 개발하는 데에 사용하는 것이라고 저자는 설명한다. 그렇다면, Prefactoring이란 경험을 가진 여러 소프트웨어 개발자들이 이미 하고 있는 일이다. 단지 반짝하는 제목 이상의 뭔가가 있을까? 다음은 저자가 내세우는 3가지의 가이드라인이다.

  • Extreme Abstraction
  • Extreme Separation
  • Extreme Readability

더이상 언급이 필요없을 정도로 소프트웨어 개발에 있어서 핵심적인 가치들이라고 할 수 있다. Abstraction과 Separation은 나도 ‘프로그래머에게 필요한 능력‘이라는 글에서 언급한 적이 있다.

이 책에서 가장 읽을만한 부분은 Preface다. 이 책을 사지 않더라도 서점에 들르게 되면 서문 부분을 한번 뒤적거려볼만한 가치는 있다.

서문에서 얘기하고 있는 것 중 하나는 바로 어떤 원리나 프랙티스에 얽매이지 말고 항상 상황-문맥에 따라 트레이드 오프(trade-off)를 고려해서 판단해야한다는 것이다. 이름 있는 훌륭한 엔지니어들에게서는 항상 이러한 모습을 볼 수 있다.

One rule exists: nothing works everywhere, and hence, you must be the judge if a particular practice is appropriate for your application. You need to apply principles in context. The decison whether to use a particular principle or practice depends on the situation in which it is employed.

다른 하나는 바로 회고의 중요성이다. 회고에 대해서는 다른 글에서 좀 더 얘기하기로 하고 여기서는 말을 아껴야겠다. Norman L. Kerth의 Project Retrospectives라는 책을 추천하고 있는데, 한번 읽어봐야겠다.

이 책의 본 내용은 처음에 얘기했듯이 CD 대여점을 위한 가상의 프로젝트를 진행해 나가면서 정련된 가이드라인과 원리들을 보여주는 식으로 이루어진다. 이 가이드라인과 원리들은 하나하나 한번 읽고 넘기기 아까울 정도로 소중한 교훈들이지만, CD 대여점 프로젝트는 좀 지루한 편이다. 참고로 난 100 페이지 정도 읽고 나서는 그냥 나머지는 가이드라인만 읽고 말았다.

가이드라인 중에는 자주 들을 수 있는 것들도 있고 아닌 것들도 있는데, 그렇지 않은 것 중에 하나를 소개하자면 다음과 같은 것이 있다.

Splitters can be lumped more easily than lumpers can be split: It is easier to combine two concepts than it is to separate them.

다시 말하면, 뭉쳐있는 것을 나누는 것보다 나뉘어있는 것을 합치기가 쉽기 때문에, (고민이 된다면) 나누어놓는 쪽을 택하는 것이 좋다는 것이다.

이는 여러가지 상황에서 적용될 수 있는데, 예를 들어 어떤 인터페이스에서 발생할 수 있는 예외 (또는 에러 코드)들을 정한다고 해보자. 당연히 너무 세부적으로 나누면 복잡할 것 같다는 생각이 들기 마련이다. 어느 정도 수준으로 나누어야 할지도 애매한 경우가 있다. 어차피 미래의 필요는 예측하기 힘들다. 하지만 우리가 지금 알 수 있는 것은 미리 나누어두는 것이 좋다는 것이다. 나중에 쌓인 에러 로그를 보면서 비슷한 종류의 에러끼리 모아서 분석할 수는 있지만, 애초에 나누어놓지 않은 에러는 분석이 아예 불가능하다.

이러한 원리는 이러한 결정이 돌이키기 힘들 수록 더욱 강하게 작용한다. 분류하는 정보의 크기가 너무 커서 다시 분류하기가 힘들수록, 이미 여러 고객들과 미리 정한 인터페이스를 변경하기가 힘들수록 이러한 가이드라인이 머리 속에 떠오를 것이다.

이 책은 그리 두꺼운 책도 아니니 부록에 있는 가이드라인 모음만 쓱 훑어보는 식으로 읽어보는 것도 괜찮을 듯 하다. 하지만, Jolt Award 수상작에게 기대한만큼 만족스럽지 못한 것도 사실이다.

“Prefactoring”에 대한 1개의 생각

  1. 토파즈의 생각

    뭉쳐있는 것을 나누는 것보다 나뉘어있는 것을 합치기가 쉽기 때문에, (고민이 된다면) 나누어놓는 쪽을 택하는 것이 좋다는 것이다.

댓글 달기

이메일 주소는 공개되지 않습니다. 필수 필드는 *로 표시됩니다

이 사이트는 스팸을 줄이는 아키스밋을 사용합니다. 댓글이 어떻게 처리되는지 알아보십시오.