SI업계에서 좋은 소스코드를 작성하기 어려운 이유

내가 대학생 시절 상상했던 실무 프로젝트는 개발자들이 화이트보드에 소스코드를 적고 그 소스코드를 리뷰하며 서로의 조언을 얻어 소스코드를 수정하는 모습을 상상했다. 그것은 나의 상상이었을 뿐이었다. 좋은 소스코드를 작성하기 어려운 이유는 아래와 같다.

 

 

 

1.소스코드 리뷰가 없다.

소스코드 리뷰를 하지 않다 보니 본인만의 방식대로 소스코드를 작성하게 된다. 이때의 단점은 본인의 소스코드가 남들이 읽기 쉬운 소스코드인지 읽기 힘든 소스코드인지 파악이 안된다는 점이다. 소스코드 리뷰를 하게 되면 팀원들 간의 지식으로 작성된 소스코드의 문제점을 가르쳐주고 어떻게 수정하면 좋은지를 토론하며 성장을 하게 되는데 이러한 과정이 없다. 그렇다 보니 성장은 없고 계속 똑같은 방식의 정체된 소스코드를 작성하게 된다. 이런 부분이 있기 때문에 성장을 하려면 서비스 회사를 가라고 하는 것 같다.

 

 

 

2.동작하는 프로그램을 개발하기만 하면 그만

소스코드가 아무리 깔끔하더라도 프로그램이 동작하지 않는다면 아무 의미가 없는 소스코드다. 이런 의미에서 "동작하는 프로그램을 개발하기만 하면 그만"이라는 말도 맞는 말이다. 하지만 동작하면서 소스코드까지 깔끔하면 더 좋다. 하지만 SI 프로젝트의 경우 개발만 하고 철수를 하기 때문에 소스코드를 유지 보수할 일이 없다. 그래서 소스코드가 더럽더라도 동작하는 모습만 확인되면 거기서 더 이상 소스코드를 수정하지 않고 내버려 두는 경우가 많이 있다.

 

 

 

3.소스코드 인스펙션

SI의 경우 프로젝트에 투입되는 개발자가 적을 때는 몇 명이지만 많을 때는 수백 명이 되기도 한다. 수백 명이 투입됐을 때 각 개발자들의 소스코드 작성 방식을 맞추기 위해 나온 것이 소스코드 인스펙션이다. 소스코드 작성 표준을 정하고 해당 방식대로 소스코드를 작성하지 않으면 문법을 수정하라는 문구를 뱉는다. 예를 들어 if(str.equals("DVCD")){}라고 작성을 하면 if("DVCD".equals(str)){}로 수정하라고 경고 문구를 뱉는다. 위의 예시는 그나마 괜찮다. 소스코드 인스펙션이 쓸데없이 소스코드를 더럽히는 경우가 있는데 다음과 같다.
String str ="Korea information";
int strLength = str.length();
라고 두 줄로 작성하면 되는 상황인데도 불구하고

 

String str = "Korea Infomation";

int strLength = 0;

if(str != null){

   strLength = str.length();

}

와 같이 작성해야한다. 소스코드가 2줄에서 5줄로 늘었다.

str이 null일 경우 str.length();를 사용하면 에러를 일으키기 때문에 str에 대한 null 체크를 하라는 것이다.

내 생각은 차라리 에러가 생긴다면 그 에러가 발생하는 상황을 해결하는 게 우선이라고 생각되는데 그것보다는 우선 프로그램이 비정상적으로라도 돌아가게 하는 것에 중점이 맞춰져있다. 

이러한 프로그램들 때문에 책에서 보는 클린소스코드, 리팩터링과 같은 적용은 어려운 부분이 있다.

대표적인 소스코드 인스펙션 제품들이 있는데 제품 이름은 언급하지 않겠다. 사용해 보는 나로서는 너무나도 쓰레기 같은 제품이기 때문이다.

 

 

 

최악은 소스코드 인스펙션

내 생각에는 소스코드 인스펙션 제품이 제일 나쁜 프로그램이라고 생각한다.

소스코드 리뷰가 없어도 다른 개발자들이 돌아가는 프로그램에만 관심이 있어도 본인이 개발에 열정이 있다면 좋은 소스코드를 공부해서 작성할 텐데 개발자의 자율성을 막아버려서 좋은 소스코드를 작성할 수 없게 만드는 것이 소스코드 인스펙션이다.  이러한 제품들이 IT 시장에 팔리고 있다는 사실이 안타깝다.