More on this book
Community
Kindle Notes & Highlights
Don't spoil a perfectly good program by overembellishment and over-refinement. Move on, and let your code stand in its own right for a while. It may not be perfect. Don't worry: it could never be perfect.
Two or more things are orthogonal if changes in one do not affect any of the others. In a well-designed system, the database code will be orthogonal to the user interface: you can change the interface without affecting the database, and swap databases without changing the interface.
"lazy" code: be strict in what you will accept before you begin, and promise as little as possible in return.
Turning off assertions when you deliver a program to production is like crossing a high wire without a net because you once made it across in practice. There's dramatic value, but it's hard to get life insurance.
When allocating the same set of resources in different places in your code, always allocate them in the same order. This will reduce the possibility of deadlock.
You can use activity diagrams to maximize parallelism by identifying activities that could be performed in parallel, but aren't.
Sometimes we come up with fairly complex O() functions, but because the highest-order term will dominate the value as n increases, the convention is to remove all low-order terms, and not to bother showing any constant multiplying factors. O(n2/2+ 3n) is the same as O(n2/2), which is equivalent to O(n2
The O() notation doesn't apply just to time; you can use it to represent any other resources used by an algorithm. For example, it is often useful to be able to model memory consumption
It's easy to get sucked into the "just one more feature" maelstrom, but by tracking requirements you can get a clearer picture that "just one more feature" is really the fifteenth new feature added this month.
Quality is a team issue. The most diligent developer placed on a team that just doesn't care will find it difficult to maintain the enthusiasm needed to fix niggling problems. The problem is further exacerbated if the team actively discourages the developer from spending time on these fixes.
Maybe appoint a chief water tester. Have this person check constantly for increased scope, decreased time scales, additional features, new environments—anything that wasn't in the original agreement.
Some teams appoint a member as the project librarian, responsible for coordinating documentation and code repositories. Other team members can use this person as the first port of call when they're looking for something. A good librarian will also be able to spot impending duplication
isolate the team as a whole from the effects of change. If the user suddenly decides to change database vendors, only the database team should be affected.
People just aren't as repeatable as computers are. Nor should we expect them to be.
There are a wide variety of other metrics you can use to examine code, including: McCabe Cyclomatic Complexity Metric (measures complexity of decision structures) Inheritance fan-in (number of base classes) and fan-out (number of derived modules using this one as a parent)
If you find a module whose metrics are markedly different from all the rest, you need to ask yourself if that is appropriate. For some modules, it may be okay to "blow the curve." But for those that don't have a good excuse, it can indicate potential problems.
Once a human tester finds a bug, it should be the last time a human tester finds that bug. The automated tests should be modified to check for that particular bug from then on, every time, with no exceptions, no matter how trivial, and no matter how much the developer complains and says, "Oh, that will never happen again."
too many comments can be just as bad as too few.
comments should discuss why something is done, its purpose and its goal.
we need to work with them to come to a common understanding of the development process and the final deliverable, along with those expectations they have not yet verbalized.
Try to surprise your users. Not scare them, mind you, but delight them. Give them that little bit more than they were expecting. The extra bit of effort it requires to add some user-oriented feature to the system will pay for itself time and time again in goodwill.
