Thoughts on the survival of software companies

2. If you choose to use a technology for better selling this product, you can basically say that you are not going to do it.
4. Whether a development mode or design mode is suitable for introducing to your project depends not on how advanced the design mode is, but on the customers who use the mode, that is, whether developers can understand and master them. If not, it is not a suitable technology. At this time, you have several options: 1. Educate Your employees; 2. Change employees; 3. Give up this technology. For a new company, the cost of option 1 and option 2 is very high, and option 3 may make you uncomfortable, but it is a more feasible solution.
6. Enterprise-level framework deployment and application have extremely high risk costs. Most of the time, for a small company in the entrepreneurial stage, its viability depends on its ability to adapt and execute. For example, one day, China Mobile has reached a cooperation intention with you on the premise that you can provide the service. There are two potential logics behind such cooperation: a) it is very likely that a third party suddenly plug in one day to provide the service earlier than you, so the formal cooperation contract will be ruined; B) more importantly, even if you provide the service for other objective reasons, the intention may still be lost. As a result, what you may have worked so hard to do is useless. You know, if a huge object does not work, it may be a burden. At this time, it will be very embarrassing: will it be difficult to dismantle it or not? Through branch, it may be possible to face such cooperation. If multiple projects are carried out occasionally at the same time, it is impractical to use branch to avoid the demolition problem;
8. enterprise-level frameworks and even design patterns are still a good book for many developers. Never think that developers will be as smart as the prophets who come up with the design mode or TDD development mode. If so, I am afraid you and I will both be Bill Gates. Based on my experience, there will be no more than 33% developers who can understand these things in a small business. That is to say, if you apply these design and development modes here, you will simply face the following two results:) that 66% of people need you to tell them what you wrote (for them, you are writing a book); B) then 66% of people will simply bypass your Code and re-write a bunch of bad code, which is mostly the case. This is really not a good thing, for example, you will see a bunch of code disgusting with your mood. In addition, you can imagine that the original good MVC code is well stripped layer by layer. In a short time, someone may directly write a bunch of SQL statements and business logic on V. At this time, I would rather not have the MVC structure, so that I will not waste time debugging M-layer clearly correct SQL and C-layer clearly correct business logic, even more, it's hard to figure out where he is confused, and where he suddenly calls the underlying code. Of course, this is the worst case. In the best case, with the passage of time, the garbled code will always accumulate and occupy the absolute majority. That is to say, your efforts are in vain.