반응형

혼자만의 잡다한 생각

최적화된 모듈화 vs 가독성을 위한 중복소스 ?

 

SI프로젝트 개발자로 일하며...

나는 개인적으로 중복소스가 생기는 것을 싫어한다.

유지보수에도 안 좋다고 생각하고, 일단 Copy&Paste라 할지라도 코딩을 많이 해야 한다.

소스가 너무 길거나 많이자면, 관리하기가 어렵다고 생각한다.

 

이번 프로젝트를 수행하며...

업무요건을 반영하기 위해 함께 일하는 개발자의 소스를 같이 보는 일이 있었다.

유형별로 처리해야 하는 패턴이 조금씩 다른 업무였는데,

각 업무별로 각각의 Class파일을 생성해서 처리하고 있었다.

 

그런데, 업무들 중 동일한 패턴으로 수행되는 유형들도 있었고,

패턴은 달라도 상당부분(70~80%)은 동일하고 약간씩만 다른 처리가 필요한 것들도 많았다.

이런 모든 것들을 개별 소스로 개발하여 관리하고 있었다.

 

개인적인 프취(프로그래밍 취향)에 맞지 않다보니...

넌지시 개인적인 의견을 전달했다.

완전히 동일하게 쓰는 유형들은 하나의 소스(모듈)을 호출하여 처리하고

패턴은 다르지만, 공통적으로 쓸수 있는 부분을 따로 모듈화하여 사용하면 어떻겠느냐고...

 

'라떼'는 말이야... 모듈화 안하면 욕먹고, 혼나고.. 어쩌고....

요즘은 '꼰대'라는 소리만 듣고, 서로 프리랜서다보니 득보다 실이 훨씬 많아서

잘(?) 돌아가만 가면, 모른척 하는것이 낫다. - 이 바닥의 현실...

 

의견을 들은 그 개발자는...

유지보수나 가독성면에서 유형별로 명확하게 분리되는 것이 더 낫다고 한다.

유형별로 소스를 분리하였으니 인지하기 명확하다는 것이다.

 

공통적으로 사용하는 부분의 요건이나 로직의 변경이 필요하다면....?

그 모든 중복소스를 찾아서 고쳐야 한다.

이를 이야기 하였으나 '소 귀에 경읽기', '생각이 다르다'

 

굳이 들을 생각도 없어보이고, 

나도 내 프취를 강요하고 싶지도 않고, 설득하고 싶은 열정도 없기에 그냥 돌아섰다.

잘 돌아가기면 하면 되니...

결국, '요건만 잘 처리될 수 있게 해달라 ' 라고 전달했다.

 

중복소스가 꼭 나쁜 것만은 아니다.

때로는 그 개발자의 말처럼 가독성이나 인지의 명확성이 중요할 수도 있다.

그렇다 할지라도 나는 .. '기본적으로 중복소스는 반대일세' 라는 입장이다.

어느새 나도 '라떼족'이 되어 있는 것인가...

 

끝.

반응형