Some gains from internal company training

Author: Zhu Jincan

Source: http://blog.csdn.net/clever101

 

Our company invited a lecturer to give us training near the end of the year. The subject should be a design craftsman. To be honest, I can't organize all the content that I have mentioned in my lecture as a lecturer. Let me talk about some of my notes. In general, this Lecturer has rich practical experience and is also vivid.

 

Viewpoint 1: there is a conflict between code scalability and maintainability. This is a point raised by the lecturer at the beginning of the class. To be honest, I don't quite agree with this point of view. On the one hand, it makes code maintenance more difficult to enhance the maintainability of the Code. For example, if the mode is used, the system complexity may be increased, however, it often enhances code scalability and facilitates code maintenance. For example, if the scalability is enhanced, you can easily find the code you want to maintain if an error occurs. I believe that many people who often perform Code refactoring have this experience.

 

Viewpoint 2: three features of good code: communication, simplicity, and flexibility. In fact, these three points are the same as the maintainability of the code, so the lecturer's next point is that the maintenance cost of the Code is far greater than the development cost. This should be in line with the actual situation. The problem is limited to the domestic IT environment. How many enterprises pay attention to the accumulation of technology? If you pay attention to technical accumulation, you will really pay attention to code maintenance. Ambitious enterprises should all work in this direction.

 

Opinion 3: code is design. This is a somewhat vulgar point of view, but it cannot attract our attention. In the past, I always dreamed that the more documents I maintain, the better. The document has many drawbacks: first, there is a gap between the Code and the document, for example, the Code is updated, but the document is not updated in a timely manner. Second, even if your document is well written, but will the maintenance personnel view your documents? The code must be viewed whether the maintenance personnel like it or not. Now I think that in addition to some complex mathematical algorithms that need to be described in the documentation (and tools and code must be used together), the code should be designed, that is, the document!

 

Viewpoint 4: the three elements of object orientation are roles, responsibilities, and collaboration. All design models are responsible for solving the problem .. First, there is a responsibility to have a design model. These ideas are brilliant. I want to re-read the design pattern of the four-person group, and I will definitely think about the problem from this perspective.

 

Viewpoint 5: design patterns are encapsulation techniques, but encapsulation is not just information hiding.

 

Viewpoint 6: Design Method: extraction (Abstract isolation), indirect and consistent.

Viewpoint 7: Fast iteration is required for most software projects or mobile development fields. Fast delivery of an available product is more important than anything else. Do not pray that the demand will not change (there is a joke: any demand has occurred more than three times, and the demand analysts who have changed twice will die on the way to the user to change the demand ). Because changes are inevitable, we must strive for changes to come early, and fast delivery can bring more user feedback to better cope with changes.

 

Viewpoint 8: continuous building must be combined with a series of tests, such as unit tests and stress tests.

 

Viewpoint 9: UML is mainly a communication tool. The instructor promoted a simple UML + test-driven development mode. Testing actually sets a red line for software development activities.

 

Opinion 10: The lecturer thinks unit testing is very good. He believes that unit testing can provide timely feedback; unit testing can make your code more robust; unit testing is a useful design tool; unit testing is the background that gives you confidence; unit testing is a problem-solving detector; unit testing is a trusted document; unit testing is a learning tool. (Now I am very interested in unit testing .)

 

Some of my questions: If we advocate fast iteration of small version delivery, who determines the priority of feature development? Is software design, such as interface design, completed by developers?