I wrote an internal exercise book: Perfect software development: Methods and logic

First of all, let's talk about "Perfect software development". Imagine that perfect circles do not exist in reality. In reality, circles can only return to perfect circles, but the perfect circle describes the composition rules of the circle. Perfect software development has the same meaning. It tries to describe the rules and iron laws of software development. But since there is no such thing in reality, is there a sense of perfection? Well, let's look at the perfect state again:

Newton's first law said: when an object is not balanced by any external force or force, it always keeps moving or static at a constant speed, until the external force acting on it forces it to change this state.

This is obviously a perfect state or an ideal state, and it does not exist in reality. Is it meaningless?

I personally feel that the perfect state of software development is the same as the Newton's Law in software. Although it does not exist in reality, it has great guiding significance for reality. I just want to be a master. For example, the android master is not very useful in such discussions and books. But to grasp the global picture, this kind of discussion and this kind of book is of some significance.

 

So how can we explore this perfect state?

Such books, including the Mythical man-month, are often written by induction. However, in this way, there will be a certain limit on the sky: there is a limit on the experience of a person's vision, and the software world is actually infinitely broad, compilers and information management systems may differ significantly from humans and pigs. Therefore, when we use induction and cannot clearly understand the boundary of our conclusions, the book is easily biased. Therefore, this book is written by the embedding method and deduced by the logical chain. The three bodies may know how the law of the Dark Forest came out, but the logical chain is used in such books, i'm afraid few have done this yet.

 

Look at several logical chains. This book presets several preconditions, and all logical chains are based on these premises.

• Software is a solid way of thinking
• Consciousness-Guided action
• Project resources are limited.
• Repeating the same job will reduce the efficiency.

The following are the logical links in several books.

For quantitative management:

Software is a kind of Fixed Thinking → the essence of thinking is concept and logic → concepts and logic cannot be directly measured and precise measurements → A lot of subjective judgment is required in the measurement process → target-oriented, personal-centered quantitative management (related incentives and punishments) will crash → judgment based on unambiguous data (function complexity, etc.) will become an auxiliary measure for programmers to evaluate.

 

Process scale:

Software is a kind of solidified thinking → thought solidification is essentially not a routine business → people on site need a large autonomous space → the process granularity of software needs to be relatively large, rather than specifying work details, manual. → The process can be equivalent to an interruption. From this scale, it can be used to determine whether the current process is too heavy.

 

Selection of development models:

Repeat the same work will reduce the efficiency → No analysis and preparation for the established problems in advance, it will lead to the same work multiple times → pure iterations will lead to some problems that can be found in advance not to be handled, and thus lead to unnecessary duplication, and ultimately reduce the overall production efficiency of the organization

 

Where to end demand development:

The resources that the project can consume are limited. if the demand is expanded infinitely, the limited resources will be used for unlimited work, which will eventually lead to errors in the busy schedule → in terms of the breadth, as the application environment of software is changing, there is an increasing trend in demand. → In terms of breadth, we need to clearly define those requirements that are not needed. → In depth, the need is clearly a gradual process. It is expected that at a certain end time in the early stage, it is unrealistic to clarify all requirements. However, the lack of clarification can lead to a reduction in efficiency. → In depth, we need to define the detailed degree of requirement development

 

Orthogonal Design:

 

Software is a kind of solidified thinking → the solidification of thinking is embodied in the solidification of concepts and logic → to ensure simplicity, the logic should be as few as possible → the concepts should be as orthogonal as possible

 

Of course, only these logical chains are not enough. We also need to add examples to explain the specific meaning of the logical chain.

Taking the last logic chain as an example, if you believe it is right, and then look at the design and code, you will see many new problems, such as: Robert C. in Agile Software Development: principles, methods, and practices, Martin provides an example of the door.

 

In the example of Robert C. Martin, there are some security systems that can be loaded and unlocked and know whether they are open or closed.

Class door

{

Public:

Virtual void lock () = 0;

Virtual void unlock () = 0;

Virtual bool isdooropen () = 0;

};

Next, a more advanced door appears, which generates an alarm if it is too long to open, known as timeddoor.

Timeddoor needs to use a timer to start certain events on a regular basis. The basic creation mechanism of a timer is as follows:

Class timerclient

{

Public:

Virtual void timeout () = 0;

};

Class Timer

{

Public:

Void register (INT timeout, timerclient * client );

};

Any timerclient can register itself with timer, and timer will call the timeout () of timerclient according to the specified time interval ().

 

So far, timer, timeclient, and door are conceptually orthogonal and there is no problem.

 

Next, to enable timeddoor to have the timed alarm function, these three concepts need to interact.

 

There are many processing methods. The first method, door, inherits from timeclient. The orthogonal degree of this method is the worst, and the contact surface is too large, such as Robert C. according to Martin, many doors do not have to be scheduled at all, but once the door is inherited from timerclient, No matter what door has the characteristics of timing, this association makes no sense.

The second method is to enable timeddoor to inherit timerclient and door respectively (multiple inheritance ). Robert C. Martin thinks he will prefer this method.

From the orthogonal perspective, in this way, timeddoor is associated with only the parts related to itself, and the orthogonal has been very good.

If you think about it, you will find that there is still a problem with the second method of Robert C. Martin.

Timing alarm is a function, and recording is also a function. Automatic Message sending is also a function.

These functions may even be dynamically configured. If multiple inheritance is used to solve the problem, a variety of objects will be derived, such as videodoor, timevideodoor, messagedoor, timevideomessagedoor, and so on. It seems that this is not a good thing.

This means that the orthogonal degree may be improved.

If you do not want your thinking to be limited to everything that must be an object, you can find other solutions. We can think that the timed alarm function is a combination of links, that is, using links rather than inheriting relationships. That is to say, we do not think that there should be classes such as timerclient independently, but think that this is an accidental combination. Otherwise, classes like xxclient will fly in the sky. Imagine that the door and toilet can both be timerclient and motor client.

 

The above is the discussion and analysis of orthogonal in the book, which will be aimed at almost all major software development fields. The advantage is that you can think of more things that others don't see. The disadvantage is that there will be a little abstraction in many places. In general, this book is suitable for people who are willing to think about things and are willing to think about essential issues. It is not suitable for people who like things and do not like to think about things.

 

In addition to using the deconstruct method to re-deconstruct software development, this book also does one thing: to explore the relationship between various fields of software development. All the software users know that the management is good, the project result is good, the process is good, the project result is good, the development model is good, and the design code is good. The project result is good. However, in practice, people responsible for different things will always conflict with each other, and the process and the on-site code will always be unable to work together, because the different parts work together on the one hand, on the one hand, the competition is limited resources. In order to cooperate well, it is clear that any part of the book has to be stopped to a certain extent, which is also abstract and another part of this book.

It will take a long time to write it down.

The last two sentences are the other ones.

People who have read my other articles should generally know that I prefer to write essential things and like to look at things in a philosophical way. From the perspective of immediate usefulness, such articles are actually quite different from books. However, I sometimes think that The Mythical man-month is not immediately useful, and many people still read it. Therefore, this kind of thinking on the essence is still useful, so I insist on writing it out.

Next, I will write a little bit about how to share the written content with anyone who wants to write a book.