Computer engineering is a very young tree compared to civil engineering, mechanical engineering or manufacturing engineering etc. Many engineering concepts will naturally be transplanted to computer engineering. It is also easy for us to find these similarities, such as: system architecture is to architectural architecture, system style is to architectural style, architectural design drawing is to system design drawing, pipeline assembly line is to production assembly line, etc.
It is undeniable that in terms of learning from other projects, computer engineering has made great efforts in just a few decades. Canine feeling. Especially when a product has just appeared, the strong commercial atmosphere always makes people feel embarrassed, such as: cloud computing, blockchain, metaverse, etc. It seems that their products can do everything, as if their products represent everything. Without this thing, the whole world will be finished. It is extremely exaggerated. That kind of mystical metaphysical atmosphere is also pursued by many people. Every now and then, your mobile phone and computer are filled with such things, which are almost pervasive, and the hateful recommendation system.
From a certain point onwards, the system design or architecture began to go up and down, and it was full of incomprehensible argots for a while. When we went to look at the unified modeling language diagram, there was a familiar feeling. In fact, system design is also like architectural design. It needs to draw design drawings and construction drawings. The troublesome thing is that few people in the fence are going to break it. Because it is called Unified Modeling Language, not construction drawings. If it is called construction drawings, the bubbles blown up by many things will burst. Program design is no longer called design, it is called code words, and programmers are no longer called programmers. It's called a code farmer, but when you first learn a language, it's called "**** Programming", which feels very fragmented.
Integrated Circuit Diagram: Use Case Diagram: Collaboration Diagram: Deployment Diagram:
Over the years, computers have been disguised as a commercial technology, and the public has been instilled in their daily lives that there is nothing wrong with the system. In fact, what did we do again, borrowing a PPT from a certain teacher:
While being criticized, the money was earned cautiously and fearfully.
Can building a thatched cottage be the same as building a skyscraper? Browsing the web and playing 3A masterpieces require different computers. . . .
In many cases, from business-oriented requirements to technology-oriented software system implementation, especially the design of complex systems, a large gap needs to be crossed. Even if the requirements analysis is very clear, isn't it a lot of trouble to put the system into practice? How to choose a design method, how to choose a design pattern, how to choose an architecture, how to choose a server, how to choose a storage, how to lay out a network, and how to use these raw materials to produce an information system in a decent way, is a hard work. live.
On the one hand, when we design the system, we often face a dilemma: should we design the business logic better (vertical direction), or should we design the technical logic better (horizontal direction); Should general functions be better designed (framework), and features should be gradually expanded in future personalized design, or should the relationship between the system and subsystems be sorted out from an overall perspective (architecture), and new additions should be gradually expanded in subsequent development systems or components. In fact, when faced with a complex system, you also need to face various issues in terms of personnel, capital, technology, management, and sales. A software product is plagued by too many uncertain factors from design, development, application to promotion, and it is difficult for you to cover everything.
On the other hand, the system architecture is, after all, a product of the initial stage of system design. After the system is designed, coding, testing, and delivery are still required. If the complexity of system development, the technical cost of organizational development, the quality of products delivered to users, and software upgrades cannot be controlled Or the possibility of regeneration, if the product line is too grand or complex, and does not match the reality, it must be a failure. A certain book says:
It is a common practice that software architects spend too much energy on the vertical line (what functions customers need), but leave most of the horizontal technology to the coders. It is this common practice that there have been too many failed systems in information systems in recent years (every once in a while, you will hear that the information system in a certain place has collapsed), and architects should focus on performance while focusing on functions. (System reliability, service stability, functional scalability, etc.) Put it on the agenda, let the project manager or system analyst do things like requirements, well, your project manager is drinking (to pull the project) , Your project team does not have a system analyst, when I didn't say it.
There must be a time limit for an information system from development to delivery, and it will not and is impossible for you to keep procrastinating. When the project duration is gradually approaching the critical point, many people may have experienced the scene of jumping around. . Whether the project is profitable, how long the project duration will be, whether it can be realized technically, how complicated the technical realization is, whether the ability of the developers in hand is up to the level, etc., these factors need to be carefully considered, otherwise it will be difficult for everyone not good.
The function (business), construction period, quality and benefit of the system need to be considered at the same time. For some information development companies that are new to a certain industry, they pay more attention to business (what data does this industry have, which functions can express business, which technology can achieve this function). In many cases, due to the excessive emphasis on function, construction period and benefits, the consideration of quality is often ignored. It is also true that for some information development companies that have penetrated into a certain industry, the product quality of the system is particularly important (performance, security, ease of use, continuous service availability, scalability, interoperability, reliability, etc.) , robustness, reusability, portability). The latter is obviously more mature than the former, but this maturity is due to the habit formed after years of deep cultivation in a certain industry, and it is also the countless reprimands and complaints of Party A's father that can be continuously improved.
System development technology trade-offs and product cost-benefit analysis are issues worthy of in-depth discussion. Projects do not exist in a vacuum. It is meaningless to discuss whether system design or architecture is more economical, more advanced, simpler, more mature, or simpler in isolation. In certain scenarios or backgrounds , the right one is the best. This may be the difference between engineering and research. If a high-quality system generates too much overhead in cost, let’s take it easy. Engineers and raw materials, tools, technologies, The local or global optimal solution of product and cost is suitable.
Fit and fit inevitably fall into the trap of metaphysics. In fact, for solving a multi-objective problem, selecting the objectives one by one for planning or prediction, whether you use linear or nonlinear functions, the evaluation value is relatively reliable.
