기능 구현 중심 개발의 심각한 문제

기능 구현 중심 개발의 문제-2에 이어서..

기능 구현에 집착하다보면 다른 소프트웨어의 중요한 가치를 놓치게 된다. 는 일부 틀린 말이다. 중요한 가치를 놓치는 것이 아니고 더 나아가 해를 입힌다. 우리는 고객의 기능을 성실히 구현하여 소프트웨어의 완성에 노력했는데 이 노력이 소프트웨어의 다른 뭔가를 훼손한다고요?

 

소프트웨어를 만들 때 지향해야할 큰 가치는 유연한 소프트웨어다. 소프트웨어가 유연하다는 것은 소프트웨어가 재사용하기 쉽고, 수정하기 쉽고, 확장하기 쉽고, 버그잡기 쉽고 가독성이 좋아 유지보수와 추가 개발하기 편하다는 의미이다. 우리는 고객이 원하는 기능을 개발 하면서 이런 가치를 함께 추구해야 한다.

 

우리는 당장의 기능 구현도 어려운데, 이런 가치까지 같이 신경써서 개발하라니 더 어렵게 느껴질 것이다. 그러나 유연한 소프트웨어도 같이 관심 갖지 않으면 우리한테도 직접적인 피해가 닥친다. 우리가 여행을 갈때, 내가 몰던 자동차가 뭔가 콜콜거렸는데 괜찮겠지 했는데, 고속도로 한복판에서 차가 멈출때의 당혹감과 짜증을 소프트웨어 개발에서 경험할 수도 있다.

 

‘코드의 중복’, 기능 중심 구현만 집착하다 보면 당장의 기능 작동을 위해 썼던 코드를 다른 곳에 복사/붙여넣기 하는일이 생긴다. 정신없이 프로젝트를 하다보면 이런일이 자주 생긴다. 이렇게 기능은 작동 되겠지만 문제의 불씨를 남긴다. 나중에 같은/비슷한 기능을 하는 코드에 버그가 생기가나 수정할일이 있으면, 관련된 코드를 똑같이 수정해야 한다. 그러나 시간이 지나면 이 코드가 다른 곳에도 있는지 기억하기 어렵다. 더구나 다른 담당자가 유지보수 개발을 이어 받았으면, 코드 중복을 알기 힘들다.

 

‘코드 속성의 과도한 노출’, 기능 중심 구현은 객체지향의 캡슐화등의 권장사항을 지킬 여유를 주지 않는다. 그래서 한 코드(=클래스)의 속성(=변수)들이 다른 코드(=클래스)에서도 직접 접근하여 조작할 수 있다. 코드가 지저분하게 의존하게 된다. 코드가 지저분해지고 가독성이 떨어진다. (일단 이 정도만 알고 구체적인 용어나 상황 설명은 다음 장에서 이어가겠습니다.)

 

‘코드 메소드(=함수, 행동)의 과도한 노출’, 소프트웨어의 유연함을 위해, 외부(=다른 클래스에)에 노출할 메소드와 감춰야할 메소드가 구분 되야한다. 역시 기능 중심 구현에 몰두 하다보면 이런 규칙은 놓치게 된다. 그 결과 메소드가 원칙 없이 일관성 없이 개발 된다. 역시 코드의 결합도가 증가되고 코드가 지저분해지고 사이드 이펙트가 증가된다. (역시 일단 이런 개요정도만 알고 구체적인 용어나 상황 설명은 다음 장에서 이어가겠습니다.)

 

‘코드의 뚱뚱’, 기능 구현 중심 개발은 구현이라는 목표를 위해서 수단과 방법을 가리지 않는다. 그래서 코드의 속성이나 메소드, 각종 로직 배치에 일관성이 없다. 메소드 내부에 있어야할 속성이 전역 변수로 빠져 나와 있기도 한다. 메소드의 하나의 길이가 너무 길어서 1,000라인을 넘기도 한다. 이 경우 역시 코드의 가독성이 떨어지고 지저분해지고 사이드 이펙트는 증가하고 버그 잡기는 더 힘든 상황이 된다.

 

‘코드의 가독성’, 코드는 읽기 쉬워야 한다. 읽기 쉬워야 버그 잡기 쉽고, 기능 수정하기 쉽고, 확장 개발하기 수월하다. 기능 중심 개발만 몰두 하다보면 가독성도 같이 챙기기 어려워 진다. 가독성은 단순히 주석을 많이 달아서 해결되는 상황이 아니다. 객체지향적으로 속성과 메소드를 배치하고 메소드 길이를 간결하게 유지할 때 더 좋아진다. (객체지향적으로 속성과 메소드를 배치한다는 것이 어떤 것인지는 다른 장에서 설명합니다.)

 

이렇게 기능 구현 개발에만 매몰 될 경우 기능은 작동할지라도 그 안에서는 악취가 풍긴다. 연기나는 자동차처럼 고장날 징후가 여기저기서 보인다. 그때는 고치고 싶어도 이미 엉망으로 소프트웨어를 개발 했다. 쉽게 고치기도 쉽지 않다.

 

기능 구현 개발은 단순히 좋은 소프트웨어의 가치를 놓치는데서 끝나지 않는다. 위의 사례처럼 악영향을 준다.