Flowchart oo killer?

In fact, I want to write this article for a long time, but I have never started it. Today I am not missing it.

First, I would like to introduce the background: The project is completed in Java and. Net in two languages (non-object-oriented languages can be skipped below ).

Today, I heard two colleagues (old employees) say that the boss wants them to draw a flowchart in the design document and draw the flowchart of the entire system. It seems that the flowchart is really harmful.

First of all, let's talk about the module I am responsible. My job is done by someone else. It's maintenance and rewriting. When I took over the course, I didn't quite understand why a method would be 600 + rows (a class would be 2-3 methods). I didn't want to understand it for a long time, so after I got familiar with the process, draw out the flowchart, and then break down the large method into small ones. But it is still a very large class. Later, I read the restructuring book in my spare time, so I tried to break down all the categories into small categories with specific responsibilities, (the main method used is to extract the base class and the public method ), as a result, several 600 + rows of classes are divided into 10 100-rows of classes (of course, some of the methods are put into public class libraries, about lines of code ). After the reconstruction, the Business Process has undergone a major change and the business logic of the module in my charge needs to be greatly changed. I thought this change would make me very uncomfortable, unexpectedly, I used about three 10-line functions and an if statement to solve this change (of course, I thought about it for about half a day before I started it). The remaining work was a battle with the interface. This is the first time that I really feel the power of object-oriented.

The second is what I see from the restructuring of the entire system. In the past, the system was written by two colleagues (one of which was previously in PHP), but the code I saw was a large function with more than 500 rows, most of the time I see a page_load function with more than 300 rows. A lot of code is repeated. Even in the page_load function, there are duplicates, and shared code can be extracted. I have never figured it out. Later, I saw a pretty girl, And suddenly thought about the process when I was responsible for authentication reconstruction. Everything was clear.

At that time, my boss asked me to draw the entire process, which was very detailed. There were about 60-80 frame flowcharts, And the twist was 2-80 ~ 3. Then, because this flowchart was drawn during detailed design, I wrote the entire authentication process to a class in the process of writing a program, finally, I wrote a class with more than 600 rows (the only consolation is that I didn't write a function with more than 600 rows ).

So I came to the conclusion that the flowchart should not appear in the detailed design instruction of OO as the main programming language, instead of the sequence diagram (others may not be so good ). (Or we seem a little cool to mark the process as belonging to that class in every process ...) Of course, you may say that this should be done during detailed design. If your company's process is like this, I would like to ask you to write down the specific process, because I have never experienced such a company. Another possibility is that a class of 600 + lines or code with a function of 600 + lines is not detailed enough when you split the function, I admit this, but please let us know how to use the functions in detail and how to use the object's responsibilities or other methods.

Why do I come to this conclusion? The main reason is that if you can draw a sequence chart, you have to divide some responsibilities, so in general, there will always be fewer responsibilities for a class than before. In addition, when you draw a sequence chart, you should think about the composition of the class. Therefore, our class responsibilities are clearly defined. Our class is also small, our waist is not sour, and our legs are not hurt.

However, isn't the flowchart useless? I don't think so, because for the document that needs to be explained to users or non-technical personnel for requirement analysis and outline design, the flowchart is very simple and clear, especially when designing the requirements. The problem we encountered here is that we copied the flowchart directly to the detailed design. (Maybe you are a puryeist. User case can easily communicate with customers, but I have never understood the use case diagram, but the flowchart also draws a good customer)

Or, is this laziness among the seven sins ....

Comments are welcome.