좋은 코드에 대한 딜레마.

유지보수가 쉽고, 성능이 뛰어난 코드를 좋은 코드라고 한다. 

 

내가 만든 코드가 유지보수가 쉽다 함은, 그 코드가 다른 개발자들이 읽기 쉽고, 그 코드에 쓰인 기술이 쉬워서, 내가 없어도 다른 개발자들이 새로운 기능을 추가하거나, 버그를 수정하기 쉽다는 말이다.

 

그러나 성능과 유지보수는 trade-off 양자택일이다.

 

예를 들어, 성능을 잡기 위해서, 메모리 복사 횟수를 최소화하는 코드를 작성한다고 하자. 결국에 그 코드는 기계 친화적일 수밖에 없다. 어셈블리어로 작성됐을 수도 있고, 컴파일러 최적화까지 고려해서 작성되었을 것이다. 그러나 대부분의 개발자들은 균등히 똑똑하지 않다.

 

현자 지로보

 

다른 예로는,  기술이 발전한 경우, 즉 언어차원에서 새로운 문법이 도입되어, 읽기 쉽고 성능이 좋아졌지만, 개발자가 그 기술을 완벽히 이해하지 못한 경우에서 코드를 작성한 경우이다. 이 경우, 신기술을 습득해야 한다.

 

하지만 성능과 유지보수를 모두 만족하는 코드를 작성했다고 하더라도 구조를 생각하지 않고 작성된 하드 코드는 반드시 문제가 생긴다.

 

예를들어, 초기에 작성된 하드 코드가 있다고 하자. 이 경우, 읽기 쉽고, 코드에 쓰인 기술도 쉽고, 최소의 기능만 탑재해서 성능도 나쁘지 않다. 그런데 점점 기능의 요구사항이 늘어나서, 후속 개발자가 그 위에 새로운 기능을 추가하게 될 경우, 난잡한 코드가 되어, 결국엔 읽기도 어렵고, 성능이 심각하게 나쁜 그런 코드가 된다. 결국에 회사는 성능 문제를 해결하기 위해서, 높은 연봉을 주고 능력자를 고용한다. 하지만 회사에 능력자들이 이직하게 될 경우, 남겨진 코드는 시한 폭탄이 되어, 서비스는 종료된다.