Ting 이네 Software 이야기

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

__stdcall vs. __cdecl

refer below page..

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

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

Requirement is one of most popular cause of problem in software development. Change of requirement always affect overall software development, severely. I want to skip general things about Requirement because there are already lots of stuffs about this. Let's just focus on Requirement of Handset software development. Especially, User Interface Specification (henceforth UIS).

In general, there is department in charge of UIS. The department composes UIS. Then, this UIS is delivered to Development team (development team design software big picture based on this.), designers(designers make images, screen layouts etc based on this), and test team (test team makes test and verification cases based on this.)
As you see, the point is "UIS's impact in the software development is extremely critical.". And usually, number of people who make UIS not alone. And it is true for design, software development and test. Let's image that UIS is not clear. What will happen? In this case - development based on unclear UIS -, huge amount of communication overhead is required between UIS, design, development and test team. This cost is extremely large - over than expected. (I can say like this based on my experience. Believe me.)

Even though clarity of UIS - we can also say it as 'completeness' - is very important, in many cases, it is underestimated. Instead of clarity, originality or creativity of UIS is usually required. I'm not saying that originality and creativity are not important. My point is, clarity or completeness is as important as originality or creativity.

UIS is also a kind of "Specification". So, it should be clear. That's my point.