Code Encyclopedia read Note 03

No matter what the drag is always done, I feel that my procrastination seems to be meaningless waste of time, my procrastination squeeze out of the time is doing what, this really let me reflect on. Okay, go ahead and read the code encyclopedia, I'm starting to get bored already, because it's too thick. Transition engineering, this problem is not easy to grasp well. On the one hand, we want the system to be robust, and if the constituent parts of the system only meet the robustness requirements at least, then the whole is usually not up to the requirement. The robustness of software does not depend on the weakest, but on the product of all weak points. The architecture should point out that each part, the programmer would rather do over-engineering for the sake of prudence, or make simple things that can work is enough. Some things should not be too much effort, this mistake we have also committed, especially some beginning to know the future is likely to be reconstructed parts, a lot of energy spent in it is wasteful.

Some things I still do not understand, for example, this is called management complexity of the noun, followed by the teacher on a semester of software engineering introduction, learned a lot about the project introduction, I heard is the time complexity and space complexity this is said algorithm, the book said is the core of software construction, well forgive me still small, I don't know anything about the core. In addition to these also learned some small knowledge, such as the interface of the class should provide a consistent abstraction, if the violation may cause a lot of problems, the interface of the class should hide some information-such as a system interface, a design decision, or some implementation details, these I am a bit confused, interface so much attention AH. And the inclusion of classes is more reliable than inheritance, this, I still have no experience, what is more reliable, is IT security? Oh, there are said, inheritance will increase complexity, well, the original still have this stubble, really do not feel ah.

And then it's about the subroutine, does this have something to do with our unit tests? The main purpose of creating subroutines is to improve the manageability of the program, and there are other good reasons. Of these, saving code space is only a secondary reason: it is more important to improve readability, reliability, and modifiable reasons. Sometimes it is valuable to write simple operations as separate subroutines. Subroutines can be categorized into many classes according to their cohesion, and you should make most programs functionally cohesive, which is the best form of cohesion. The name of the subroutine is the indicator of its quality. If the name is bad but appropriate, it means the sub-program is poorly designed. If the name is bad and inaccurate, it doesn't reflect what the program does. Anyway, a bad name means that the program needs to be modified. A function should only be used if the primary purpose of a subroutine is to return a specific result that is described by its name. Careful programmers use macros with great care, and they only use them when they have a last resort.

Reading these feelings is a little more insight, although it is old books, but some knowledge is not outdated, I am such a starter really need to eat this knowledge.

Code Encyclopedia read Note 03