#10 - It's Both What You Say and the Way You Say It
It's not just what you've got, but also how you package it. Having the best ideas, the finest code, or the most pragmatic thinking is ultimately sterile unless you can communicate with other people. A good idea is an orphan without effective communication.
#11 - DRY—Don't Repeat Yourself
Every piece of knowledge (code, docs, ...) must have a single, unambiguous, authoritative representation within a system.
#12 - Make It Easy to Reuse
if you fail to reuse, you risk duplicating knowledge.
#13 - Eliminate Effects Between Unrelated Things
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.
#14 - There Are No Final Decisions
#15 - Use Tracer Bullets to Find the Target
when you're building something that hasn't been built before. Like the gunners, you're trying to hit a target in the dark. Because your users have never seen a system like this before, their requirements may be vague. Because you may be using algorithms, techniques, languages, or libraries you aren't familiar with, you face a large number of unknowns. And because projects take time to complete, you can pretty much guarantee the environment you're working in will change before you're done..
we're looking for something that gets us from a requirement
to some aspect of the final system quickly, visibly, and repeatably.
It simply is not fully functional. However, once you have achieved an end-to-end connection among the components of your system, you can check how close to the target you are, adjusting if necessary. Once you're on target, adding functionality is easy.
#16 - Prototype to Learn
Prototypes are designed to answer just a few questions, so they are much cheaper and faster to develop than applications that go into production. You can prototype Architecture, New functionality in an existing system, Structure or contents of external data, Third-party tools or components, Performance issues, User interface design.
#17 - Program Close to the Problem domain
By coding at a higher level of abstraction, you are free to concentrate on solving domain problems, and can ignore petty implementation details.
you can invent a mini-language tailored to the application domain that expresses exactly what users want:
// this is my example:
if userA.balance >= transferAmount {
tx.transfer(balance, toUserB)
} else {
print "Fill your balance"
}
This language need not be executable. Initially, it could be simply a way of capturing the user's requirements, a specification..
#18 - Estimate to Avoid Surprises
Quick! How long will it take to send War and Peace over a 56k modem line? How much disk space will you need for a million names and addresses? How long does a 1,000-byte block take to pass through a router? How many months will it take to deliver your project
#19 - Iterate the Schedule with the Code
So you complete the coding and testing of the initial functionality and mark this as the end of the first increment. Based on that experience, you can refine your initial guess on the
number of iterations and what can be included in each. The refinement gets better and better each time, and confidence in the schedule grows along with it
Top comments (0)