익모초 vs 하드코딩

익모초

vs

최소한의 원칙 - 상수들을 하드코딩해서는 안된다!! (4 page / 22 pages  )

http://www.slideshare.net/agebreak/gpg1-10-14

익모초는 많이 먹으면 설사를 하고 부작용을 수반하는데요.

적당히 먹으면 여름 더위를 한방에 날려 줍니다.

안녕하세요. 

하드 코딩 관련되서 글을 한번 적을까 했는데요.

다행히 오늘 질문 받은 것 중 하나가 하드 코딩입니다.

일반적으로 한국에서 하는 SI 프로젝트 or SITE 별 솔루션을 분석 하다 보면,

필히 마주 치게 되는  것 중 하나가,  국적 불명의 존재의 의무점을 갖게 하는 스트링 소스 입니다.

두루뭉실하게 말하길 하드 코딩이라고 하는데요. 

과연 이게 필요 한걸까요? 필요 없는걸까요?

개인적으로 필요 할때는 쓰는게 맞고, 필요 없는 부분은 함수로 대체 하는게 맞습니다.

일전에 신세계 I&C 굿앤디 프로젝트 할 때 제 프로젝트 역사상 가장 막장 PM을 만났는데요.

코딩 능력이 정말 의문이 드는 이야기중 하나가,

"하드코딩을 없애라" 입니다.

고객은 두루뭉실하게 이야기 하지요.

문제는 프로젝트 수행하는 PM이 저 말을 곧이 곧대로 바이패스 할 경우 그 프로젝트는 100% 나가리 패 입니다.

대표 적으로 하드코딩 범위로 두는것중 하나가 FLAG 값 입니다.

YES, NO, Y, N, OK, N/G 등등..

문제는 요러한것들을 제거 하기 위해서 들어가는 비용(cost)가 실제 하드코딩으로 유지 하는 비용보다 훨씬 비싸며,

개선을 한다 치더라도 미미 할 뿐입니다.

또, 하드코딩이 무조건 안좋다란 인식이 낳은 결과 인데요, 가독성에서 저렇게 직관적인것들은 대체를 한다 치더라도 얻게 되는 이득은 미미 합니다.

구지 이런 상황에 "하드코딩은 절대 쓰지 말아라." 란 명제를 들고와서 적용을 해야 하나란 의문을 항상 갖습니다.

세상일이 그렇듯이 절대 법칙 한가지로만 해결 할 수는 없고, 어떤 그림도 한가지 색으로 표현 할 수는 없습니다.

한가지 룰로 적용 된다면, SI 프로젝트로 발주될만한 사이즈가 아닐꺼다라고 봅니다.

여러명이 작업 할 때는 직관적으로 이해 할 수 있는 하드 코딩 역시 하나의 방식으로 받아 줘야 합니다.

개인적으로 이러한 룰이 적용되서 망조든 케이스중 하나가, 디비 컬럼에, INT, NUMBER, VARCHAR를 두루두루 섞어 가면서 처리 한 케이스 입니다.

실제 SI에서는 VARCHAR 를 활용해서 처리 해야 많은 에러를 줄일 수 있습니다.

MVC 패턴, 퍼포먼스 향상등을 이유로 들며 해결책을 제시 하는 분들을 봤는데요.

정작 이 방식을 적용 할 경우 프로젝트 성능향상에 얼마나 많은 영향을 끼칠지 궁금합니다.

많은 프로젝트가 유수한 SW 공학의 석박사들의 컨설팅과 개발론을 바탕으로 진행해도 70%이상 실패 하며,

납기일을 못맞춥니다.

에러를 더 줄일수 있는건 많은 개발 인력에게 우리우리는 이러이러한 방식으로 이러이러하게 꾸준히 개발을 진행 했으니, 

너도 이러이러한 방식으로 개발을 하라라는걸 수달에 걸쳐서 알려줘야 하는데..

이 기회 비용은 고스란히 고객의 버젯에서 털어 먹게 됩니다.

 하드코딩, 필요 할 때 쓰면 맞고, 필요 없는 부분은 과감히 제거 하면 됩니다.

기준은 특정 개인만 알 수 있는 방식이며 학습의 기간이 필요한 하드코딩이면, 제거 하는게 맞고,

그게 아니고 직관적이라면 그냥 흘러가게 두는게 맞습니다.

하드코딩 제거는 배보다 배꼽이 더 커질수 있는이유중 하나는,

코드 1개를 관리 하기 위해 테이블과 컬럼을  수개 추가 할수 있는 상황이 있기 떄문입니다

감사 합니다.