'유지보수성'에 해당되는 글 2건

  1. 2008.10.30 대형 프로젝트에서 통합과 분리
  2. 2007.09.13 유지 보수성. 3
'최고는(The Best)는 우수(The Good)의 적이다.'

현재 개발진행중에 특정한 화면에서 공통된 사항을 뽑아,공통 통합 파트를 구현하면서 새롭게 느겼던 말이다.알골(Alcol)을 설계한 팀에서의 조언이기도 하다.

구현 - 변경 - 구현, 흔히 말하는 이터레이션이 계속 되는데 어디까지 세분화 시켰다가 또 어디까지 통합할 것인가를 계속 고려해본다. 그 와중에 과연 품질수준은 어디까지로 할까 개인적으로 고민해보다가 떠오른 말이다.

적당한 수준으로 통합을 하고 있고 이런 정도가 현재는 맞다고 판단한다.

개인적으로 이런 대형 프로젝트에서는 유지보수성을 가장 최우선으로 하고 싶다.프로그램의 자유도는 딱딱해지고 화면은 평이해지겠지만,이런건 트레이드 오프 라고 생각한다.

그렇다면 과연 프레임웍을 도입했어야 할까, 이 부분은 개인적인 생각이 계속 바꼈다.

처음 프로젝트 투입할때는 프레임웍을 도입을 고려해보자고 제안했었고,속도가 붙었을땐 과연 그랬다면 낭패였겠다 싶었는데, 일차 오픈과 더불어 개발자들이 대거 나가고 나니, 또 다시 유지 보수성 문제가 고개를 들고, 다시 프레임웍을 도입하는게 좋았을것 같다 라고 생각한다.

최초 맡았던 파트는 공통모듈화가 상대적으로 잘 되었지만, 지금 파트는 일정이 밀리고 변경도 잦고 책임자가 없이 휘둘리니 유지보수성은 이미 물건너간 상황이다.

다시 공통화로 돌아오면,가장 어려움을 느낀건 남의 소스를 보는데 이해할수가 없다는 거다.프로그램 코드가 아닌,백그라운드 프로세스를 알수가 없었다.

파일 처리가,SAP의 EP->D/A(Data Archive)->ECC 로 까지 복잡한 처리가 되어있는데,왜 이렇게 되었는지는 해당 개발자와 업무 담당자만이 알고 있다.
그리고 구현을 담당했던 개발자중 한사람은 계약만료되어 나가있고,다행히 옆자리에 해당 프로세스에 익숙한 개발자가 있어서 많은 도움을 받고 있다.

만일 담당한 개발자가,업무 담당자가 없다면 어떻게 됐을까,어떤식으로 업무 인수인계를 할것인가.

'결국은 모두 글쓰기' 이다.

동일한 모델의 또다른 뷰가 문서화라는 말에 무안함을 느끼지만, 일단은 수정중인 소스에 주석을 덧붙이고,오랜만에 비지오로 프로세스 순서도를 그려놓았다.한결 낫다.

대형 프로젝트가 시간이 갈수록 허우적대는건 왜일까.이만한 프로젝트는 앞으로도 접하기 힘들것 같은데,뭔가 필연적으로 그렇게 되어가는것 처럼 보인다, 마치 공룡이 멸망한것처럼.



하지만,무엇보다,반드시,하늘이 무너져도,퇴근시간은 꼭 지켜져야한다.



프로젝트는 낼도 모레도 계속된다.모르긴 해도 숭례문 완공될때까지도 계속 될꺼다,이름이야 바뀌겠지만.

'취미' 카테고리의 다른 글

참 아름다운 프로젝트  (0) 2008.12.24
Parallel Programming  (0) 2008.12.19
Extending Flex Builder3  (0) 2008.09.02
Hug a Developer  (0) 2008.08.29
Enterprise IDE Plugin  (0) 2008.08.27
Posted by iamyhs
,

유지 보수성.

취미 2007. 9. 13. 20:15
SE나,SD 자격증을 취득할때보면 항상 시험문제중에 나오는게 있다.한쪽은 하드웨어이고 다른 한쪽은 소프트웨어 개발인대도 공통된 사항은 용어만 다를뿐 같다,그건 바로

maintainability, flexibility, extensibility, scalability,

물론 여기에 몇가지가 더 있지만, 오늘 회의를 주관한분이 유지보수성을 강조하면서 최대한 개발자의 flexibility를 지양하고 오히려 템플릿 형태의 개발 방식을 제시해줬다.
꽤 면밀하고 냉정한 판단을 한것 같다.

속단일지 모르지만,상황상 제품의 질을 따질 계제가 아니다.1년전부터 프로젝트를 시작했으니 상당한 준비기가인대,앞단에 아직은 그 성능과 안정성에서 만족할만 테스트를 거치지 않는 제품을 채택했다.

그 와중에 이미 일정을 정해져있고,규모 측정도 제대로 한걸로 보여지는데 리스크 관리를 어떤식으로 할지 두고봐야겠다.이정도 규모인대 여러 복안을 가지고 있으리라 기대한다.

회의때 이 부분을 대 놓고 물었었다.

"프렘임웍을 선택하면 복잡도는 커진다,어쩌면 투입되는 개발자들에게 교육시간을 따로 들어갈지도 모른다.이런 리스크는 고려되어졌습니까?"

"개발자를 더 뽑아야죠, 그리고 프레임웍을 선택하고 한번 익숙해지면 속도는 오히려 더 빠르리라 예상합니다"

다시한번 유지보수성을 일순위로 강조하면서 언급한 말이다.물론 동의한다.걱정되는건, 사내에서도 프레임웍을 적용해본 결과,처음은 적응시간이 필요하다.많던 적던간에 그리고 개개인의 저항감도 상당하다.

지금이야 그 효용성과 유지보수성의 힘을 느끼고 있지만,
이 프로젝트는 추가로 한꺼번에 들어오지도 않을껀데,개발자들을 위해서 만들어진 프레임웍의 효율성과 그 복잡도의 상관관계가 어떻게 될까, 고민된다.

어쨋든 덕분에 국내에 나와있는 관련 프레임웍과 컴포넌트 차트등등 모두 다 테스트해볼수 있게됐다.

인터뷰때 각 티어별로 프레임웍을 써서 붙였던 경험을 언급했는데 그게 화근(?)이 된것 같다.알고 봤떠니 날 인터뷰 했던 그분이 회의를 주관하더라.
내 이름과 딴분의 이름을 언급하면서 그 파트를 맡어라했다.뜨끔했다!! 아니 사실, 그 순간 도망가고 싶엇다.

회의실 분위기가 인상적이었다.사방 벽면에 씌어져 있는 각 파트들과 개발자들 이름과 진척율을 보니 나도 모르게 얼굴이 굳어졋다.

맥시멈 리스크에 좋은 기회다.아자!

ps
개발자 서버에 산출물만, 얼핏 봐도 몇십기가다.거기에 따로 개인폴더를 만들게되어있었고,각 사용자가 1기가씩 쓸수 있었다.

가장 인상적인건(좋다는게 아니다) 최신 영화,만화 올릴 폴더도 함께 있었는데, 그 안을 살펴보다가 올라온 날자를 무심코 봤다.

..... ㅡㅡ;;;;;;;  당최 여긴 뭐하는곳이냐.






'취미' 카테고리의 다른 글

아키텍처에 관한 세가지 질문  (0) 2008.01.25
How to solve it  (0) 2008.01.18
JCO를 이용한 SAP 연결 테스트  (2) 2008.01.02
디버깅 FM  (0) 2007.12.21
표준  (0) 2007.12.21
Posted by iamyhs
,