|
|
||||||||
| 경고! 게시물 작성자의 사전 허락없는 메일주소 추출행위 절대 금지 |
|
이건 진짜 개발언어에 상관없이 프로그래밍을 하는 곳이라면 심각히 고민을 하는 딜레마인데.
물론 안그런곳도 있스빈다... 이사람 저사람 소스코드를 바꿔대다가 2,3년 후에는 머리 따로 다리 따로노는 시스템으로 인해 더 이상은 관리를 포기하고 차세대 시스템 구축이란걸로 도망가곤 하죠. -_-; 공용모듈이나 인터페이스, 부모/자식 클래스들에 대해서는 애초부터 시스템 구조설계의 의도를 이해하면서 소스수정을 가해야 한다는 게 문제인데.. 막 새로 투입된 개발자가 처음부터 전체 시스템의 구조설계 의도를 이해하고나서 소스코드 수정점을 결정하기 어려우니까요. 시간은 급하다보니 일단 자기 시야에 보인 부분만 기준으로 수정하게 되고..... 이런게 쌓이면 아무리 아키텍쳐를 잘 주의깊게 설계해도 얼마안가 시스템 구조설계의 의도같은건 사라져버리고... 결국 그래서 나오는게 소스코드 변경위치를 결정하는 사람과 코딩하는 사람을 분리한다는 건데, SDS나 C&C, CNS등등에서 몇년째 시도는 해오고 있지만 아직 정착하긴 쉽지않은 상황입니다. 가끔 "내가 다 알아서 고칠 수 있는데, 왜 작업위치를 지시받아야 하냐?"라는 반발하는 사람도 봤는데, 개발자의 기술적인 수준과 해당 시스템에 대한 업무로직/구조이해는 별개의 영역이라는 것을 이해해줬으면 싶더군요. (문제해결을 위해 소스코드를 고치는 선택사항이야 수만가지지만 시스템 구조의 일관성을 유지하는 범위 내에서 수정해야하는게 관건이니까.) 그래서 유닛테스트라는 것을 합니다. 특히 말씀하신 공유코드처럼 중요도가 높을수록 좀더 철저하게 합니다. 사람은 실수를 할 수 밖에 없기 때문에, 또한 소스의 복잡도가 올라갈 수록 그것을 컨트롤하기 어려워지기 때문에 무언가 안전장치 내지는 검증장치가 필요합니다. 내가 이걸 이렇게 고쳤는데, 제대로 동작할까? 이 수정으로 인해서 전에 잘 작동하던 것에서 버그가 생기지는 않을까? 그래서 흔히 프로그램을 실행해서 기능을 테스트해 봅니다. 하지만 아시다시피 한계가 많기 때문에 다른 방법이 필요합니다. 그게 유닛테스트라는 겁니다. 뭐 물론 설계를 잘하는 것도 중요하겠고 이런저런 다른 중요한 것들도 있지만, 결국은 돌려봐서 결과가 정확히 나오는지 확인해 봐야 합니다. 그래서 유닛테스트를 해야 합니다.
공통코드 ......
순수한 API라이브러리성 ... 혹은 프레임워크의 Core모듈들로만 구성을 할수 있도록 최대한 군더더기를 빼야 합니다... 예를 들어 프레임워크 구조가 좀 복잡한 은행의 프레임워크 구조에는 표준전문( 시스템 전문 ) 같은 것이 있는데... 프로젝트 발주사 별로 이 부분은 많이 달라지는 부분입니다만... 프레임웍크 자체에서도 아주 중요한 정보를 가지는 부분이 랍니당. 이 예에서 .... 만약 프레임워크를 개발하는 회사에서 표준전문 영역을 프레임웍크의 공통코드 영역으로 간주해버리게 되면 프로젝트가 발주 될때마다 심각하게 고객과 대립하는 구도가 발생할 수 있습니다... 프레임웍크 구성에서의 공통 요소( 아키 래벨 ) 와 업무단위레벨의 공통요소( 업무 레벨)를 잘 구분해내는 눈을 갖기 위해서는 많은 프로젝트의 경험을 통하지 않고는 불가능한 일이라고 사려 됩니다.... 지금 처럼 업무와 시스템의 공통 요소를 분리하는 눈을 계속 가지고 프로젝트를 하다보면... 자연스럽게 공통이라는 업무 영역이 어떻게 설정 되어야 한다는 것이 보이게 되지 않을까 싶습니다. 너무 조급하게 생가하지 마시길 ... 이런 글을 보니 참 흐뭇하군용. 관련 글 리스트
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Copyright © 1999-2015, borlandforum.com. All right reserved. |
우선 말씀하신 "공통코드"라는 것은 회사 내부에서 사용하는 라이브러리 정도로 보면 되겠네요.
1. Version Control이 매우 중요합니다. 저 같은 경우에는 제품을 Release하면서 소스 관리 모듈을 이용하여 항상 tag를 달아 놓습니다. 그렇게 해야만 나중에 문제가 생겼을 때 release되었을 때 당시의 소스 코드를 이용해서 디버깅을 해야 하기 때문이죠. CVS/SVN/GIT 가 많이 사용됩니다.
2. Core 모듈에 대해서는 UnitTest를 구축해 놓으시기 바랍니다. Core 를 변경하면 "Core를 프로젝트A, B, C에 적용시키면 문제가 생기지 않을까?' 하는 걱정이 들 수가 있죠. 이럴 때 UnitTest는 굉장히 큰 안심을 줄 수 있습니다.
3. 다양한 디자인 패턴을 숙지해 보시기 바랍니다. 프로젝트를 할 때 이런 패턴으로 해야 한다, 저런 패턴으로 해야 한다라는 똑 쪽 찝어서 정답이 있는 것은 아닙니다. 다만 여러 가지 패턴을 익히고 있다면 많은 도움을 주죠. 코더에서 프로그래머로 넘어 가는 관문 정도로 보시면 될 것 같습니다. http://en.wikipedia.org/wiki/Software_design_pattern
"고민"이라는 것은 신입때만 있는 것이 아니고 경력이 많은 개발자들에게도 항상 닥치게 되는 문제입니다. 항상 고민하시고, "how"보다는 "why"라는 의문을 갖는 자세를 가지시기 바랍니다.