Ting 이네 Software 이야기

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에 어려움이 있었다. 사람들간의 차이를 알고, 상황에 맞게 생산성을 이끌어낼 수 있는 방법을 찾는 노력을 기울이지 않았다.