How I build a sustainable development project

Speaking of projects, each programmer should build their own projects, and I have built dozens of enterprise-level or Internet-level projects, in the enterprise-level project also abstracted a set of development scaffolding ES easy to develop, but also did some common code generation tools to generate common project shelves or some crud code. Do these platforms or projects when more or less give me some inspiration and principles, and these revelations and principles have been guiding my inner direction, always guide me not to deviate course.

Revelation

• There are principles in mind
• Code Normalization
• Code review
• Code refactoring
• Code comments
• Code Logic Abstraction
• Tool class
• Project closed loop
• Continuous improvement
• Automation

There are principles in mind

I think this is the soul of building and maintaining the project, losing the soul, although the project can run, but the future is no direction. Come to demand on the next, the last is tinkering. In fact, I personally believe that there is a principle in the mind is the future foresight, according to the existing needs to foresee the future development of demand.

For example, one of the projects I did was to rely on dozens of systems, so the previous practice was to have all of the systems I relied on call my synchronization interface to synchronize the data when it changed, and there were a few problems: assuming that the IP or domain name changed, you need to notify all the relying parties; Suppose we have a problem, Each relying party needs to retry itself, assuming that the data is out of order and need to notify the relying party to synchronize the data; This approach creates a serious coupling. So in designing a new architecture we completely abandon this approach, instead of using asynchronous notifications + pull-dependent data, such as notifying us of data changes through MQ, and then pulling the data through the interface provided by the relying party; the benefits of this approach: loose coupling If there is a problem with the data, then call the next relying party interface to pull off the data repair. So the principle of this project is asynchronous notification + pull data. And if the relying party does not provide this interface, we will not be able to meet their needs. Another special case is that some dependent data can be synchronized once a day, so you can use timed tasks to run once a day, that is, timed tasks + pull data. In other words, the worst case scenario is using the timed task + pull data mechanism.

For example, we received a request that we need to add a data to your page to show, when we show the page to call their interface to get the data and then show, the problem here is: if we rely on them, then their jitter will affect the experience of our page, although can be degraded, But we can't tolerate a bit of jitter, so the scenario we provide is asynchronous notification + pull data, store the data on our own side, or the front end is loaded asynchronously.

There are principles in mind, that is, there must be one or several central principles to guide our architecture is not off course, otherwise the project will be in the direction of decay, the more rotten, the last few people can maintain the project. Nor is it possible to bury the future because of the simplicity of the plan.

Code Normalization

There are some principles or standardized things to guide when writing code. For example, our project also divided what DAO, Service, Controller, and everyone may call the name/development of the idea is not the same, then we must unify, such as:

1, no need to come up on the abstract what DAO, service interface, my principle is an implementation class, because I project 90% above the situation does not need to interface this thing, in order to interface and interface can only make the number of classes increase;

2. All class names must be known and understood, and cannot express the full reconstruction of meanings;

3, the configuration file normalization, in fact, is classified, according to functional classification configuration;

4, such as the name of spring beans can be with the suffix, **service, **dao, **rpcservice, **httpservice, **datasource, see the name suffix to know what this function is implemented.

The standardization of different companies may not be the same, follow their own set of standardization to let the code in the direction of good development.

Code review

Code review for some new people I personally feel that it is necessary, because the new person does not understand our principles, not familiar with our code specifications, should be through the code review mechanism to correct or lead them toward us in a common direction. A code review can correct some of the wrong or bad implementations, identify a current optimal scheme, and let the newcomer be aware of some problems that he feels indifferent to.

Code refactoring

Finding bad or broken code has to be refactored, because if you feel that this code is a problem, as long as the project is alive, there will be a future problem for a certain day. A good one or a later change it could lead to a major online accident. So finding bad code should find time to refactor immediately. The goal of refactoring is also guided by the principle of architecture, and the non-conforming principle should be reconstructed.

Code comments

Many people may be bothered to write comments, think the code is a comment; Well, I think maybe he hasn't seen a pervert. Business needs, there are always some very perverted or magic code in our project, the code is only written by the people understand that, if there is no comment, you do not understand the intentions of his doing that, it will feel very strange, But that's actually the business requirement. There are some of the interfaces we rely on others, and this interface is very unacceptable, but already have a lot of departments rely on the impossible to change, at this time can only silently accept. Write a comment about these perverted needs or incomprehensible needs.

Code Logic Abstraction

Abstraction is a very important process that abstracts some of the common and often used functions in a project and abstracts them into common code or basic components, so that they can be reused for these functions, and this process is continuous, and discovering commonalities takes into account refactoring abstractions. This approach can improve our development efficiency and simplify the implementation of business logic. For example, we do the message processing system, only need to be simple configuration can work.

Tool class

In the project development process, to lead team members to use common tool classes, such as Apache Commons, Google guava and so on. Using these tool classes can make code bugs less (the most common such as null pointer exceptions), shorter code, and more understandable.

Project closed loop

When we were doing the project, we found that someone had split a large project into subsystems, and then these subsystems were separate projects, and then when the newcomers came they were always confused. So my approach is to build a big project like Maven and then split it into sub-modules, and the whole project is together.

Continuous improvement

Technology changes every day, so we have to continue to learn, to understand the current project of the best solution, and then appropriate application to the project, the continuous improvement of the project, sometimes it is necessary to develop their own life, sustainable development; But there must be a good rollback strategy, Any improvement can not sacrifice stability or increase accident rate as a precondition, this risk should have a good control.

Automation

For some operations or business-related functions We need to automate, and if we deal with some problems often, consider building an automated tool for these issues to reduce our duplication of effort.

I personally think that to build a good project, is to have good values, do not break the principles of their establishment, self-discipline towards a good direction of development, not lazy; anyone who destroys my code I have to find a way to correct it.

From Zhang Kaitao's blog: http://jinnianshilongnian.iteye.com/blog/2232357

How I build a sustainable development project