'Essay'에 해당되는 글 86건

  1. 2007.06.15 [Dev] XP에서 말하는 code branch 관리에 대한 의문점...
  2. 2007.05.14 [Essay] Over-engineering에 대해서...
  3. 2006.12.14 [Dev] Sometimes, code duplication may need to be allowed.
  4. 2006.10.07 [Dev] Source code editing 환경의 통일...
  5. 2006.04.13 [Prog] Layering hardware specific part in software.
  6. 2006.02.27 [Prog] Basic knowledge about HW is required even to the application engineer.

[Dev] XP에서 말하는 code branch 관리에 대한 의문점...

Essay/Software 2007.06.15 22:03

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

XP(Extream programming)에 따르면, code branch는 항상 release가능한 상태를 유지해야 한다. 그런데 이는 XP에서 마찬가지로 주장하고 있는, "누구나 수정할 수 있고, 누구나 test가능한 code"의 개념과는 상반된다. 누구나 수정할 수 있고, 누구나 test가능하다면, 그 code branch는 언제든 깨어질 수 있다. 따라서, 항상 releasable할 수는 없다.

"누구나 수정할 수 있고, 누구나 test할 수 있다"는 것과 "코드는 항상 release가능한 상태를 유지해야 한다." 는 것을 어떻게 같이 가져갈 것인가????
나의 XP에 대한 지식이 짧아서 그런것 같은데...
(XP에서 어떻게 표현했는지, 그 정확한 영어 표현이 생각나지 않아서 한글로 적는다...)

신고
tags : development
Trackback 0 : Comment 0

[Essay] Over-engineering에 대해서...

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

"Design pattern" / "Extream programming" / "내 경험"

"Design pattern" 은 정말 유용하다. 이것은 코드를 좀더 flexible하고 또 건전하게 만든다. 그러나, software의 불변의 진리 중에 하나는, "Software를 soft하게 만들기 위해서는 비용이 든다" 이다. 즉 design pattern을 최대한 많이 적용해서, flexible한 코드를 만든다는 말은, 많은 추가적인 비용이 든다는 말이다. 또한 몇몇 책에서는, 개발자는 이후 변화할 요구사항에 대해 예측하는 것은 매우 어렵기 때문에, 초기부터 너무 flexible한 code를 짜고자 한다면, 이는 결국 project가 끝날 때까지 거의 쓸일이 없는, 쓸데없이 복잡한 구조를 만드는, over-engineering을 하게 된다고 주장한다("Addison Wesley Refactoring to patterns" 참조.). 따라서 Extream programming에서는 현재까지 알려진 요구사항만을 만족시킬 수 있는 최소한의 Flexibility를 가지는 software로 충분하며, 이후 추가되는 요구사항에 대해서는 refactoring을 통해서 계속해서 개선시켜 나갈 것을 권고하고 있다.

그런데, 문제는, 보통의 경우, 요구사항이 바뀌고, 이를 만족시키는 코드를 추가하고, 또 바뀌고, 추가하고... 이를 반복하다가 어느 순간, 이런 작업으로 인한 overhead가 너무 많다고 생각되면, source code refactoring을 하게 되며, 이는 source code의 구조를 바꾸는 큰 일이 된다. 즉, Extream programming에서 주장하듯 꾸준한 refactoring을 통해서, source code의 건전성을 확보하면 된다는 말은, 물론 좋은 말이긴 하다. 그러나 한편, 이는 design pattern을 이용한 "over-engineering"을 피하다가 결국 refactoring을 결정하기 까지, 많은 추가적인 비용을 들이게 되는, 또 다른 형태의 over-engineering을 하게 될 수도 있다..

결론적으로 절대적인 옳고 그름은 없다는 말을 하고 싶다.

개발자가 이후 발생할 요구사항의 변화를 100% 예측하는 것은 분명히 불가능하다. 그러나, 몇몇 부분에 대해서는 예측이 가능할 수도 있다. 그리고 이렇게 예측이 가능한 부분에 대해서도, 단지 현재의 요구사항에 없는 부분이라고 해서 flexible한 design을 적용하지 않는다면, over-engineering을 피하기 위해서, 또 다른 문제를 만들게 되는 폐단을 낳게 된다. (내가 보기에는 이것도 일종의 under-engineering이다. 따라서 이후 이것 또한 under-engineering으로 칭하기로 한다. - 이는 "Addison Wesley Refactoring to patterns" 에서 이야기하는 under-engineering과는 좀 다른 이야기이다.)

즉, flexible해야 한다고 강력하게 예측가능한 부분은 처음부터, 혹은 추가되는 요구사항을 구현하는 초기 부터 flexible하게 만드는 것이 under-engineering으로 발생하는 폐단을 막을 수 있다. 또한 programmer로서의 능력과 영감을 좌우하는 상당부분은 바로, 어떤 부분이 flexible해야 할 것인가? 를 판단하는 능력이 결정한다.

예를 하나 들어보자. (내가 경험한 실례를 가지고 설명한다.)

분산 컴파일을 위한 program을 만든다고 생각하자. 그리고 이 중에서도, network programming부분에 focus를 맞추어서 생각해 보자.
처음에 생각되는 요구사항은, 컴파일 할 파일을 전달하고, 결과로 만들어진 object binary file을 되돌려 받으면 될 것 같다.
그렇게해서, "size(4byte)+data(...)" 의 binary를 보내고 받는 socket function을 짠다. 그런데, programmer로서의 경험은, server-client간 통신은 항상 추가적인 필요가 발생했었고, 지금의 경우도 분명히 추가적인 무언가가 발생할 것이라고 말하고 있다. 그런 이유로, client-server가 network communication을 위한 layer를 만들었고, 단순히 compile을 위한 file과 object만이 아니라, 일반적인 data를 전송할 수 있게, protocol unit manager를 만들었다. 이후 이 두 module은 추가적인 요구사항이 발생할 때, 큰 어려움 없이 feature를 늘리는데 상당히 큰 도움을 주었다.

만약 만들지 않았다면?... 손발이 더욱 고생하지 않았을까?

신고
tags : essay
Trackback 0 : Comment 0

[Dev] Sometimes, code duplication may need to be allowed.

Essay/Software 2006.12.14 20:42

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

Ideally, duplicated code leads to maintenance nightmare. So, Not-allowing-duplicated-code always seems to be better. But, in this article, I want to say that in some cases, code-duplication needs to be allowed.

In practice, lots of people who has different ability work together in one source code branch. In this case, if code duplication is not allowed, all developer should search all sources to find the reusable module. Let's image that there are thousands modules. Finding appropriate module is not easy. And lots of people try to customize(modify) the module for easy-reuse. If all engineers are enough good at programming and enough time to consider code quality then we don't need to worry about "customization". But, it cannot be in some cases - especially, product development. Skill level of engineers are always various and they are always pushed by project schedule. So, the shared module tends to become worse and worse in terms of its quality. (It's normal in large-size-project).

Here is merits of allowing code duplication.(There are lots of well-known-disadvantage of allowing code duplication. So, let's talk about only "Merits".)
  * There is no dependency among people. So, it's very easy to work in parallel.
  * Merging is easy, because of no-dependency and no-conflicts.
  * Bug from mistake affects only limited area. So, detecting issued part is easy.

So, practically, we need to consider what should be reused(shared) and what shouldn't.

Here is my opinion about this.
Codes that should not be duplicated.
  - codes for interface with external modules.(In App. point of view, OS, filesystem and so on can be external modules)
  - codes that are used very frequently. (ex. code for getting lengh of string. - strlen)
  - stable codes.
  - ... (anything else???)

Codes that can be duplicated.
  - parts that should be done in parallel with tight schedule and enough human resources.
  - codes that are customized very often.
  - ... (anything else???)

Hmm... I need further study...

신고
tags : development
Trackback 0 : Comment 0

[Dev] Source code editing 환경의 통일...

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

큰 팀이 project를 할 경우, 팀내 개발자 각각의 local환경이 서로 틀려서, 문제가 생길때가 많다. ("나는 build가 잘 되는데, 너는 왜 안되느냐?" 등). 그래서 보통의 경우, 같은 project를 하는 사람들끼리는 개발환경을 통일하는 경우가 많고, 이런 개발환경에 대한 script file또한 형상관리의 대상이 되는 경우가 일반적이다. 환경을 통일하기 위해서는 각 개인의 Local환경을 공통 환경으로 Mapping시켜 주는 일이 필요한데, 보통의 경우, 환경 변수, Virtual Drive 등이 쓰인다.

예를 들면,
- 개발 root directory는 "P:\project"로 한다. => Virtual drive를 이용.
- project build directory는 %MY_PRJ%\%PRODUCT_NAME%으로 한다. 등등

그런데, 개발환경이란, 비단, file path, 개발 tool의 path, 환경 변수의 차이 등을 의미하는 것 만이 아니다. source code editor도 주요한 개발환경이라고 할 수 있다.

어느 한 'A'라는 editor에서 개발한 사람이 줄을 잘 맞추어서 정돈된 코드를 만들었다고 하자, 이 코드가 'B'라는 editor에서는, 'tab size의 차이', 'font의 width'차이 등으로 인하여 무질서 하게 보이는 경우가 허다하다. 즉, 'A'라는 editor를 기준으로한 code beautify는 'B'라는 editor에서는 무의미할 수도 있다는 말이다.
그런데 문제는 다른 개발 환경과는 달리, code editor는 개발자들에게 '통일'을 강조하기 어려운 면이 있다는 것이다. 왜냐하면, 개발자들이 다년간 사용한 editor를 바꾸게 된다면, 한동안 새로운 editor에 익숙해 지기까지 꽤나 긴 시간동안 생산성이 크게 떨어질 뿐만 아니라, 개발자 개개인의 커다란 반발을 살 가능성도 농후하기 때문이다.

따라서 차선책으로, editor 환경을 통일시키게 된다. 개개인 개발할 때는 임의의 editor환경을 사용해도 좋지만, code branch에 'submit'한다던가, 'check in'할 경우는 반드시 통일된 editor환경에서 beautify된 코드를 사용하도록 해야 한다. (사실 매번 submit혹은 check in할때마다 이런 작업을 해야 한다면, 개발자들은 차라리, editor환경을 여기에 맞추게 된다. editor환경을 바꾸는 일은 editor자체를 바꾸는 것보다는 수월하며, 또 반발 또한 작다. 왜냐하면, 이것은 editor 자체를 바꾸라는 것 보다는 당위성이 충분하기 때문이다.)
code editor 환경의 예를 들면 다음과 같은 것이 있다. (너무 복잡한 규정은 잘 지켜지지도 않고, 반발만 살 수 있음을 명심해야 한다.)

- tab은 space replacement로 하되 size 4로 한다.
- 줄바꿈은 Unix style(LF)를 따른다.
- ... etc..

신고
tags : development
Trackback 0 : Comment 0

[Prog] Layering hardware specific part in software.

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

It seems obvious that hardware specific software should be layered with unified interface.
This is very important to portability and debugging. In addition, this can help simulate hardware functionality in other platform - desktop PC. This is something like "Porting to PC". Programming and debugging on PC platform can increase productivity very much. Can you understand how important this is?
(Please refer "Linux" device driver interface. This is very good example!)
신고
tags : Programming
Trackback 0 : Comment 0

[Prog] Basic knowledge about HW is required even to the application engineer.

Essay/Software 2006.02.27 00:28

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

((To avoid misunderstanding) I am also application engineer.)
Application engineer tends to ignore HW characteristics. But, without HW, SW is useless. Even application engineer in embedded software, would better to know basic stuffs about low-layer. Here are some examples about considering these low-layer characteristics. These examples are to appeal to application engineer.

* Each assembly code line may spend different number of CPU clocks. So, counting assembly code line is useless to check CPU performance.
* Optimized code for "2 CPU + 1RAM" is totally different from the one for "2 CPU + 2 RAM for each". Besides, DMA, Bus arbiter etc may also affect to code.
* In some cases, using compressed data is faster than uncompressed one. For example, using highly-compressed-RLE data on the platform which has very-fast-CPU but slow NVRAM. In this case, dominate factor of performance is "performance of accessing NVRAM". So, compressed data has advantage on this. Besides, overhead for uncompress is very low in case of RLE.

Point in here is, "In embedded environment, even application engineer needs to know about it's HW platform where software runs on."

신고
tags : Programming
Trackback 0 : Comment 0