Ting 이네 Software 이야기

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

On Android, usually developer just set parameter of layout (LayoutParams.FILL_PARENT ... etc) for compatibility.

Then, when the exact size of each view is determined? The size of each View is decided when "onLayout()" is called.

The problem is, sometimes we need to know exact size of some Views and do something with this.
In this case, in my opinion, "onWindowFocusChanged()" is quite good place to do this. (in Activity).
At the moment when "onWindowFocusChanged()" is firstly called, all exact size of Views are decided. That is, we can get each View's exact size by calling "getWidth()/getHeigh()". - yes, I know. We need to handle quite many exceptional cases... :-(
But, until now, I cannot find any better place to do this.

Note!
Views added at "onLayout" of ViewGroup, are not drawn in Canvas before layout is re-updated!.

pseudo code)

    class View myView {
        onDraw(...) { // -- (*1)
            ...
        }
    }

    class LinearLayout layout {
        onLayout(...) {
            addView(myView)... // ---(*2)
        }
    }

At (*2), we can know exact size of 'layout'. So we can create myView's instance with layout's exact size, and add it to 'layout'.
In this case, even though (*1) is called, (process stops at (*1) when I set breakpoint.), it is not shown in the LCD screen.
Why? Because, newly added view - henceforth new View - is already excluded in the process of calculating View's exact size. So, layout of this new View is just empty rectangle! So, this cannot be drawn!.
So, all layout(by parameter) in View Tree should be decided, before starting framework's calculating-layout process (recursive calls of each View's 'onLayout()') to determine exact size of each View in View Tree.

[[ blog 이사 과정에서 정확한 posting날짜가 분실됨. 년도와 분기 정도는 맞지 않을까? ]]
 
======= 같은 실무자로서 일을 맡기기 (ex Lead Programmer) ========
일을 맡기기전에, "What"을 원하는지, 아니면, "What + How"를 원하는지 먼저 물어보고, 일을 시킬 필요가 있는 것 같다. 사람에 따라, "What"을 주고 일을 시킬 경우, 너무 막막해 하는 사람이 있고, "What + How"를 주고 일을 시킬 경우, 단순 노동을 시킨다고 짜증내는 사람이 있다.

따라서 일을 시키기 전에 미리, 이를 물어보고 선택의 여지를 주는 것이 좋아 보인다. 일에 자신이 있고, 자기 나름대로 무언가를 해 보고 싶은 사람 (사실 이런 사람을 원한다.) 에게는 "What"을 주고, 그렇지 않고, 아직까지는 일에 자신이 없고, 구체적인 일의 모습을 원하는 사람에게는 "What + How"를 주는 것이 좋다. 그러나 만약, 계속해서 "What + How"를 아주 상세한 level까지 줘야 하는 사람이라면, 같이 일하지 않는 편이 더 나아 보인다. 이런 사람은 관리하는데, 더 많은 시간이 소모되고, 또 더 많은 스트레스를 받게 된다.

또 한 가지 중요한 점은, 'What'을 주고 일을 시킨다고 할 지라도, 그 'What'의 내용이 너무 포괄적이거나, 추상적이여서는 안된다. 예를 들면, "좋은 코드를 만들어라". 같은건 말이 안된다. "Performance에 초점을 맞추어서 개발해라" 라는 식의 구체적인 모습을 주어야 한다. 이것이 중요한 이유는 일을 진행하는 중에, 서로 다른 가치가 충돌할 때, 어디에 더 비중을 두어야 할 지를 결정하는 기준이 바로, 일의 목적인 'What'의 내용이 되기 때문이다.

더불어 일의 진행상황이나 결과물을 reporting받아야하는데, 이때, deadline과는 조금 여유를 두고 받는 편이 좋다. 왜냐하면, reporting된 결과물이 원하는 형태가 아닐 확률이 높기 때문이다. 따라서, 2~3번 정도의 수정/검토를 염두해 두고 reporting 일정을 계획하는것이 좋다.

========= 실무를 모르는 관리자의 입장에서 일을 맡기기 ==========
실무에서 막 관리자로 역할이 바뀐 사람을 제외하고, 대부분의 경우, 관리자는 실무자에 비해 실무의 내용을 모른다. 또 몰라야 한다. (관리자가 이를 알려고 시간을 낭비하게 되면, 그 만큼 관리자가 해야할 일을 못하게 되기 때문이다.)

그럼, 실무를 모르는 관리자가 실무를 자신보다 더 잘 아는 실무자에게 어떤 식으로 일을 시켜야 하는가?

먼저 관리자는 자신이 실무자에 비해, 실무에 대한 구체적인 지식이 부족함을 인정해야 한다. (종종, 좋지 않은 관리자는, 자신이 실무자보다 실무경험이 더 많다는 점을 내세워 실무에 대한 구체적인 지식이 모자람에도 불구하고 이를 인정하지 않고 잘못된 방법론을 강요하는 경우가 많다.) 이를 전제로 관리자는 실무자에게, 구체적인 실무의 "How"에 대한 부분은 전적으로 맡기는 것이 좋다. 그럼 관리자가 할 일은? 관리자는 실무자에게 일의 방향성과, 요구되는 schedule등을 지시해야 한다. 즉 관리자는 "어떤 일을 언제까지 끝내야 한다."를 지시하는 것이지 "어떻게"를 지시하지는 못한다.(해서는 안된다.)

이때, 많은 경우 "언제까지"를 충족시키기 힘든데, 관리자는 이를 위해 실무자와 논의해서 최상의 결과를 얻을 수 있는 절충안을 찾아야 한다. 필요한 resource, requirement의 수정 등등.

다시 한 번 생각해 보면, 위의 과정은 관리자가 실무자를 신뢰함을 전제로 하고 있음을 알 수 있다. 즉 관리자는 실무자가 자신의 편의를 위해서 관리자를 속이지 않음을 전제한다는 말이다. 그런데 이는 너무 이상적인 가정이다. 많은 실무자가 자신의 편의를 위해, 일의 양을 부풀리거나 더 많은 resource를 요구할 것이다. 그렇다면 관리자는 어떻게 이를 방지할 것인가?

가장 좋은 방법은, 속이지 않는 실무자를 고용하는 것이다. ("인사는 만사") 자신에게 모든 인사권이 있다면 이런 사람을 뽑는데, 대부분의 시간을 할애해야 한다. 그렇게만 된다면, 이 문제는 더 이상 고민할 필요가 없다.

차선은, 실무자의 '도덕적 헤이'를 막기 위해, 해당 실무를 잘 아는 여러명의 실무자에게 같은 질문을 함으로서, 특정 실무자의 진심을 파악하도록 노력하고 이에 맞는 조치를 취해야 한다..

각설하고, 중요한 것은, 관리자가 실무자에게 "How"를 지시해서는 안된다는 뜻이다.!!!
손자병법에서도 전쟁에서 패하는 요인중에 하나를 "군주가 진격하지 말아야 할 때 진격을 명하거나, 후퇴하지 말아야 할 때 후퇴를 명하는 것"으로 뽑았다. 비단 전쟁 뿐이겠는가???

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

The team member (henceforth member) needs to report current state (what he/she is doing and progress etc) frequently to team leader (henceforth leader); Leader always want to know what members are doing.
On the contrary, leader needs to tell members what he/she wants to be done.

Usually, leader set the vision, goal and direction; members make those come true. Members cannot decide what they should do if they don't have any idea about what leader wants.; It is same to the leader. Leader cannot make right decision about the future goal and vision without knowledge of current state of what members are doing.

So, "Sharing current state and goal" is very important to team.

In general, members know about practical state and issues better than leader. And leader understands external situation better and studies vision and future goal harder than members.

Now, it's time to share it!!

(Is it too trivial to discuss? Never!.)