1, care about your skills
Care About Your Craft
Other things are meaningless unless you can't develop software in a beautiful development.
2, think! Your work
Think! About Your Work
Think about what you are doing when you do something. Thinking uninterrupted, criticizing your work in real time. This will occupy some of your valuable time, and reward is more active to participate in your favorite work, feeling that you have a variety of themes that have increased in the scope and is happy than feeling ongoing progress. In the long run, your investment will become more efficient as you and your team, write more easily maintained code and rendering of meeting time.
3. Provide a variety of options, don't find the excuse of the feet
Provide Options, Don't make Lame Excuses
Don't say things can't do; to explain what you can do to save the situation. Don't be afraid to ask questions, don't be afraid to admit that you need help.
4, don't tolerate the window
Don't live with broker window
Don't stay "broken windows" (bad design, wrong decision, or bad code). Find one to repair one. If there is not enough time to make proper repairs, take some action to prevent further damage and explain the situation under your control.
If you find that your team and the code are very beautiful - write neat, good design, and elegant, you won't want to be the first person who blurred things.
5, change the catalyst
Be a catalyst for change
You can't force people to change. Instead, what might show them to them, and help them participate in the future creation.
Design something you can reasonably require, develop it. Once you have finished, you will give it to everyone, let them be shocked. Then say: "If we increase ... maybe it will be better." Pretending that it is not important. Sit back and wait for them to start if you want to increase your original. It is found that participation is more easier. Let them see the future, you can make them gather around you.
6, remember big picture
Remember The Big Picture
If you catch a frog into the boiling water, it will jump out. However, if you put the frog into the cold water, then slowly heat, the frog will not notice the slow change of the temperature, it will stay in the pot until it is cooked.
Don't be like frogs. Store big picture. It is necessary to continue to observe what happened around, not just what you are doing.
7, make the quality a problem
Make Quality a Requirements Issue
The scope and quality of the system you make should be specified as part of the system needs. Let your users participate in trade-off, know when to stop, provide sufficient software.
8, regular investment in your knowledge asset
Invest Regularly in your knowledge portfolio
Let learning become habits.
Continuous investment is very important. Once you are familiar with a new language or new technology, continue to advance, learn another.
Whether to use these technologies in a project, or put them in your resume, this is not important. The process of learning will expand your thinking so that you expand towards new possibilities and new things. Thinking "Different Pollen" is very important; try to apply what you have learned to your current project. Even if your project does not use this technology, you may also learn from some ideas. For example, familiar with object-oriented, you will write pure C procedures in different ways.
If you can't find an answer yourself, you can find out what people who can find the answer. Don't put the problem there.
9. Critically analyzed what you read and heard
Critically Analyze What You Read and Hear
Don't be used by suppliers, media speculation, or talk around the dogma. To analyze information in accordance with your own opinions and your project.
10, what do you say and you say the same important it's both what you say and the way you say it?
As a developer, we must communicate on many levels. Our time has a large part of it spends on communication, so we need to do it well.
If you can't effectively convey your great ideas to others, these ideas are useless.
Know what you want to say; understand your listener; choose time; choose a style; let the documents are beautiful; let the audience participate; do listeners; Reply to others.
The more effective communication, the more influential.
11, Dry principle - don't repeat your own
DRY - Don't review yourself
Each knowledge in the system must have a single, unambiguous, authority. Different from this is to express the same thing in two or more places. If you change one of them, you must remember to change the other. This is not the problem you can remember, but when you forget the problem.
12, let multiplexes become easy
Make it Easy to Reuse
What you have to do is creating an environment, in which you have to find and have an existing thing, it is easier than you write. If the multiplex is easy, people will be reused. And if you don't reuse, you will have a risk of repeating knowledge.
13. Eliminate the impact of unrelated things
Eliminate Effects Between Unrelated Things
We want to design a self-contained component: independent, single, and good definition purpose. If the component is isolated from each other, you know that you can change one without worrying about the rest of the components. As long as you don't change the external interface of the component, you can rest assured: You will not cause the issue of the entire system.
You get two main benefits: increasing productivity and reducing risk.
14, there is no final decision
There is no final decision
Nothing will never change - and if you rely on a certain fact, you can almost determine that it will change. Demand, use, and hardware becomes faster than the speed of our development software. With Dry principles, decoupling, and metadata, we don't have to make many critical, irreversible decisions. There are many people who will try to keep the flexibility of the code, and you also need to consider the flexibility in the fields of sustaining, deployment and supplier integration.
15, find the target with traction
Use tracer bullets to find the target
Tragers can pass all kinds of things and check how far they are going to make you track goals.
The tracer code contains a complete error check, structure, document, and self-examination of any product code. It is only a function of functionality. However, once you realize end-to-to-end connection between components of the system, you can check how far you go to the target, and adjust it if necessary. Once you are fully aiming, the increase in functions will be an easy task.
16, make prototypes for learning
Prototype to Learn
Anything with risks. Things that have not been tried before, or things that are extremely critical to the final system. Anything that has not been proven, experimental, or doubt. Anything that makes you feel uncomfortable. Can be studied by making prototypes. For example: architecture; new features in the existing system; structure or content of external data; third-party tools or components; performance issues; user interface design, etc.
Prototype production is a learning experience, and its value is not the code produced, but the lessons learned.
17, approaching the problem area programming
Program close to the problem domain
The computer language affects your way of thinking, and how you look at the way. Design and encode your user's language.
18, estimate to avoid accidents
Estimate to Avoid Surprises is estimated before starting. You will find a potential problem in advance.
1) To select the unit that reflects the accuracy you want to convey;
2) Basic estimation: to ask people who have already done this matter;
3) understand the content of the question;
4) According to the understanding of the problem, establish a rough, ready-to-think skeleton;
5) Decompose the model into components to find mathematical rules that describe how to interact with these components, determine the parameters of each component;
6) Give each parameter to find out which parameters have the greatest impact on the results and is committed to allowing them to be substantially correct;
7) Multiple calculations, change the value of the key parameters, and then express your answer according to those parameters;
8) When it is asked to estimate: "I will answer you".
19. Iterations through the code
Itereate the schedule with the code
Implement incremental development. Track your estimation ability, refine the number of iterations, and the conjecture that can contain content in each iteration. Refining will become better than once, the confidence of the progress table will also grow. You will give the management department to the most accurate progress estimation you can.
20, save knowledge with plain text
Keep Knowledge in plain text
When it is guaranteed;
Leverage: Each tool can operate on plain text;
It is easier to test;
You need to make sure all parties can communicate using public standards. Pure text is that standard.
21, use the power of the command shell
Use the power of command shells
The GUI environment is usually limited to their designers want to provide. When you want to quickly integrate some commands to complete a query or some other task, the command line is more appropriate. Use your command shell, you will be surprised that it can improve your productivity.
22, use a good editor
Use a single editor Well
Choose an editor, completely understand it, and use it for all editing tasks. If you use an editor for all text editing activities, you don't have to stop thinking about how to complete the text manipulation: The necessary keys will become a response. The editor will be the extension of your hands; the key will sing when you slip the text and thought. This is our goal.
23, always use source control
Always Use Source Code Control
always. Even if your team is only you alone, your project is only one week; make sure everything is under source control.
Source Clear Control is your work machine - you can return to the past.
It has a large, concealed benefit of putting the entire project in the protection of the source control system: You can build automated and repeatable product builds.
24, to correct the problem, not to send a blame
FIX THE PROBLEM, NOT THE BLAME
To accept the fact: debugging is to solve the problem, to initiate attack accordingly. BUG is your fault or someone else's fault, is not really true. It is still your problem.
25, don't panic
Don't Panic
Do a deep breathing, think about what may be bug.
It is always trying to find the root cause of the problem, not just a specific performance of the problem;
Collect all relevant data;
The best way to start amending the bug is to make it reproduce;
Make your data visualization;
Tracking: Observation procedure or data structure is time varying;
A very simple reason for finding the problem, but special useful technology is to explain it to others. You just explain what you want to do step by step, you often let the questions jump out from the screen and announce your existence.
26, "SELECT" no problem "SELECT" isn't broker
BUG may exist in the OS, compiler, or third-party products - but this should not be your first idea. It is much more likely that bugs exist in application code being developed. Compared with the assumption library itself, it is assumed that the application code is incorrect to the library is usually more beneficial. Even if the problem does pay a third party, you must first eliminate the bug in your code before submitting the BUG report.
27, don't assume, to prove
Don't Assume IT - Prove IT
Don't let go of routines or code that is implicated with bugs because you "know" it works. Prove it. In practical environments - using real data and boundary conditions - prove your assumption.
28, learn a text operation language
Learn a Text Manipulation Language
You use a large part of the time every day to handle the text, why not let your computer complete some work for you?
Application example:
Database SCHEMA maintenance;
Java, C # Properties (Property) Access;
Test data generation.
29, write code that can write code
Write Code That Writes Code
Code generators can improve your productivity and help to avoid repetition.
30, you can't write perfect software
You can't Write Perfect Software
This is stabing you? No. Take it as a loose axiom, accept it, hug it, celebrate it. Because the perfect software does not exist. In a short history of computer, no one has written a perfect software. You are also unlikely to be the first. Unless you accept this as a fact, you will eventually waste time and energy in the dream of chasing impossible.
31, design through contract
Design with contracts
What is the correct program? There are not many, doing the procedures for what it wants to do. This document is recorded in the document and checks the core of the contract design (referred to as DBC).
Here, emphasizing the focus is on "lazy" code: the things that are accepted before the start, and the things that will be returned as little as possible.
The biggest benefit of using DBC may be that it is forcing the needs of demand and guarantee to come to the front desk. Simply list the range of input fields when designing, the boundary condition is, the routine is promised to deliver something - or, more importantly, it does not deliver what is delivered - a leap to write better software. If you have made these matters, you will return to coincidence programming, which is where many projects begin, end, and failure.
32, early collapse
Crash Early
The dead program is not lying.
When your code finds that something that is considered impossible, your program no longer has survival. From then on, anything it does become suspicious, so I will stop it as soon as possible. The hazards caused by the dead program are usually much smaller than if there is a problem.
33. If it can't happen, use assert to ensure that it will not happen
IT can't happen, use assertions to ensure That Won't
Ascertain to verify the various assumptions. In an uncertain world, protect your code with assertions.
Do not use asserts to replace the true error handling. As an assertion is something that should never happen.
34, will use abnormal problems
Use Exceptions for Exceptional Problems
An abnormally represents even, non-local control transfer - this is a cascading GOTO. An exception should be retained to an accident. Those processes that use exceptions as part of their normal processing will suffer from all readability and maintainability issues. These programs have destroyed the package: through exception handling, routines and their calvles are more closely coupled together.
35, there must be the end
Finish What You Start As long as possible, the routines or objects assigned a certain resource should also be responsible for the release of its assignment.
36, minimal coupling between the modules
Minimize Coupling Between Modules
Write the code of "shame";
The DEMETER rule stipulates that any method of an object should only call the following cases:
1) It itself;
2) Any parameters incurred in the method;
3) Any object it created;
4) Any component object directly holding.
Physical decoupling.
37. To configure, don't integrate
Configure, don't integrate
Details will mess with our neat code - especially if they often change. Put them out of the code. When we lies in it, we can make our code highly configurable and "soft and" - That is, it is easy to adapt.
To describe the application of the application with metadata: Tuning parameters, user preference, installation directory, and more.
38, put abstract put into code, detail to metadata
Put Abstractions in Code, Details in metadata
But we don't just want to use metadata for simple preferences. We want to use metadata configuration and drive applications as much as possible. Our goal is to think in declaration (what is going to do, not what to do), and create a highly flexible and adaptive application. We do this by adopting a general criterion: preparing the procedures for the general situation, putting the specific situation elsewhere - outside the compiled code base.
Maybe you are writing a system with a terrible workflow demand. The action will start and stop according to the complex (and varied) business rules. Consider coding them in a rule-based system (ie, an expert system) and embedded in your application. In this way, you will configure it by writing rules, not modifying the code.
39. Analyze the workflow to improve concurrency
Analyze Workflow To Improve Concurrency
Time is a commonly overlooked aspect of the software architecture. There are two aspects of time. It is important to us: concurrency (things happen at the same time) and the order (the relative position in time).
When we write programs, we usually don't put these two aspects in your heart. When people initially sit down and start designing the architecture, or when writing code, things are often linear. That is the way most people think - always do this first, then do that. However, this thinking will lead time coupling: Method A must always call before the method B; can only run a report; before receiving the button, you have to wait for the screen to redraw. "嘀" must happen before "".
This kind of method is not so flexible, nor is it true.
We need to allow concurrency and consider the depends on any time or order.
40, design with services
Design Using SERVICES
In fact, we create is not a component, but a service-located independent, concurrent object after a well-defined, consistent interface.
By constizing your system architecture, you can make configurations become dynamic.
41, always design for concurrent
Always Design for Concurrency
First, it is necessary to protect any global or static variables, which is free from concurrent access, and now maybe ask yourself, why do you first need a global variable? In addition, regardless of the order of the call, you need to make sure you give the consistent status information.
When called, the object must always be in a valid state, and they may be called when the most embarrassment. You must ensure that the object is in a valid state at any time that may be called. This problem often appears in a class defined in the constructor and the initialization routine (the constructor does not enable the object into the initialized state). Once you have designed an architecture with concurrent factors, you can flexibly handle the deployment of your application: stand-alone, customer-server, or N layer.
42, separation of views and models
Separate Views from Models
That is, Model-View-Controller, is also often said.
model. A abstract data model representing the target object. The model has no direct understanding of any view or controller.
view. Interpretation of the model. It subscribes to changes in the model and logical events from the controller.
Controller. Control view and provide new data to the model.
By loosening the coupling between the model and the view / controller, you have exchanged many flexibility for yourself with a low price.
43, coordinate workflow with blackboard
Use blackboards to coordinate Workflow
Coordinate with blackboards completely different factors and factors, while maintaining individual participants independently and isolated.
Modern distributed blackboard (Blackboard-like), such as Javaspaces and T Spaces.
44, don't deal with coincidence
Don't Program by Coincide
I always realize what you are doing.
Do not blindly program. Trying to build the app that you don't fully understand, or using the technique you are not familiar with, you will hope that you have been misleading.
Affairs in accordance with the plan.
Relying on reliable things. If you can't say the difference between a variety of specific circumstances, it is assumed to be the worst.
Establish a document for your assumption. "Programming by contract" helps clarify the assumption in your mind and help to convey them to others.
Don't just test your code, but also test your assumption.
Divided the priority for your work.
Don't do historical efforts. Don't let the existing code dominate the future code.
So next time there is something to work, but you don't know why, to make sure it is not coincident.
45, estimate your algorithm level
Estimate the Order of Your Algorithms
Before you write the code, you will take a moment to estimate how long it takes.
46, test your estimation
Test Your Estimates
Mathematical analysis of the algorithm does not tell you everything. The speed was measured in the target environment of your code.
47, early reconstruction, often reconstructed
Refactor Early, Refactor Off
Rewrite, redo and reform the code when needed. To eradicate the root of the problem. Don't tolerate the windows.
For the reconstruction, see the book of "Reconstruction" of Martin Fowler for details.
48, design for testing
Design to Test
Start thinking about test problems when you have not written code. Test driver development?
49. Test your software, otherwise your user has to test
Test Your Software, Or Your Users Will
Test is technology, but it is cultural. A little pre-preparation can greatly reduce maintenance costs and reduce customer service phones.
50, don't use the widespread code you don't understand
Don't use wizard code you don't understand
The wizard is very strong. Just click on a button to answer some simple questions, the wizard will automatically generate the skeleton code for you. But if you use the wizard, you don't understand all the code it produced, you can't control your own application. You have no ability to maintain it, and it will encounter great difficulties when debugging.
51, don't collect demand - excavate them
Don't Gather Requirements - Dig for them
Demand is rarely existing on the surface. They are deeply buried below the layer assumption, misunderstanding, and political means. 52, work with users to think like users
Work with a user to think like a user
To understand how the system is actually used, this is the best way. The process of mining needs is also to establish a harmonious relationship with the user group to understand the issue and hope they are building the system you are building.
53, abstract than detail live longer
Abstractions Live Longer Than Details
"Investment" is abstract, not real. Abstract can survive under "attack" from different implementation and new technologies.
54, use project vocabulary
Use a project Glossary
If users and developers are alleged with different names, or worse, with the same name to align different things, such a project is difficult to succeed.
55, don't think out outside the box - to find the box
Don't think Outside the box - Find the box
Ask yourself the following questions when you encounter an impossible problem:
Is there a easier way?
Are you trying to solve the true problem, or transfer your attention by the external technical problems?
Why is this matter a problem?
What makes it hard to solve?
Does it do in this way?
Do you really have to complete?
Many times, when you try to answer these questions, you will have a surprising discovery. Many times, reinterpret the demand will make all the problems disappear.
What you need is just true constraints, misunderstanding, and distinguish between their wisdom.
56, listen to repeated doubts - waiting for you to get ready again
Listen to Nagning Doubs - Start When You're Ready
Your life is accumulating experience and wisdom. When you face a task, if you feel doubts, or experience some kind of reluctance, pay attention to it. You may not be able to accurately point out the problem, but give it time, your doubts are likely to be crystallized into a more solid thing, some kind of thing you can handle. Software development is still not scientific. Let your intuition contribute to your performance.
57, "do" better "" description "for some things
Some Things Are Better Done Than Described
You should tend to collect demand, design, and implementation as the same process - Different aspects of delivery of high quality systems. Don't fell into the specification spiral, at a moment, you need to start coding.
58, do not do slaves of form methods
Don't be a slave to formal methods
If you don't put a technology into your development practice and ability, don't blindly use it.
59. Expensive tools do not necessarily produce better design
Expensive Tools Do Not Produce Better Designs
Careful suppliers' hype, industry dogma, and temptation of price tags. Try not to consider how much money is taken into account in the output of the tool.
60, around the function, not working positions
Organize Around FunctionAlity, Not Job Functions
Divide your people into a small team, respectively responsible for the specific aspects of the final system. Let the team organize internally according to their personal skills.
However, this approach is only valid when the project has a responsible developer and a powerful project management. It is a catastrophic prescription to create a group of self-circulation.
Remember, the team is composed of individuals. Let each member will shine in their own way.
61, do not use manual flow
Don't Use Manual Procedures
The shell script or batch file will perform the same order in the same order again and again. We can automatically arrange backup, night build, website maintenance, and anything else can be done without people. Let your computer do repetition, imperfect things - it will do better than us. We have more important, more difficult things to do. 62, early test, normal test, automatic test.
Test Early.Test OFTEN.TEST Automatically.
Compared with the test plan staying on the bookshelf, the test runs more time.
63. To wait until all tests, coding is completed
Coding ain't done 'til all the tests run
That's it.
64, test your test through "deliberate destruction"
Use saboteurs to test your testing
In a separate software copy, it is deliberately leading BUG to check them.
65, the test state is covered, not the code coverage
Test State Coverage, Not Code coverage
Determine and test important procedures. Just testing the code line is not enough. Instant code coverage, the data you use to test will still have a huge impact, and more importantly, the impact of the order of the code you may be the biggest.
66, a BUG only grabs it once
Find Bugs ONCE
Once the tester finds a bug, this should be the last time the tester finds it. Since then, the automatic test should be checked.
67, regard English as another programming language
Treat English As Just Another Programming Language
Write a document like you write code: Follow DRY principles, use metadata, MVC, automatic generation, and so on.
68, build a document inside, don't squat outside
Build Documentation in, Don't Bolt It on
Documents separated from code is unlikely to be corrected and updated. Using tools like Javadoc and Ndoc, we can generate API documents based on the source code.
Documents and code are different views of the same underlying model, but the view is the only thing that should be different.
69, moderately exceed the expectation of users
Gently Exceed Your Users' Expections
To try to make your users surprised. Please note that it is not frightening them, but to make them happy. To understand the expectations of the user, then give them more things. Adding a little additional effort to the system to provide a user-oriented feature will return again and again.
70, signing on your work
Sign Your Work
We want to see pride of ownership. "This is what I have written, I am responsible for my work." Your signature should be considered quality assurance. When people see your name on a code, it should be expected that it is reliable, written, tested, and documents, a real professional work, written by the real professionals.
A programmer who pays attention to effectiveness.
