Why not be object-oriented

There are good ways to solve the problem through Rome.

1. The product must meet user needs.
Windows, ie, word, and firefox are used every day. But for users, who cares about the code and architecture behind them.
People on the production line use the products you write every day. They only care about whether the products can complete functions accurately, without faults, and whether the operations are convenient.

Many people think that the architecture is not good and the code uugly, So rewrite the product. Let's take a look at the following old links.
Talk about: http://blog.joycode.com/demonfox/archive/2007/03/21/98381.aspx
Things You shoshould Never Do, Part I: http://www.joelonsoftware.com/articles/fog0000000069.html
It mentioned NetScape rewriting and so on, and even Microsoft's word was intended to be rewritten. It seems that these articles or somewhere else mentioned that an ftp code was rewritten for 3 or 4 years.

When we face a line of code every day, can we think more about how the code can help users complete the desired work conveniently? How can they help companies achieve more profits and help customers achieve greater value? What impact does the application of new design ideas and every error hidden in code affect the project and the customer?
This is not only the responsibility of the boss, architect, and project manager. Everyone in the project should have a deep understanding of the product. Programmers who want to go high in their careers, even if they are promoted to a Senior Programmer or architect, need to constantly focus on these aspects. So don't stare at the code all day long. It's always the same as the code.

2. The product must meet market requirements and meet market operation strategies.
A lot of programmers, who were later project managers and sales engineers, were already working as bosses. They wanted to learn more about their problems and their ideas. Maybe you plan to start a business as a boss soon.
There are not many projects that can be written for six or seven years as Blizzard does. The launch of the product ensures great success in the market. Vista has been written for five years, writing for another few years may be out of control. In particular, the fierce competition in China has already done well for a slow half-beat.
Therefore, the boss has market pressure. The project manager needs to handle the project cycle and quality pressure and handle various technical and unknown fault risks.

In many cases, the boss's requirements are not wrong. The customer's requirements are not unreasonable, but you do not understand them, therefore, you are declared unreasonable, funny, and unsuitable for product development requirements. As a result, we cannot fully cooperate with the boss or manager to achieve our goals. Finally, the boss said that programmers are incredible. The programmers said that the boss is really poor, double-lose!

3. Do not blindly follow.
"Don't get lost in the ocean of technology" should also mean that.
Looking at "Domain-driven design", the author began to say that this method is not a panacea, and many of his projects failed to use this method. Looking at the enterprise application architecture model, the author does not tell you whether your project should use a domain model, a transaction script, or a table module. You need to select a project based on your actual situation. I recently started to read "Analysis Mode", where every mode was described from simple to complex. However, at the beginning, the author proposed whether to choose a simple mode or a complex model based on actual needs, A good model is required for the correct implementation. Do not blindly make too many assumptions for the product.
Although Martin Fowler and Eric Evans are both influenced by agile thinking, this is not the key, and so are other books. They provide only one method, thought, specific use of the specific environment, some inconspicuous words at the beginning, after understanding these ideas, these words are the most important.
If a manager can always manage and develop products according to the ideas of everyone in the garden, it is very likely to be a manager who has failed completely.

4. products need to be accumulated.
Product maturity does not mean that the code is more beautiful and the architecture is more perfect. These things only occupy a relatively small part. Product maturity mainly refers to the product features, performance, stability, and user usability, as well as the flexibility and scalability from the business features and operational deployment requirements.

Many times I will hear this: this project is so simple that I really don't know how it took them so long; it's so simple that I can't figure out why it's so complicated.
I have carefully read the two links recommended above and can easily understand them based on my own experience. Many very Uggly codes hide a lot of difficult fixing knowledge, which is one aspect.
On the other hand, it is not easy to collect requirements step by step, and create products from scratch to meet user requirements and run on the production line, there are a lot of difficulties you can't think of. It may not be better to give you a redo.

Many people are learning the design model. Many people are constantly refactoring code every day. Have you actually paid attention to the work you have done, how many benefits are brought to products and users and how much value is realized. In fact, from the actual needs, the programmer may not have played a role from start to end, or the role is very limited.
Most of the time, you find that the products you are responsible for are flexible and feature-effective. However, there are many new requirements for users and the next project/customer, and the existing architecture cannot meet many requirements.

For a long period of time, it is unlikely to develop a product like many programmers imagine. We can only constantly make small changes in the project to accumulate products, and make some major adjustments as appropriate to improve products.
What is the probability of success of a product if we use various methods and ideas that we advocate from the very beginning?
Do not say that small companies have such bad practices. Managers with no mind will deny such practices. Look at Oracle, MS, HP, etc. Look at Indian software factories, do they all adopt the ideal practice?

Ensure that the first version is available, the second version is easy to use, and the third and fourth versions can be used in a general sense, not at the code level, but at the functional level. I believe many of the company's products are such a strategy. There are not only market strategies, but also product project iterative development methods, gradually improving functions, user feedback, and other considerations.

Finally:
Look at the problem not just, object-oriented or non-object-oriented, stored procedures or SQL, and discuss and communicate with each other to deepen understanding. As for the actual environment, how should we adopt, are not conclusive.
A lot of programmers and development teams have been passing through and are not willing to understand what they have not mastered. Because of Chen's old-fashioned style, it is indeed one aspect. Some of them are not self-motivated, sometimes life or other things are too stressful, and work is just perfunctory. Since they are active in the garden, most of them should not be listed here, so we should pay more attention to changing our perspective to analyze the problem and make our technical research more targeted, A more comprehensive view of the problem.