Ting 이네 Software 이야기

'물을 거울로 삼는 자는 자기 얼굴을 볼 수 있고, 사람을 거울로 삼는 자는 자기의 길흉을 알 수 있다.'고 합니다. 또 옛글에는 '성공했으면 그 자리에 오래 있지 말라'고 했습니다.
- '사기'(사마천)의 '채택열전' 중에서

내가 현재 처한 상황을 어떻게 알 수 있는가? 내가 앞으로 어떤식으로 처신해야 하는지 어떻게 알 수 있을까? '사기'의 '채택열전'에서 채택의 변론은 여기에 대한 답을 제시해 주고 있는 듯 하다. 채택이 응후에게 변론한 말 중 일부를 다시 한번 적어 본다.

"지금 당신의 군주가 충신을 가까이하고 옛 친구를 잊지 않는 점에서는 효공, 도왕, 구천만 못하고, 당신의 공적과 군주의 총애나 신임을 받는 정도 또한 상군, 오기, 대부 종만 못합니다. 그런데 당신의 봉록은 많고 지위는 높으며 가진 재산은 위의 세사람보다 많습니다. 만일 당신이 물러나지 않고 그대로 그 자리를 지키고 있으면, 당신에게 닥칠 근심은 세 사람보다 클 것입니다."

상군, 오기, 대부 종은 모두 큰 공을 세운 이후 군주로 부터 신임을 잃고 크게 해를 당한다. 채택의 변론은 이들을 거울로 당시 진나라의 재상이였던 응후가 취해야할 처세의 방향을 제시하고 있다.

나라고 다르겠는가? 나도 나와 비슷한 위치에 있는 다른 사람들을 거울로 보면, 내가 현재 처한 상황을 알수 있지 않을까? 그러면 자연스럽게 내가 취해야할 길도 알 수 있지 않을까? 그게 가능하기 위해서는 일단 여러가지 사례에 대해서 많이 알고 있어야 할텐데... 그래서 과거의 역사가 중요한가 보다. "과거를 통해서 현재를 안다."는 비단 국가의 존망, 역사, 성패 같은 거대한 흐름 뿐만 아니라, 작게는 내 자신이 성패, 상황, 처세를 읽는데도 중요하다는 것을 새삼 실감하게 된다..

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

Let's consider two different level - Coder, Programmer.
Coder is engineer who can modify and implement not-big-size source code under the given SW architecture, requirement and environment.
Programmer is engineer who can define requirements, design SW architecture, analysis and fix system-wide-issues.

At first, we decide which level of SW engineer should be recruited.

To recruit Coder, following questions may be enough.
- Questions about language syntax and it's application.
- Simple problem-solving-ability (ex. simple optimization and so on.)
- Coding test. (ex. implement linked list, Queue or Stack etc)

But, to recruit Programmer, you may need additional questions to know about his/her programming policy and values.
For example,
- What's your opinion about 'modularity'?
- What is 'software layer' and what it should be?
- Please tell me about 'information hiding'

But, someone may give well-known answer that may come from books. So, detail and concrete question should be follows.
For example, followings can be asked after question "What's your opinion about 'modularity'"
- Then, What should good modular architecture be?
- Show example of good modular architecture.
- What kind of design can be used to connect between modules.
- What is good interface design to support modularity?
- Please design linked list with C language focusing on modularity.

... I am not sure that this kind of evaluation can be possible in practical. But...

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

어떤 사람을 회사에서 내 보내고자 할때, 어떻게 하는가? 그 중 하나가, "성취 불가능한 project에 자주 투입시키는 것"이라고 한다. ("회사가 당신에게 알려 주지 않는 50가지 비밀" - 산시아 샤피로). 뭐.. .실제로도 그렇게 보인다. 그렇게 해서, 그 사람으로 하여금 회사에 정나미가 떨어지게 만들어, 제 발로 걸어나가게 만들 수 있으니까.

그렇다면, software개발에서는?

거의 모든 회사에서, software개발의 schedule은 항상 overly optimistic하다. 또한 상당부분, overly optimistic을 넘어 impossible한 경우가 많다. 그래서 어느 순간에는, software 개발 schedule이 나오더라도, 당연히 못 지킨다고 생각하고 마음을 비우게 된다...-_-; 그렇다면, SW회사는 software engineer를 회사에서 떠나보내게 하려고 그러는 것일까? 물론 아니겠지만.... engineer는 떠나고 싶어진다... 문제는.. 안 그런 곳을 찾기가 어렵다는 것인데... 씁쓸하다...

Using 'const' wherever possible is very very important. It can help to avoid mistakes and increase readability very much.
Personally, I even regard ability of using 'const' in code, as one of most important evidence to evaluate programmer's quality.

==== const member function ====

class A {
    void funcB(void) const;
    void funcA(int* pa) const;
    int* funcC(void) const;
    int a
}

const member function(henceforth const member) cannot change class member variable. And, const member can call only const member. But, const member can call any C function.
By the way, there is no constraints about parameter in const member. So, following is possible.

Hack 1
  void A::funcB(void) const { funcA(&a); }
  void A::funcA(int* pa) const { *pa = 9; }

Hack 2
  void A::funcB(void) const ( int* p = funcC(); *p = 8; }
  int* A::funcC(void) const {return &a;}

Even if, funcB changes value of member variable, it compiles well. This is one of week points of const member.

==== const & pointer ====

const int* p;   // *1 - (*p) is const
int const *p;   // *2 - (*p) is const
int* const p;   // *3 - (p) is const

case *1, *2;

"*p = 4" is error, but, "p = &b" is OK.
So, we can hack this like "*((int*)p) = 9;".

case *3

contrary to upper case. So, we should initialize pointer before using it.

==== const & multiple pointer ====

const int** p;   // *1
int const **p;   // *2
int* const *p;   // *3
int** const p:   // *4

int*       pb;
const int* cpb
int b;

case *1, *2.

// p = &pb; // error - "cannot convert from 'int **' to 'const int **"
p = &cpb; // OK.
*p = &b;
// **p = 8; // error - "you cannot assign to a variable that is const"
*((int*)*p) = 8 // OK. Hack!

case *3

p = &pb; // OK
*p = &b; // error - "you cannot assign to a variable that is const"

case *4

p = &pb; // error - "you cannot assign to a variable that is const". p should be initialized before used.

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

필자가 국내 핸드폰 소프트웨어 개발 직종에 종사하면서, "이건 아닌데..."라고 생각한 부분이 몇가지 존재하는데, 그 중에 하나가 Test & Debugging Cycle에서의 문제점이다.
필자가 경험한 바로는 Test & Debugging Cycle에서의 업무는 다음과 같이 이루어 진다.

1. Test engineer(이후 TE)가 발견한 버그를 Issue Tracking system에 기록한다.
2. Engineer가 이를 보고 실제 재현을 해 본다.
3.1 문제없이 재현하였다면,   이게 정말로 버그인지 아닌지 확인한다.
3.2 재현에 실패했다면, TE에게 재현 방법을 물어보고, 3.1의 과정으로 간다.
4. 실제 버그가 맞다면, 수정에 들어간다.

그런데, 문제는 위의 과정에서 생산성을 저하시키는 일들이 필요이상으로 많이 발생한다는 것이다. 하나씩 살펴보자.
먼저, 1과 2사이를 보자.
보통의 경우 - 국내 업체 -  Product Specification, User Interface Specification(이후 UIS)같은 문서들이 대부분 상당히 부실하게 작성되어 진다. 이 중에서 SW측면에서 보았을때, 특히 중요한 것이 UIS인데, Specification이라는 이름에 걸맞지 않게 허술하게 작성되는 경우가 대부분이다. 필자의 소견으로는, 기업이 이 부분에 크게 투자하지 않는 것 같다.  SW를 경시하는 만큼 UIS도 경시하는 듯 하다. 따라서, TE입장에서는 무엇이 버그이고, 무엇이 버그가 아닌지 판단할 수 있는 확고한 근거가 없으므로, 그냥 본인이 이상하다고 생각하면 전부 버그라고 reporting하게 된다.

2와 3 사이의 경우, TE의 reporting미숙에서 오는 overhead가 상당히 크다. 개발자들은 bug report을 보고, 이를 어떻게 재현할 수 있는지 몰라서, TE에게 찾아가거나 혹은 전화로 다시 한번 확인하는 경우가 태반이다. 심지어는 "xxx를 하면 화면이 이상하게 보임." 이라고 기록된 어이없는 reporting을 본 적도 있다. 이는 TE의 역할에 대한 기업의 잘못된 정의가 가장 큰 원인이라고 필자는 본다.
보통  QA를 TE의 역할로 정의하는 업체가 많다. 물론, QA는 TE의 가장 중요한 역할 중 하나이지만, 국내의 경우 그 정도가 지나친 것처럼 보인다. 무슨 말이냐 하면, 오로지 bug를 찾아내는데만 TE의 역할이 집중되어 있다는 뜻이다. 보통의 경우, TE의 임금은 Developer에 비해 저렴하다. 그래서 TE라는 직종이 따로 생겼고 (만약 그렇지 않다면, developer가 TE의 역할을 같이 겸하게 되었을 것이다.)  SW의 bug를 찾고 품질을 검증하는 역할이 주어졌다. 그렇다면, 상대적으로 비싼 비용이 드는 Developer의 시간을 절약하고 이 역할을 TE가 해 줄 수 있도록 해야하지 않겠는가? 따라서 debugging을 위해 developer를 support하는 것 역시 TE의 중요한 역할 중 하나가 되어야 하고, TE의 성과 평가 항목에 반드시 이 부분이 반영되어야 한다. 이때, 가장 기본적인 것이 bug reporting이다. TE는 bug를 재현할 수 있는 방법을 명확하게 기술해야 하고, debugging에 도움이 되는 정보를 추가적으로 기록해 줄 필요가 있다. 에를 들면 아래와 같다.

menu -> setting -> time & data -> 24시 format으로, 12:00를 setting하면 phone이 reset됨.
menu -> setting -> time & data -> 12시 format으로 12:00를 setting하면 정상 동작함.
menu -> setting -> time & data -> 24시 format으로, 11:00를 setting하면 정상 동작함.

이런 정도의 reporting은 상대적으로 비싼 비용이 들어가는 Developer의 시간을 상당히 절약시켜 줄 수 있다.  물론, 너무 상세한 reporting으로 인해 쓸데 없이 많은 시간이 소모된다면, 그것 역시 피해야할 것이다.
좋은 TE를 유지하는 일은 상당히 어렵다. TE라는 일 자체가 가지는 특성때문에, 좋은 TE는 빨리 다른 직종으로 이직하고자 하기 때문이다. 따라서, 어떻게 좋은 TE를 유지할 것이냐 또한 심각하게 고민해할 문제이다.

[[ blog 이사 과정에서 정확한 posting날짜가 분실됨. 년도와 분기 정도는 맞지 않을까? ]]
 
!!!사람을 힘들게 하는 것은 "Hard work"가 아니다. "Stress"다
사람들이 일을 즐기면 - 즐기지는 못하더라도 할만하면 -, 열심히 일해도 힘들지 않다.
그러나, 사람들은, 자신이 무엇을 하고 있고, 왜 이 일을 하고 있는지 알지 못하면 일을 즐길 수가 없다.
사람들은 자신이 하고 있는 일의 방향과 타당성을 알고 비젼에 공감하며, 열심히 일한 것에 대한 보상이 있을때, 일을 즐길 수 있고, 이때는 하루에 10시간 혹은 12시간을 일하더라도, "회사일 때문에 힘들다."라는 이야기를 하지 않을 수 있다.

반면, 내 경력에 전혀 도움이 되지도 않고, 왜 이 일이 필요한지도 모르겠는 일을 계속해서 하면서, 다른 사람과의 갈등으로 계속해서 스트레스를 받으면, 아무리 9-6 8시간 근무를 하더라도.."회사일 때문에 힘들다."라는 생각이 들 수 밖에 없다.

음.... 지금 당연한 이야기를 하고 있는 것일 수도 있으나.. 다시 한 번 되새겨 보자는 의미에서 한번 적어 본다....

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

Before developing something, we should clarify "what we want to develop". In the same context, we want clear requirement specification. But I am not saying about requirement specification. Subject of this article is "Clear description about outcome - not only final one but also intermediate and sub-module's one". In case of very short and simple program, required goal is also simple and clear. So we don't need to worry about this. But, usually, size of software project is quite big.

Here is very big-size-software project. So, we divide a project into several sub-projects and assign these to sub-team; After developing each sub-project, we try to integrate them. But, as you know, integration is not an easy job. There may be conflicts between sub-module, interface mismatching and so on. Changing software design or algorithm may be required to resolve these integration issues, and usually, this kind of change is very expensive. How can we reduce this costs?.

Yes. I think everyone already knows the solution.To reduce this, we should clarify outcome of each sub-project.
Actually, changing software due to integration issues means "Requirement of that sub-project is changed"; Big Costs!. In this scenario, outcome of sub-project can be interface, data format and so on. In sub-teams' point of view, "Knowing exactly about outcome of other module" means "Knowing exactly what we can use and what we can supports". In my opinion, this is basic knowledge to reduce integration issues.

[[ blog 이사 과정에서 정확한 posting날짜가 분실됨. 년도와 분기 정도는 맞지 않을까? ]]
 
"世有伯樂然後有千里馬, 天里馬常有而伯樂不常有." 라 했다.

좋은 사람을 알아 본다는 것은 그 만큼 힘든 일이고 어려운 일이다.

옛 중국에는 '사람을 추천했을 경우 추천받은 사람이 죄를 지으면 추천한 사람도 그와 같은 처벌을 받는다.'는 법이 있었다고 한다. 모르긴 몰라도, 그 반대로 추천받은 사람이 공을 세울 경우, 추천한 사람도 그 공을 나누어 가지지 않았을까?

따라서 사람을 추천한다는 것 혹은 추천받는 다는 것은 그 만큼 어렵고 또 중요한 일이란 뜻이다. 추천 받은 사람은 자신의 공과가 추천한 사람에게 그대로 이어짐을 명심해야하고, 추천한 사람또한 이러한 것을 충분히 고려한 후 추천해야 한다.

그렇지만 무엇보다도, 사람을 추천하기 전에 '좋은 사람을 알아본다'는 것이 얼마나 어려운 일인지 알고, '좋은 사람을 추천할 수 있는 사람' (伯樂)의 가치를 알며, 이를 소중히 여길 줄 아는 것! 이것이 아마도 가장 중요한 것이 아닐까? 그리고 나 또한 '좋은 사람을 알아볼 수 있는 안목'을 기르는데 노력해야 하지 않을까?

What is variable in C? Let's think about this deeply.

The variable consists of type and name.
Then, what is 'type'? and what is name?
'type' is "What the memory value means"; Way of interpreting memory.
'name' is alias of memory address.

Can you understand?
We can know that 4-byte-memory-value from address '&a' represents 'signed integer value' from C code "int a;".

Following example(ARM assembly and C codes) shows this explicitly.

// asm.s
EXPORT my_symbol
CODE32
my_symbol
DCD 0x73d71034

------------

// symbol.c
extern char* my_symbol;
int data = (int)my_symbol;

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

Let's consider a software project.

Usually, we have two general way to make up team.
1st : We may organize one team for each project. That is, one team for one project. And this team - actually, team lead if we should pick only one person - is fully responsible for the project.
2nd : one team for each features.(for example, WAP team, MMS team etc...)

We cannot tell which model is better (each model has it's own pros and cons.).
But, in terms of time-critical project, 1st model is better.
In the 1st model, issues detected during project development are definitly under project team's responsibility. So, we don't need to struggle for finding appropriate team to handle those issues. And this project team tends to be active to resolve those. (But, Several teams may suffer same issues with high possibility, because sharing know-how and accumulating knowleges about each feature is difficult)

But, in 2nd model, it is difficult and takes time to know which team should handle those - for this, usually lots of communication overhead is required. So, each feature team tends to be passive. And they want to avoid being assiged to issues, because they don't have responsibility to succeed this project. (But, in this case, each feature team can accumulate know-how about features and expect synergy from this because team becomes expert for the feature!)

We should take attention to main difference between 1st model and 2nd model. That is just "Is there any ONE person who are fully responsible for the project?".

So, we would better to mix up this two models. (ex. 1st model for SW maintenance and enhancement; 2nd one for making product.)

My point to succeed in time-critical-project (ex. making product), (based on my experience..) is,

* There should be only ONE person who are fully responsible for a project and he/she should have enough authority to manage this project. Responsibility of several people means "No one under responsibility".

Does it seems too simple and trivial? But, it is not easy to obey this rule efficiently.