글
도서 2008. 7. 4. 09:02초난감 기업의 조건 - 읽기 시작하다.
뭐...잡담에 가까운 글이지만...그래도 책 관련 내용이니까 도서 카테고리로 낙인!
앞부분만 약간 읽기 시작했는데...오호 이거 왠지 재밌을것 같다. 뭐 IBM의 OS/2의 실패 이야기는...소싯적 아버지 회사가 IBM인지라...OS/2를 써보면서 '아...이거 WIN32만 지원하면 좋을텐데. 윈도보다 잘 죽지도 않고 좋은데' 란 생각을 했던 나에게 추억거리를 곰씹을 기회를 줄 것 같기도 하고...
솔직히 우리나라에서 프로젝트 실패 이야기는 잘 떠돌지않는다. 완전히 회사가 망하지않고서는. 하지만 '성공'한 프로젝트들 속에 많은 프로젝트가 실질적으로는 실패한 프로젝트다. 한 예로...내가 예전 산업체 다닐때 마지막으로 했던 H사의 프로젝트는...유지보수의 난해함으로 인한 실패한 프로젝트로 봐야한다. 그러나...외부적으로는 성공적인 프로젝트로 광고하겠지. ㅎㅎㅎ
그때 문제는...다중 DB를 사용하는것이었다. 그것도 속도를 위한 memory db를 사용한 수준이 아닌...10개였나? 뭐 그정도였고...DB들의 sync는 개발자가 직접-_-제작한 XML을 이용해서 제작되어졌었지. 왜냐고? 글쎄. 처음부터 아키텍쳐가 잘못 된것이고, 특히나 DB를 잘 만들어서 DB1개로 할 생각을 하지못했고 (역량이 딸려서.) 그리고 XML로 sync를 맞춘것은...TCP통신만 신뢰할줄 알았다고 해야되나. 여튼 그런식으로 하다보니...개발했던 인원이 어느정도 빠진 후에는 유지보수의 난해함으로 인해 계속 문제점은 발생하고...디버깅은 어렵고 ^^;;
나? 변명을 하자면...이미 아키텍쳐를 세운 다음에 투입되었고, 그것을 엎을만한 힘이 없었고...(계속 주장은 했었지만...) 뭐 여튼...그런 프로젝트를 했던 기억을 나게하는 책일듯 싶다. ㅎㅎㅎ
솔직히 현 회사에서도 기존에 소스를 만들었던 사람 한두사람이라도 없어지면 유지보수가 가능할지 의문인 부분이 많긴한데...하긴. 회사에 전적으로 묶인 사람들이 한둘이 아니니 괜찮으려나? (회사코앞의 집을 사고 - 집사는게 보통일이 아니니까. 돈이 넘치면 모를까 - 이만한 보수를 주는 회사가 국내엔 그렇게 많지않고. 플랫폼 잠금 이라던가 벤더 잠금..같은건 들어보긴했는데, 직장 잠금 이란말이 있나? 없으면 내가 쓰는게 최초가 될지도 하핫)
여튼 도서관에서 빌린 책이니...제시간내에 다 볼수있도록 열심히 읽어봐야겠다~
트랙백
댓글
글
잡동사니 2008. 7. 1. 16:51단순함의 미학.
Simple is beautiful.
충분히 동의하는바이다... 가만보면, 좀 더 생각하고 고려해서 한방향으로 쉽게 갈 수 있는길을... 대충 생각하고 이렇게저렇게 하다보니 '어? 안되네?' 하고 다시 옆길로 샛다가 다시 돌아오는..우회도로 코드를 작성한다. 결과는? 원래 생각한 대로의 방식이 아니므로 논리적이 구멍이 생기고 그로 인해 버그가 발생한다...
그래서 하나의 함수 및 클래스는 하나의 일만 담당하는것이 좋다.
그러나 만들다보면....특정 클래스(혹은 함수)에서 A, B 작업이 있는데 거의 대부분의 작업들이 A -> B 순서대로 진행되어진다. 그럴경우 많은 개발자들이 사용자 편의를 위한답시고 저 2가지의 함수를 아예 합쳐버리거나(...) 혹은 클래스 public 함수로 하나의 함수를 더 만든다. 그러지 말자는것.
차라리 따로 helper 함수를 하나 만드는것이 훨씬 좋다. 지금 A->B 상태라지만 나중에 C가 추가되어서 A->B->C가 될수도 있잖아? 어떻게 바뀔지는 아무도 모르는일. 그렇다면, 클래스 자체에서는 깔끔하게 하나의 작업만 하는 함수들을 남겨두고, 일괄처리같은거를 helper 함수로 해놓았으니 그것만 수정한다면, 기존 소스코드를 고치는 일도 적어지고, 보다 flexible 하게 대처할 수 있는것이지.
C로 생각한다면, struct A, B 가 있다고 치자. 근데 둘간에는 공통분모가 있다고 한다면 그것을 따로 빼서 A, B, C로 만들고, C를 처리하는 함수를 fooC()로 하고나면, fooA() 에서는 A에 해당되는부분 처리 후 fooC() 를 호출하고, fooB()에서는 B에 해당되는부분 처리 후 fooC()로 처리하는것.
구조체 개수가 2개에서 3개로 늘어났으니 더 관리가 힘들어졌다? 전혀 그렇지않다. 오히려 기존의 fooA,fooB 함수에서 처리하던 공통적인 부분을 fooC()로 분리해냈으니 코드 사이즈가 줄었고, 공통적인 부분인 C 부분에 대한 코드가 duplicate 되어있던것을 삭제했으니 오히려 개선효과가 있는것이다.
결론은? 기능추가 시에 급하다고 무턱대고 추가말고, 좀 더 생각해보면 간단한 방법은 존재하기 마련이라는것.
ps : 그러나...simple is best 는 아니다. 분명히 복잡하게 풀어야하는 것도 존재한다. 그러나, 그 복잡한 문제마저도 보다 간단하고 명료하게 문제를 풀 수 있는것이야 말로, 더 좋은 개발자가 되는 방향이 아닌가 싶다.
트랙백
댓글
글
잡동사니 2008. 6. 4. 20:42사용툴의 자유를 보장하라~ 보장하라~
아. 2MB덕분에 80년대로 돌아갔으니...군대문화가 만연한것도 당연한가? -_-;;
뭐 여튼...회사에서 내 프로젝트는 현재 "Trac" 으로 운영되고 있다. Subversion(이하 SVN)을 이용해서
이리저리 프로젝트 관리가 되는 시스템. 그냥 내혼자서...없으면 무쟈게 불편할것임이 뻔하기에
도입해서 사용중인데...위에 부사장'님'께서 우리파트는 소스관리도 안하느냐 하고 한소리하자...
소파트장 수석'님'께서 땜빵으로 내가 사용하고있는걸 데모한것 같더라... 그래서 일단 결론은
2개월안에 프로젝트를 모두 올리라고 지시 및 필요한 상용툴이 있다면 지원요청해라.
뭐 여기까진 나름 굳. 매우 바람직한 모습 아닌가? 그러나....두둥.
오늘...SCM을 VisualSourceSafe(이하 VSS)로 구성하랜다. -_-;;; 이뭥뮈;;;;;;;;;;;;;;
VSS는 MS툴로써...MS 개발툴들과 매우 밀접하게 연동되는 시스템이다. 그러나..단점이 좀 있어서
MS툴을 쓰지않는 경우에라면 잘 쓰이지않는다. (MS툴을 쓰더라도 잘 안쓰는경우가 많다. 뭐...
단점이 약간있긴하지만 그것보다는 SVN이 더 좋은것)
그런데 그걸 쓰라고? 아니왜? ㅡ.ㅡ;;; MS에 커미션이라도??
이유는...부사장이 이끌었던 예전팀이 VSS를 썼기때문. 다시한번...이뭥뮈;;;
이건...내가 울트라에디트 쓰는데 상부에서 자기가 예전에 노트패드써보니까 좋더라~ 하면서 그거 쓰라는격이다.
거참, 사용툴의 자유도 보장못하나;;;;
내가 부사장'님'이랑 "싸우자!!" 할순 없으니...(뭐 못할건 없지만 -_-a;; 그래도 부사장이랑 싸운 최초의 사원이라는 타이틀은...그닥;;;) 참 답답하긴하다. 에혀...이 무식한 바닥을 떠야하려나?
1인 시위라도 할까? 타이틀은...
'사용툴의 자유를 보장하라~ 보장하라~~'
RECENT COMMENT