Talking about the top ten reasons for hibernate's success-I personally think the software development process should be like this.

Top Ten Reasons for hibernate's success

(2005.06.22) from: Saidi

The following is my personal thoughts on Hibernate development, which makes hibernate so popular so quickly. 1. Fast version release Maintain active development speed, frequent version release, or even several days From the previous version to the next version. This is the best way to ensure that the software is away from bugs. It can also reassure users that hibernate is very active in development. In addition, this also has a great advantage, is to find out which functions are really needed by the user. 2. regression testing I think the entire Java Community must pay great attention to automatic regression testing. If the functions and design of the software are greatly modified, a comprehensive test suite is too important for Software maintainability and stability. We should be aware that if a new function of the software is not tested for regression, we should not do it at all. 3. Make a function the best. If you do not do this, you must do your best. If we cannot do the best functions, we will not do it at all. Instead, we will do it with other software. 4. Avoid over-design It is a waste of time and energy to abstract software functions and expand the flexibility of the software. It is better to spend more time solving the actual problems your users face! Simply put, the most important thing about software is to run it. Do not try to solve problems that your users don't care about at all. It doesn't matter if your software design is not elegant enough. It's still in the initial stage. In the future, you can refactor again. The problem you should pay attention to is to promptly develop useful functions. 5. Centralization At least you have prepared the software outline before you can decide on it through democratic voting. Software development needs to be led by one or two enlightened people. This can ensure the consistency of software development and avoid too many disagreements. It can ensure that the development team can focus on the best functions to be implemented. I think the biggest risk of OSS software is that the opinions are not uniform, the stalls are too large, and nothing is done at last. (According to the Translator's note: All successful OSS software is released after a person has completed the software and then adds functions to it, and under the leadership of this person, he keeps improving. The lack of this person's OSS software is not very successful, such as Mozilla) 6. Documents Nothing is more important than the document. If your users do not know that your software has such a function, it means they do not have this function. simply remove it, saving the complexity of source code. 7. Avoid Standardization Good standards can bring about the interoperability and portability of software, and bad standards can suffocate software innovation. The best software is generated during constant attempts, errors, and experience accumulation. In fact, the standards are often closer to user needs. 8. Run hibernate in 10 minutes Potential hibernate Users download hibernate. During the first use, it is impossible to spend half an hour to install, configure, and troubleshooting, they have long lost their interest in hibernate. Our slogan is that new users (assuming they have enough knowledge about JDBC) can run the hibernate demo within five minutes, they can write the "Hello World" type of the simplest hibernate program within one hour and run normally. 9. developer responsibility When users encounter problems, the development team is obligated to provide assistance. Users let us know the vulnerabilities in the document, and users let us know the small bugs in the test case. In addition, there are no users who use our hibernate. What should we do with it? Isn't it a waste of time! There is a joke about bugs: users don't even mind discovering new feature bugs (the translator presses: Windows users seem to be doing the same), as long as you can quickly get rid of bugs. "Sense of Responsibility" means that bug fixing should be within one week. From the receipt of the bug report to the submission of the bug fixing code to CVS, the average time should be around 24 hours. This is an ideal goal. 10. Easy-to-use and updatable wiki webpages