요즘은 제대로 블로그에 근황 쓰기 조차 힘들다. 시간이 없다기보단 환경이 좀 그렇네. 업무 시간에 블로그에 글 적기도 그렇고, 집은 인터넷이 되질 않으니. 오늘은 휴가라서 집 앞 PC방에서 이렇게 오랫만에 블로그에 글을 남긴다.
프로젝트는 금요일에 중간시연을 무사히(!) 마쳤다. 오늘은 수고했다고 전체 팀이 휴가 중이다. 내일부터는 다시 또 종료를 위해 달려야지. 현재 개발 상에 있어 큰 문제는 없지만, QA & CM 으로써 좀 아쉬운 면들이 많이 보인다.
우선 개발자의 SVN 활용면에서 문제가 보인다. commit 커멘트의 누락, 너무 잦은 commit, 깨지는 build가 가장 큰 문제이다.
commit 커멘트는 초기 교육때 한번 강조를 했고, 중간에 PL분들을 통해 다시 한번 전달을 하였음에도 불구하고 잘 지키는 사람 따로, 전혀 남기지 않는 사람 따로이다. 음, 아예 pre-commit hooking script를 통해 무조건 commit 커멘트를 남기도록 하는 것이 정답일까. 다음 개발 프로젝트가 있다면 반드시 적용해야 하겠다.
두번째로 너무 잦은 commit. 대게 2가지 유형이다. 이전 commit 에서 포함시켜야 할 내용을 넣지 않아서 그것을 위해 추가 commit 하는 경우가 있고, 테스트 해 보니 잘 안되서 개정된 내용을 다시 commit 하는 경우이다. 둘 다 충분히 피할 수 있는 문제이다.
먼저 포함시킬 내용 빼먹은 경우는 십중팔구 project 단위로 update/ commit 하지 않고 개별 파일이나 폴더 단위로 update / commit 하기 때문이다. 아무리 방금 전에 만든 따끈따끈한 모듈이라도 사람이 사람인지라 자기가 손 댄 파일을 일일이 tracking 하는 것은 힘들다. 또, 사람이 그렇게 tracking 할 이유도 없다. 그런 작업을 대신 하라고 소스코드 버전 관리 시스템이 있는 것이 아닌가. 그럼에도 불구하고 자꾸 일일이 찍어서 commit 하는 개발자들이 보인다. CVS에 너무 익숙해져 버린 개발자의 문제도 있다. CVS의 경우 파일 개별단위로 revision 번호가 부여되므로, 묶어서 commit 하나 하나하나 commit 하나 사실 다를 게 없다. 그러나 SVN의 경우 프로젝트 단위로 revision 번호가 부여되므로, 저런식으로 찔끔찔끔 commit 하다간 revision 번호가 금새 팍팍 올라가게 된다. 현재 우리 프로젝트 revision 번호가 2000에 가깝다. 한달만에 이렇게 revision 번호가 증가한 것은 정상적인 상태라고 보기 힘들다. 로그를 보면 심할 경우 몇분 사이에 revision 번호가 10도 넘게 올라가곤 한다.
잦은 commit에 대한 두번째 이유는 테스트 해 보니 문제가 발생되어 수정 후 다시 commit 하는 경우이다. 이 경우 대부분 화면단 문제가 아닌, service 단 문제인데, unit test 를 제대로 하지 않기 때문이다. test case 만 하나 만들어서 돌려보면 단박에 잡을 내용을, "음, 대충 도네?" 라고 하고 웹 페이지에서 이거저거 해 보다 문제 나오니 고쳐서 commit, commit....흐음.
그런데 이런 잦은 commit 을 막기 위한 대책은 언뜻 해결책이 잘 보이질 않는다. 이미 SVN 사용 및 unit test에 대한 교육도 했으므로 어느정도 개발자들에게 전달이 되었다고 생각하는데, 이리 잘 안된다. 프로젝트 단위의 commit 을 종용하는 것은 그나마 좀 더 쉬운데, unit test 적용은 정말 어려운 문제다. 개발자의 영역을 침범하는 듯한 느낌도 들고, 개발자 입장에서도 QA가 얼마나 시어머니같이 느껴질까. 내가 또 이런 싫은 소리 못하는 성격이라서. 결국은 초기 교육 시 좀 더 강조를 하고, 초반에 확실히 분위기를 잡아야 할 것 같다.
개발자의 SVN 사용 문제 뿐 아니라 eclipse subversive 문제도 있다. 팀 내에서 보고된 문제들은 유형도 다양해서 update 했는데 난데없이 예전 revision 으로 돌아가더라, 현 folder 에 대해 commit 했는데 상위 folder 에서 commit 된 것으로 되어 남의 code 날려버렸다는 등의 심각한 경우들이 있었다. 앞의 잦은 commit 등의 문제로, 진짜 도구의 문제인지 사람의 문제인지는 모르겠다. 하지만, 팀 내 subversive 의 신뢰도가 떨어진 이상 어쩔 수 없이 많이 불편해지긴 하겠지만 TortoiseSVN으로 갈야타야 할 것 같다. 흐음, 전반적인 상황이 맘에 들지 않아.
SVN 외의 문제로는 코드 품질 문제가 있다. 앞서도 나왔지만 역시 단위 테스트의 부실은 큰 문제이다. 대부분 CRUD 수준이라서 대단한 로직은 없지만, 일단 단위 테스트의 부재는 코드 신뢰성 측면에서 문제를 야기한다. QA로서 품질 수준을 유지할 방법은 test 에 대한 code coverage 를 유지하는 것인데, 현재 많이 나아져서 11% 정도이다. MVC 쪽은 다 빼더라도 service 들만 제대로 test해도 상당히 올라갈 수 있을 텐데. unit test는 귀찮은게 아니라 오히려 개발을 더 편하게 해 줄 수 있는, 하지 말라고 해도 하겠다고 해야 할 활동일텐데 ^^;. 아직까지도 unit test가 그렇게 확실히 자리잡지 않은 것 같다. 이젠 좀 확산될 때도 되지 않았나. 흐음...
이런 문제와 별도로, 가장 불안했던 Spring framework 적용 문제는 오히려 너무 깔끔하게 된 것 같다. 개발자분들의 새로운 framework에 대한 학습의지도 높고, 경험이 있으신 분들도 많아서 그랬던 것 같다. (아니면 내가 초기에 교육을 너무 잘 해서;;;) 하여간 spring framework 실무 적용은 문제가 없는 것으로 판단된다.
환경 적 측면에서는 WAS가 weblogic 이라는 것이 가장 큰 문제다. 초기에는 개발은 tomcat , deploy는 weblogic으로 정하였다가 별개의 환경때문에 발생할 수 있는 문제 방지를 위해 weblogic/ weblogic 으로 변경하였다. 그러나 weblogic은 도저히 개발 환경에서 쓸 수가 없겠더라. tomcat 에 비해 너무너무너무 느리다. 메모리 먹는 것도 장난이 아니고. 그래서 결국 tomcat / weblogic 으로 옮겨갈 수 밖에 없었다. 매일 weblogic 으로 deploy 하므로 어느정도의 문제는 찾아낼 수 있었지만 문제의 소지는 계속 안고 가고 있는 상태이다. 흐음.
이런 저런 소소한 문제/불만들이 있긴 하지만 전체적으로 프로젝트는 잘 진행되고 있다. 금요일의 프로젝트 시연 때에도 막판에 deploy 문제 발생해서 20분 남겨두고 겨우 deploy 성공하는 깜짝쇼를 벌이긴 했지만 (심장마비 걸릴 뻔 했다.) 어느정도 deploy 활동이나 CI 활동도 안정되게 유지되고 있다. 항상 문제는 막판에 터지기 마련이지만, 현재까지는 날씨 약간 흐리지만 대체로 쾌청한 수준.
@글 못 남긴 사이에 영화도 많이 보았지만, 너무 밀렸고 시간도 없어 올릴 엄두가 안난다. 장강7호, 다크나이트, 월E, 다찌마와리, 놈놈놈, 원티드... 흐윽. 파견근무 끝내고 본사 돌아가고 파.
프로젝트는 금요일에 중간시연을 무사히(!) 마쳤다. 오늘은 수고했다고 전체 팀이 휴가 중이다. 내일부터는 다시 또 종료를 위해 달려야지. 현재 개발 상에 있어 큰 문제는 없지만, QA & CM 으로써 좀 아쉬운 면들이 많이 보인다.
우선 개발자의 SVN 활용면에서 문제가 보인다. commit 커멘트의 누락, 너무 잦은 commit, 깨지는 build가 가장 큰 문제이다.
commit 커멘트는 초기 교육때 한번 강조를 했고, 중간에 PL분들을 통해 다시 한번 전달을 하였음에도 불구하고 잘 지키는 사람 따로, 전혀 남기지 않는 사람 따로이다. 음, 아예 pre-commit hooking script를 통해 무조건 commit 커멘트를 남기도록 하는 것이 정답일까. 다음 개발 프로젝트가 있다면 반드시 적용해야 하겠다.
두번째로 너무 잦은 commit. 대게 2가지 유형이다. 이전 commit 에서 포함시켜야 할 내용을 넣지 않아서 그것을 위해 추가 commit 하는 경우가 있고, 테스트 해 보니 잘 안되서 개정된 내용을 다시 commit 하는 경우이다. 둘 다 충분히 피할 수 있는 문제이다.
먼저 포함시킬 내용 빼먹은 경우는 십중팔구 project 단위로 update/ commit 하지 않고 개별 파일이나 폴더 단위로 update / commit 하기 때문이다. 아무리 방금 전에 만든 따끈따끈한 모듈이라도 사람이 사람인지라 자기가 손 댄 파일을 일일이 tracking 하는 것은 힘들다. 또, 사람이 그렇게 tracking 할 이유도 없다. 그런 작업을 대신 하라고 소스코드 버전 관리 시스템이 있는 것이 아닌가. 그럼에도 불구하고 자꾸 일일이 찍어서 commit 하는 개발자들이 보인다. CVS에 너무 익숙해져 버린 개발자의 문제도 있다. CVS의 경우 파일 개별단위로 revision 번호가 부여되므로, 묶어서 commit 하나 하나하나 commit 하나 사실 다를 게 없다. 그러나 SVN의 경우 프로젝트 단위로 revision 번호가 부여되므로, 저런식으로 찔끔찔끔 commit 하다간 revision 번호가 금새 팍팍 올라가게 된다. 현재 우리 프로젝트 revision 번호가 2000에 가깝다. 한달만에 이렇게 revision 번호가 증가한 것은 정상적인 상태라고 보기 힘들다. 로그를 보면 심할 경우 몇분 사이에 revision 번호가 10도 넘게 올라가곤 한다.
잦은 commit에 대한 두번째 이유는 테스트 해 보니 문제가 발생되어 수정 후 다시 commit 하는 경우이다. 이 경우 대부분 화면단 문제가 아닌, service 단 문제인데, unit test 를 제대로 하지 않기 때문이다. test case 만 하나 만들어서 돌려보면 단박에 잡을 내용을, "음, 대충 도네?" 라고 하고 웹 페이지에서 이거저거 해 보다 문제 나오니 고쳐서 commit, commit....흐음.
그런데 이런 잦은 commit 을 막기 위한 대책은 언뜻 해결책이 잘 보이질 않는다. 이미 SVN 사용 및 unit test에 대한 교육도 했으므로 어느정도 개발자들에게 전달이 되었다고 생각하는데, 이리 잘 안된다. 프로젝트 단위의 commit 을 종용하는 것은 그나마 좀 더 쉬운데, unit test 적용은 정말 어려운 문제다. 개발자의 영역을 침범하는 듯한 느낌도 들고, 개발자 입장에서도 QA가 얼마나 시어머니같이 느껴질까. 내가 또 이런 싫은 소리 못하는 성격이라서. 결국은 초기 교육 시 좀 더 강조를 하고, 초반에 확실히 분위기를 잡아야 할 것 같다.
개발자의 SVN 사용 문제 뿐 아니라 eclipse subversive 문제도 있다. 팀 내에서 보고된 문제들은 유형도 다양해서 update 했는데 난데없이 예전 revision 으로 돌아가더라, 현 folder 에 대해 commit 했는데 상위 folder 에서 commit 된 것으로 되어 남의 code 날려버렸다는 등의 심각한 경우들이 있었다. 앞의 잦은 commit 등의 문제로, 진짜 도구의 문제인지 사람의 문제인지는 모르겠다. 하지만, 팀 내 subversive 의 신뢰도가 떨어진 이상 어쩔 수 없이 많이 불편해지긴 하겠지만 TortoiseSVN으로 갈야타야 할 것 같다. 흐음, 전반적인 상황이 맘에 들지 않아.
SVN 외의 문제로는 코드 품질 문제가 있다. 앞서도 나왔지만 역시 단위 테스트의 부실은 큰 문제이다. 대부분 CRUD 수준이라서 대단한 로직은 없지만, 일단 단위 테스트의 부재는 코드 신뢰성 측면에서 문제를 야기한다. QA로서 품질 수준을 유지할 방법은 test 에 대한 code coverage 를 유지하는 것인데, 현재 많이 나아져서 11% 정도이다. MVC 쪽은 다 빼더라도 service 들만 제대로 test해도 상당히 올라갈 수 있을 텐데. unit test는 귀찮은게 아니라 오히려 개발을 더 편하게 해 줄 수 있는, 하지 말라고 해도 하겠다고 해야 할 활동일텐데 ^^;. 아직까지도 unit test가 그렇게 확실히 자리잡지 않은 것 같다. 이젠 좀 확산될 때도 되지 않았나. 흐음...
이런 문제와 별도로, 가장 불안했던 Spring framework 적용 문제는 오히려 너무 깔끔하게 된 것 같다. 개발자분들의 새로운 framework에 대한 학습의지도 높고, 경험이 있으신 분들도 많아서 그랬던 것 같다. (아니면 내가 초기에 교육을 너무 잘 해서;;;) 하여간 spring framework 실무 적용은 문제가 없는 것으로 판단된다.
환경 적 측면에서는 WAS가 weblogic 이라는 것이 가장 큰 문제다. 초기에는 개발은 tomcat , deploy는 weblogic으로 정하였다가 별개의 환경때문에 발생할 수 있는 문제 방지를 위해 weblogic/ weblogic 으로 변경하였다. 그러나 weblogic은 도저히 개발 환경에서 쓸 수가 없겠더라. tomcat 에 비해 너무너무너무 느리다. 메모리 먹는 것도 장난이 아니고. 그래서 결국 tomcat / weblogic 으로 옮겨갈 수 밖에 없었다. 매일 weblogic 으로 deploy 하므로 어느정도의 문제는 찾아낼 수 있었지만 문제의 소지는 계속 안고 가고 있는 상태이다. 흐음.
이런 저런 소소한 문제/불만들이 있긴 하지만 전체적으로 프로젝트는 잘 진행되고 있다. 금요일의 프로젝트 시연 때에도 막판에 deploy 문제 발생해서 20분 남겨두고 겨우 deploy 성공하는 깜짝쇼를 벌이긴 했지만 (심장마비 걸릴 뻔 했다.) 어느정도 deploy 활동이나 CI 활동도 안정되게 유지되고 있다. 항상 문제는 막판에 터지기 마련이지만, 현재까지는 날씨 약간 흐리지만 대체로 쾌청한 수준.
@글 못 남긴 사이에 영화도 많이 보았지만, 너무 밀렸고 시간도 없어 올릴 엄두가 안난다. 장강7호, 다크나이트, 월E, 다찌마와리, 놈놈놈, 원티드... 흐윽. 파견근무 끝내고 본사 돌아가고 파.
덧글