Shulou(Shulou.com)06/03 Report--

At the end of last year, I wrote the Java coding specification for my technical team. The implementation process is smooth, because the team is not large, and everyone wants to have something to refer to. But when I communicated with other teams, some programmers gave me a different opinion. Now I pick out a few:

1. The team should pursue consistency in design, such as consistent business logic and consistent algorithms, but should have some personal color in the coding style, otherwise it will be no fun.

2. We have so many things that restrict us every day, for example, we have to clock in to and from work, work tasks have to be completed on time even if we work overtime, the salary is not raised according to our wishes, and the boss does not understand my wishes and thoughts, and so on. Why restrict something with such a small coding style?

3. There are so many specifications in the development team that even the coding specifications should be unified? The development team leader and technical manager should not interfere too much in the details, so how else are we supposed to work?

Hearing these words, I sigh very much, because I have had similar thoughts before. But what I want to say now is:

1. We are a team, we need to cooperate and work together. The job of project development is not to play with each other, let alone to amuse yourself. A standard coding specification is conducive to team collaboration, including code sharing, interactive learning, pair programming, cross-testing, code review, etc., and is more conducive to improving everyone's work efficiency and team spirit. It is like the implementation pattern so that people do not have to waste energy on trifles and do it directly according to tested conventions. It is more like a design pattern, so that we have a common reference, a common standard practice.

2. People live in the world, unless they have the ability and courage to be a unique and history-making person, they need to abide by the norms and systems of the social state, family, company and team. But even the kind of awesome people mentioned above need to learn with an open mind and integrate into the environment before they can make history. Therefore, I think an organization needs its own rules, whether it is reasonable or not can be discussed and discussed, but the necessity of its existence can be completely affirmed. I believe that a member who wants to work with a team and has team spirit will not question general norms and systems.

3. As far as development work is concerned, what I advocate is the unity of coding style and the freedom of design style. The design concept and architecture of each project need to be controlled by the technical person in charge of the project. only in this way can we really think about how to do a good job in software design, and only in this way can we really gain experience and exercise in the project. However, small things such as coding style, parent package naming rules, indentation rules, and so on, are not needed and not worth the trouble of every programmer to choose, which is not conducive to the clarity of work priorities or the improvement of code readability.

4. In fact, from the concepts of implementation pattern and design pattern, we can reflect the real meaning of unified coding style and free design style.

Implementation patterns are some historically proven conventions and principles. Although it can be adjusted according to the specific situation, in most cases it has become a habitual behavior of most developers. Change for no reason means that extra effort is needed to explain and understand in the process of interaction and communication. The coding specification is similar to the implementation pattern.

Design pattern is also a good design method summed up by the elites in the industry. However, each project has its own particularity and independence. We need to make our design according to the needs of the project, and it is no good to copy the design pattern completely like a textbook. I rarely see that completely copied code can be a good design. What is a good design? In my opinion, good design is that developers choose, combine, evolve and apply many design methods and techniques according to the actual problems to deal with, and build efficient and flexible solutions to meet all kinds of objective indicators. Note that I'm not talking about the small piece of pattern code used in a class, but at least for the systematic design of the module. What is the free and open design for? this is why, according to the problem solving, we can exert our productivity and creativity and build an excellent solution.

All of the above, you are welcome to discuss and pat bricks reasonably.

The "Java coding reference Specification" (which has been changed to version 1.0) that I wrote earlier is mentioned in the attachment, for reference only. Of course, I also hope that you can put forward your own suggestions and opinions on the details.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.