[Book] 실용주의 프로그래머 정리 - 02

실용주의 프로그래머 - 교보문고

2장 실용주의 접근법

 

7. 중복의 해악

  이번에는 DRY 원칙에 대하여 설명합니다. DRY란 'Don't  Repeat Yourself' 반복하지 말아라 라는 뜻입니다. 개발자들은 개발의 시작부터 끝까지 항상 유지보수의 과정에 놓여 있다고 해도 과언이 아닙니다. 그리고 이 유지보수를 피곤하게 만드는 것 중의 하나가 중복된 코드입니다. 중복된 코드가 많으면 많을수록 해당 부분에 대한 수정은 피로해질 것이기 때문이죠. 이 중복이 생기는 이유는 대부분 이 중에서 찾아볼 수 있습니다.

 

- 강요된 중복 : 개발자들이 중복된 코드를 사용하는 것 외에는 다른 선택이 없다고 느끼는 경우입니다. 환경이 중복을 요구하는 것처럼 느껴질 때입니다.

- 부주의한 중복 : 개발자들 자신이 중복된 정보를 작성하는 것을 깨닫지 못하는 경우입니다.

- 참을성 없는 중복 : 중복된 코드를 사용하여 작업을 할 경우 쉬워 보이기 때문에 중복된 코드를 작성하게 됩니다.

- 개발자 간의 중복 : 팀의 다른 구성원이 다른 사람들과 동일한 정보를 중복하여 작성하는 경우입니다.

 

 

8. 직교성

  설계, 빌드, 테스트 그리고 확장하기에 쉬운 시스템을 만드는 데에 있어서 직교 성은 매우 중요한 개념입니다. 컴퓨팅에서의 이 용어는 일종의 독립성, 또는 결합도 줄이기를 의미합니다. 즉 프로젝트를 구성하는 요소 중의 하나가 변화하여도 나머지에 어떠한 영향도 주지 않는 것을 직교한다고 할 수 있습니다.

 

직교의 장점

  직교적인 시스템을 작성하게 되면 생산성 향상과 리스크 감소의 장점을 가집니다.

 

생산성 향상 - 상대적으로 작고 자족적인 컴포넌트를 작성하는 것이 하나의 커다란 코드 덩어리를 만드는 것보다 쉽습니다. 간단한 컴포넌트들을 직교적으로 잘 만든다면 설계하고, 코딩하고, 단위 테스트를 진행한 뒤 잊어버릴 수 있습니다. 또 새로운 코드를 추가할 때에 기존의 코드를 바꿔야 할 필요도 없습니다. 직교적으로 잘 만든 컴포넌트들은 그렇지 않은 컴포넌트들 과의 결합보다 더 많은 기능을 얻을 수도 있습니다.

  

리스크 감소 - 직교적인 접근법은 리스크 감소에 효과적입니다. 일단 감연 된 코드를 격리시킬 수 있습니다. 어떤 모듈에 문제가 생겼을 때 다른 코드까지 문제가 전염될 확률이 낮습니다. 또 시스템에서 문제가 발생하였더라도 다른 부분을 신경 쓰지 않고 문제가 발생한 부분만 골라서 수리할 수 있습니다. 그리고 직교적인 시스템은 해당 컴포넌트들에 대해 테스트를 설계하고 실행하기 훨씬 쉽기 때문에, 더 많은 테스트를 하게 되고 이는 리스크의 감소로 이어지게 됩니다.

 

 

9. 가역성

  가역성은 반응 시 초기 상황으로 되돌아올 수 있는지의 여부를 일컫는 말입니다. 개발자들의 프로젝트에서의 이 가역성은 프로젝트가 얼마나 유연한 지에 대해서 말합니다. 작업을 진행하면 어떤 문제를 해결해야 하고, 이 문제를 해결하는 방법은 여러 방법이 있을 것입니다. 그러나 수많은 이유 때문에 하나의 방법에만 몰두하는 경우가 생기게 되고 이 결정은 예기치 않은 변수에 가로막혀 새로운 방법을 찾아야만 하는 상황이 오게 됩니다. 그렇기 때문에 가능한 유연한 생각을 가지고 만약을 대비한 코드를 작성하는 것이 좋습니다.

 

 

10. 예광탄

 어둠 속에서 목표물을 맞추는 방법은 두 가지가 있습니다. 목표물이 어디에 있는지 정확히 확인하고, 환경 조건을 고려한 다음 사용하는 총과 탄의 정확한 사양을 파악하여 완벽한 계산을 한 뒤 발사하는 방법이 있고 다른 방법은 예광탄을 쏘는 것입니다. 예광탄이란 날아가는 경로에 빛의 궤적을 남겨주는 탄으로 다른 일반탄의 중간중간에 섞어서 사용하게 됩니다. 이러한 예광탄을 사용할 경우 단번에 목표물을 맞추는 것은 힘들겠지만 예광탄의 경로를 확인하며 차차 조준을 수정하면 목표물을 맞출 수 있게 됩니다. 즉 프로그래밍에서도 예광탄을 사용하는 것은 매우 효과적인 프로젝트 방법이 될 수 있습니다.

 

예광탄은 실제 비즈니스 로직까지는 아니더라도 가볍지만 탄탄한 틀을 만드는 방식이라고 볼 수 있습니다. 틀을 만들어 놓으면 사용자들은 일단 진전이 되어 있음을 볼 수 있고, 그들의 더욱 자세한 요구사항을 이끌어 낼 수도 있습니다. 또 백지에 내용을 채우기는 힘들지만 틀이 주어져 있다면 그나마 괜찮듯이 예광탄으로서 틀을 만들어 놓으면 이후에 작업하는 개발자들의 생산성은 좋아지게 됩니다.  

 

물론 예광탄이 항상 목표물을 향해 다가갈 것이라는 확신은 없습니다. 그렇지만 예광탄은 충분히 가볍기 때문에 큰 부담 없이 새로운 방법을 찾아 시작할 수 있다는 장점도 있습니다.

 

예광탄 코드 대 프로토타이핑

  여기까지의 설명만 보더라도 프로토타입과 예광탄이 같은 것이 아닌가 하는 생각이 들 수도 있습니다. 그렇지만 분명히 다른 점이 존재합니다. 예광탄 코드는 기능은 별로 없지만 완결된 코드이며, 최종 시스템 골격의 일부를 이루게 됩니다. 프로토 타입은 나중에 버릴 수 있는 코드를 만드는 것이라고 이해할 수 있습니다. 

 

 

11. 프로토타입과 포스트잇

  조금 전에 예광탄 코드와 비교되었던 프로토타입입니다. 프로토 타입은 굉장히 많은 분야에서 사용하고 있는 새로운 아이디어를 도입할 때 사용할 수 있는 방법입니다. 자동차 회사에서는 자동차의 디자인을 위해서 나무와 테이프를 이용하기도 하고 포스트잇을 이용한 작업의 흐름이나 애플리케이션 로직 프로토타입을 만들어 볼 수도 있습니다. 프로토 타입은 위험을 수반하는 모든 것에 적용해 볼 수 있으며 이를 통해서 수많은 교훈을 배울 수 있습니다. 

 

프로토 타입을 어떻게 사용할 것인가?

 

프로토타입을 만들 때에 무시해도 좋은 세부사항이 있습니다.

 

- 정확성 : 적절하게 가짜 데이터를 사용할 수 있습니다.

- 완전성 : 프로토타입은 때때로 미리 선정한 데이터와 선정한 기능만이 작동하면 되기 때문에 제한된 기능만을 제공하기도 합니다.

- 안정성 : 프로토타입은 에러 검사에 불완전할 수도 있고, 때로는 완전히 무시될 수도 있습니다. 또 미리 정의된 방법대로 실행시키지 않았을 때에는 망가진 모습을 보일 수도 있지만 그래도 괜찮습니다.

- 스타일 : 프로토타입 코드는 주석이나 문서를 많이 만들지 않아도 됩니다. 프로토타입을 통한 경험의 결과로 많은 문서를 많이 만들어 낼 수도 있겠지만, 프로토타입 자체에는 많은 문서를 많이 만들어 넣지 않아도 됩니다.

 

프로토 타입을 선보일 일이 생기면 항상 모든 사람에게 이 프로토타입 코드는 폐기 처분할 코드라고 이해를 시켜야 합니다. 그 코드가 프로토타입임을 모르는 사람들이 보았을 때에 이 코드가 매력적으로 보일 수 있기 때문입니다. 그러므로 이 코드는 폐기할 것이고 완성할 수 없는 코드라는 사실을 분명히 인지시켜 주어야 합니다. 만약 작업하는 환경이나 문화에서 프로토타입 코드의 목적이 잘못 해석될 가능성이 크다고 느낀다면 프로토 타입이 아닌 예광탄 접근 방식을 취하는 게 나을 수 있습니다.

 

 

12. 도메인 언어

  개발자들이 문제를 접하게 될 때에는 주로 그들이 사용하는 컴퓨터 언어의 관점에서 이를 접근하게 됩니다. 즉 Python을 이용하여 문제를 접근할 때와 Java를 이용하여 문제를 접근할 때에 접근 방식이 달라질 수 있다는 이야기 입니다. 문제는 이렇게 특정 언어를 가지고서 문제에 접근을 하게 될 때에 유연하지 못한 사고를 할 수 있다는 사실입니다. 

 

  이 때에 우리는 문제 도메인 언어를 사용해 보는 것이 해결 방안이 될 수도 있습니다. 실제 존재하는 프로그래밍 언어가 아닌 우리가 해결해야 할 문제의 용어들을 가지고 그 애플리케이션 도메인에 맞추어진 소형 언어를 만들어 기능을 만들어 보는 것 입니다. 물론 이 도메인 언어가 꼭 실행가능할 필요는 없습니다. 그저 사용자의 요구사항을 잡아내는 명세로서의 역할만 해도 됩니다. 

 

13. 추정

  추정은 무언가의 가능성, 어떤 일이 가능한지 아닌지, 어떤 일이 얼마 나의 시간이 걸릴지 판단하는 능력을 말합니다. 추정을 잘할 수 있다면 무슨 일이 발생했을 때, 어느 정도 예상을 할 수 있고 이에 대한 대책을 세울 수 있게 됩니다. 어떤 의미에서는 모든 답이 추정치입니다. 그저 누가 남 보더 다 정확한 답을 가지고 있는지가 다를 뿐입니다.

 

  누군가 질문을 했을 때 고려해 보아야 할 것은 질문자가 어느 정도의 정확도를 가진 답을 원하는지입니다. 집에서 어머니가 언제 오는지 물어보았을 때, 점심때 오는지 저녁때 오는지 정도만 궁금할 수 있습니다. 근데 사고를 당해 위급한 환자가 타고 있는 구급차와 병원 간의 질문이었다면 몇 분 몇 초까지의 정확한 시간을 요구하고 있을 가능성이 높습니다. 

 

  대부분 상황에서 좋은 추정치를 얻는 방법은 경험자들에게 조언을 구하는 것입니다. 과거에 비슷한 일을 겪은 사람에게 질문을 하고 그들이 어떻게 그 문제를 해결했는지, 얼마나의 시간과 노력이 들어갔는지 물어보면 이후에 다른 사람들의 경험을 통해 성공적인 추정치를 낼 수 있다는 사실을 알게 될 것입니다.

 

  또 다른 방법으로는 클라이언트의 요구를 이해한 뒤 대략적이고, 꾸밈없는 모델을 만들어 보는 것입니다. 이 모델은 여러분의 조직이 개발을 하는 동안 사용할 디딤대 역할을 해줄 뿐 아니라 대략적인 틀을 제공해 줄 것입니다. 그리고 이 모델을 만들어 보는 과정 자체가 창의적이고 유용한 사고를 해야 하기 때문에 이 과정에서 표면에 명확히 드러나지 않았던 패턴과 프로세스를 발견하게 됩니다. 이를 통해서 초기에 생각한 방법보다 유용한 방법을 찾을 수 있습니다. 다만 모델을 만드는 것에 몰두를 하는 것은 좋지 않습니다. 언제까지나 대략적인 추정치를 알기 위함이며 모델을 만드는데 두 배의 노력을 들인다 하더라도 결과의 정확도는 조금씩밖에 향상되지 않을 것입니다. 

 

  모델을 만들었다면 이를 컴포넌트로 분해할 수 있습니다. 그리고 컴포넌트들이 어떻게 상호작용을 하는지 수식을 찾을 필요가 있습니다. 어떤 컴포넌트는 결과에 합산될 단일 값을 내어줄 것이고 어떤 컴포넌트는 곱셈 값을 제공할 것입니다. 여러분은 각 컴포넌트가 모델에 얼마나 영향을 끼치는 매개 변수를 가지고 있다는 것을 알게 될 것입니다. 그렇다면 이제 이 매개 변수의 값에 적절한 수치를 예상해 보고 여기에 적당한 값들을 대입해보며 추정치를 찾아내야 합니다. 마지막으로 이렇게 계산한 추정치들을 기록해 놓고 이후 실제와 얼마나 가까웠는지 평가해보는 것도 좋은 생각입니다. 여러분은 이렇게 구한 추정치가 꽤 좋다는 것을 자주 발견할 것이고 점차 이를 기대하게 될 것입니다.

 

  추정치가 잘못되었다고 하더라도 낙담하지 않아도 됩니다. 어디서 추정치가 달라졌는지 매개변수를 잘못 찾았는지 모델을 잘못 설계했는지 찾아내고 개선하여 더 좋은 추정치를 찾아내도록 발전하면 됩니다.