Jakob Nielsen's Alertbox, August 25, 2003:

Usability 101: Introduction to Usability

Summary:
How to define usability? How, when, and where can you improve it? Why should you care? This overview answers these basic questions.

This is the article to give to your boss or anyone else who doesn't have much time, but needs to know the basic usability facts.

What (Definition of Usability)

Usability is defined by five quality components:

• Learnability: How easy is it for users to accomplish basic tasks the first time they encounter the design?
• Efficiency: Once users have learned the design, how quickly can they perform tasks?
• Memorability: When users return to the design after a period of not using it, how easily can they reestablish proficiency?
• Errors: How many errors do users make, how severe are these errors, and how easily can they recover from the errors?
• Satisfaction: How pleasant is it to use the design?

Why Usability is Important

The first law of e-commerce is that if users cannot find the product, they cannot buy it either.

For intranets, usability is a matter of employee productivity. Time users waste being lost on your intranet or pondering difficult instructions is money you waste by paying them to be at work without getting work done.

Current best practices call for spending about 10% of a design project's budget on usability. On average, this will more than double a website's desired quality metrics and slightly less than double an intranet's quality metrics. For software and physical products, the improvements are typically smaller — but still substantial — when you emphasize usability in the design process.

For internal design projects, think of doubling usability as cutting training budgets in half and doubling the number of transactions employees perform per hour. For external designs, think of doubling sales, doubling the number of registered users or customer leads, or doubling whatever other desired goal motivated your design project.

How to Improve Usability

• Get hold of some representative users, such as customers for an e-commerce site or employees for an intranet (in the latter case, they should work outside your department).
• Ask the users to perform representative tasks with the design.
• Observe what the users do, where they succeed, and where they have difficulties with the user interface. Shut up and let the users do the talking.

To identify a design's most important usability problems, testing five users is typically enough. Rather than run a big, expensive study, it's a better use of resources to run many small tests and revise the design between each one so you can fix the usability flaws as you identify them. Iterative design is the best way to increase the quality of user experience. The more versions and interface ideas you test with users, the better.

User testing is different from focus groups, which are a poor way of evaluating design usability. Focus groups have a place in market research, but to evaluate interaction designs you must closely observe individual users as they perform tasks with the user interface. Listening to what people say is misleading: you have to watch what they actually do.

When to Work on Usability

1. Before starting the new design, test the old design to identify the good parts that you should keep or emphasize, and the bad parts that give users trouble.
2. Unless you're working on an intranet, test your competitors' designs to get cheap data on a range of alternative interfaces that have similar features to your own. (If you work on an intranet, read the intranet design annuals to learn from other designs.)
3. Conduct a field study to see how users behave in their natural habitat.
4. Make paper prototypes of one or more new design ideas and test them. The less time you invest in these design ideas the better, because you'll need to change them all based on the test results.
5. Refine the design ideas that test best through multiple iterations, gradually moving from low-fidelity prototyping to high-fidelity representations that run on the computer. Test each iteration.
6. Inspect the design relative to established usability guidelines, whether from your own earlier studies or published research.
7. Once you decide on and implement the final design, test it again. Subtle usability problems always creep in during implementation.

The only way to a high-quality user experience is to start user testing early in the design process and to keep testing every step of the way.

Where to Test

Learn More

Three-day camp teaching Usability in Practice at the Usability Week 2008 conference in San Francisco (June) and Melbourne (July).

from: http://www.opensource.org/licenses/category

Agile Development

Introduction

In this whitepaper I argue that the person most affected by the introduction of agile or extreme programming techniques is not the software or quality assurance engineer, but the build manager. And the build manager can no longer make do with home grown tools; software production automation tools are required to make agile development a build reality.

The reality is that agile techniques are a throwback to the age when developers were able to work on small projects in small teams. Each developer (or sometimes pair of developers) concentrates on small building blocks of code (with associated unit tests), and integrates regularly with other developers to ensure that the overall software project is progressing. For developers, agile techniques are a natural fit because they reflect how developers like to work best: on small, manageable pieces of code with regular feedback.

Even though developers are working on small sections of code, the overall projects they are part of are now very large. So there's no going back to a small build on a single machine for build managers. While developers may have broken their work down into small units that they can code and test, the overall size of most enterprise software projects is constantly growing. And it's the large body of code that the build manager is expected to work with, not the manageable chunks that developers deal with.

In fact, the build manager is expected to cope with ever larger software, on ever more platforms, while at the same time dealing with developers' requests for fast integration builds. Those integration builds enable agile development at the software engineer's desktop because they are able to integrate their local changes into a large build, but cause build managers to be required to produce one or two orders of magnitude more builds per day.

Continuous Integration

To the build manager, the words "multiple integrations per day" and "each integration is verified by an automated build" mean a radical change from once-nightly builds. All these changes are brought about by one central tenet of agile development: continuous integration.

The seminal paper on Continuous Integration (and an excellent, and readable introduction to the topic) is Martin Fowler's article entitled, simply, "Continuous Integration" and is available here.

Its abstract states:

Continuous Integration is a software development practice where members of a team integrate their work frequently; usually each person integrates at least daily - leading to multiple integrations per day. Each integration is verified by an automated build (including test) to detect integration errors as quickly as possible.

To the build manager, the words "multiple integrations per day" and "each integration is verified by an automated build" mean a radical change from once-nightly builds.

Fowler goes on to list a number of "Practices of Continuous Integration." The first build-related practice is "Automate the Build." He argues that the set of tasks required to go from source code to the final shipping binary is so complex that it should be automated so that it is repeatable. If the build is not automated, he argues, the build process will be error prone.

He also argues that the build includes much more than just compiling the software and building a binary. He sets the goal of, "anyone should be able to bring a virgin machine, check the sources out of the repository, issue a single command, and have a running system on their machine."

It's worth stopping and thinking about the implications of that statement for your build organization. It's very likely that getting to such an automated stage seems impossible, when starting from what is often a creaky build system held together by a collection of Makefiles, Perl scripts and other programs whose exact function or operation is often unclear.

Clearly, the goal of going from a virgin machine to fully running code is a stretch, but I think it's a good overall goal. Once you reach that stage, you will have put together a build system that is very reliable and should, if written and documented well, be easy to modify and adapt as software changes.

Such a fully automated build has advantages outside the direct realm of agile development. How many times has your build team been asked to rebuild an old version of your software and been unable to do so? Important customers can sometimes demand that old versions of code be patched or updated, or a security problem can mean that all versions of a company's currently supported code need to be fixed and released.

In general, only very well prepared teams are capable of building an arbitrary version of their code. Even if a good archive of the sources was made at the time of release, other components of software are likely to have decomposed: you may not have the right build scripts, or the right compiler, or the right version of some third-party component any more.

Fowler's goal, which I refer to as a "pickled build" (the entire build is pickled in a jar ready for use whenever demanded), done right, means that old versions of software can be rebuilt at will, and helps support developers in their move to agile development.

Fowler's second practice for builds is: "Make Your Build Self- Testing." This implies that the automatic build also includes an automatic test. He asks that any body of code have a set of automatic tests that can check a large part of the code base for bugs. Many developers are, in fact, already writing such test suites through the Extreme Programming focus on unit testing, or by performing Test Driven Development (where developers write the tests before the code).

With this test suite in place, Fowler asks that the automated build test itself by running the test suite and reporting the results. Results would typically be reported on screen or by email if the build and test was run remotely.

Fowler's next two practices have a profound effect on build management: "Everyone Commits Every Day" and "Every Commit Should Build the Mainline on an Integration Machine." The implication is that every developer will be committing code once per day (at least) and that every commit will cause a build and test on some build resource (the "integration machine") managed by the build manager. To put that in perspective, for a team of 20 engineers committing once per day during an 8 hour work day, that's a build and test every 24 minutes. For large teams that number increases, and the time between builds is greatly shorted.

The reason agile developers want these per-commit builds is to ensure that integration between developers is working and that the software being built works, and is testable, at all times. The idea that the software should run at all times is central to agile development, and the health of the per-commit build and test becomes an important sign of health for the entire project. If per-commit builds are done quickly and frequently enough, the build will reflect changes made by a single check-in by a single developer offering unparalleled opportunity to narrow down the cause of a breakage.

In fact, this build is so important that I refer to it as the Agile Heartbeat. Agile teams will install monitoring devices (such as red and green lava lamps) that make the status of the heartbeat build visible to all. Fowler states that no developer should "go home until the mainline build has passed with any commits" they've added. This means that all of engineering looks every day to the heartbeat to measure their own progress (Fowler refers to this in the practice "Everyone can see what's happening").

Another important practice mentioned in Fowler's paper is 'Keep the Build Fast'. This seems like an obvious corollary to the previous practices, since a team that requires a build every few minutes and every time the code changes will necessarily need very fast builds. In fact, Extreme Programming outlines the goal of "ten minute" builds, and I've written previously about what I call espresso builds (builds that only take as long as a coffee break).

Fast builds are also important because developers are looking to the status of the build as a measure of their progress. Every minute that is shaved off the build is a minute saved for all developers who have committed code to that build. With many developers, and many builds, that time saved adds up quickly and fast builds improve the productivity of the entire team.

Fowler suggests that this entire process be either managed by hand (if the team is very small), or through the use of a "continuous integration server." This whitepaper will later describe tools that can be used to implement continuous integration, but first, the very idea of getting to continuous integration may seem daunting. Luckily, it can be broken down into stepping stones that are of a manageable size.

Stepping Stones to Continuous Integration

Although pickling your entire build system (getting the build under ten minutes, building every time a developer checks in and giving automatic feedback) is an enormous task, a stepping stone approach can get you to continuous integration without a single, painful push to change everything in the organization.

And, typically, build managers simply do not have the time or resources to spend on a major change to everything they do. This is especially true when build managers are, naturally, expected to keep churning out the builds that they currently create while improving their processes to meet the needs of agile development.

However, a five-stage approach can help ease the way to continuous integration. Those five stages are: fully automated builds, fast builds, lava lamps, build and test and pre-flight builds. At each stage, the build manager should carefully consider the tool available for automation of the software production process as continuous integration requires a very large effort.

1. Fully Automate

Although some builds are already fully automated, most require integration and agile builds is some manual intervention on the part of the build manager (for the ability to build your example, during the installation of the software when a dialog box software automatically needs clicking). But the core of continuous integration and agile builds is the ability to build your software automatically.

So the first stepping stone is to make the build runnable from a single command invocation (the build manager should simply be able to type build followed by some arguments specifying a particular branch or version of the software to build). Once that build script is in place, the build system should be set to run automatically.

This is mostly a matter of detecting when the source code in the source code management system has changed. One way to do that is to have a simple periodic job that checks for changes. Once changes are detected, the job then waits for the repository to stabilize (to give developers time to commit all their code). The job could then wait for a period of quiet for fifteen minutes following a commit. Once the quiet period has ended, the build system starts a full build and test using the build script to build from the main line of code.

This is probably the only stepping stone that can be performed without resorting to new software production management software. The build script can be written using existing tools (such as GNU Make or Perl), but it's worth looking at available automation tools (open source or commercial) since the detection of source code changes and kicking off of an automated build is a common feature. Getting started with a new tool in a limited way (just for the change detection and build kick off) is a good way to learn the tool without having committed to each of the five steps to continuous integration.

2. Fast Builds

Having automated the build, the next step is to speed up the builds themselves. Although Extreme Programming preaches a ten minute automated build and test, I think that a realistic goal for an existing project is to get the automated build and test under one hour.

With multi-core processors and multi-processor machines becoming commonplace, exploiting parallelism available in builds is a relatively simple way to achieve significant build speed-ups. However, missing or incomplete dependency information makes implementing a homegrown parallel build error-prone…

Getting to fast builds can be hard.

For some projects, it's simply a matter of upgrading from outmoded build hardware to newer machines (and often newer, faster disks since builds require a lot of disk access getting sources and writing objects), but for others the build will either require restructuring (so that it can be broken down into parts runnable on separate machines), or a purpose-built parallel build system will be needed. Parallel build systems are available as both open source and commercial products (including from Electric Cloud). With multi-core processors and multi-processor machines becoming commonplace, exploiting parallelism available in builds is a relatively simple way to achieve significant build speed-ups. However, missing or incomplete dependency information makes implementing a homegrown parallel build error-prone, and requires specialized tools to overcome the inherently serial nature of almost all large build systems.

3. Lava Lamps

Lava lamps (those bubbling colored liquid lamps popular in the 1970s) may seem like a silly way to monitor build progress, and in a physically large team (or with remote teams or a complex project) they may not actually be suitable, but introducing some sort of build monitoring is the third stepping stone. Lava lamps are just a fun, easy-to-implement example of a monitoring system.

A build monitor could be red and green lava lamps, or an internal web page showing live build status, or a flat screen monitor mounted high on the wall giving build status. Introduce a mechanism for build feedback that is clear (red and green for bad and good, for example), easily visible (perhaps those lava lamps are right by the water cooler) and continuously updated.

The build monitor will get its input (good or bad) from the fully automated builds set up in the first stepping stone. Everyone will look to the build monitor first thing in the morning and throughout the day as new builds are run.

Although the build may only run and give feedback a small number of times per day (perhaps as little as four times), the build monitor will start to represent the pulse of the engineering team, illustrating the health of the build and hence the software for all to see. This is another important step towards the goal of every commit initiating a build with results for all to see.

Even with just four builds a day with feedback, developers will be able to identify integration problems much quicker than with a nightly build. And with the automation effort expended in the first stepping stone, these automatic builds will be reliable and repeatable and a good indication of the software's health.

4. Build and Test

If developers are following agile methods, they'll be developing automated test suites using tools like jUnit or cppunit. The third stepping stone is to integrate these tests (and other "smoke tests" that may already exist) into the build system now in place.

This is probably a relatively simple task given that the tests themselves are already automatic. This step is also important because it will raise the visibility and importance of the builds, and becomes the start of the agile heartbeat.

5. Pre-Flight Builds

The primary need of developers practicing agile development is the ability to see that their code integrates with the changes made by other developers. Although they could do this on their local machine (by getting all the relevant sources and running a tool like Make), the integration build may take too long, or need special build resources to be able to construct every part of the software. Typically, that means that developers are forced to limit their builds to small parts of an overall project. Even if developers could run full builds on their machines, the production build environment is often different from the environments on developers’ machines, so a build that works on a developer’s machine may not work in the production environment. Because of these issues, developers frequently introduce errors when they ultimately integrate with the complete system by checking in their code.

A good first step is to put full builds in the hands of developers. The build manager needs to assign a machine (or perhaps more than one if multiple platforms are involved) and set up an internal web page where a developer can request a build.

The developer's request should include their email address, the location of the software they want built (this could be the name of a branch to build, or a directory on a shared server where the developer has placed a personal copy of the source), and the opportunity to determine the extent of the build (for example, the developer could request a build on all platforms, or limit the build to just a single operating system).

The system should maintain a queue (visible through another internal web page) of pending build requests and should handle the builds in first-come, first-served order. When a developer's build has completed running (perhaps a couple of hours after their request), the developer receives an email giving the status of the build and any error output generated by the build system.

In addition, the build system takes the entire output of the build and stores it on a shared disk for the developer to examine. After some fixed period (perhaps a week), the output of the build is automatically deleted by the build system to free up space.

The advantages to the agile developer are immediate: they no longer have to wait for a nightly build (with the inherent 24-hour delay) to determine whether their changes broke anything, and by isolating the build to their sources, or their branch, they are able to much more quickly fix a problem even if their pre-flight build took many hours to complete, because they can narrow down the changed parts of the code more quickly. Furthermore, they can be confident that their check-in will not introduce environment-related build breakages, since the pre-flight build was run in the production environment.

At this point, the entire team can decide to introduce a new rule: no one commits to the mainline of source code control until they've run a successful pre-flight build. Here you've introduced another part of agile development which will greatly reduce the number of errors in the nightly builds. With developers checking their own code against a full build run through the pre-flight system before committing, they ensure that most integration errors are removed before affecting the entire team.

For the team, the great advantage of pre-flight builds is that the nightly or automated builds suddenly become more reliable. If developers are checking their code for breakages against a pre-flight build before checking in, the nightly build's reliability will increase greatly. For the build manager, there are two significant challenges to implementing pre-flight builds: automation and build resource availability.

The first prerequisite of an pre-flight build system is an automatic build, so tackling the first stepping stone is critical. It is, in fact, Fowler's first build-related practice and the cornerstone of continuous integration. The price of getting to a fully automated build (without automated tests at this stage) has to be paid up-front and will be the most expensive (in terms of time) part of the move to continuous integration.

Secondly, the internal web page needs to be written. This is relatively easy with free web servers (such as Apache), and free tools (such as PHP and Perl) being widely available and well documented.

Lastly, as developers start to use the system (and they will if they are trying to be agile), the number of available build machines will become a problem. As many developers begin to ask for preflight builds the build queue may become long (especially if the build time is also long).

At this point, the build manager has achieved agile builds. Developers can build whenever they need to; when code is checked in, it gets built automatically (and quickly) and everyone sees the state of that build. If the build breaks, developers can stop work to get the code integrating quickly.

The build manager may also choose to stop doing nightly builds altogether. With pre-flight and per check-in builds, the nightly build may be a thing of the past.

Tools That Can Help

A good starting point when searching for continuous integration tools is the Wikipedia page entitled "Continuous Integration." There you'll find a long list of commercial and open source tools for building continuous integration servers.

To preserve the team’s sanity and reduce downtime for developers and the build team when looking at tools or considering a build- versus-buy decision, you should aim to change as little as possible about your existing build environment. The goal should be to automate the build completely (so that it can be fired off from a single command) without changing the entire system. All that's needed to get continuous integration off the ground is a single command capable of running an entire build: the command needs to extract the sources from source code management and perform the build.

Once that script is in place, the choice of appropriate tool really comes down to a few key questions:

1. Does the tool support scheduled builds? If the tool can't support "cron" style builds then it's not worth considering. These are the most basic sort of builds and, even when you've introduced agile development methods, they'll still be important.
2. Is the tool scalable? One of the characteristics of agile development is that enormous loads will quickly be placed on build resources as engineers start running their own builds. And those resources will be even more stressed when every commit starts a build. Scalability needs to be considered from the start to avoid having to change servers in the middle of the stepping stones to continuous integration. Any tool must scale as resources (such as servers) are added, and be able to make use of pools of resources simultaneously as demand fluctuates throughout the work day. Business demands should be considered as well, as requirements for additional target platforms or integration of new teams will place additional demands upon the system over time.
3. Does the tool provide reporting or analytical tools? With hundreds of builds per day, managing the output or even just the status of every build is a headache. What was simple with a single nightly build becomes very hard with builds every ten minutes, and it's vital to be able to understand the performance of build systems and how the load and use of the build servers are changing over time.
4. Is the tool easy to adopt? Avoid any tool that requires rewriting existing Makefiles or build scripts: it's hard enough to adopt a new methodology without being required to start everything from scratch. The tool should work with existing tools and integrate with the existing source code management system.
5. Will the tool enable pre-flight and per-commit builds? Since these two styles of build are fundamental to continuous integration, the tool must make it easy to integrate with source code management to detect changes to the source base and automatically start builds, and to allow any user to start a build at will.
6. Does the tool support access control? Since the build servers will now be shared with all of development (and not with the small build team alone), access control is vital to ensure that developers have access to the appropriate resources from any location whether local or remote, and that the build team is able to override running builds to perform high-priority builds at will.
7. Will the tool support multiple teams or will each group or division require its own investment in a tool (plus configuration and maintenance)? Once automated, many build procedures (such as the job that monitors the source code management system for changes) will likely be generic in nature and easily shared across the organization. To maximize investment in a tool and reduce duplicate work, can common procedures or company standards be rolled out across teams?

In many, if not all cases, a homegrown approach will fall short in one or more of these areas. Or, if the homegrown system is adequate at the outset of the stepping stones to continuous integration, it may fall short over time as the load increases, the number of target platforms increases or as the number of users increases. Commercial tools will also pay off in terms of the reduced administration and maintenance required of a manual setup.

Conclusion

Extreme Programming and Agile Development are being adopted by many software engineering organizations. Achieving agility is not easy, but teams can realize some of the benefits of agile development with a step-by-step approach. Careful planning is required by all parts of the engineering team with a special focus on the build resources. The build team will come under enormous pressure once agile methods are implemented and a step-by-step approach to implementing agile builds is recommended.

Careful selection of appropriate build tools is essential from the start of the roll-out of any agile method. Those tools must be able to cope with the varied demands on the build resources and with the likely growth in the number and size of builds.

Enabling Agile Builds with ElectricCommander

Faster Builds, Automated Tests

To maintain aggressive product release schedules, the LSI Logic Consumer Products engineering team wanted to move toward a daily integration model, integrating, building and testing 25 to 50 unique software builds every 24 hours.

The company first chose Electric Cloud’s ElectricAccelerator to address the build speed issues within the integration model, succeeding in reducing build times by 7-8x (from 150 minutes down to 20-30 minutes).

Seeing success with ElectricAccelerator, LSI decided to convert its test environment to ElectricCommander, Electric Cloud’s production automation solution. Where their previous environment became overloaded handling just 250 concurrent steps, ElectricCommander was able to schedule and execute more than 1,000 concurrent steps with the same hardware setup, dramatically streamlining and speeding the smoke test process.

ElectricCommander is a tool to consider for implementing an agile production process within an enterprise environment. It is a Web-based solution for automating software builds and other production tasks to enable agile, iterative development. Only ElectricCommander is simple enough to use on a small build, yet scalable enough to support the most complex software production environments. It requires minimal process changes to get started or to deploy across teams. It provides the reporting and visibility organizations need for compliance efforts and release planning, plus an unprecedented level of flexibility and customizability to suit the agile organization. For agile teams ElectricCommander enables:

• Fast builds: Run multiple procedures in parallel on the same resource, or distribute procedures or individual steps across any number of machines for faster turnaround and more efficient production. For additional speed improvements to the build step, ElectricAccelerator provides a fine-grained parallelism to speed builds by as much as 20x (see below).
• Automated and scheduled builds: Schedule production procedures to run at a specified day or time, on an hourly or daily basis, or whenever someone checks in code to a specified repository or branch.
• Pre-flight and per-commit builds: The underlying information architecture allows build and release teams to organize production assets into virtual, access-controlled projects, while access to production machines can also be limited or controlled. In this way, a release team can provide developers with dedicated or specified resources for pre-flight builds, as needed. Further, ElectricCommander supports integrations with leading SCM tools to facilitate per-commit builds.
• Visibility and reporting: ElectricCommander’s unique analytics provide valuable insight into the details of the build, not just success or failure. The analytics engine extracts information and stores it as persistent properties of the job step, providing easy access to pinpoint statistics and trend reporting.

About Electric Cloud

Electric Cloud is the leading provider of Software Production Management solutions that accelerate, automate and analyze the software development tasks that follow the check-in of new code. These include the software build, package, test and deploy processes.

The reality is that homegrown systems are expensive to maintain and difficult to standardize across an enterprise, and are typically not able to support the frequent iterations at the core of Agile Development. Electric Cloud makes it simple to achieve a scalable, agile software production environment across the organization. Electric Cloud's product suite – ElectricAccelerator, ElectricCommander and ElectricInsight – improves development productivity and product quality by accelerating, automating and analyzing the entire software production management lifecycle. In addition to the ElectricCommander production automation tool, Electric Cloud offers:

ElectricAccelerator

ElectricAccelerator™ accurately executes parallel builds across a cluster of inexpensive servers to reduce build times by as much as 20x. ElectricAccelerator plugs seamlessly into existing build infrastructures, without modifying existing scripts. Faster, more accurate builds dramatically reduce the time developers spend waiting for builds to complete, and enable them to do complete builds before checking in their changes.

ElectricInsight

ElectricInsight™ is a software build visualization tool that, when used in conjunction with ElectricAccelerator, provides job-level detail into parallel builds and provides unprecedented visibility into build results for simplified troubleshooting and performance tuning. Leading companies such as Qualcomm, Intuit, Motorola, and Expedia have trusted Electric Cloud’s Software Production Management solutions to change software builds and the entire production process from a liability to a competitive advantage.

License

This article, along with any associated source code and files, is licensed under The Code Project Open License (CPOL)

About the Author

John Graham-Cumming

John Graham-Cumming is Founder and Chief Scientist at Electric Cloud. Prior to Electric Cloud, John was a Venture Consultant with Accel Partners, VP of Internet Technology at Interwoven, VP of Engineering at Scriptics, and Chief Architect at Optimal Networks. John holds BA and MA degrees in Mathematics and Computation and a Doctorate in Computer Security from Oxford University. John is the creator of GNU Make Standard Library and has six pending patents in the build space. Electric Cloud, ElectricInsight, ElectricAccelerator, ElectricCommander and Electric Make are trademarks of Electric Cloud. Other company and product names may be trademarks of their respective owners. Location: United States

国内外数独网站推荐

《修改代码的艺术》，Michael Feathers 著， 刘未鹏 译，人民邮电出版社，2007。
《UML嵌入式设计》，高焕堂 著， UMLChina改编，清华大学出版社，2008。
《Head First 设计模式》，Eric Freeman, Elisabeth Freeman, Kathy Ierra, Bert Bates 著， O'Reilly台湾 译，UMLChina改编，中国电力出版社，2007。
《掌握需求过程(第2版)》，Suzanne Robertson/James Robertson 著， 王海鹏 译，人民邮电出版社，2007。
《软件工程实践者的研究方法原书第6版》，Roger S. Pressman 著，郑人杰/马素霞/白晓颖 译，机械工业出版社，2006。
《重构与模式》，JOSHUA KEREVSKY 著，杨光/刘基诚 译，人民邮电出版社，2006。
《设计模式初学者指南》，Allen Holub 著，徐迎晓 译，机械工业出版社，2006。
《程序开发原理--抽象、规格与面向对象设计》，Barbara Liskov, John Guttag 著，裘健 译，电子工业出版社，2006。
《设计模式解析（第2版）》，Alan Shalloway, James R.Trott 著，徐言声 译，人民邮电出版社，2006。
《Visual Basic设计模式》，Mark Grand, Brad Merrill 著，杨环英、周锐博 译，人民邮电出版社，2006。
《UML用户指南（第2版）》，Grady Booch,James Rumbaugh,Ivar Jacobson 著，邵维忠 麻志毅 马浩海 刘辉 译，人民邮电出版社，2006。
《UML2.0和统一过程（原书第2版） 》，Jim Arlow,Ila Neustadt 著，方贵宾 胡辉良 译，机械工业出版社，2006。
《MDA与可执行UML》，Chris Raistrick,Paul Francis,John Wright 著，机械工业出版社，2006。
《对象设计》，Rebecca Wirfs-Brock, Alan McKean 著，人民邮电出版社，2006。
《面向对象分析与设计（UML 2.0版）》，Mike O'Docherty 著，俞志翔 译，清华大学出版社，2006。
《程序设计的模式语言-卷2》，John M.Vlissides, James O.Coplien, Norman L.Kerth 著，詹文军 周毅 译，清华大学出版社，2006。
《领域驱动设计》，Eric Evans 著，陈大峰、张泽鑫 译，清华大学出版社，2006。
《UML面向对象建模与设计（第2版）》，Michael Blaha, James Rumbaugh 著，人民邮电出版社，2006。
《统一过程最佳实践移交和产品化阶段》，Scott W.Ambler 著，机械工业出版社，2005。
《敏捷数据》，Scott W.Ambler 著，机械工业出版社，2005。
《过程模式（上册）》，Scott W.Ambler 著，人民邮电出版社，2005。
《面向模式的软件体系结构：卷3》，Michael Kircher, Prashant Jain 著，机械工业出版社，2005。
《Enterprise Java with UML 中文版》，C.T.Arrington、Syed H.Rayhan 著，机械工业出版社，2005。
《平衡敏捷与规范》，Barry Boehm、Richard Turner 著，清华大学出版社，2005。
《UML参考手册 （第2版）》，James Rumbaugh、Ivar Jacobson、Grady Booch 著，机械工业出版社，2005。
《The Object Primer中文版》，Scott W.Ambler 著，机械工业出版社，2005。
《C#设计模式》，Steve John Metsker 著，中国电力出版社，2005。
《重构极限编程—XP的实践与反思》，Matt Stephens、Doug Rosenberg 著，清华大学出版社，2005。
《Clouds to Code 中文版》，Jesse Liberty 著，徐峰 译，电子工业出版社，2005。
《对象模型：策略、模式与应用》（第2版），Peter Coad 著，科学出版社，2005。
《用例驱动UML对象建模应用——范例分析》，Doug Rosenberg、Kendall Scott 著，人民邮电出版社，2005。
《DSDM业务中心框架开发方法（第二版）》，DSDM Consortium、Jennifer Stapleton 著，人民邮电出版社，2005。
《UML精粹——标准对象建模语言简明指南》（第3版），Martin Fowler 著，徐家福 译，清华大学出版社，2005。
《软件开发问题框架：现实世界问题的结构化分析》，Michael Jackson 著，机械工业出版社，2005。
《UML对象、组件和框架——Catalysis方法》，Desmond Francis D’Souza、Alan Cameron Wills 著，清华大学出版社，2004。
《UML 2工具箱》，Hans-Erik Eriksson 著，电子工业出版社，2004。
《软件需求》（第2版），Karl E.Wiegers 著，清华大学出版社，2004。
《程序设计的模式语言-卷4》，Neil Harrison、Brian Foote、Hans Rohnert 著，清华大学出版社，2004。
《程序设计的模式语言-卷3》，Robert Martin、Dirk Riehle、Frank Buschmann 著，清华大学出版社，2005。
《超越传统的软件开发——极限编程的幻象与真实》，雷剑文 陈振冲 李明树 著，电子工业出版社，2005。
《Contributing to Eclipse中文版》，Erich Gamma、Kent Beck 著，中国电力出版社，2005。
《数据模型资源手册（卷2）》（修订版），Len Silverston 著，机械工业出版社，2004。
《OOD启思录》，Arthur J.Riel 著，人民邮电出版社，2004。
《探索需求——设计前的质量》，Donald C. Gause, Gerald M. Weinberg 著，清华大学出版社，2004。
《OMT应用》，Kurt W.Derr 著，清华大学出版社，2004。
《企业应用架构模式》，Martin Fowler 著，机械工业出版社，2004。
《数据建模：分析与设计的工具和技术》，Steve Hoberman 著，机械工业出版社，2004。
《UML基础、案例和应用》（第3版），Joseph Schmuller 著，李虎 译，人民邮电出版社，2004。
《用UML设计并发、分布式、实时应用》，Hassan Gomaa 著，北京航空航天大学出版社，2004。
《面向模式分析和设计——通过模式合成来进行软件系统的设计》（影印版），Sherif Yacoub, Hany Ammar 著，中国电力出版社，2004。
《UML风格》，Scott W. Ambler 著，王少峰 译，清华大学出版社，2004。
《软件需求管理：用例方法》（第2版），Dean Leffingwell, Don Widrig 著，蒋慧 译，中国电力出版社，2004。
《UML业务建模》，Hans-Erik Eriksson, Magnus Penker 著，夏昕、何克清 译，机械工业出版社，2004。
《解析MDA》，Anneke Kleppe,Jos Warmer,Wim Bast 著，鲍志云 译，人民邮电出版社，2004。
《产生式编程——方法、工具与应用》，Krzysztof Czarnecki,Ulrich W.Eisenecker 著，梁海华 译，中国电力出版社，2004。
《C++网络编程 卷1：运用ACE和模式消除复杂性》，Douglas C.Schmidt,Stephen D.Huston 著，於春景 译，华中科技大学出版社，2003。
《分析模式：可复用的对象模型》，Martin Fowler 著，樊东平 张路 译，机械工业出版社，2004。
《敏捷软件开发》，Alistair Cockburn 著，俞涓 译，人民邮电出版社，2003。
《实时UML——开发嵌入式系统高效对象》，Bruce Powel Douglass 著，尹浩琼 译，中国电力出版社，2003。
《用UML构建Web应用》（第2版），Jim Conallen 著，陈起 译，中国电力出版社，2003。
《应用MDA》，David S.Frankel 著，鲍志云 译，人民邮电出版社，2003。
《人本界面：交互式系统设计》，Jef Raskin 著，史元春 译，机械工业出版社，2003。
《面向模式的软件体系结构 卷2：用于并发和网络化对象的模式》，Douglas Schmidt 著，张志祥 译，机械工业出版社，2003。
《面向对象分析与设计（原书第2版）》，Grady Booch 著，冯博琴 译，机械工业出版社，2003。
《敏捷软件开发：原则、模式与实践》，Robert C. Martin 著，邓辉 译，清华大学出版社，2003。
《VS.NET UML建模高级编程——应用Visio for Enterprise Architects》，Andrew Filev 著，冯丽 译，清华大学出版社，2003。
《面向对象软件设计经典》，Rebecca Wirfs-Brock 著，张金明 译，电子工业出版社，2003。
《有效用例模式》，Steve Adolph, Paul Bramble 著，车立红 译，清华大学出版社，2003。UMLChina训练教材。
《用例建模》，Kurt Bittner 著，姜昊 译，清华大学出版社，2003。
《面向对象方法原理与实践》（第3版），Ian Graham 著，袁兆山 译，机械工业出版社，2003。对象技术知识大全。
《统一软件开发过程之路》，Ivar Jacobson 著，程宾 朱鹏 张嘉路 译，机械工业出版社，2003。其实是Ivar Jacobson在90年代的文集。
《面向对象软件构造（第2版）》（影印版），Bertrand Meyer，机械工业出版社，2003。
《软件复用：结构、过程和组织》，Ivar Jacobson 著，韩柯 译，机械工业出版社，2003。
《面向模式的软件体系结构 卷1：模式系统》，Frank Buschmann 等 著，贲可荣 译，机械工业出版社，2003。
《编写有效用例》，Alistair Cockburn 著，王雷、张莉 译，机械工业出版社，2002。
《面向对象的软件测试》，John D.McGregor David A.sykes 著，杨文宏 译，机械工业出版社，2002。
《UML with Rational Rose 2002 从入门到精通》，电子工业出版社，2002。用来学习工具操作，书中方法不可学。
《统一软件开发过程》，Ivar Jacobson，James Rumbaugh，Grady Booch 著，周伯生 译，机械工业出版社，2002年1月。
《UML面向对象设计基础》，Meilir Page-Jones著，包晓露等译，人民邮电出版社，2001年4月第1版。
《Oracle 8 UML对象建模设计》，机械工业出版社，2000年4月。很实用。
《设计模式 可复用面向对象软件的基础》，Erich Gamma等 著，李英军 译，机械工业出版社，2000
《面向对象的分析》，“面向对象的设计”，两本小册子，Peter Coad，Edward Yourdon著，邵维忠等译，北大出版社，原书1991年写就。国内第一本关于面向对象分析和设计的书。
《实用面向对象软件工程教程》，Edward Yourdon, Carl Argila著，电子工业出版社，原书1995年12月写就。
《面向对象的系统分析》，邵维忠，杨芙清，清华大学，广西科技出版，1998年12月第一版。

以下是UMLChina 参与制作的一些书籍。
软件工程
2002年《人月神话》创下销售记录 2003年《最后期限》、《人件》、《人月神话》分别排在china-pub年度总销售榜的1、3、4名
需求
设计

                  C++ Tips
                  Sections
            Intro
            I.   ABCs and Inheritance
            II.  Scope
            III. CLASSES
            IV.  MISC
            V.   OVERLOADING
            VI.  PARAMETERS
            VII. Constructors (more on classes)
            VIII.EXCEPTIONS
            IX.  TEMPLATES (more on classes)

Intro
This is not a code guideline document. See the C++ Style Guide for guidelines.
This is more of a document to fuel questions while you design and code
with C++. In some cases the point is simply stated and probably comes
off as a rule. In reality, they are simply meant as rules of thumb.
One of the main problems in C++ (more so than C) is that C++ provides
many mechanisms in the language by which the same task can be achieved
through different policies.  For example, C++ has the Polymorphism mechanism.
Some of the policies are templates, macros, inheritance, overloading,
(those are the static, compile-time ones), and virtual functions (the
run-time polymorphic policy).  Hopefully the following will provide 
enough fuel for questions to arrive at the best policy to use for a 
particular design.

I. ABCs and Inheritance
-----------------------
1. Abstract Base Class (ABC) : Make ABC class constructor protected when
      possible. Derived classes can have public constructor to override
      this.  The same is true for non-ABC classes as well.
2. Class Inheritance : Use protected keyword where ever possible, never use
      public to expose data members so the inheriting classes have access
      to them.
3. Multiple Inheritance and VBC's :The only drawback is the most derived
      class must initialize the lowest base classes. This breaks
      encapsulation.  Most people view multiple inheritance as a bad
      thing, but when used sparingly for parts of a design, there is
      no problem with it.
4. Data in classes should be keep private as much as possible.  Use a
      member function if a client needs to access the data.  If a member
      function does not need to be seen by a client, make it private.
      If the class might be inherited, then protected may be a good choice.
5. Private inheritance: Don't use it.  Too many ambiguities when used with
      run-time type identification.  Use a private data member instead
      or use public inheritance.
      Example:      class Foo: private Bar { ... }      dont do

6. Inheritance & virtual overrides: Care must be taken in overriding
      inherited functions. Sometimes functions are grouped together,
      and all need to be overridden. The base class designer must make
      this clear, if overriding one function requires multiple 
      functions to be overridden.
7. Inheritance & Get/Set functions: Typically functions that perform
      Get/Set shouldn't be overridden unless they are used by
      the derived class. Otherwise if the base class does direct
      field manipulation, you usually can't override it correctly,
      or it could be a maintenance nightmare.
      Note: Get/Set functions as referred to above are merely meant as
      abstractions. As a rule of thumb (thumb must be getting pretty
      big by now), one should not create functions called Get or Set,
      or flavors thereof. They tend to break the spirit of encapsulation.
      Of course, there will be times to use them.

II. SCOPE
---------
1. Law of Demeter : Do not make references to classes in a class that are
      not variables of the class, inherited by the class, or global.
      This also applies to including header files.
      Example:
            class Foo{public: Go(){} };
            class Bar{ Foo aFoo;  public:       Foo GetFoo(){return aFoo;} };
            class Fubar{ public:
                        void Bad(){  Bar aBar;  aBar.GetFoo().Go(); }
            };
      The method Bad() breaks encapsulation. It calls a method of a class
      it probably does not need to know about.  This will also affect 
      maintainability. If the Foo class changes, the changes may also 
      need to be done in the Fubar class.  
      The other side of the coin that must be looked at is do you
      want a pass-through method in the Bar class that simply
      calls the Go() method of the Foo class.  Lots of silly simple
      1 line member functions may not be desirable in all the classes.
      What probably needs to be looked at to decide what road to take
      is speed, or perhaps redesign the classes.
      Beyond the Law of Demeter is Doug's rule of thumb: Don't
      play hide and seek with data.
2. Scope: Another way to say the previous point is to keep scope
      small. This will increase the lifetime of the code and keep it
      maintainable and safe.
III. CLASSES
------------
1. Be explicit about the keywords, public, protected, and private in a class
      interface. Try not to have multiple sections. In other words, 
      multiple private sections in the class interface.  It is generally
      a good idea to place the public section first because this is 
      what most people are looking for when they go to use a class.
2. Make classes as atomic as possible. Give them a clear purpose. Break
      them into smaller classes if they become too complex. This may
      also eliminate duplicate code.
3. Don't let the compiler generate the default constructor,destructor,
      operator= and copy constructor.  If the class is entirely value
      based, this is probably fine, if not, for example, if the class
      has a data member that is a pointer, the above will probably not
      work.  Note, the default copy constructor only does a memcpy
      of the class, so all you copy is the pointer data. This may not
      be sufficient for copying a class.  Regardless, if you do want the
      default ones, place them in the code, and leave them commented.
      For example:
            // Fubar(const Fubar&)   use default copy constructor
4. If your class contains pointers, you should create the default constructor
      destructor, operator=, and copy constructor.
5. Class Copy: If the class should never be copied, then place the copy
      constructor in the private section and don't implement it.
      The linker will catch this, and the program will fail to build.
      This, although not graceful, is better than a malformed program.
6. Initialization: Perform all data member initialization in the constructor.
      It's best not to leave uninitialized objects running around in 
      the system.  Note, it is often more efficient using the
      constructor initializer list, otherwise, the default constructor
      would be called, and then you probably call member functions of
      the object later in the constructor.  For example:
      class Foo{ Bar mung;  Foo(int iCount) : mung(iCount) {}  ... };
      The variable mung is initialized once. But in the following:
      class Foo{ Bar mung;  Foo(int iCount){ mung = iCount; }  ... };
      mung's default constructor is called before the body of the
      class Foo's constructor is entered. Then mung is set again -
      this assumes that mung has an assignment operator. The net
      effect is that mung is initialized twice.
7. Class Naming:  There exists several ways to name classes that seem to
      work well for certain groups or people.  There is Hungarian notation
      and the "Taligent's Guide to Designing Programs" that document some
      of the more typical methods.

IV. MISC
--------
1. Implicit int:  The 'implicit int' rule will go away in the next 
      C++ standard. So for a proto like:  'main()'  you will have to 
      say 'int main()' in the future. Same for variables.
2. Preprocessor: Avoid it.  Use const values in the class, or inline
      functions instead of macros.  This is not to say, never use any
      #defines.
      Main reason:      #define MIN(a,b)      ( (aSomeFunction(); }

V. OVERLOADING
--------------
1. operator overloading:  It's syntactic sugar. Don't add them if they
      are not needed.  This does NOT refer to the typical ones like
      '=', '==', but ones like '()', '[]', '+'.  It does not always 
      make sense to add two objects together.

2. Overloading:  If a member function is conditionally executing code, 
      it may be a candidate for operator overloading, or just overloading.
3. Operator overloading and chaining: When designing an overloaded
      operator, think about whether it needs to be chained. For example:
            String cstr = "a" + "b" + "c";
      The String class's operator returns a reference to the String class.
      A partial implementation might be:
      
      class String{ public:
      String& operator+(const char *pcBuf){ 
                  // code to add the char* to the string
                  return *this;
      }
            ...
      };

VI. PARAMETERS
--------------
1. Argument Passing:  The first choice is typically a const ref.  The 
      const ref is basically an alias, and is easier to use than a 
      pointer.  It creates the same amount of instruction code as passing
      a pointer (for most cases). It's typically better than passing
      by value, where an object constructor will be called (if its an
      object).  As a rule of thumb, you might want too give the following
      a whirl:
            IN      const &
            OUT      &            If the object has the support functs
            INOUT      *&            Acts like a **.
      So for an IN parameter, what the 'const &' says, is here is a 
      reference to it, but you cannot modify the object. But you can
      call member functions that do not change the object ( member
      functions defined as const).  The OUT parameter is a parameter
      that is passed to a function that will modify it.  If the parameter
      needs to be created, then the INOUT parameter of *& may be a
      good choice.
2. Returning Ref:  In functions that return a reference, remember not to
      reference a temporary object and return it.  For example:
            String &Zippo(void){ ....  return String();
      What happens, is that the String() is a temporary object that
      upon return goes out of scope and is destroyed.  Thus, you
      return a reference to a destroyed object. Unfortunately, the
      program will probably work in most cases till it's shipped.
      The ol' Heisenbug!
3. Ref vs Pointer: Here's another way to look at when to use references,
      and when should to use pointers.
      C programmers sometimes don't like references since the
      reference semantics they provide isn't *explicit* in the caller's
      code. After a bit of C++ experience, however, one quickly realizes
      this "information hiding" is an asset rather than a liability. In
      particular, reuse-centered OOP tends to migrate the level of
      abstraction away from the language of the machine toward the
      language of the problem.  References are usually preferred over
      ptrs whenever you don't need "re-seating". This usually means that
      references are most useful in a class' public interface. References
      then typically appear on the skin of an object, and pointers on the
      inside. The exception to the above is where a function's parameter
      or return value needs a "sentinel" reference. This is usually best
      done by returning/taking a pointer, and giving the nil ptr (0) this
      special significance (references should always alias *objects*, not
      a dereferenced nil ptr).

VII. Constructors (more on classes)
-----------------------------------
1. Creating Constructors: These creatures should be simple. Try not to
      do anything in them that may generate errors.  Remember they
      don't have return values. If it's necessary to allocate
      memory or other complex things in the constructor, throw an exception
      if possible as the first recourse. Else, the class will have to be
      protected everywhere that may use something that may be in error.
      It's generally not a pretty sight to see an error returned in the
      constructor's signature.
2. Constructors: Another reason to keep them simple is in the case
      of inheritance.
3. Destructors:  It's responsibility is to release resources allocated 
      during the class's lifetime, not just from construction.
4. Member Initialization List: The constructor can have a comma separated
      member initialization list. If a class contains value based classes
      as data members, they can be initialized in the constructor. For
      example:
      class Foo{
            String cstr1;      // value based class called String
            String cstr2;      // value based class called String
      public:
            Foo(const char* pcStr1, const char*pcStr2):
                  cstr1(pcStr1), cstr2(pcStr2){}
      };
      With the variables cstr1, and cstr2 initialized in the constructor,
      they are initialized only once. Else, if they were initialized in 
      the body of the constructor, they would first be initialized with
      a default constructor, then again in the body.
      
VIII. EXCEPTIONS
----------------
1. Exceptions: Use exception hierarchies, possibly even derived from the
      Standard C++ ones.
2. Exceptions: Throw exceptions by value and catch them by reference.
      This way the exception handling mechanism cleans up anything
      created on the heap. If you throw exceptions by pointer, the
      catcher must know how to destroy them.  This is probably not
      a good coupling.  Even so, any up casting may slice and dice the
      object.

IX. TEMPLATES (more on classes)
-------------------------------
1. Templates:  Before creating new ones, see if they are in RogueWave,
      or part of the C++ Standard.
2. Templates:  When creating them, try to filter out any code that
      does not depend on the type, and place that into a base class.
      Thus, the template class itself is only the necessary information
      that depends on type. Good examples can be found in RogueWave.

Douglas J. Waters

(best reached on the internet)

Internet: waters@openmarket.com

Phone: (781) 359-7220

子弹 2008-07-18 09:17 发表评论

]]>http://www.cppblog.com/ztwaker/archive/2008/07/16/56317.html子弹子弹Wed, 16 Jul 2008 09:12:00 GMThttp://www.cppblog.com/ztwaker/archive/2008/07/16/56317.htmlhttp://www.cppblog.com/ztwaker/comments/56317.htmlhttp://www.cppblog.com/ztwaker/archive/2008/07/16/56317.html#Feedback0http://www.cppblog.com/ztwaker/comments/commentRss/56317.htmlhttp://www.cppblog.com/ztwaker/services/trackbacks/56317.html[轉]C++程序设计最佳实践

2007年04月23日 星期一 00:57

随着计算机语言的发展，我们现在编写一个程序越来越容易了。利用一些软件开发工具，往往只要通过鼠标的拖拖点点，计算机就会自动帮你生成许多代码。但在很多时候，计算机的这种能力被滥用了，我们往往只考虑把这个程序搭起来，而不去考虑程序的性能如何，程序是否足够的健壮。而此节课的目的主要是介绍一些编码的经验，让大家编写的程序更加健壮和高性能。 　　1、Prefer const and inline to #define 　　在C++编程中应该尽量使用const和inline来代替#define，尽量做到能不用#define就不用。#define常见的用途有“定义常量”以及“定义宏”，但其中存在诸多的弊病。 　　第一，查错不直观，不利于调试。Define的定义是由预处理程序处理的，作的是完全的文本替换，不做任何的类型检查。在编译器处理阶段，define定义的东西已经被完全替换了，这样在debug的时候就看不到任何的相关信息，即跟踪时不能step into宏。例如，把ASPECT_RATIO用define定义成1.653，编译器就看不到ASPECT_RATIO这个名字了。如果编译器报1.653错，那么就无从知道此1.653来自于何处。在真正编码的时候应该使用如下的语句来定义： static const double ASPECT_RATIO = 1.653; 　　第二，没有任何类型信息，不是type safe。因为它是文本级别的替换，这样不利于程序的维护。 　　第三，define的使用很容易造成污染。比如，如果有两个头文件都定义了ASPECT_RATIO, 而一个CPP文件又同时包含了这两个头文件，那么就会造成冲突。更难查的是另外一种错误，比如有如下的代码： 　　// in header file def.h 　　#define Apple 1 　　#define Orange 2 　　　 #define Pineapple 3 　　 … 　　// in some cpp file that includes the def.h 　　enum Colors {White, Black, Purple, Orange}; 　　在.h文件中Orange被定义成水果的一种，而在.cpp文件中Orange又成为了一种颜色，那么编译器就会把此处的Orange替换成2，编译可能仍然可以通过，程序也能够运行，但是这就成了一个bug，表现出古怪的错误，且很难查错。再比如定义了一个求a与b哪个数大的宏，#define max(a,b) ((a) > (b) ? (a) : (b)) 　　int a = 5, b = 0; 　　max(++ a, b); 　　max(++ a, b + 10); 　　在上面的操作中，max(++ a, b); 语句中a被++了两次，而max(++ a, b + 10); 语句中a只加了一次，这样在程序处理中就很有可能成为一个bug，且此bug也非常的难找。在实际编码时可以使用如下的语句来做： 　　template 　　inline const T& 　　max(const T& a, const T& b) { return a > b ? a : b; } 　　2、Prefer C++-style casts 　　在程序中经常会需要把一种类型转换成另外一种类型，在C++中应该使用static_cast、const_cast、dynamic_cast、reinterpret_cast关键字来做类型转换。因为这有以下好处，一是其本身就是一种注释，在代码中看到上面这些关键字就可马上知道此处是进行类型转换。二是C语言中类型转换通常是很难进行搜索的，而通过关键字cast则可以很容易的找到程序中出现类型转换的地方了。 　　3、Distinguish between prefix and postfix forms of increment and decrement operators 　　通常对于操作系统或编译器自身支持的类型，prefix（前缀，如++i）与postfix（后缀，如i++）的效果是一样的。因为现在的编译器都很聪明，它会自动做优化，这两者的汇编代码是一样的，性能不会有差别。但有时候也会有不同的，如一些重载了操作符的类型。下面是模拟prefix与postfix的操作过程，可以发现在postfix操作中会生成一个临时变量，而这一临时变量是会占用额外的时间和开销的。 　　// prefix form: increment and fetch 　　UPInt& UPInt::operator++() 　　　{ 　　　 *this += 1; // increment 　　　return *this; // fetch 　　　} 　　// postfix form: fetch and increment 　　　const UPInt UPInt::operator++(int) 　　　{ 　　　 UPInt oldValue = *this; // fetch 　　　++(*this); // increment 　　　 return oldValue; // return what was fetched 　　 } 　　一般情况下不需要区分是先++，还是后++，但是我们在编写程序的时候最好能习惯性的将其写成++i的形式，如在使用STL中的iterator时，prefix与postfix会有相当大的性能差异。请不要小看这些细节，实际在编写程序的时候，若不注意具体细节，你会发现程序的性能会非常的低。但要注意，虽然在大多数情况下可以用prefix来代替postfix，但有一种情况例外，那就是有[]操作符时，比如gzArray [++index] 是不等于 gzArray[index++]的。 4、Minimizing Compile-time Dependencies 　　有些人在编写程序时，往往喜欢将一个.h文件包含到另一个.h文件，而实践证明在做大型软件时这是一个非常不好的习惯，因这样会造成很多依赖的问题，包含较多的.h文件，别人又使用了这个class，而在他的那个工程中可能并不存在这些.h文件，这样很可能就编译不能通过。而且这样做，还可能造成很难去更新一个模块的情况。因为一个.h文件被很多模块包含的话，如果修改了此.h文件，在编译系统的时候，编译器会去寻找哪些模块依赖于某个被修改过的.h文件，那么就导致了所有包含入此.h文件的模块全都要进行重新编译。在项目比较小的时候，大家可能还感觉不到差别，但是如果说是在大型的软件系统里，你可能编译一遍源码需要七、八个小时。如果你这个.h文件被很多模块包含的话，就算在.h文件中加了一行注释，在编译时编译器检查哪些文件被改动，那么所有包含入此.h文件的模块都会被重新编译，造成巨大的时间和精力负担。对于此问题，解决的方法就是让.h文件自包含，也就是说让它包含尽量少的东西。所谓尽量少是指如删掉任何一个它包含进来的.h文件，都将无法正常进行工作。其实在很多情况下，并不需要一个.h文件去包含另一个.h文件，完全可以通过class声明来解决依赖关系的这种问题。再来看下面这个例子： 　　#include "a.h" // class A 　　#include "b.h" // class B 　　#include "c.h" // class C 　　#include "d.h" // class D 　　#include "e.h" // class E 　　class X : public A, private B 　　{ 　　　public: 　　E SomeFunctionCall(E someParameter); 　　　private: 　　 D m_dInstance; 　　}; 　　当类X从类A和类B中派生时，需要知道X在内存中都有哪些data，通常在内存中前面是基类的data，后面紧跟的是此派生类自身定义的data，因此就必须知道类A与类B的内部细节，要不然编译器就无法来安排内存了。但是在处理参数以及参数返回值的时候，实际上并不需要知道这些信息，在此处定义的SomeFunctionCall()只需知道E是个class就足够了，并不需要知道类E中的data如长度等的具体细节。上面的代码应该改写成如下的形式，以减少依赖关系： 　　#include "a.h" // class A 　　#include "b.h" // class B 　　#include "c.h" // class C 　　#include "d.h" // class D 　　class E; 　　class X : public A, private B 　　{ 　　　public: 　　E SomeFunctionCall(E someParameter); 　　　private: 　　D m_dInstance; 　　}; 　　5、Never treat arrays polymorphically 　　不要把数组和多态一起使用，请看下面的例子。 　　class BST { ... }; 　　class BalancedBST: public BST { ... }; 　　void printBSTArray(ostream& s, const BST array[], int numElements) 　　{ 　　for (int i = 0; i < numElements; ++i) 　　{ 　　 s << array[i]; 　　// this assumes an operator<< is defined for BST 　　} 　　} 　　BalancedBST bBSTArray[10]; 　　printBSTArray(cout, bBSTArray, 10); 　　数组在内存中是一个连续的内存空间，而在数组中应该如何来定位一个元素呢？过程是这样的，编译器可以知道每个数据类型的长度大小，如果数组的index是0，则会自动去取第一个元素；如果是指定了某个index，编译器则会根据此index与该数据类型的长度自动去算出该元素的位置。 　　在printBSTArray()函数中，尽管传入的参数是BalancedBST类型，但由于其本来定义的类型是BST，那么它依然会根据BST来计算类型的长度。而通常派生类实例所占的内存要比基类实例所占的内存大一些，因此该程序在编译时会报错。请记住，永远不要把数组和C++的多态性放在一起使用。 　　6、Prevent exceptions from leaving destructors 　　析构函数中一定不要抛出异常。通常有两种情况会导致析构函数的调用，一种是当该类的对象离开了它的域，或delete表达式中一个该类对象的指针，另一种是由于异常而引起析构函数的调用。 　　如果析构函数被调用是由于exception引起，而此时在析构函数中又抛出了异常，程序会立即被系统终止，甚至都来不及进行内存释放。因此如果在析构函数中抛出异常的话，就很容易混淆引起异常的原因，且这样的软件也会让用户非常恼火。由于析构函数中很可能会调用其它的一些函数，所以在写析构函数的时候一定要注意，对这些函数是否会抛出异常要非常清楚，如果会的话，就一定要小心了。比如下面这段代码： 　　Session::~Session() 　 { 　　logDestruction(this); 　 } 　　比如logDestruction()函数可能会抛出异常，那么我们就应该采用下面这种代码的形式： 　　Session::~Session() 　 { 　　 try 　　{ 　　　logDestruction(this); 　　 } 　　 catch (...) 　　{ 　　 } 　} 　　这样程序出错的时候不会被立即关掉，可以给用户一些其它的选择，至少先让他把目前在做的工作保存下来。 　　7、Optimization:Remember the 80-20 rule 　　在软件界有一个20-80法则，其实这是一个很有趣的现象，比如一个程序中20%的代码使用了该程序所占资源的80%；一个程序中20%的代码占用了总运行时间的80%；一个程序中20%的代码使用了该程序所占内存的80%；在20%的代码上面需要花费80%的维护力量，等等。这个规律还可以被继续推广下去，不过这个规律无法被证明，它是人们在实践中观察得出的结果。从这个规律出发，我们在做程序优化的时候，就有了针对性。比如想提高代码的运行速度，根据这个规律可以知道其中20%的代码占用了80%的运行时间，因此我们只要找到这20%的代码，并进行相应的优化，那么我们程序的运行速度就可以有较大的提高。再如有一个函数，占用了程序80%的运行时间，如果把这个函数的执行速度提高10倍，那么对程序整体性能的提高，影响是非常巨大的。如果有一个函数运行时间只占总时间的1%，那就算把这个函数的运行速度提高1000倍，对程序整体性能的提高也是影响不大的。所以我们的基本思想就是找到占用运行时间最大的那个函数，然后去优化它，哪怕只是改进了一点点，程序的整体性能也可以被提高很多。 　　要想找出那20%的代码，我们的方法就是使用Profiler，它实际上是一些公司所开发的工具，可以检查程序中各个模块所分配内存的使用情况，以及每个函数所运行的时间等。常见的Profiler有Intel公司开发的VTune，微软公司开发的Visual Studio profiler，DevPartner from Compuware等。

子弹 2008-07-16 17:12 发表评论

]]>http://www.cppblog.com/ztwaker/archive/2008/07/14/56087.html子弹子弹Mon, 14 Jul 2008 04:44:00 GMThttp://www.cppblog.com/ztwaker/archive/2008/07/14/56087.htmlhttp://www.cppblog.com/ztwaker/comments/56087.htmlhttp://www.cppblog.com/ztwaker/archive/2008/07/14/56087.html#Feedback0http://www.cppblog.com/ztwaker/comments/commentRss/56087.htmlhttp://www.cppblog.com/ztwaker/services/trackbacks/56087.html1.  《经济人的末日》（The End of Economic Man ）- 1939
2.  《工业人的未来》（The Future of Industrial Man） - 1942
3.  《公司的概念》（Concept of the Corporation） - 1946
4.  《新社会》（The New Society） - 1950
5.  《个人推荐首批阅读》《管理实践》（The Practice of Management） - 1954
6.  《美国的下一个20年》（America's Next Twenty Years） - 1957
7.  《明日的里程碑》（Landmarks of Tomorrow） - 1957
8.  《成果管理》（Managing for Results ）- 1964
9.  《个人推荐首批阅读》《卓有成效的管理者》（The Effective Executive） - 1966
10. 《断层时代》（The Age of Discontinuity） - 1968
11. 《技术、管理与社会》（Technology， Management and Society） - 1970
12. 《人、思想与社会》（Men， Ideas and Politics） - 1971
13. 《个人推荐首批阅读》《管理：任务、责任、实践》（Management: Tasks， Responsibilities， Practices） - 1973
14. 《看不见的革命》（The Unseen Revolution） - 1976 (1996年以《退休基金革命》（The Pension Fund Revolution）重版)
15. 《人与绩效：德鲁克论管理精华》（People and Performance: The Best of Peter Drucker on Management ）- 1977
16. 《管理导论》（An Introductory View of Management） - 1977
17. 《旁观者》（Adventures of a Bystander） - 1978
18. 《毛笔之歌：日本绘画》（Song of the Brush: Japanese Painting from the Sanso Collection） - 1979
19. 《动荡时代中的管理》（Managing in Turbulent Times） - 1980
20. 《迈向经济新纪元及其他论文》（Toward the Next Economics and Other Essays） - 1981
21. 《变动中的管理界》（The Changing World of the Executive） - 1982
22. 《最后可能出现的世界》（小说，The Last of All Possible Worlds） - 1982
23. 《行善的诱惑》（小说，The Temptation to Do Good ）- 1984
24. 《创新与企业家精神》（Innovation and Entrepreneurship） - 1985
25. 《管理的前沿》（Frontiers of Management: Where Tomorrow's Decisions are Being Shaped Today） - 1986
26. 《新现实：政府与政治、经济与企业、社会与世界》（The New Realities: in Government and Politics， in Economics and Business， in Society and World View） - 1989
27. 《非营利组织的管理：原理与实践》（Managing the Nonprofit Organization: Principles and Practices） - 1990
28. 《为了未来－20世纪90年代及其以后的年代－而管理》 “Mananing for the Future:The 1990's and Beyond” - 1992
29. 《生态远景》（The Ecological Vision） - 1993
30. 《后资本主义社会》（Post-Capitalist Society） - 1993
31. 《巨变时代的管理》（Managing in a Time of Great Change） - 1995
32. 《德鲁克看亚洲：德鲁克与中内的对话》（Drucker on Asia: A Dialogue between Peter Drucker and Isao Nakauchi） -1997
33. 《德鲁克论管理》（Peter Drucker on the Profession of Management） - 1998
34. 《21世纪的管理挑战》（Management Challenges for the 21st Century ）- 1999
35. 《德鲁克精华》（The Essential Drucker） - 2001
36. 《下一个社会的管理》（Managing in the Next Society） - 2002
37. 《功能社会》（A Functioning Society ）- 2002
38. 《个人推荐首批阅读》《德鲁克日志》（The Daily Drucker） - 2004
39. 《卓有成效管理者的实践》 （The Effective Executive in Action）-2006

子弹 2008-07-14 12:44 发表评论

]]>http://www.cppblog.com/ztwaker/archive/2008/06/17/53703.html子弹子弹Tue, 17 Jun 2008 07:06:00 GMThttp://www.cppblog.com/ztwaker/archive/2008/06/17/53703.htmlhttp://www.cppblog.com/ztwaker/comments/53703.htmlhttp://www.cppblog.com/ztwaker/archive/2008/06/17/53703.html#Feedback0http://www.cppblog.com/ztwaker/comments/commentRss/53703.htmlhttp://www.cppblog.com/ztwaker/services/trackbacks/53703.html阅读全文

子弹 2008-06-17 15:06 发表评论

]]>http://www.cppblog.com/ztwaker/archive/2008/06/17/53698.html子弹子弹Tue, 17 Jun 2008 06:08:00 GMThttp://www.cppblog.com/ztwaker/archive/2008/06/17/53698.htmlhttp://www.cppblog.com/ztwaker/comments/53698.htmlhttp://www.cppblog.com/ztwaker/archive/2008/06/17/53698.html#Feedback0http://www.cppblog.com/ztwaker/comments/commentRss/53698.htmlhttp://www.cppblog.com/ztwaker/services/trackbacks/53698.html

建立你自己的温伯格图书馆     9月，清华大学出版社隆重推出了《软件与系统思想家温伯格精粹译丛》首批共6种。该丛书共14种，均出自美国计算机界的泰斗人物杰拉尔德·温伯格（Gerald M. Weinberg）。     温伯格首要的贡献集中于软件领域，他是从个体心理、组织行为和企业文化角度研究软件管理和软件工程的权威和代表人物。在超过40年的软件职业生涯中，温伯格从事过软件开发，软件项目管理、软件管理教学和咨询，他更是一位杰出的软件专业作者和思想家。1997年，温伯格因其在软件领域的杰出贡献，被美国计算机博物馆的计算机名人堂选为首批5位成员之一。这个名人堂至今只有20名成员。为中国读者所熟悉的比尔·盖茨和迈克尔·戴尔也是在温伯格之后方才获得这一计算机界至高无上的殊荣。     温伯格精力旺盛、思想活跃，从20世纪70年代开始，他总共撰写了30多本书籍和数以百计的论文。这些著作主要集中在两个主题：人与技术的结合；人的思维模式、思维习惯以及解决问题的方法。温伯格的大部分作品已经被翻译成10多种语言发行到法国、德国、西班牙、葡萄牙、荷兰、俄罗斯、日本等多个国家，30余年畅销不衰。在西方国家乃至全世界，温伯格拥有大量忠实的读者群，这些"追星族"阅读了温伯格的每本重要著作，他们甚至建设有专门的组织和网站，讨论和交流大师的重要思想。可以说，温伯格近年来的每本新书都是在万众瞩目中推出的。     成熟的软件产业是管理实践和信息技术结合的产业。而软件管理思想的引进，比技术和资金更为紧迫和重要。在西方国家图书市场上，软件管理图书非常多。浪里淘沙之中，温伯格的著作正是西方软件管理思想发展和集大成的中流砥柱。             --美国计算机名人堂代表人物温伯格的思想精华             --微软亚洲研究院院长兼首席科学家张亚勤强力推荐             --12种语言的版本发行全世界，30余年畅销不衰             --提倡人与技术相结合、引导系统化思维模式 程序开发心理学（银年纪念版） √ "这是有史以来计算机编程领域的最经典的一部著作。"--Datamation √ "一本杰作的新生！……1971年，当《程序开发心理学》首次面世时，我们都如雷轰耳--从未有人提出软件开发可以被看作是一种人类的活动。经历多年，该书成为全球畅销书……不管你是属于上世纪60年代和70年代那一代，还是属于80年代和90年代的新一代，你要感谢你自己去拿起这样一本奇妙的书。一旦你读了它，你应该接着追读Weinberg所有其他的书，每一本都是一颗宝石。"--Ed Yourdon, Cutter IT Journal √ "《程序开发心理学》……是第一本强调计算机编程是个人和团队共同努力过程的图书，并且成为了这个领域的经典图书……尽管本书写作时采用的是1971年的视角，但是30多年后的今天，这本书还是所有软件开发经理们的必读经典。"--J.J.Hirschfelder，Computing Reviews √ "Gerald M. Weinberg是我的良师益友，我的同行，也是我们这个职业（软件开发）造就的最好的思想家和作者……《程序开发心理学》一书写成于1969年，1971年出版，自此被不断重印，其重印记录是任何其他计算图书都未能比及的。大多数书中的'关于人的内容'比其中的技术更经得住时间的考验。"--Sue Petersen在Visual Developer Magazine（March/April, 1999）的评论 √ "Gerald M. Weinberg的《程序开发心理学》 是我最喜爱的一本关于软件开发的书。……书中的有关'无私软件开发'的观点……带动了开放源码思想崛起。好的软件工程思想要比具体的技术更经久不衰。就这一点而言，没有一本书提供的思想可以与《程序开发心理学》中的思想相比。"--Steve McConnel，IEEE主编，IEEE Software (Jan/Feb, 1999) √ "Gerald M. Weinberg的经典之作《程序开发心理学》影响了我的一生……因为他认识到了一个随着时间推移将变得越来越重要的问题：关注和培育程序员和程序员队伍。……和Fredrick Brooks的《人月神话》一样，Weinberg的《程序开发心理学》同样是一本经久不衰的经典之作。"--Michael Schrage，MIT Media Lab，"No More Teams!"一书的作者，摘自Computerworld √ "《程序开发心理学》（银年纪念版）是1971年该书第一次出版后的修订本。这本书如何还能适合今天人们的口味呢？答案很简单：人并没有真正改变。……Weinberg在全书提供了无数强有力的经历时间考验的见识，这些见识过去是正确的，现在也仍然正确的。……如果你在这本书中看不到一些你自己，你就不是一名计算机专业人员。买一本，读读它，然后把它留在你的经理的椅子上。相信你们俩都将受益匪浅。"--B. Scott Andersen，Silver anniversary edition hits gold, Amazon.com (Feb 27, 2001) √ "Weinberg在银年纪念版的每一章结尾处都做了评注，这恪守了他在前言里的承诺：'我决不会去掩盖自己的错误--因为也许正是通过这些错误，我的读者才会获得更大的收获。'……有时侯，老书是最好的，尤其是在对其做了修订、对当初的大胆预言和贤明建议做了评价。"--Johanna Rothman （The Psychology of Computer Programming : Silver Anniversary Edition） 9月出版，敬请关注！         ISBN: 7-302-07026-1     在计算机界，还没有任何一本计算机方面的书，在初次出版之后，能够在长达25年的岁月中一直保持活力——而且这种活力到今天仍在继续。《程序开发心理学》是开创“以人为本”研究方法的先驱，它以其对程序员们在智力、技巧、团队和问题求解能力等方面独特的视角和敏锐的观察经受住了时间的考验。 成为技术领导者——解决问题的有机方法 √ "共24章的内容，逻辑清晰、引发思考，帮助你如何完成从技术人员到问题解决型领导者的转变……一本实用的、实实在在的指南……热情、友好、诙谐的语言，不时地穿插着一些奇闻轶事，非常适合阅读。"--Cause/Effect √ "本书可是看作是一本有关发展个人领导能力的指南，但是，本书的价值不只这些……本书包含很多有关个人职业成长非常实用和颇有价值的观点……是这位作者写的最好的一本书之一。"--Journal of Systems Management √ "《成为技术领导者》可以指导所有领导者并使几乎任何一个领域的领导者受到鼓舞。"--Data Processing Digest √ "温伯格在书中阐述了不同类型的领导行为，分析了那些阻止我们进行有效领导或排斥他人领导的不利因素，并提出了能让我们把事情做得更好的行为。所有这些内容都是通过他幽默和坦率的语言表达出来的……总是那么引人入胜……激发我们去思考如何使技术人员在工作中进行有效的合作……温伯格不仅在引导大家如何成为一名领导者，他自己本身就是一名出色的领导者。"--IEEE Computer √ "无论你是在管理单机、网络、还是多用户系统，你都将会发现这是一本条理清晰和内容精练的好书。"--Computer Book Review （Becoming a Technical Leader: An Organic Problem-Solving Approach） 9月出版，敬请关注！         ISBN: 7-302-06889-5     本书阐述了作为一名成功领导者所必须掌握的领导方法与技巧——创新、激励和组织。本书提出了一些方法，供读者分析自己在这三个方面的领导技巧，并提供了开发这些技巧所需的实践步骤。本书探讨的范畴不仅仅局限于技术层面，而且还拓展到了如何与他人更好地协作。作者在讲解基本原理的过程中所举的逸闻趣事、类比与比喻令人印象深刻，因此有助于读者领会其中精要。 系统化思维导论（银年纪念版） √ 有关《系统化思维导论》（银年纪念版）的赞誉 √ 整理中... （An Introduction to General System Thinking） 9月出版，敬请关注！         ISBN: ISBN: 7-302-06804-6     25年以来，《系统化思维导论》在介绍系统理论方面被一致认为是一本创新性的著作，在计算机以及其他各个领域获得了普遍的应用。在世界各地，在课堂上和研讨班，本书开启心灵、磨砺思维的威力得到不断地证明。 系统设计的一般原理 √ 有关《系统设计的一般原理》的赞誉 √ 整理中... （General Principles of Systems Design） 10月出版，敬请关注！     本书一位计算机专家与一位人类学家思想的碰撞结晶，针对那些无法通过传统方法加以解决的系统问题，本书为我们介绍了分析与理解这类问题的新观点与方法。本书是一本一般性系统思想著作，对各个学科领域，具有很广泛的适应性，不仅仅是关于计算机系统，还包括各种系统——人类、自然、科技。它提供了许多关于诸如设计信息处理系统、培训程序、商业组织、停车场、或都市人日常工作的应用实例。 走查、审查与技术复审手册——对程序、项目和产品进行评估 √ 有关《走查、审查与技术复审手册》的赞誉 √ 整理中... （Handbook of Walkthroughs, Inspections, and Technical Reviews : Evaluating Programs, Projects, and Products） 9月出版，敬请关注！ ISBN: 7-302-06987-5     这本备受赞誉和推崇的佳作，可以让你学会如何将技术复核的方法应用于各种产品与软件的开发过程。本书详细地解释了开展走查（或者同级团体复审）、审查和技术复审的流程，同时还为每一种接受复审的材料（包括规格、设计和代码复审）配备了详实的检查表。 你的灯亮着吗？——发现问题的真正所在 √ "一本有关如何解决问题的最好的一本书。……我强烈推荐这本书。"--John S. Rhodes, WebWord.com √ "出自Weinberg和Gause之手笔的又一本神奇的力作。"--Barry Kornfeld, Sound Bytes √ "作者用通俗易懂的故事，提出了他对问题定义的深刻见解以及实用的解决问题的方法，这些见解和方法对管理者的作用之大无法估量。尽管这一话题是非常严肃的，但是行文却幽默风趣，完全不是一本讨论技术的书。"--Jim Van Speybroeck, Data Processing Digest √ "这是迄今为止这一领域最有趣、最有帮助的一本书。作者在分析和处理问题的方法方面提出了很多颇有帮助和价值的建议。"--Charles Ashbacher, Amazon.com √ "我管理着一个程序员团队。我希望他们头脑反映敏捷，能够知道通向程序开发的捷径，把握住程序开发真正问题之所在，然后顺利解决这些问题。这就是为什么我给公司里的每一名程序员买了这本书。"--Garry Bor, 来自新加坡的一名软件工程师 √ "如果说这是一册教科书，那一定是我太偏爱了故事；如果说这是一束小品文，那一定是我太沉迷于思考；如果说这是程序员解决问题的指南，那一定是我忽略了问题的普遍性；如果说这将改变你的生活，那一定是你洞察了其中的奥秘。"--Citizen √ "本书包含很多具有深刻哲理的警句，诸如'不管看上去如何，人们很少知道他们想要什么，直到你给了他们想要的东西。'；'鱼总是最后一个看到水的。'但是本书并不是简单的警句的罗列，它真的是一本有关问题解决的有趣的和有用的书。……我已经读了两遍，我还会很快再读一遍。"--Tim Ottinger, Object Mentor Inc. （Are Your Lights On? : How to Figure Out What the Problem Really Is） 9月出版，敬请关注！ ISBN: 7-302-06888-7     这是一本关于问题解决的书，在美国20年畅销不衰。主要探讨了从“问题出现”到“决定采用什么方式解决该问题”之间我们需要考虑的方方面面，从而教会你一种分析问题的全新思路，让你轻轻松松解决问题！20则幽默的现代寓言故事，60副精美的全彩卡通插图，您将看到大师温伯格如何改变我们的思考方式！ 探索需求 （Exploring Requirement） 2004年4月出版。UMLChina隆重推荐！     本书着眼于系统设计之前的需求分析。通过对一些需求分析中的常见误区和问题的分析和讨论，从和客户沟通开始，深入研究一些可能的需求，澄清用户和开发者期望值，最终给出了能够大幅度提高项目成功几率的一些建议方法。全书语言通畅，词汇量小，通俗易懂，层次分明，是需求分析人员的入门和提高指南。 理解专业程序员 （Understanding the Professional Programmer） 2004年年初出版，敬请关注！     本书是一本关于人和思想方面的书。主要介绍了对于程序员这个职业来说什么问题是重要的，怎样在官僚机构中保持生存，成为职业程序员的方法，怎么样有效的思考，以及程序员这个职业的前途。本书的特点是各个短文简练易读，文中借用故事或轶事来阐明作者的观点，非常具有启发性。 12月出版，敬请关注！ 咨询的奥秘——成功提出和获得建议的指南 （Secrets of Consulting: A Guide to Giving and Getting Advice Successfully）     本书内容是关于如何更好的为别人给出建议或接受别人建议的。作者凭借对自己25年专业经验总结和提炼，精辟地归纳出了各种规则、定律和原理，包括如何在竞争激烈的咨询市场中脱颖而出，如何为咨询服务定价和拓展市场，如何衡量咨询服务的有效性以及如何处理咨询人员与客户的关系等等。本书深受咨询专业人士推崇和欢迎，是一本畅销多年的经典著作。 咨询的奥秘——咨询师的百宝箱 （More Secrets of Consulting: The Consultant's Tool Kit）     本书是Gerald M. Weinberg的畅销书The Secrets of Consulting的姊妹篇，在前一本书给出的众多定律、法则的基础上，本书给出了作为咨询人员应该具有的更多的专业和个人素质。作者通过生动的比喻，结合实例的简单精辟的说理，列举了咨询人员应该注重培养的能力，方法和生活态度。 2004年年初出版，敬请关注！ 质量软件管理——系统思维 （Quality Software Management : Systems Thinking）     在本卷中，Gerald M. Weinberg剖析了开发质量软件的第一个必要条件：掌握（对问题、解答以及质量本身的）正确的思维方法。其中所介绍的在管理过程中应该遵循的方针，可以促使我们进行这类必要的思考。 质量软件管理——测试优先 （Quality Software Management : First-Order Measurement）     该卷循序渐进地为你提供计划指导，使你学会通过细致的观察与测量来收集可靠的信息。详细介绍了具体的技术方法，同时还提供了一个模型，将复杂的测量过程划分为四个步骤：入口、含义、重要性和反馈。每一步都说明了在软件开发过程中，应该如何更为精确地进行观察与测量。 质量软件管理——协调行动 （Quality Software Management : Congruent Action）     为了生产出高质量的软件，我们首先需要高质量的、得力的经理。Weinberg深受推崇的该系列丛书中独立的第三卷所讨论的，就是如何成长为这样一名经理。为了领导得力，经理们必须行动一致。换而言之，这些经理不仅需要对优秀软件工作的概念有所理解，而且还必须身体力行这些原理，在实践中这一点更为重要。 质量软件管理——预期变革 （Quality Software Management : Anticipating Change）     软件企业进行变革的尝试往往以失败告终，其原因就在于对变革过程中的各种动力理解不够充分--这也是企业之所以出现危机的首当其冲的一个原因。Jerry Weinberg的这本书为其包含四本独立分卷的系列丛书进行了总结，该卷为我们在变革过程中的管理工作提供了注重实效、内容翔实的最后交待。 相关链接 · 透明对温伯格的专访（《程序员》第9期） NEW! · 名人堂温伯格专栏（《程序员》第8期） NEW! · 微软亚洲研究院院长兼首席科学家张亚勤专文推荐 · 剑、气和令狐冲 · 七宝楼台今安在 · 个体性最后的堡垒 · 走出问题的乌托邦 · 从今天开始，做你自己的上帝

Copyright by shinebook, who publishes best books for IT people. Edited by Shiningxyy,and designed by Orrin.

子弹 2008-06-17 14:08 发表评论

]]>http://www.cppblog.com/ztwaker/archive/2008/06/13/53110.html子弹子弹Fri, 13 Jun 2008 03:23:00 GMThttp://www.cppblog.com/ztwaker/archive/2008/06/13/53110.htmlhttp://www.cppblog.com/ztwaker/comments/53110.htmlhttp://www.cppblog.com/ztwaker/archive/2008/06/13/53110.html#Feedback0http://www.cppblog.com/ztwaker/comments/commentRss/53110.htmlhttp://www.cppblog.com/ztwaker/services/trackbacks/53110.html阅读全文

子弹 2008-06-13 11:23 发表评论

]]>http://www.cppblog.com/ztwaker/archive/2008/06/10/52752.html子弹子弹Tue, 10 Jun 2008 06:38:00 GMThttp://www.cppblog.com/ztwaker/archive/2008/06/10/52752.htmlhttp://www.cppblog.com/ztwaker/comments/52752.htmlhttp://www.cppblog.com/ztwaker/archive/2008/06/10/52752.html#Feedback0http://www.cppblog.com/ztwaker/comments/commentRss/52752.htmlhttp://www.cppblog.com/ztwaker/services/trackbacks/52752.htmlFrom: http://www.macadamian.com/index.php?option=com_content&task=view&id=27&Itemid=31

Macadamian's Code Review Checklist 

At Macadamian, we practice what we preach with peer code reviews. Before we commit any code to source control, we check it for compliance with this list.

We’ve made the checklist public for the use of software development teams implementing code review as part of their process. For more information about code review processes and software development best practices, read check out the Critical Path newsletter – it’s free, too!

General Code Smoke Test
Comments and Coding Conventions
Error Handling
Resource Leaks
Control Structures
Performance
Functions
Bug Fixes
Math

 

General Code Smoke Test

Does the code build correctly?
No errors should occur when building the source code. No warnings should be introduced by changes made to the code.

Does the code execute as expected?
When executed, the code does what it is supposed to.

Do you understand the code you are reviewing?
As a reviewer, you should understand the code. If you don't, the review may not be complete, or the code may not be well commented.

Has the developer tested the code?
Insure the developer has unit tested the code before sending it for review. All the limit cases should have been tested.

Comments and Coding Conventions

Does the code respect the project coding conventions?
Check that the coding conventions have been followed. Variable naming, indentation, and bracket style should be used.

Does the source file start with an appropriate header and copyright information?
Each source file should start with an appropriate header and copyright information. All source files should have a comment block describing the functionality provided by the file.

Are variable declarations properly commented?
Comments are required for aspects of variables that the name doesn't describe. Each global variable should indicate its purpose and why it needs to be global.

Are units of numeric data clearly stated?
Comment the units of numeric data. For example, if a number represents length, indicate if it is in feet or meters.

Are all functions, methods and classes documented?
Describe each routine, method, and class in one or two sentences at the top of its definition. If you can't describe it in a short sentence or two, you may need to reassess its purpose. It might be a sign that the design needs to be improved.

Are function parameters used for input or output clearly identified as such?
Make it clear which parameters are used for input and output.

Are complex algorithms and code optimizations adequately commented?
Complex areas, algorithms, and code optimizations should be sufficiently commented, so other developers can understand the code and walk through it.

Does code that has been commented out have an explanation?
There should be an explanation for any code that is commented out. "Dead Code" should be removed. If it is a temporary hack, it should be identified as such.

Are comments used to identify missing functionality or unresolved issues in the code?
A comment is required for all code not completely implemented. The comment should describe what's left to do or is missing. You should also use a distinctive marker that you can search for later (For example: "TODO:francis").

Error Handling

Are assertions used everywhere data is expected to have a valid value or range?
Assertions make it easier to identify potential problems. For example, test if pointers or references are valid.

Are errors properly handled each time a function returns?
An error should be detected and handled if it affects the execution of the rest of a routine. For example, if a resource allocation fails, this affects the rest of the routine if it uses that resource. This should be detected and proper action taken. In some cases, the "proper action" may simply be to log the error.

Are resources and memory released in all error paths?
Make sure all resources and memory allocated are released in the error paths.

Are all thrown exceptions handled properly?
If the source code uses a routine that throws an exception, there should be a function in the call stack that catches it and handles it properly.

Is the function caller notified when an error is detected?
Consider notifying your caller when an error is detected. If the error might affect your caller, the caller should be notified. For example, the "Open" methods of a file class should return error conditions. Even if the class stays in a valid state and other calls to the class will be handled properly, the caller might be interested in doing some error handling of its own.

Has error handling code been tested?
Don't forget that error handling code that can be defective. It is important to write test cases that exercise it.

Resource Leaks

Is allocated memory (non-garbage collected) freed?
All allocated memory needs to be freed when no longer needed. Make sure memory is released in all code paths, especially in error code paths.

Are all objects (Database connections, Sockets, Files, etc.) freed even when an error occurs?
File, Sockets, Database connections, etc. (basically all objects where a creation and a deletion method exist) should be freed even when an error occurs. For example, whenever you use "new" in C++, there should be a delete somewhere that disposes of the object. Resources that are opened must be closed. For example, when opening a file in most development environments, you need to call a method to close the file when you're done.

Is the same object released more than once?
Make sure there's no code path where the same object is released more than once. Check error code paths.

Does the code accurately keep track of reference counting?
Frequently a reference counter is used to keep the reference count on objects (For example, COM objects). The object uses the reference counter to determine when to destroy itself. In most cases, the developer uses methods to increment or decrement the reference count. Make sure the reference count reflects the number of times an object is referred.

Thread Safeness

Are all global variables thread-safe?
If global variables can be accessed by more than one thread, code altering the global variable should be enclosed using a synchronization mechanism such as a mutex. Code accessing the variable should be enclosed with the same mechanism.

Are objects accessed by multiple threads thread-safe?
If some objects can be accessed by more than one thread, make sure member variables are protected by synchronization mechanisms.

Are locks released in the same order they are obtained?
It is important to release the locks in the same order they were acquired to avoid deadlock situations. Check error code paths.

Is there any possible deadlock or lock contention?
Make sure there's no possibility for acquiring a set of locks (mutex, semaphores, etc.) in different orders. For example, if Thread A acquires Lock #1 and then Lock #2, then Thread B shouldn't acquire Lock #2 and then Lock #1.

Control Structures

Are loop ending conditions accurate?
Check all loops to make sure they iterate the right number of times. Check the condition that ends the loop; insure it will end out doing the expected number of iterations.

Is the code free of unintended infinite loops?
Check for code paths that can cause infinite loops. Make sure end loop conditions will be met unless otherwise documented.

Performance

Do recursive functions run within a reasonable amount of stack space?
Recursive functions should run with a reasonable amount of stack space. Generally, it is better to code iterative functions.

Are whole objects duplicated when only references are needed?
This happens when objects are passed by value when only references are required. This also applies to algorithms that copy a lot of memory. Consider using algorithm that minimizes the number of object duplications, reducing the data that needs to be transferred in memory.

Does the code have an impact on size, speed, or memory use?
Can it be optimized? For instance, if you use data structures with a large number of occurrences, you might want to reduce the size of the structure.

Are you using blocking system calls when performance is involved?
Consider using a different thread for code making a function call that blocks.

Is the code doing busy waits instead of using synchronization mechanisms or timer events?
Doing busy waits takes up CPU time. It is a better practice to use synchronization mechanisms.

Was this optimization really needed?
Optimizations often make code harder to read and more likely to contain bugs. Such optimizations should be avoided unless a need has been identified. Has the code been profiled?

Functions

Are function parameters explicitly verified in the code?
This check is encouraged for functions where you don't control the whole range of values that are sent to the function. This isn't the case for helper functions, for instance. Each function should check its parameter for minimum and maximum possible values. Each pointer or reference should be checked to see if it is null. An error or an exception should occur if a parameter is invalid.

Are arrays explicitly checked for out-of-bound indexes?
Make sure an error message is displayed if an index is out-of-bound.

Are functions returning references to objects declared on the stack?
Don't return references to objects declared on the stack, return references to objects created on the heap.

Are variables initialized before they are used?
Make sure there are no code paths where variables are used prior to being initialized. If an object is used by more than one thread, make sure the object is not in use by another thread when you destroy it. If an object is created by doing a function call, make sure the object was created before using it.

Does the code re-write functionality that could be achieved by using an existing API?
Don't reinvent the wheel. New code should use existing functionality as much as possible. Don't rewrite source code that already exists in the project. Code that is replicated in more than one function should be put in a helper function for easier maintenance.

Bug Fixes

Does a fix made to a function change the behavior of caller functions?
Sometimes code expects a function to behave incorrectly. Fixing the function can, in some cases, break the caller. If this happens, either fix the code that depends on the function, or add a comment explaining why the code can't be changed.

Does the bug fix correct all the occurrences of the bug?
If the code you're reviewing is fixing a bug, make sure it fixes all the occurrences of the bug.

Math

Is the code doing signed/unsigned conversions?
Check all signed to unsigned conversions: Can sign completion cause problems? Check all unsigned to signed conversions: Can overflow occur? Test with Minimum and Maximum possible values.

子弹 2008-06-10 14:38 发表评论

]]>