SW 에서 양과 질에 관해서..

안녕하세요.

최근 다시 프로젝트에 투입이 되었습니다.

삼성 관련된 사이트 이고 일전에 했던 곳입니다.

3년만에 들어가서 해보니 감회가 새롭네요.

SW 품질 관련되서 저 역시 아이템을 찾아야 하니 이곳에서 SW 난이도를 낮추는것과 관련되서,

평소 생각하던 생각들을 적어 볼까 합니다.

구글 검색 결과 입니다.

https://www.google.co.kr/search?q=%EC%BD%94%EC%8A%A4%ED%8A%B8%EC%BD%94+%ED%94%BC%EC%9E%90&espv=2&biw=1221&bih=719&site=webhp&tbm=isch&source=lnms&sa=X&ei=PrtsVcSuOuTVmAWU9IFI&ved=0CAgQ_AUoAg&dpr=1

미국에 있을 때 먹었던 피자는 9.99 이며 빵의 두께가 한국 꺼 보다는 얇았고 토핑은 더 많았던 것 같네요.

 

아래 사진은 질 좋은 피자(?) 라는 전제하에 갖고온 이미지 입니다.

항상 비싸다고 질이 좋은건 아니다…라 생각을 하기도 합니다.

…

 

SW 작업을 하다 보면, 위의 피자 처럼 양보다는 질, 질보다는 양 이런걸 선택해야 될 경우가 있습니다.

질은 좋은 코드란,

검증받은 프레임웍 , Common, Helper or wrapper클래스등을 활용 한 코드입니다.

또한 이미 검증 받은 모듈 or 함수 등을 활용 하여 만들어졌기에, 추가로 검증 작업을 하지 않아도 됩니다.

 

양이 많지만 질은 좀 떨어져도 사용하는데 문제가 없는 코드,

즉 맛은 그렇게 좋지 않지만 가성비가 좋은 코스트코 피자 같은 경우는 양이 많은 코드가 되겠습니다.

 

개인적으로 SW 쪽에서 일을 하면서 얻은 경험은 아래와 같습니다.

 

질 좋은 코드의 장.단점을 열거 하면 아래와 같습니다.

장점

• 추가 디버깅 시간 불필요 -> 품질 보증
• 소스 코드의 간결화 -> 유지 보수 용이-> 유지 보수 비용 절감.
• 러닝 커브가 적음 -> 초급을 활용 할 수 있음.

단점

• 초기 개발 비용이 비쌈 -> 품질이 보증되는 설계가 반영 및 코드의 검증
• 어플리케이션 아키텍이란게 들어가야 하기에 고급 인력이 투입 되어야 함.
• 고객은 왜 이러한 곳에 비용을 투자 해야 하는지 납득 못함.
• 정형화 되지 않은 업무를 정형화 시킬 때 제작 비용이 비쌈.(비정형화->정형화 과정은 반복 수정.)

 

 

질은 떨어지지만 양이 많은 코드의 장.단점은 아래와 같습니다.

 

장점

• 직관적이기에 제작시 들어가는 총 비용이 작다.
• 검증 받지 않은 코드이기에 불안하지만, 비정형업무를 정형화 시킬 때 용이 하다
• 코드 생성기를 활용 하여 작성 할 수 있다.
• 2,3 번 정도 재사용 되는 코드이기에 구지 공통으로 추릴 필요도 없다.
• 복사 후 붙여 넣기를 하는 코드의 경우 연결 고리가 강하지 않기에 해당 페이지만 수정 처리 하면된다.
• 초급으로도 유지 보수가 가능하다.

 

단점

• 동종업 종사자들이 봐도 왜 이런 코드를 작성했을까 의아해 한다.
• 경력이 높을수록 이런 코드를 작성해야함을 부끄러워 한다.
• 주석에 내 이름을 달아놓기 찝찝 하다.
• 복 & 붙을 해놓고 돈을 받아야 하나 자괴감에 빠지기도 한다.
• 최초 업무 분석을 잘못하고 추가 사항이 발견되면 모든 페이지에서 수정할 내용이 * N 라인 이다. (질 좋은 코드는 해당 함수만 변경 처리 후 각 페이지별 인자만 추가 or 삭제)

 

 

간략히 적었지만,

SW 배우는 사람들 중 시스템 통합 or 업무 전산화 작업을 하는 사람들이라면, 코드 재사용성의 합리적 비용 측면에서,

학교에서 배웠던 내용에 관해서 재고 할 필요가 있습니다.

스티브 맥코널이 지적 한 내용중 많은 부분에 공감할 때가 있습니다.

그 중 전산 전공자들은 너무 질 좋은 코드를 만들려는 강박감 때문에 목줄을 옮아 죄고 있다..

뭐 이런 부분이 있는데요. 저는 이부분에 정말 많은 공감을 합니다.

 

최근 드랍 처리 한 사이트 중 한곳은 각 페이지에서 쓰이는 COMMON 코드를 갖고 오기 위해서,

YES 일 경우와 NO 일 경우 DB쪽에 2번 질의 해서 처리 해야 된다란 생각을 담당자가 갖고 있었습니다.

말은 맞는데요. 결론은 제작시 들어가는 시간 & 공수 즉, 리소스의 대비 결과물이 문제인거죠.

 

또 설계에 ㅅ 도 모르는 분들이 설계를 한다고 하면서 DB Table을 그리고 설계가 끝났다고 하는데요.

프로그램은 100가지 순서중 1가지라도 잘못되면 FAIL 이기에,

모든 과정에 들어가는 설계를 부지런히 궁합 맞춰가면서 가다듬어 나가야 설계가 끝났다고 저는 생각 합니다.

 

항상 질 좋은 코드를 만들려고 노력 하지만,

점점 요구사항이 기존의 요구사항 보다 복잡해지고, 기존 요구사항에 추가 & 변경이 들어갈 경우,

질 좋은 코드는 못나 오는 것 같습니다.

 

경험을 해보니, 개비 작업 보다는 기존의 시스템에 추가로 코드를 덕지 덕지 붙여 놔서 돌아가게 하는게 맞고,

그 후 꾸준한 리팩토링 비용을 들이지 않는 이상 질 좋고 하위 버전과 호환이 되는 코드는 만들어 질 수 없다가 제 생각입니다.

 

즉, 비용이 적게 들이기 위해서는 질은 포기 하는 수 밖에 없다가 결론입니다.