소프트웨어 장인 :: 6장 동작하는 소프트웨어

[소프트웨어는 주기적인 관리가 필요하다]

 4장, 5장에 이어서 이번 장에서도 소프트웨어 장인이 지녀야 하는 태도를 설명한다. 유지 보수가 원활한 소프트웨어는 주기적인 관리를 필요로 한다. 소프트웨어를 구현할 때 단순히 동작하는 것을 목표로 설정하면 안 된다. 소프트웨어가 '잘' 동작하는 것을 목표로 설정해야 한다. 만약 그렇지 못했다면, 구현 후에라도 잘 동작하도록 리팩토링해야 한다. 현실과 원칙 사이에서 균형을 잘 잡아야 한다.

[테스트 코드 운용 및 관리의 필요성]

 소프트웨어의 주기적인 관리 리스트 중에는 '테스트 코드를 잘 관리하기'가 있다. 테스트 코드를 잘 관리하여 운용하고 있다면 동료들의 소중한 시간을 아낄 수 있다.

 예를 들어보자. 코드를 생성하거나 수정한 다음 dev 서버에 배포하기 전에 local 서버에서 먼저 테스트를 해봐야 한다. 그러나 local 서버에서 테스트하기가 번거로워서 local 서버 테스트를 건너 뛰고 dev 서버에 배포하는 경우가 종종 발생한다. 그런데 이때 dev 서버에 배포한 코드에 이상이 있어서 dev 서버가 제대로 동작하지 않는다면 어떻게 될까? dev 서버를 배포자 본인만 사용하고 있었다면 원인을 찾아 수정하면 돼서 큰 문제는 없다. 그러나 dev 서버를 다른 동료도 사용하고 있었다면, 그 동료는 하던 업무를 멈춰야 할 수도 있다. 심지어 원인이 해결될 때까지 업무 진행이 막힐 수도 있다. 이러한 동료의 수가 n명이라면 리소스 낭비는 더 심해진다.

 위 상황의 원인은 'local 서버에서 테스트하기가 번거롭다는 것'에 있다. 만약 프로젝트에 테스트 코드가 잘 관리되고 있었다면 local 서버 테스트가 그리 번거롭지 않았을 것이다. 그러면 dev 서버에는 테스트가 성공한 코드만 배포될 것이고, 다른 동료들의 리소스를 낭비하지 않았을 것이다.

[결국은 작업자의 책임]

 업무 요청자는 업무의 구현 방식보다는 업무의 구현 여부를 우선적으로 신경 쓸 수밖에 없다. 업무 요청자에게는 '업무가 어떻게 구현되었는지'라는 사실 대단한 관심거리는 아닌 것이다. '업무가 어떻게 구현되었는지'는 전적으로 작업자의 몫이다. 업무를 어떻게든 구현은 해놨지만 그 방식이 엉망이면 언젠가 문제가 발생할 확률이 높다. 그러면 결국 업무 작업자에게로 화살이 쏠린다. 엉망으로 구현해놓으면 결국은 자기가 피를 본다.

 '잘' 구현해놓자. 그러기 위해 테스트 코드를 '잘' 운용하고 관리하자. 그럴 시간이 없을 것 같으면 시간을 요구하자. 시간을 보장받지 못한다면 문제 발생 여지를 미리 알리고 나중에라도 꼭 소프트웨어를 보완해놓자.

[레거시 코드를 대하는 자세]

 레거시 코드 자체에 대한 불평은 무의미하다. 그 레거시 코드에는 많은 사연이 담겨있었을 것이다. 그런 상황에서 나라면 더 좋은 코드를 짤 수 있었을까? 누구라도 자신 있게 그렇다고 하기 어려울 거다. (그렇다고 하는 사람이라면 정말 능력이 출중한 개발자이거나 프로불편러일 거라고 생각한다.) 책임론에 빠지지 말고 이 코드를 어떻게 개선할 수 있을지에만 집중하자. 141p~145p는 너무 공감되는 내용들이 많다. 레거시 코드를 어떻게 바라봐야 하는지, 그리고 어떤 방향으로 개선해야 하는지 알려준다. 레거시 코드 처리에 대한 바이블 같은 느낌이다.