The most important thing of OOP is "Making objects that developer don't need to look inside of it.". Reliable objects are foundation of OOP. Then let's think about this more.

* Object should respond at all cases.

That is, crashing inside object should not be happened! object should be in valid state at any case. If software is crashed inside object, developer should analyze internal code of object, and this is what we want to avoid.

* Reducing possibility of misuse interface should be considered when interface is design.

That is, usage of interfaces should be easy and intuitive. If not, developer need to investigate for object's internal parts to know correct usage. And, usually, interdependent interfaces leads to misuse. For example, "Interface B should be used after interface A is called", "Interface A should not be called after interface B is called" and so on. So, if possible, reduce dependency among interfaces of objects.

* Interface should be well-commented.

In the same context with above, developer don't need to look into the object that is well-commented. In my opinion, comments of interface should include at least following things.
  + behavior of interface.
  + prerequisite to use the interface.
  + explanation about each parameters.
  + description about return value.
And, adding usage example is recommended.

* For object to starts supporting minimal set of interface is better.

Adding interface is easy. But deleting interface is difficult because it may affect to number of other objects that already use the interface. And, stabilizing object having small number of interface, is easier. Starting from minimal set can also help developer escape from temptation of over-engineering

 
Next important point is relations among objects.
Software created by OOP consists of lots of objects and relations. To understand software's behavior, knowing relations and inter-operations among objects is significant.

* Software documentation.

Design concept, policy, block diagram, used patterns and so on is needed to be documented to help reader to understand overall shape of software.

 
There is also disadvantage of OOP.

* Performance drop.

In every object, there are lots of routines for checking and handling unexpected cases. And in general, software in OOP consists of lots of objects. So, inevitably, number of duplicated check and handling are unavoidable - all objects may check same thing. And sometimes this drops performance very much.

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

+++ 내가 Lead했던 첫번째 SW Project가 끝났다... 이 경험을 보존하기 위해 Review를 적어본다. +++

Project인원 : 나를 포함해서 3명
프로젝트 기간 : 약 4개월..
규모 : 한 10,000 라인 정도 되나??

내 관점에서 보기에, 다른 두명의 Programming능력 수준은 기대 이하였다.(아니면, 나 자신이 그들의 능력을 보지 못할 정도로 미숙했을 수도...)
Programming 경험이 많지 않은 사람과 같이 일하면서 크게 문제가 되었던 점들은 아래와 같았다.

+ 기본적으로... Code의 Stability가 떨어진다. (많은 Bug를 내포하고 있다. 일정이 짧아서 그럴수도 있지만, 일단 돌아가는 코드만 만들고 Program의 구조는 신경쓰지 않는다.)

+ SW design의 중요성을 전혀 인식하지 못한다. (이게 가장 큰 문제다!!!) SW design의 중요성을 모르고, 상호간 Interface간 정의의 중요성을 모르기 때문에, 여기에 큰 관심을 기울이지 않는다. 아무리 이게 중요하다고 이야기해도 전혀 반응하지 않는다.(소 귀에 경읽기??) 이번 프로젝트의 경우, Interface에 대한 communication을 초반에 상당히 강조했음에도, 결국 Integration단계에서, 그들이 전혀 Interface의 중요성을 인지하지 못했고 또, 관심조차 기울이지 않았음을 알게 되었다. 그들은 자신의 module과 연결될 다른 모듈의 동작 방식으로, 모듈 작성자와 communication하지 않고, 자기 나름대로 상상해서 API를 정했다. 결국 Integration단계에서, 문제가 발생했다..

+ Code re-factoring을 하지 않는다.... 내 개인적인 생각으로는, 그들은 자신이 짠 코드를 버릴 줄 모른다. 첫번째 짠 코드보다는 두번째 짠 코드의 질이 좋을 수 밖에 없다. 그리고 필요한 경우, 첫번째 짠 코드의 전체를 버릴 수도 있어야 한다. 그런데, 어설픈 구조로 짠 코드를 벗어나지 못해, bug를 양산할 가능성이 있는 불안한 코드에 땜질하는 형태로 project를 진행시키고 있고, 그게 Project를 빨리 그리고, 완성도 높게 끝낼수 있는 길이라고 생각한다. 이는 결국, SW design을 모르는 것과 어찌보면 그 맥을 가치하는데 - 보통 re-factoring은 design이 좋지 않은 경우 수행되어 진다. - 자신의 코드의 design이 좋지 않다는 사실을 인지하지 못하므로, re-factoring을 해야한다는 사실 자체를 모른다.

그럼 이런 경우 어떻게 이를 극복해야 하는가?
궁극적으로는 같이 일하는 사람의 능력을 향상시키는 것이 가장 중요하겠지만, 당장 일을하기 위해서는 결국 SW design과 Interface, API등을 모두 정의한 상태에서 상당한 수준까지 design을 구체화 한다음, 나머지 부분을 채워 넣으라는 방식으로 일을 할당했다.
(결국 이렇게라도 일을 시켜야, 생산성을 이끌어 낼 수 있었다.)

반성
+ 사람마다 능력과 경험이 다르고 일하는 방식이 다르다. "내가 아는 것은 다른 사람도 알 것이다."라는 전제 자체가 잘못 되었으므로, co-work에 어려움이 있었다. 사람들간의 차이를 알고, 상황에 맞게 생산성을 이끌어낼 수 있는 방법을 찾는 노력을 기울이지 않았다.

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

I want to say only one sentence about software design.

"Software design starts from and ends with [ separating things that will be changed with high possibility, from others that will not. ]".

In macro point of view, software requirement is main subject to classify. In micro point of view, function parameter, algorithm, data structure and so one can be targets.

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

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

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

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

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

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

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

[[ 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날짜가 분실됨. 년도와 분기 정도는 맞지 않을까? ]]

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날짜가 분실됨. 년도와 분기 정도는 맞지 않을까? ]]

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.

+ Recent posts