취업한지 딱 한달 됐습니다. 걱정이 많네요.
집이 가깝다는? 이유로 DVR업체에 취업하게 되었습니다.
제가 이제 경력 2년 반 조금 넘어서 이제 프로그래머의 세계에 발을 반쯤 걸쳤구나 하는 생각이 한창 들고
무엇이든지 코딩하면 잘해보려고 하는 경향이 좀 있습니다.
VC프로그래머라서 (mfc 보다는 api) 좀더 하드하게.. 빠르게 먼가 있어보이게 짜고 싶은.. 아직 한창 모를때죠 머..
아무튼 일을 시작해서 소스를 넘겨 받게 되었는데
이 소스란게 사업 처음부터 시작해서 여러사람의 손을 거쳐서 부분부분 필요 없는 코드와 함수 변수도 꽤 있고
아마 쓰던 부분인데 필요 없는 부분 삭제나 개선으로 그렇게 된것 같습니다.
라이브러리는 MFC와 API가 완전히 뒤죽박죽 되있습니다. 또한 주석은 거의 안달려 있고..
요세 제가 에러처리와 디버깅 로그에 되한 클래스를 만들어볼까 한창 고민하고 있는데 이 소스는
에러 처리 조차 일관되지 않고 여러사람이 만졌던거 처럼 모든게 제 각가 이었습니다.
제가 너무 불만이 많은 것 일수도 있지만
아마도 이회사에서 지금 버젼이 3.0인데 1.0제작시 부터 사용되던 제각각의 라이브러리를 거의 수정없이 그냥 붙여 쓰기 형식으로
사용 하고 기능 추가만 하는 듯 싶습니다.
위에 소스코드보다 더 걱정 스러운건 개발팀 간에 아무리 실행가능한 프로젝트 단위로 하나씩 각각 맡겨져 있기로 서니 서로간의
대화나 공통된 형식 없이 그냥 자기꺼는 자기가 일률 적으로 알아서 하는 분위기 라는 겁니다.
제가 별거 아닌 일이 걱정만 많이 하는것 같기도 하고요
생각 같아서는 제가 맡은 프로그램만이라도 싹 갈아 엎어 버리고 싶은 마음도 있네요
하지만 제 상사는 일정에 쫓기고 기존 만들어 놓은 것이 있으니 최대한 활용 하는 것이 좋다고 합니다.
선배님들 조언 좀 부탁 드립니다.
어느 회사를
어느 회사를 들어가서든지..
처음 소스를 봤을때 비슷한 생각을 하시는 분들이 많을겁니다..
근데 한달쯤 지나면.. 이런 소스일수밖에 없구나 하게 돼죠..
님 외에 이전분들도 소스 보면서 뜯어 고치고 싶다고 다들 생각했었을겁니다.
몇달 지나고.. 님이 그 회사에 적응을 다 끝내고.. 시간적 여유가 있을때 다시 생각해 보시기 바랍니다.
입사한지 한달밖에 안된 신입이 소스 뜯어 고치겠다고 나오면 좋아할 분들 없을듯 하네요..
이런 소스일 수밖에 없구나
하는 게 개발 외적인 부분이 많다는 게 문제죠.
그냥 거기에 익숙해져 있어서 그걸 고치는 고비를 한번만 다같이 노력해서 넘기면 훨씬 편해지는데,
무리한 개발 일정이 때문에 쌓인 피로가 이유일 수도 있고 이미 매너리즘에 빠져서
기존 조직원은 대부분 실제로 문제를 문제로 인식하지 못합니다.
잘 몰라서 오해하는 부분일 수도 있지만 대부분의 경우 문제점은 어떤 조직에서든지 신입이 먼저 발견합니다.
단지 신입에게 해결을 맡길 수는 없는 이유는 신입은 그만큼 모르는 부분이 더 많기 때문에
고치다가 다른 부분을 망가뜨릴 수가 있는 거죠.
그것도 정확히 말하자면 모듈 의존성이 지나쳐서 그걸 숙지하지 못하고 있기 때문에 그런 것이겠죠.
정확히 말하자면 함부로 고치려고 덤비지 못할 만큼 간단히 고칠 수 있는 문제가 아니라는 겁니다.
하지만 고쳐야 한다는 원론적인 면에서는 신입의 지적이 맞을 가능성도 상당히 높습니다.
어떻게 고쳐야 할지는 모두가 한데 힘을 모아야 하는 문제지만요.
혁신이 가능한 조직은 신입의 의견을 잘 파악해서 결정권자가 확실한 개선 방향으로 이끌고 가는 것입니다.
그렇게 하려면 경험이 많고 새로운 정보에 밝은 엔지니어가 개발팀을 총괄하고 이끌어야 하는데
문제는 우리나라에서는 다들 지쳐서, 혹은 업계 분위기상 어쩔 수 없이 개발은 나이 차면 그만둬야
한다는 곳이 많아서 상급 개발자로 남아서 개발팀을 이끄는 경우는 드물다고 하더군요.
누가 -1점을 주었을지;;
다들 아실거 같네요 -0-
초보인생아키
초보인생아키
문제 되는 것은
저도 기존 소스를 최대한 활용하는 것은 환영하긴 합니다. 하지만
개발팀 전 직원이 소스를 전체 적으로 파악한 사람도 없을 뿐더러
수정 사항이라고는 막상 에러가 나왔을 경우 그부분에 한해서 임시 방편 이라는 것입니다.
이번에 새 버전을 만드는데 아마 제가 조금 진행된 상태에서 들어온거 같습니다.
그러나 새 코드에서도 이전 코드와 다를 바를 느낄수 없었으며
왠만하면 한 회사에 오래 다니고 싶은 마음인데
이런식의 코드를 계속 만져야 한다면 저 자신이 피곤해 질듯도 싶고
사실 뜯어 고쳐 보겠다고 생각을 하게 된건 팀 내에 공통적인 코딩 형식이나 정해 놓은 것이 없으며
자기가 맡은 프로젝트는 지지던지 볶던지 알아서 하라라는 다른 사람들의 생각(절대 서로 관여하지 않음)
에서 나온 발상 입니다.
일단...코드
일단...코드 중복은...버젼관리, 팀간의 communication 부재. 가 가장 큰 이유가 아닐까 싶습니다...
남이 뭘 만드는지 신경 안쓴다는 거지요 ㅎㅎㅎ 새로 갈아엎을 생각을 하시면..좀 힘들구요 (원래 개발자라는것이...남소스 보는것보단 새로 만드는걸 낫다...라고 생각하죠 ^^) 이런식으로 해보시는게 어떨까 싶습니다.
어차피 신입은 큰일은 없을 겁니다. (일이 많으시면 낭패 ㅋㅋ) 그럼...버젼관리,이슈트래킹 (Subversion & trac이 제격일듯...) 시스템을 만드시구요... 서로 대화를 계속해서 불필요한 코딩에 시간을 쏟지않는 방향으로 유도를 하셔야됩니다. 예를 들자면 이런식이겠죠...
A : 어이~ 그 XXXX하는 함수 있던가?
B : 음..그거 UTIL쪽에 있을껄 서버에서 다운받아서 봐봐
A : ...있긴한데 좀 미흡한데 이거 이렇게 고쳐보면 어떨까?
B : 그거 괜찮네 (아니면, '이런방식이 더 나아보이는데?') 그럼 수정해서 새버젼에 반영해둬.
------------------------------------------
Let`s Smart Move!!
http://kalstein.tistory.com/
그 의견이라면...
머 하는 일이야 입사해서 2주는 제 실력 테스트를 봤습니다.
코드는 보지 않고 결과 물만 2분 채 안되는 시간에 검토하고 말더군요(나름 실망 ㅠㅠ)
현재로서는 기존 소스 코드 분석 하고 있고 추가 업무로
현제 소켓 연결개수에 문제가 있어 제가 제안한 IOCP방식으로 새로 서버 방식을 바꾸기로하고
간단히 얼마나 견디나 부하 테스트 프로그램 제작 중에 있습니다.
아마도 분위기를 봐서 IOCP의 정확한 내용이나 돌아가는 방식은 아무도 신경 안쓰며 성능이 잘나오면 소켓 부분을
거의 전적으로 제가 맡게 될꺼 같은 느낌이 강합니다.
버젼관리나 이슈트래킹의 경우는 제가 전 회사에서도 제안했지만 안먹혀서 포기 했는데 그래도 전회사는 전적으로 저 혼자 코딩을 해서
서로간의 커뮤니티가 크게 필요 없었습니다.
여기와서 현제 백업방식(그냥 날짜별로 프로젝트 폴더를 통째로 압축해서 백업)을 보고 문제가 좀 있다고 생각하여
상급자에게 CVS라는거를 말해주니 이미 알고 계시는듯 했습니다. 하지만 별관심을 안보이시더군요 ㅠㅠ 새로 들어온 주제에
괜히 주장을 앞세우다가 오히려 잘 못 보일까 포기 했고요
주석이 너무 안달려서 제가 doxygen을 사용하여 힘들게 제가 만든 테스트 프로그램들에 주석 작업을 다해놓고 문서화 까지 해놔서
보여 줬더니 처음 말로만 문서화 자동으로 해주는게 있다 하실때는 흥미를 보이더니 막상 코드안에 주석 들어가는 것과 결과물을 보시더니
좋은데 혼자 쓰라고 친절히 말해 주더군요 ㅠㅠ
개발팀과 제 마인드가 많이 틀린것 같습니다. 그게 너무 힘들어요ㅠㅠ
위 사항을
위 사항을 체계적으로 문서화 해서 제안서 형식으로 제출해보는 것은 어떨까요?
그리고 간이로 CVS 서버를 구축해서 버전 관리의 편리성을 보여주는 것도 좋을 것 같습니다.
동병상련이군요..
저도 처음 회사에와서 정말 기겁했습니다. ㅜ_ㅜ
요즘도 기겁하고있구요..;;
예를들자면 한도 끝도 없지만..
코드가 C로 되어있는데 main.c 에 모든 기능이 들어가있고
변수는
BLAH_BLAH_t blah1[64];
BLAH_BLAH_t blah2[64];
BLAH_BLAH_t blah3[64];
함수는
send1()
{
ABCD;
ABAB;
AAAA;
}
send2()
{
ABCD;
ABAB;
AAAB;
}
이런게 수도 없이 많았죠.. ㅜ_ㅜ
소스 컨트롤은 고사하고 날짜별 백업조차 하지 않습니다;;
좌절하다가 높은 분께 건의해서 PPT로 SVN 사용법까지 만들어 세미나를 했지만
결국 아무도 안쓰더군요.. -_-
뭔가 더 하고싶어도 말단 개발자 입장에서 이정도 한것도 많이 나대는 행동이었을거 같아서 이제 자제하고있습니다.
지금은 그냥 나라도 잘하자 하는 마음으로 서버 하나 구해서 SVN 서버 올려놓고 사용하고있습니다.
소스도 되도록 예쁘게 유지하려고 노력중이구요.
공동작업이 별로 없다는게 그나마 위안거리이고..
예전 소스를 받아서 개선한 일이 있었는데 소스를 절반 이상 걷어냈는데도 이전보다 잘 동작한다는 것에
아무도 알아주진 않지만 뿌듯하게 생각하고있습니다.
소스에 대한 권한(?)이 있어서 그나마 이게 가능했죠.
어느 정도 돌아가던 소스라면
사실 새로 짠다고해서 성능이 탁월하게 좋아지는 경우는 없는것 같으니
기존 소스를 사용하라는 말씀도 일리는 있는것 같습니다.
하지만 계속 작업해야하는 소스라면 엉망인 상태를 파악하는데 시간이 더 오래걸리곤하죠.
구조를 바꾸기도 점점 힘들어지구요.
다 갈아 엎지는 못하시더라도 손대시는 부분만이라도 조금씩 청소를 하시면 점점 나아지지 않을까 하는 생각이 듭니다.
뭐 이건 제 자신에게하고싶은 말이기도해요.
사실 이런 상태의 소스코드 & 관리 상태를 보고있자면 의욕이 감퇴되는게 현실인거 같습니다.
저 자신도 조금씩 닮아가고 있는거 같아 무섭기도하구요.
제 소스를 누가 보게
제 소스를 누가 보게 된다면 윗 분들이 말씀하신 내용의 소스가 아닐까 싶습니다^^
모든 작업은 제 혼자하고 있습니다. 때론 이 방법이 맞을까 고민도 하게 되는데
뭐, 조언을 구할곳이라든지 고민해서 새로운 알고리즘으로 고칠 시간 여유도 없을뿐더러
계속, 한정된 자원(인력, 기간)으로 타 경쟁 업체 기능들만 바라게 되니 정작 디버깅 제대로 해본
경우가 없습니다.^^(물론, 제 게으름도 한몫 톡톡히 했구요)
원글 쓰신분이 계신 선배들도 그런 절차를 밟고 오다보니
새로 소스 엎을 시간적 여유를 못가지게 되지 않았나 싶습니다. '기존의 구현되어 있는 소스를
최대한 활용해보자' 하는 부분에서 지금의 저의 상황에 맞춰 생각해 볼때 저도 후배에게
그렇게 밖에 말 못할것 같습니다.
새로 다시 작성한다는거 자체가 원글 쓰신분에게 독으로 작용될겁니다.
-------------------
나는 Copy&Paster 이다. 나의 화려한 기술 조합에 모두들 나를 두려워 한다. 나도 코드 Maker 이고 싶다.
-------------------
나는 Copy&Paster 이다. 나의 화려한 기술 조합에 모두들 나를 두려워 한다. 나도 코드 Maker 이고 싶다.
소스 코드 양이..
소스 코드의 내용이 저혼자 하나하나 파악하기엔 절대 시간이 안따라 준다는걸 절실히 느끼고 있습니다.
제가 세운 계획은
1. 새프로젝트 작성
2. 이미 사용되는 라이브러리들을 이용하여 API로 UI 작성(라이브러리와 UI의 분리를 위하여)
3. 개발도중 틈틈히 라이브러리들을 분해 개조
솔직히 도저히 못 봐주겠습니다 ㅠㅠ
예를들어 시계 클래스..
현재 구현방법 UI를 포함한 시계표시 Child Window를 DLL파일로 만듬
제 생각엔 부모 핸들과 위치만 정해주면.. 알아서 붙는게 당연한데..
안에서 후킹을 하더군요.. 즉 메인 프로그램에서 윈도우를 만들어주고 HWND를 DLL에 넘겨주면
DLL에서 HWND의 WNDCLASS에서 WNDPROC부분을 자기가 만들걸로 교체 한후.. 사용 하더군요.
왜 저래야만 할지 참 이해하기 힘들었습니다.
그런데 저런 소스는 양호하다는거...
전체적으로 저래 버리니 분석도 힘들고 바꿔야 할 필요가 확실히 있을것 같습니다.
누구나 그런
누구나 그런 경험을합니다.
하지만, 처음부터 너무 혁신적인 모습을 보일 필요는 없다고 생각합니다. 적당한 선에서 이런 저런 재안을 하세요. 그리고, 작은 부분부터 조용히 시작하세요. 신입사원한테 바라는 덕목이 어느회사든 있을겁니다. 작게 꾸준히 실천하세요. 득이 있을겁니다. 힘내시구요!
--
콘쏠의힘
--
Life is short. damn short...