'Essay/Software'에 해당되는 글 51건

  1. 2009.09.04 [Prog] Do not underestimate costs for refactoring.
  2. 2009.08.10 [Prog] Step of progress (programming skill).
  3. 2009.06.04 [Prog][Debug] irregular bug....
  4. 2009.04.01 [Essay] Overly optimistic schedule...
  5. 2009.03.11 [Essay] Test&Debugging Cycle과 Test Engineer의 role에 대한 단상...
  6. 2009.02.15 [Dev] Clear description of outcome - submodule, subproject...
  7. 2009.01.21 [Dev] one persone under full responsibility for one time-critical-project
  8. 2008.11.22 [Prog] What is "good code"?
  9. 2008.05.12 [Prog] Trade offs
  10. 2008.04.27 [Prog] Avoid prematured exception handling...

[Prog] Do not underestimate costs for refactoring.

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

Refactoring itself requires lots of costs. Especially, verifying result - refactored software - is extremely expensive. So, to minimize this costs, auto-test-system is essential. Don't underestimate the costs. Usually, making auto-test-system can save costs more than expecting.
신고
tags : Programming
Trackback 0 : Comment 0

[Prog] Step of progress (programming skill).

Essay/Software 2009.08.10 00:29

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

This id 100% personal opinion...
Step of progress in terms of programming skill(excluding co-working skill).

1. Coding with giving attention to the language syntax.
2. Coding his/her own thought quickly. (number of code line per hour is a lot. But, very buggy & poor design)
3. Realizing difficulty of debugging. So, coding considering debugging. initial speed becomes slower than (2)
4. Realizing software design. Coding considering design too. (slower than (3))
5. Knowing design techniques and importance of interface design, but immature. So, software is tended to be over-engineered. Lots of time is spent on designing over-engineered-software, interface and so on. In this stage, programmer knows about "What should be considered for good software". But he/she doesn't have any idea/experience about solutions. That's why initial speed is very slow.
6. Being mature. Becoming faster step by step.

신고
tags : Programming
Trackback 0 : Comment 0

[Prog][Debug] irregular bug....

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

Classifying non-regular bugs. (My opinion)

I usually classify non-regular bugs into 3 category.

(*1) : caused by timing. In multi-threaded software, sometimes unexpected execution order - ex. race condition - may raise error.
(*2) : caused by memory corruption. Memory is corrupted by some reasons - this is root cause, and because of this, error is occurred irregularly.
(*3) : caused by using uninitialized data.

Knowing that which category the bug belongs to, is very difficult and usually, only based on developer's experience.
Here one tip comes from my experience.

In case (*2) :
  reproducing way itself seems to be very irregular and the representation(result) of crash is also very un-determined.
In case (*3) :
  even if reproducing sequence is irregular too, the representation(result) tends to be simlar among cases. Usually, software is crashed from 'wrong memory reference'. And the overall outlook of crash is very regular.

신고
tags : Debug, Programming
Trackback 0 : Comment 0

[Essay] Overly optimistic schedule...

Essay/Software 2009.04.01 21:41

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

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

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

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

신고
tags : essay
Trackback 0 : Comment 0

[Essay] Test&Debugging Cycle과 Test Engineer의 role에 대한 단상...

Essay/Software 2009.03.11 21:57

[[ 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를 유지할 것이냐 또한 심각하게 고민해할 문제이다.

신고
tags : essay
Trackback 0 : Comment 0

[Dev] Clear description of outcome - submodule, subproject...

Essay/Software 2009.02.15 21:55

[[ 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.

신고
tags : development
Trackback 0 : Comment 0

[Dev] one persone under full responsibility for one time-critical-project

Essay/Software 2009.01.21 22:14

[[ 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.

신고
tags : development
Trackback 0 : Comment 0

[Prog] What is "good code"?

Essay/Software 2008.11.22 00:03

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

Followings are all my personal opinion!

We always tell "good code". And lots of constraints are suggested for so-called "good code". For example, "number of line in one function should be less than xx", "number of class members should be less than xx", and so on.

Let's think from the basic. What is "good code". We don't need messy conditions for this. Just one factor!.
I want to define "good code" as "code that is easy-to-understand". Codes that is easy-to-understand, are easy to modify too.

Let's talk about this more.
"code that is easy-to-undertand" means, "It should be easy to know that the codes for and to predict the execution result.". Then what we should do to acheive this?

"Making code be small" can be an option. Anyway, small codes are easy. But, without reducing features and functionalities, decreasing code size enough is impossible. So, in practice, the is not a solution.

Let's convert the sentence into "Making stuffs required to be understood, be small". How about this? We can use lots of reliable module/component to do this. For example, let's think about standard library. We don't try to understand inside of each standard library functions because, we already trust the library enough. So, after understand inputs and outputs, we just use it. If we should understand inside of all those library functions, it will be nightmare. Too many things to understand!

In this context, we can say OOP(Object Oriented Programming), component-based software engineering, modularity, and so on. Making reliable and reusable modules/components can reduce stuffs required to be understood. Knowing input and output is much simpler than understanding inside codes of it.

This is my definition about "good code"

신고
tags : Programming
Trackback 0 : Comment 0

[Prog] Trade offs

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

* Space vs. Speed
- Most famous one. (Memory space vs. execution speed) - details are omitted.

* Modularity vs. (Performance & Space)
- Well-designed-module should be stable. To be stable, there may be lots of 'parameter check', 'condition check', 'sanity check' and so on. Besides, for the safety reason, it may not trust passed memory space. So, it may allocates it's own memory space and try to copy data from passed memory to use it. Those make this trade-off. Well-designed-module hides it's information and stable as it is. But to be like this, it consumes speed and space.

* Abstraction vs. Debugging
- When software is stable, abstraction reduces maintenance costs very much. But, if not, debugging is more difficult than straightforward designed software, especially, to the engineer who are not accustomed to the software.

* low possibility to misuse vs. various and rich functionality
- It is clear...

* Backward-Compatibility vs. Innovation
- ...

신고
Trackback 0 : Comment 0

[Prog] Avoid prematured exception handling...

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

In general, handling exception smoothly is very difficult. So, in many software, there are lots of prematured routine for exception handling. My recommend is, "just put "Assert" instead of premature exception handling(henceforth PEH)".

PEH give noisy information when exception is occurred, because software crashes at unexpected place due to PEH (Not the place where exception is actually raised).
Let's see following codes.

...
info = Get_personal_info(name);
if(!info){ return SYS_Fail;}
...
Personal_InfoT* Get_personal_info(char* name)
{
    ...
    int index = Search_with_name(name);
    if(index < 0) {return NULL;} // fail. (exception handling part)  ---- (*)
    ...
}

In this case, the place where exception is raised at first is (*). But, to handling exception, this function returns just 'NULL'. And at caller, it also returns 'SYS_Fail'. OK. It's reasonable. But, in practice, handling all these returned error smoothly requires lots of costs. So, in many cases, this is handled prematurely. And eventually, this error leads to software crash at unexpected place.

So, again, my point is just put 'Assert'. After all, we should try to debug all errors. 'Assert' is very helpful in debug. And then, we should decide whether remaining as 'Assert' or handling exception later - usually, exception from IO should be handled. This is more efficient in my opinion.

신고
tags : exception
Trackback 0 : Comment 0

티스토리 툴바