본문 바로가기

개발 단상

내가느낀 프로그램의 코드가 망가지는 경우.

이유야 굉장히 여러가지가 있겠지만...


전체적인 코드 디자인도 좋고, 잘짠 코드마져 망가지는 경우는 PM의 능력부족이 가장 크지 않을까 생각한다.

하나의 프로젝트가 종료되어 개발이 다 끝난 다음에 나오는

 클라이언트의 무분별한 추가 요구사항을 PM이 제대로 조율하지 못하고 그대로 가져와서 

개발자에게 


'이거 어서 개발해. 무조건 빨리!'


라는 형태로 개발을 시키게 되면 이제 코드의 망가짐이 시작된다.


시스템적으로 변경할 부분이 적은 자잘한 요구수준 이라면야 딱히 코드가 망가질일이 없지만...

과연 클라이언트가 그런 요구만 하겠는가.

코드를 잔뜩 뜯어고쳐야만 되는 요구도 나오고, 아예 기획 의도가 변경되는게 아닌가 싶은 요구도 나오고 한다.


그걸 PM이 조유율하지 못하고 그대로 가져와서 개발자에게 시키니...


코드 디자인을 다시 하기엔 시간이 너무 촉박하니까 결국 추가 기능들의 구현은 땜질 하듯이 코딩을 할 수 밖에 없고

자연스레 코드가 조금씩 난해해지고, 망가지고, 지저분해 진다.

프로그램 역시 무분별한 추가사항으로 인하여 초기 기획과는 영 다른 물건이 되어 버리기 마련.


결국 능력없는 PM이 일을 맡아서, 

클라이언트의 무분별한 의도를 아무 조율없이 무작정 프로그램에 반영 시키도록 프로젝트를 진행하면

프로그램도 이상하고 + 코드도 그지같고 + 그덕에 향후 유지보수도 개판이 되는

최악의 프로그램이 탄생한다.



그래도 초기 기획이 정말 정교하고 확실하게 되어 있었다면

그 기획을 바탕으로 탄생한 프로그램은 코드 디자인도 매우 잘되어있기 마련이고, 

프로젝트 마감후 클라이언트의 무분별한 요구사항을 다 반영해도 코드의 망가짐이 크진 않다.


하지만 무분별한 요구사항을 조유율없이 반영 하도록 지시하는 PM이 과연 초기 기획을 제대로 하긴 했을까?

그럴리가 없지...

'개발 단상' 카테고리의 다른 글

마소 30주년 축하 합니다  (0) 2013.11.10
용어 이해가 정확해야 개발이 편하다  (0) 2013.04.29
재시작 예고  (0) 2012.08.14