Your knowledge portfolio
1. Serious investiors invest regularly, as a habit.
2. Diversification is the key to long-term success.
3. Smart investors balance their portfolios between conservative and high-risk, high-reward investments.
4. Investors try to buy low and sell high for maximum return.
5. Portfolio should be reviewd and rebalanced periodically.
Some suggestions to fund your portfolio
1. Learn at least one new language every year.
2. Read a technical book each quarter.
3. Read nontechnical books, too.
4. Take classes.
5. Participate in local user groups.
6. Experience with different environments.
7. Stay current.
8. Get wired.
Critically thinking what you read and hear.
1. Start reading a new book (but finish this one first). If you are doing very detailed implementation and coding, read a book on design and architecture. If you are doing high-level design, read a book and coding techniques.
2. Get out and talk technology with people who aren’t involved in your current project, or who don’t work for the same company. Network in your company cafeteria, or maybe seek out fellow enthusiasts at a local user’s group meeting.
A good idea is an orphan without effective communication.
How to do it well to communicate?
1. Know what you want to say. Jot down the ideas you want to communicate, and plan a couple of strategies for getting them across.
2. Know your audience. What do you want them to learn? What is their interest in what you’ve got to say? How sophisticated are they? How much deatil do they want? Whom do you want to own the information? How cany motivate them to listen to you?
3. Choose your moment. Make what you’re saying relevant in itme, as well as in content.
4. Choose a style. Adjust the style of your delivery to suit your audience.
5. Make it look good. Your ideas are important. They deserve a good-looking vehicle to convey them to your audience.
6. Involve your audience. If possible, involve your audience with early drafts of your document.
7. Be a listener. Encourage people to talk by asking questions, or have them summarize what you tell them. Turn the meeting into a dialog, and you’ll make your point more effectively.
8. Get back to people.
Orthogonality
What is Orthogonality?
In computer, the term has come to signify a kind of independence or decoupling. Two or more things are orthogonal if changes in one do not affect any of others.
How to maintain the orthogonality?
1. Keep your code decoupled. Write shy code-modules that don’t reveal anything unnecessary to other modules and that don’t rely on other modules’ implementation.
2. Avoid global data.
3. Avoid similar function. Duplicate code is a symptom of structural problems. Strategy Pattern.
Reversibility
The mistake lies in assuming that any decision is cast into the stone, and in not preparing for the contingencies that might arise. Instead of carving in stone, think of them more as being written in the sand at the beach. A big wave can come along and wipe them out at any time.
Prototype
Things to prototype: anything unproven, unexperimental or doubtful. Anything you aren’t comfortable with.
1. Architecture
2. New functionality in existing system
3. Structure or contents of external data
4. Third-party tools or components
5. Performance issues
6. User interface design
When building a prototype, the details you can ignore: correctness, completeness, robustness, style.
When prototyping an architecture, you should answer these questions.
1. Are the responsibilities of the major components well defined and appropriate?
2. Are the collaborations between major components well defined?
3. Is coupling minimized?
4. Can you identify potential sources of duplication?
5. Are interface definition and constraints acceptable?
6. Does every module have an access path to the data it needs during execution? Does it has that when it needs it?
Debugging
Psychology of debugging:
Fix the problem, not the blame.
Don’t panic.
Always try to discover the root cause of the problem, not just this particular appearance of it.
Before you start to look at the bug, make sure you are working on code that compiled cleanly.
You may need to interview the user who reported the bug in order to gather more data than you were initially given.
Artificial test don’t exercise enough of an application, you must brutally test both boundary conditions and realistic end-user usage patterns. You need to do this systematically.
“Select is broken”, as a gentle reminder whenever one of us starts blaming the system for a fault that is likely to be our own.
Die programs tell no lies
Crash, don’t trash.
Crash early.
When your code discovers that something that was supposed to be impossible just happened, your program is no long viable. Anything it does from this point forward becomes suspect, so terminate it as soon as possible. A dead program normally does a lot less damage than a crippled one.
Assertive programming
If it can’t happen, use assertion to ensure that it won’t.
When to use exception
Ask yourself, “Will this code run if I remove all the exception handlers?” If the answer is no, then may be exceptions are being used in nonexceptional circumstances.
How to balance resources
Whoever allocates a resource should be responsible for deallocating it.
When you can’t balance resources
There are three options in the problem that who is responsible for data in an aggregated data structure.
1. The top-level structure is also responsible for freeing any substructures that it contains. These structures then recursively delete data structure they contain, and so on.
2. The top-level structure is simply deallocated. Any structure that it pointed to are orphaned.
3. The top-level structures refuse to deallocate itself if it contains any substructures.
The Law of Demeter for Functions
The Law of Demeter for functions states that any method of an object should call only methods belonging to itself, any parameters that were passed in to the method, any objects it created, any directly held component objects.
The communication among the different modules
event model
publish/subscribe protocol
If we are interest in certain events generated by a Publisher, all we have to do is register ourselves. The publisher keeps track of all interested Subscriber object; when the publisher generates an event of interest, it will call each subscriber in turn and notify them that the event has occurred.
How to program deliberately
1. Always be aware what you are doing.
2. Don’t code blindfolded. Attempting to build an application you don’t fully understand, or to use a technology you aren’t familiar with, is an invitation to be misled by coincidence.
3. Process from the plan, whether that plan is in your head, on the back of cocktail napkin, or on a wall-sized printout from a CASE tool.
4. Rely on reliable things. Don’t depend on accidents or assumptions. If you can’t tell the differences in particular circumstances, assume the worst.
5. Document your assumptions. Design By Contract, can help you clarify your assumption in your mind, as well as help communicate to others.
6. Don’t just test your code, but test your assumptions as well.
7. Prioritize your effort. Spending time on the important aspects.
8. Don’t be slave to history. Don’t let existing code dictate the future code.
Refactoring
Any number of things may cause code to qualify for refactor.
1. Duplicated
2. Nonorthogonal design
3. Outdated knowledge
4. Performance
Refactor early, refactor ofen.
How to refactor?
1. Don’t try to refactor and add functionality at the same time.
2. Make sure you have good tests before you begin refactoring. Run the tests as soon as possible. That way you will know quickly if your changes have broken anything.
3. Take short, deliberate steps: move a field from one class to another, fuse two similar methods to superclass. Refactoring often involves many localized changes that result in a large-scale change. If you keep your step small, and test after each step, you will avoid prolonged debugging.
So next time you see a piece of code that isn’t quite as it should be, fix both it and everything that depends on it. Manage the pain: if it hurts now, but is going to hurt even more later, you might as well get it over with. Don’t live with broken windows.
Don’t gather requirement, but dig for them.
It’s important to discover the underlying reason why users do a particular thing, rather than just the way they currently do it. At the end of the day, you development has to solve their business problem, not just meet their stated requirements. Documenting the reasons behind requirements will give your team invaluable information when making daily implementation decisions.
Work with a user to think like a user.
Overspecifying
A big danger in producing a requirements document is being to specific. Good requirements documents remain abstract. Where requirements are concerned, the simplest statement that accurately reflects the business need is best.
Abstractions live longer than details.
Many projects failures are blamed on an increase in scope.
The key to managing growth of requirements is to point out each new feature’s impact on the schedule to the project sponsors.
Maintain a project glossary.
Solving impossible puzzling
Don’t think outside the box, find the box.
When faced with an intractable problem, enumerate all the possible avenues you have before you. Don’t dismiss anything, no matter how unusable or stupid it sounds. Now go through the list and explain why a certain path cannot be taken.
Sometimes you will find yourself working on a problem that seems much harder than you thought it should be. That is when you step back a pace and ask yourself these questions.
1. Is there an easier way?
2. Are you trying to solve the right problem, or have you been distracted by a peripheral technicality?
3. What is it that’s making it so hard to solve?
4. Does it have to be done this way?
5. Does it have to be done at all?
Exhaustive search 穷举搜索
Speech recognition 语音识别
Knowledge-based reasoning system 基于知识的推理系统
The traveling salesman problem
Optimally packing things into a container
Get in the way 妨碍
> 我来回应