Heart’s Develop Inside

‘Ship It’ 을 읽는 중에 공감가는 부분이 있어서 일부만 발췌하여 적어 본다.

‘버스 번호’ 란 그만한 수의 개발자를 잃게 되면 프로젝트를 망치는 그런 숫자를 말합니다. 회사를 나가든, 말 그대로 버스에 치이든 이 정도 수의 사람을 잃게 되면 프로젝트가 탈선하게 됩니다.

프로젝트의 모든 세부 사항을 자신만 알고 있는 슈퍼스타가 있다면, 버스 번호는 1이고, 그렇다면 문제가 있는 겁니다.

사실 요즘 비슷한 상황에 직면하고 있어서(한 파트를 혼자 작업해 오셨던 분의 이탈) 더더욱이나 공감가는 이야기인 것 같다.

파트가 정확히 나뉘어지는데, 그 파트를 개인이 혼자 해 왔을 경우 그 개인이 회사를 이탈할 때 상당한 파장이 일어난다. ‘인수인계’ 라는 작업을 거치긴 하지만, 1달여 간의 기간에 완전히 모르는 사람을 얼마나 익숙하게 할 수 있을까?

현재 인수인계 작업 중이지만, 그 분이 이탈하시고 나서 현재 팀이 이전만큼 제대로 돌아갈 수 있을지 좀 걱정이 된다. 나가는 사람도 부담되고, 팀을 지키는 사람도 부담되는, 뭐라 형용하기 어려운 상황이랄까…

문서화의 중요성과 넉넉한 인력의 필요성을 몸으로 실감하는 중이다.
(음… 물론 책에서 제시하는 예광탄 개발도 좋은 방법이지만…)

ps. ‘버스번호 1′ 이라는 의미는 회사 내 독보적인 위치를 점하고 있다는 얘기이고, 연봉 협상에서 필살기 ‘배수의 진’ 을 칠 수 있다는 엄청난 장점이 있지만, 반대로 회사 이탈을 생각중이라면 인수인계라는 엄청난 부담을 가지게 된다는 단점이 있는 것 같다.
음… 나는 버스번호 1을 선호하지 않는다…만 어쩌다 보니 나도 이것저것 혼자 만들고 혼자만 알고 있는 게 많다…-_-;; 시간 나는 대로 문서화 작업을 시도해야겠다.

@ WLXQuickTimeControlHost.exe 문제 해결하기

나도 이 문제 때문에 QuickTime을 지웠는데, iTunes를 써야 되는 관계로(…) 어쩔 수 없이 다시 설치하고 ‘그냥 팔자려니…’ 하고 지냈는데, 왠일로 방법이 있었다.

미리보기 캐싱 문제이기 때문에, 해당 확장자에 대해 레지스트리에서 미리보기 캐싱을 막아버리면 된다고 한다.
이 분은 mov 파일이 문제여서  mov 확장자를 삭제하였고, 본인은 곰인코더로 아이팟 터치용 MP4 파일을 만들면 이 파일들에서 이런 문제가 생겨서 mov, mp4 확장자를 삭제하였다.

방법은,

레지스트리편집기(regedit)에서 [HKEY_CLASSES_ROOT\.확장자명\ShellEx]키를 삭제

오… 간단한데? 이제 인코딩 하고 나서 정리할 때 고생 좀 덜 하겠다. 후후…

ps. 근데 ‘Windows Live 사진 갤러리’ 랑 같이 쓸 경우로 써 있는데 확실한 건가? 쓰지도 않는 거 깔아놓긴 했는데 지울까 싶기도 하고… 음….

내가 요즘 자주 다루고 있는 프로그램들은 회사 내에서는 꽤 오랜 역사(?)를 가지고 있는 프로그램들이다.
솔루션의 메인 어플리케이션인데, 오랜 역사를 가지고 있는 만큼 많은 사람이 손 댄 흔적이 소스에 남아 있다.
무슨 뜻일까?
음… ‘인수인계’ 라는 것을 받아 본 사람들은 무슨 이야기를 하려던 건지 아마 알 것이다.

아무튼, 그 오랜 역사를 남의 손에서 뒹굴다가 내 손으로 들어온 친구들(?)은 솔직히 내가 설계부터 구현, 테스트, 구축까지 참여한 어플리케이션들보다 더 정감이 갈 수는 없겠지만, 어쨌던 내 일이니까 군말 없이 작업하고 있다.
(울고싶다 ㅜ.ㅜ)

특히 회사 솔루션 전략(특성?) 상 사이트 별로 커스터마이즈가 꽤 많다.
사이트 커스터마이즈가 있을 때 마다 소박하지만 나름 심각한 고민을 하게 된다.
이걸 전처리기 & Conf. 로 추가/수정을 해야 할 지, 아니면 새로운 프로젝트로 분화시킬지…

입사 초기에는 소스가 깔끔한 쪽이 낫지 않을까 싶어 조금 복잡하게 커스터마이즈되는 경우(기존 소스와 뒤섞이는 경우)에는 새로운 프로젝트로 만드는 방법을 써 왔고, 그 때는 나름 괜찮은 판단인 듯 보였다.

하지만, 원본 소스 자체가 개선의 여지가 많은 프로젝트였기에 시간이 갈 수록 원본 프로젝트와 분화한 프로젝트의 갭이 커져만 갔다. 대부분의 버그 패치는 원본 프로젝트에만 이루어졌다. 한번 두번 그렇게 지나가다 보니 원본 프로젝트에서 버그가 발견된 것이 분화한 프로젝트에서도 동일하게 일어난다는 보장이 없을 정도가 되었다.

그래서, 요즘은 쪼개진 프로젝트들을 다시 하나의 프로젝트로 묶고 있다. 리소스도 ‘#undef 와 #define 으로 리소스 번호 바꿔치기’ 를 통해 합치고 있다. 소스 코드는 전처리기 & Conf.로 거의 점령된 상태이지만, 일단 일관된 관리는 확보했다.

이제 전처리기 & Conf. 가 점령하고 있는 소스들을 재정리해 줄 멋들어진 방법을 찾아 머리를 굴려보고 있는데, 실력이 부족한 탓인지 그다지 생각이 나진 않는다. 커스터마이즈용 커스텀 클래스를 만들까 싶은데 커스터마이즈 자체가 일관성이 그다지 없다 보니 잘 될까 의문이다. 아무튼 계속 생각해 봐야 겠다.

리팩토링의 중요성을 몸으로 실감하는 중이다. 음… 리팩토링도 난잡한 코드 앞에서는 무릎을 꿇을라나?
TDD, CI 등이 적용된 프로그램에서 고생 없이 일하고 싶다. 그 전에 내가 실력을 키워야겠지.