BLOG main image
분류 전체보기 (92)
Cocoa Touch (11)
Cocoa (10)
Objective-C (13)
Swift (6)
Development (11)
Tools (11)
Books (7)
etc (21)
Application release (1)
Document Project (1)
106,090 Visitors up to today!
Today 0 hit, Yesterday 7 hit
daisy rss
tistory 티스토리 가입하기!
2013. 7. 15. 00:17
[etc]

앱스토어를 들여다 보다보면 상당히 낮익은 아이콘을 가진 앱들이 가끔 보이곤 하는데 이제 더 이상 그 앱의 코드를 손댈 일이 없는 경우가 있다. 뭐, 회사를 떠나거나 프로젝트를 떠나거나...

그런데 그게 잘 되었을 때 앞사람이 잘 해놔서 잘되었다는 말은 듣기 쉽지 않고 잘 안되면 꼭 앞사람이 일을 엉망으로 해놓아서 그렇다는 말을 듣는 경우가 많다.


한번은 우리 회사로 이직해 온지 얼마 안된 사람이 이직 전에 다니던 회사의 어떤 프로젝트의 코드를 면수습평가를 하던 나에게 욕하는 것을 들은적 있는데... 그 코드 내가 짰다. (물론 본인은 몰랐겠지)

뭐 오래전에 급하게 만든 코드라 잘 된 코드라 자랑하는 것과는 거리가 먼 코드지만... 정작 본인은 그 코드에 대해서 이렇쿵 저렇쿵 이야기 할 실력은 더더욱 아니라 조금 어이가 없긴 했었다. 결국 본인의 점수만 깍아 먹은 꼴이 된건데...


갑자기 이런 이야기를 해보고자 하는 생각한 이유는 기술자끼리는 제발 뒤에서 좀 까지말자는 이야기를 하고 싶어서이다. 기술적으로 이야기하고 싶은게 있으면 그 사람이 있을 때 정정당당하게 이야기하던가할 것이지 이미 떠단 뒤 없는 자리에서 악의적으로(설령 그렇지 않더라도) 그 사람의 작업에 대해 이렇쿵 저렇쿵 이야기 하는건 좀 아니지 않나 싶다.


어찌나 악의적인 경우도 있는지 심지어는 떠난 후에 전임자의 코드를 쓰지 말도록 종용 당한 사람들의 이야기도 들은 적이 있다. 쓸만한 프래임웍이라 팀원들이 알음 알음 그것을 기반으로 작업하고 있었는데 경쟁 팀에 있던 사람이 팀장으로 와서는 모조리 쓰지 못하게 강제했다는거다. 문제는 그 사람은 그 코드가 뭐 하는 것인지 제대로 이해도 못하고 있다는...


그 상황에서 항상 불리한 사람은 앞사람일 수 밖에 없다. 그들은 떠나면 대체로 뒷사람의 공격에 단 한마디의 변명도 하지 못한채 그냥 프로젝트를 말아먹는 사람으로 몰리기 쉽상이다. 그러니 따질게 있다면, 반드시 함께 있을때 따지고 넘어가는게 어떨까? 사람이 없는 자리에서 병신 만드는 것은 너무 쉽고 유치한 짓이 아닌가?


어찌되었건, 중요한 것은... 남의, 전임자의 코드 때문에 프로젝트는 망하지 않는 다는거다.

프로젝트가 망했다면... 그것은 전적으로 현재 작업하는 사람들의 문제이다. 정말 전임자의 코드가 문제가 있다면 리팩토링을 하던지 다 버리고 새로 작성하면 되지 않는가?



Name
Password
Homepage
Secret