Mr. David Lorge Parnas: What exciting software engineering technologies do you think will emerge in the future?

David Parnas: The most useful technology isn’t in the future. It’s been around for years, but we’re just not using it.

Many students have learned a few programming languages, read a few tech blogs, and are generally enthusiastic. They want to do a project that shows what they’ve learned all their lives.

Add cutting-edge technology and make a sensational innovation. This is encouraging, but practice has shown that it often fails.

Let’s look at some successful examples of how they did it, like when Linux was first developed:

I’m doing a (free) operating system(just a hobby, won’t be big and professional like GNU) for 386(486) AT clones.

I am writing an operating system for 386(486) AT Clones (just a business hobby, not as professional and bulky as GNU).

Those entrepreneurs who start out with the idea that they’ll make it big-can be guaranteed failure.

Entrepreneurs who start out thinking they’re going to be big fail.

preface

When I started this article, I thought of my junior high school. I went to junior high school in a town and went back once a week. I always set a goal with full confidence: to go home and read all the books I had memorized. But you know kids can’t resist temptations like sleeping in and playing games. When I wake up, my friends come, and then we go to play games. When I go to school again, I will carry these books to school. This repetitive work should have continued through my junior high school years. Back to that time, back of the book the goal of this no reason is I set too big, let me find it hard to finish, but at that time I didn’t realize this, obviously every weekend, I will desk full of books into the bag, I was delighted, fantasizing about yourself at home reading will make the family happy.

Then I think of the project competition in my university. The project leader wanted to build a beauty community mall, which is roughly equal to the combination of Xiaohongbook and Taobao in terms of positioning. Let me introduce our technical background at that time: Servlet, JSP, JQuery, MySQL(writing basic SQL statements). But at that time did not complete the design goal of the combination of Xiaohongshu and Taobao? It should be unfinished, roughly equivalent to our goal of building a building, and finally built a crumbling thatched hut, only to wait for “the high wind in August and autumn”, “three pieces of grass on my house.”

I think there’s always a sense of fear when a goal is too big, and the common practice is to break it down into smaller goals that seem easy to achieve.

I think it’s nice to solve big problems, but it’s not easy to solve small problems.

On the principles of software design

Many of the principles of software design are derived from practice, where the requirements that people encounter frequently change, to ensure the maintainability and efficiency of programs in the face of changing requirements. Let’s take two software design principles as an example. First, the Single Responsibility Principle (SRP) states:

A module (class) should have only one cause for its changes, and a module should be entirely responsible for a function.

The classic book of software design, Agile Software Development: Principles, Patterns, Practices, is divided into the following examples:

A module dealing with a square has two functions: (1) calculate the area and (2) draw the square.

This design has a module responsible for two different tasks: performing geometric operations (independent of the display graphics) and graphically drawing squares. If a collection computation program needs to use this module, it will need to include the graphical display (because it is in the same module), which is wasteful, introduces unnecessary dependencies (because the graphical display is related to the underlying graphical implementation), and hampers portability. In addition, changes to the geometric calculation requirements and changes to the graphical display requirements can cause changes to the module, increasing the risk of errors.

Another example describes the API interface for a modem:

Interface Modem{ public void dial(String pno); // pho means port number dial public void hangup(); Public void send(char c); Public void recv(); // recv receives information}

The word Modem is a little obscure, but Modem is the transliteration of Modem, which is probably more familiar to you as cat. Modem is actually a combination of Modulator and Demodulator. Modulation is the conversion of digital signal into analog signal, demodulation is the conversion of analog signal into digital signal.

When I read this example, I thought Interface was an Interface, and I added public in front of it. If it was an Interface, the context would be confusing because it says “describes the API Interface of a Modem”. Modem means Modem. If Interface is understood as an Interface, then this doesn’t make sense.

So “Modem API Interface” is supposed to mean, Interface is the Interface, Modem is the Modem. In curly braces is API(Application Programing Interface). Then he added:

This interface does two closely related things, connection management (dial,hangup) and data communication (SEND, RECV). Are they two responsibilities or one?

The conclusion is that, depending on the situation, changes in requirements cause these operations to change at the same time.

The second half of the part, my understanding is that there is no general criteria for this single responsibility, to be determined according to demand. What about “this interface does two closely related things”? My understanding of the interface is as follows:

But isn’t that about modules? Where does this get us to the interface? “This interface does two closely related things.” What does that mean?

I went through Agile Software Development: Principles, Patterns, and Practices, and realized that I may have overread it, that this was a slip of the pen by the author of The Building Method: Modern Software Engineering, and that the Modem example above is an interface in Java in Agile Software Development: Principles, Patterns, and Practices.

So should connection management and data communication count as two responsibilities, or one? In other words, in the case of eating, manipulating chopsticks and putting food in your mouth, these two closely related activities should be grouped into one module from a eating perspective. This natural division comes from an accurate understanding of one thing, eating, but what about the other? There seems to be no absoluties, but a case-by-case analysis is needed to see if a change in requirements always causes these operations to change at the same time.

Writing here, I suddenly think of microservices. At the beginning, the software was relatively simple, with less code, simpler business and fewer users, so most of the software at the beginning was integrated with the front and back ends. With the rapid development of hardware and the continuous popularization of the Internet, software is gradually getting closer to the complex at the same time, and the amount of code is also constantly expanding. Software development is not a one-time deal, unlike the sale of a house, which has little to do with the developer. After software development comes maintenance, which is very much like urban construction, where a lot of people are pouring in, and a lot of people think there’s money to be made here, and then the rulers of the city will start expanding the city to accommodate the current development of the city. It is also like social development. It is impossible to compare the county magistrate in the feudal society in the past to the present. The county magistrate in the past gathered many positions, which may be related to the relatively small population of the county in the past. This also corresponds to the micro-service architecture. We disassemble the application that was originally focused on a service into several micro-services. Each service carries out a single responsibility, and the services provided to the outside do not overlap as much as possible, which also confirms David quoted at the beginning of this paper. The words of Parnas:

The most useful technology is no longer in the future. It’s been around for years, and we just don’t use it.

I think of me who just learned Spring Boot. I watched Teacher Yan Qun’s video at STATION B: SpringBoot video Tutorial (Introduction), in the beginning of the video to talk about microservices, said that this is the current popular software architecture, I was quite novel, maybe at that time did not develop a big project, the amount of engineering code is relatively small. At the time, the idea was that microservices architecture was suitable for large projects, easy to scale and maintain, but in recent years, it seems that microservices are becoming the new normal. Is that still true? In my current opinion, microservice architecture is sinking. Is the industry focusing on the expansion and easy maintenance of microservice architecture? Not necessarily. My personal view is that the ability to reuse services, such as certification services, can be developed once and then re-developed for a new project.

This single responsibility can also be seen in the division of Web software engineers. We know that the hardware capabilities of many computers are roughly doubling every two years. However, the process of software development has not been accelerated in such a way, and the development cost has not been reduced. The Web engineers who originally integrated front-end, back-end, operation and maintenance and DBA have been divided into four occupations:

  • Front end engineer
  • Back End Engineer (also called back End Engineer)

  • operations

    DevOps is a very popular word in the current Web development world. DevOps is a portmanteau word that combines Developers and Operators, a combination of development and operations teams. The operation and maintenance that had been taken away from the back end is now back on the back end.

  • DBA

Is it the idea of holding a hammer and seeing all the nails in the world? Seems to be, and seems not. Split and division of labor can be seen everywhere in the human world, when you start a business, at first only a small business, you can do not have to ask an accountant to register the company, like a small restaurant in the countryside, you can be the boss can also be a cook, but also can be a waiter and accounting, cleaning. But you didn’t think your cooking is very good, delicious not expensive, the price affordable, your hotel soon attracted a lot of people, you slowly found that a professional life is more let you bear, there are too many people, in order not to let your parents involvement, you start hiring, cleaning and attendant responsibility assignment will you go out, you still don’t want to accounting, please. Do you think of your business is not so big, gradually found a cook you seem a little could not support the current users, you was tired to death every day, so you start wondering, recruit apprentice, cook, please make them responsible for cooking, you are responsible for into the dish, but seemed to recruit to wash dishes, to cook, wash dishes and cooking cook watch as heavy burden, cook has protested.

You want to expand the size of your business, but the daily accounting is a bit of a headache, and you don’t want to focus too much on the accounting. So you hire an accountant, and the story goes on, and you hire more people to take over your work, but when you assign the work, you try not to overlap the work, you don’t want one person to be the cook and the accountant, you want that person to be as professional as possible.

Another important software design Principle is the open-closed Principle (OCP)

Software entities should be extensible, but not modifiable.

To be specific:

  • Open for Extension is allowed. When the requirements of the application change, we can extend the module to change the function of the module
  • Closed for modification is not allowed. When extending a module’s behavior, it does not have to change itself

When should you use these principles? Agile Software Development: Principles, Patterns, and Practices also states:

The axis of change has real meaning only when the change actually takes place. It is unwise to apply SRP, or any other principle, if there are no symptoms.

Adherence to OCP is also costly….. Obviously, we want to limit the use of OCP to possible changes. . In the end, we wait for change to occur before taking action.

My understanding is that these principles are to cope with the changes, the developer is forecasted according to the own experience think here will change, the need to design personnel have some predictive power from experience, experienced designers want to users and applications are very understanding, can in order to judge the possibility of change. He can then design to follow THE OCP principles for the most likely changes.

This is not easy to predict accurately, because it means making an educated guess at what changes the application is likely to undergo over the course of its growth. If the developers guessed right, they were successful. If they guess wrong, they suffer failure. And in most cases, they guessed wrong.

How do we follow OCP? Let’s take a look at the following example to illustrate OCP:

This example is also from agile software development: principles, patterns, and practices, which describes OCP in C++, which I converted to Java. It is easy to see that if we add another Shape, the drawAllShapes method in our Shape class will draw the new Shape without changing it. Printing in the diagram can be understood as the act of drawing the corresponding graph.

This design is OCP compliant, and without changing the original code, we have completed the extension without triggering a chain change. This reminds me of the factory pattern, don’t know what a factory pattern, you can see my article: welcome to the era of the Spring – the introduction] (https://juejin.cn/post/692755…

If you add another Excel type, the WorkBookFactory needs to be changed. I don’t think I can say that. I think the POI developers thought that the changes in Excel would not be so strong that they would add a file format every year. At the same time, it also reduces the mental burden of using POI for developers. Excessive design leads to complex software, increasing maintenance and use costs.

Is the Shape above perfectly consistent with the open closed principle? It would seem that not entirely. We could have made a requirement that the drawAllShapes method had to be modified. Agile Software Development: Principles, Patterns and Practices gives the change that all circles must be drawn before squares, in which case the drawAllShapes seems to be unable to avoid the change. Wouldn’t it be nice if you said you could put the circle before the square when you pass the List argument? So I’m going to add another requirement here, which is to draw the square and the circle together. Unless you’re traveling through time, there will always be things you don’t anticipate, and no matter how “closed” the module is, there will always be changes that can’t be closed to, and no model can handle them all.

Since it is impossible to be absolutely closed, you must be strategic about the problem. That is, the designer must make a choice about which changes his module should be subject to.

The developer must first guess which changes are most likely and then construct abstractions to isolate those changes.

This reminds me of the design patterns, we think this is very useful, home of the interview is also very value, this to some extent led to the abuse of design patterns, the developers before did not have been familiar with specific business, began to expand, began using design patterns, it is easy to cause kinds of design patterns of the project, I remembered something the senior architect at my former company said to me the other day, when he saw me looking at design patterns. He told me that for someone at my level, design patterns didn’t help my code skills, and he hadn’t used them a few times in all his years of development.

To summarize

Being familiar with the business will allow you to see change, anticipate change, build abstractions to cope with change, and avoid a chain reaction of changes. You don’t want to Bug something you’ve developed before. My previous interpretation of the open closed principle was that if this part of the code is already online and running smoothly, leave it alone as much as possible. Then I added the open closed principle, which is to anticipate changes empirously and then build abstractions to cope with the changes. But it should be introduced carefully, this will increase the cost of reading and maintenance, but I often get the rebuttal that nothing will happen if I introduce it, so what?

Single responsibility before I understand is convenient and reuse, if A method to complete the A and B this two things, I suppose because some need to use A, B don’t need to use, so this way I will never, at the same time also make reading easier, I actually had the idea of can be covered in the change, I predict the future I will use A, My strategy was to make it as effective as possible.

Planning and estimation

When you can measure what you say and put numbers on it, you know it. If you can’t measure it and put numbers on it, your knowledge is lacking and unsatisfactory. — Lord Kelvin, British physicist

Is there will be a project to do the construction period, often allow developers to estimate time, this is a problem let me very headache, my project manager let me estimate of time, my brain is blank, I the idea was it to estimate without the need to work overtime, estimated that the project manager and are not satisfied, so I consult a predecessor of the company at the time, I put my worry about truthfully say, Senior said nothing, time is not enough to ask again. But I still want to estimate, I want to have a measure of my development.

When John Barkis started his FORTRAN project, his boss regularly asked him the completion date. He always gave the same answer :” Six months.” In fact, the project took nearly three years.

Before we start estimating again, we need to clarify a few concepts: goals, estimation, and determination. We don’t confuse these three words by themselves, but in practice, we can easily confuse them.

  • Goal: Indicates a desired state. Let’s say you want to catch up with a girl, but you should know that this is a goal, not necessarily a goal.

  • Estimate how much work and resources it will take to achieve something, given what you know and what resources you have.

    Pay attention to the first half sentence to understand the current situation and grasp the resources, I think of when I was in junior high school, more like to read network novels, a deep impression of a novel is “fight broken sky”, devour the grasp of the fire, this is also a kind of estimate. I really wanted to learn this kind of estimation, like when we were in junior high school, there was one time when junior high school had a Thursday off,

    Next week I was very much looking forward to having Thursday off as well, and my estimate was that the weather was going to be like an 80% chance. But in the end there was no holiday.

  • Determination: To achieve predefined features and quality by a certain time. If the determination is not well estimated, then the probability is not achieved.

We see this in software projects as well, and we see it all the time in software projects – why did we get it wrong? Because it’s hard? Why are software estimates so hard? In fact, all estimates are difficult, if you just make a blind estimate and don’t find the assumptions behind the estimate. If you don’t believe me, let’s do some estimating exercises, no search engine, you can estimate the following numbers (as long as the order of magnitude is correct)

  • The length of China’s land border
  • Population density in Africa
  • The annual flow of the Yangtze River
  • The total amount of Asian money in circulation in 2013

How’s that？ How many orders of magnitude off is your estimate? But if you make a list of the assumptions on which you make your estimate, does that make you more confident in your judgment? “It’s not that we don’t estimate,” says Paul Rook, a software engineering expert. “What we really don’t do is enumerate all the assumptions behind our estimates.” There is another dimension to our usual estimates which is the experience of our predecessors. Software engineers, in their long practice, have also developed a set of empirical formulas: the actual time spent depends mainly on two factors — the estimated time to do something, X, and the number of times he has done similar development, N.

Y = X ± X ➗N // Y is the actual time spent, and the intermediate ± means plus or minus.

Such as graduate you have been assigned to a user management module of the task, you estimate need three days, but you have never done the user management module, so N is 0, the high school math tells us that 0 can’t be divisor, but tell us university mathematics can limit case, so you spend time is 3 + infinity? So it can’t be done at all in the time given to the project, or 3 minus infinity? Instead of finishing the task, I wrote a lot of bugs, which made the team spend more time working on them and dragged the project down.

Note that this is an empirical formula, so it’s perfectly normal to have errors with the actual amount of time it takes, and this requires you to analyze the reasons after you’ve completed the requirements so that you can reduce the errors. If you keep doing the same project, the estimates will get more and more accurate as you get more and more skilled. But no one is willing to do the same thing all the time, which makes people tired.

Write in the last

At the end of the paper, I suddenly felt that this article was not exactly like the reading notes of the Method of Construction – Modern Software Engineering. When writing the principles of software design, I referred to the Agile Software Development: Principles, Patterns, and Practices, which takes only two pages to introduce in The Way of Construction: Modern Software Engineering, but the main content comes from it, as well as some of my own insights, which I hope will be helpful to you. The cover was taken by someone else when I was on vacation in Hainan, and I felt very beautiful.

The resources

  • Xin Zou, the Method of construction: modern software engineering, 3rd edition
  • The function of a modem is to implement
  • Why do big factories need DevOps?
  • 【 原 文】 The Open/Closed Principle
  • Agile Software Development: Principles, Patterns, and Practices. By Robert C. Martin