[[ blog 이사 과정에서 정확한 posting날짜가 분실됨. 년도와 분기 정도는 맞지 않을까? ]]

In case that several branches are maintained at the same time, 'change list'(ex. bug fix) tends to be patched to several different code branches. General way to apply 'change list' is code-merge. In this case, the guy who merges 'change list' may not know enough about change. So, there should be information about checking patch result - to verify that patching is successful or not - as a comments of 'change list'.

One of good example is something like this.
* before patch : title string is "xxxx" in screen A.
* after patch : title stringis "yyyy" in screen B.

[[ blog 이사 과정에서 정확한 posting날짜가 분실됨. 년도와 분기 정도는 맞지 않을까? ]]

다른 사람과 같이 일하다 보면, 서로가 일하는 style, 가치관 등이 맞지 않아서 갈등이 발생하는 경우가 많다. 그리고, 이 갈등 때문에 사람을 관리하는 노력이 들게 된다. 그렇기 때문에, "Good to Great"에서 "관리해야하는 사람이라면, 쓰지 않는 것이 낫다."라는 논조로 이야기 하고 있는지도 모르겠다. 반면, "Good to Great"에서는 이렇게 이야기 하기도 한다. "적합한 사람이 아니라고 판단하기 전에, 그 사람이 적합하지 않는 자리에 있는 것은 아닌지 생각해 보아야 한다.". 절대적으로 동의한다.

난, 한 번 같이 일해보고, 잘 맞지 않은 것 같아서 바로, 그 사람과 같이 일할 여지를 뿌리채 뽑아 버린 경험이 있다. ("같이 일하고 싶지 않다."고 단도 직입적으로 이야기 했다.) 지금 돌이켜 생각해 보면, 얼마나 성급한 결론이였던가? 그런 결론을 내릴만큼 난 충분히 상황을 고려했었는가? 정말 그 사람과는 같이 일하기 힘든 사람이였던가? 지금 다시 생각해봐도 성급한 결론이였던 것 같다. 그리고 설사, 적합한 사람이 아니라고 생각되더라도, "같이 일하고 싶지 않다" 라는 식의 단도 직입적인 말은 피하는게 당연한 도리일진데, 난 그리하지 못했다. (한국말은 '아' 다르고 '어' 다르다.)

이러한 일이 반복되지 않도록... 반성의 시간을 가져 본다.

[[ blog 이사 과정에서 정확한 posting날짜가 분실됨. 년도와 분기 정도는 맞지 않을까? ]]

여러사람이 다양한 지역에서 같은 code branch를 가지고 작업할 경우, 특정인이 check-in한 code가 branch전체를 망치는 경우가 발생한다. build가 안될 수도 있고, program running초기에 비정상 동작으로 test자체가 불가능할 수도 있다. 한국과 영국 두 나라 개발자들이 같이 일을 하고 있는 상황을 생각해 보면, 한국인 개발자 누군가의 check-in 으로 인하여 branch가 전체가 망가지고 나서, 한국 사람들이 다 퇴근하면, 영국에서는 다음날 한국 사람이 출근할 때까지, 시차를 생각하면, 영국사람 입장에서는 working time내내, 아무일도 할 수 없게 된다. 물론, branch에 submit하는 개개인은 본인의 local pc에서 test한 후 정상 동작하는 것을 확인하고 branch에 check-in하겠지만, 개개인 local에 항상 최신 revision의 code를 가지고 있지는 않기 때문에 (항상 최신 revision의 code를 local에 유지하는 것은 상당한 overhead를 수반하기 때문에 이를 강제할 수는 없다. - 만약 이를 강제한다면, 여러사람이 일할 경우에는 sync받고 build하는 것 이외의 다른 일은 거의 할 수 없을 수도 있다.) 이전에 다른사람이 check-in한 code와 충돌해서 이런 현상이 벌어질 수도 있다.

그렇다면 이런 문제를 어떻게 해결할 수 있을까?
나는 이런 방법을 생각해 본다.

해당 branch에서 일하는 개발자들은 항상 자신이 일하는 office의 local time으로 오전, 9시~10시(출근하자마자) 사이에만 branch에 submit하도록 한다. 이렇게 하면, 그 날 하루동안 같은 time zone에 있는 여러 개발자들이 이 branch를 검증할 수 있는 시간이 생기고, branch에서 발생한 문제점을 check-in한 사람이 퇴근하기 전에 발견할 확률이 높아진다.

음.. 실제로 적용해 본적이 없으니... 효과는 잘...-_-;

+ Recent posts