45 Habits of the "serial" excellent programmers 27

Dynamic Assessment Trade-offs --45 habits of highly efficient programmers "Performance, productivity, elegance, cost, and time-to-market are critical factors in the software development process." Each item must be in the desired state. ”

You might have been in a team where the management and the client will be focusing a lot of their attention on the display of the application interface. There is also such a team, whose customers think performance is very important. In a team, you may find that there is a development executive or architect who emphasizes that adherence to the "right" paradigm is more important than anything else. Such an arbitrary emphasis on any single factor, regardless of whether it is a necessary factor for the success of the project, will inevitably lead to disaster.

The importance of performance is understandable, because poor performance can make an application drubbing in the marketplace. However, if the performance of the application is good enough, it is necessary to continue to devote more effort to make it run faster. Probably not. There are many other factors that are equally important in an application. Instead of taking the time to improve performance by 1 per thousand, it may reduce development input, reduce costs, and make it more valuable to sell apps to the market as quickly as possible.

For example, consider a. NET Windows application that must communicate with a remote Windows server. You can choose to use. NET Remoting Technology or Web Services to implement this functionality. Now, for the proposal to use Web Services, some developers will say: "We're going to communicate between Windows, and in this case, the. NET Remoting is recommended." Also, Web Services are slow and we are experiencing performance problems. "Well, it's generally true.

However, in this example, it is easy to develop with Web Services. Performance testing of Web Services indicates that XML documents are small, and that the time spent on creating and parsing XML is almost negligible relative to the application's own response time. Using Web services not only saves development time in the short term, but also makes Web services a wise choice when teams are forced to use services provided by third parties.

Andy said ... Overkill
I've met a client who believes in the importance of being configurable, and has about 10 000 configurable variables for their applications. The new code becomes extremely difficult because it takes a lot of time to maintain configuration applications and databases. But they believe that this level of flexibility is needed because each customer has different needs and needs different settings.
But in fact, they only have 19 clients, and they are not expected to exceed 50 in the future. They don't weigh it well.

Consider an application that reads data from a database and displays it in tabular form. You can use an elegant, object-oriented approach to fetching data from a database, creating objects, and then returning them to the UI layer. In the UI layer, you can then split the data from the object and organize it into a tabular display. What's the good of doing this besides looking elegant?

Maybe you just need to have the data layer return a dataset or data set, and then use the table to display the data. This also avoids the resources that are consumed by object creation and destruction. If all you need is a data display, why create an object to ask for trouble? Instead of doing it according to the OO method in the book, you can reduce your input and get a performance boost. Of course, there are many flaws in this approach, but the crux of the matter is how long a mind, rather than always according to the usual way of thinking to solve the problem.

To sum up, the impact of a successful application, lower development costs and shorter time-to-market, is equally important. Because the price of computer hardware is increasingly cheap, processing speed is increasing, so the hardware can be more input in exchange for performance improvement, and will save time in the application of other aspects.

Of course, this is not entirely true. If your hardware needs are huge and you need a huge computer grid and a large number of support personnel to keep it running (like Google's), consider tilting the other end of the scale.

But who will ultimately decide that performance is good enough, or that the application has been shown to be "flashy" enough. The customer or stakeholder must evaluate and make the relevant decisions (see the Custom 10 on page 45th). If the team thinks there is room for improvement in performance, or that it makes certain interfaces look more appealing, consult stakeholders and let them decide where to focus.

There is no optimal solution for all situations. You must evaluate the problem on your opponent and choose the most appropriate solution. Each design is specific to a particular problem--only a clear assessment and tradeoff is needed to get a better solution.

There is no optimal solution (no best solution) dynamic assessment weighing performance, convenience, productivity, cost, and Time-to-market. If performance is sufficient, focus on other factors. Do not complicate the design for the sake of perceived performance or elegant design.

Personal Experience

Even if you can't do it all, you should feel that you've got the most important thing-the characteristic that the customer thinks is valuable.

The art of balance if you now devote additional resources and energy to the potential benefits of the future, make sure that the input is rewarded (in most cases, it will not be rewarded). Real High-performance systems are working in this direction from the very beginning of the design. Premature optimization is the source of all evils. Previously used solutions may or may not apply to current problems. Do not prejudge the conclusion, first see what is the situation now.