Focus on the practical programmer (The Pragmatic Programmer) recommended a good book "The Pragmatic Programmer - from Journeyman To Master"
1. Caring for your skills Care About your craft unless you carefully develop software, other things are meaningless.
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, do not find the excuses of the foot, don't make things can't be said; if you want to do what you can save. Don't be afraid to ask questions, don't be afraid to admit that you need help.
4, don't tolerate the windows don't live with broker windows 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. Changes of catalysts be a catalyst for change You cannot forced 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 the big picture Remember The Big Picture If you grab 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 as a requirement problem Make Quality a Requirements Issue The range and quality of your system should be specified as part of the system requirements. Let your users participate in trade-off, know when to stop, provide sufficient software.
8. Regularly invest in Invest Regularly in your Knowledge Portfolio for your knowledge asset
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 the Critically Analyze What you read and hear you hear should not be supplied to the supplier, media hype, or 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 n't review yourself system must have a single, unambiguous, authoritative representation. 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 to make it it easy to reuse You have to create an environment, in which you have to find and reuse existing things, 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 effects of unrelated things Eliminate Effects Between Unrelated Things We want to design a self-contained component: independent, single, 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 nothing that is never changed - 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 using traction Use TargeTra Bullets to Find The Target traction can make you track goals through experiments. 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. For learning, it makes the prototype Prototype to Learn any risk with risk. 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. Programming from the Problem Probram Close to the Problem Domain 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 estimating before the accidents of Estimate To Avoid Surprises will be estimated before they start. 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 thing; 3) understand the content; 4) Establish a rough The ready-to-model skeleton; 5) Decompose the model into components to find mathematical rules describing how to interact with these components, determine the parameters of each component; 6) Specify values for each parameter, find out which parameters on the results The biggest, and committed to the roughly correct; 7) Multiple calculations, change the value of key parameters, and then express your answer according to those parameters; 8) When it is asked to estimate: "I will wait for you" .
19. Its Iterative Iterate The Schedule with The Code is implemented by the code. 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; the leverage effect: Every tool can be operated on plain text; it is easier to test; you need to ensure that all parties can communicate using public standards. Pure text is that standard.
21. Using the power of the command shell Use the Power of Command shells 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 to select 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 the source code to 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 blame the Fix The Problem, NOT The Blame To accept the fact: debugging is to solve the problem, to initiate attack. 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 to do a deep breathing, think about what may be bug.
To always try to find the root of the problem, not just a specific performance; collect all related data; the best way to start amending bug is to make it reproduce; make your data visual; track: observation procedure or data structure Although the state changes; 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 bugs 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 get routine 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 your daily time to handle 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. Writing the code that Write Code That Writes Code Code generator can improve your productivity and help to avoid repetition.
30. You can't write the perfect software you can n't write perfect software, this is stinging 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 by 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 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 does not occur if it can't happen, use assertions to ensure That Won't assert that verify your 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. Problem for exceptions Use Exceptions for Exceptional Problems Anomaly 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. If you have the final Finish What You Start as long as you may, the routines or objects assigned a resource should also be responsible for the release of it.
36. Reduce the coupling between the modules to minimum minimize coupling between modules
Write the code of "shame" code; the DEMETER rule stipulates that any method of an object should only call the following scenario: 1) It itself; 2) any parameters of the method; 3) It creates any objects; 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 the abstraction into the code, detail placed in 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 concurrent 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. Designing Design Using Services actually created 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 designing Always Design for Concurrency first, you must protect any global or static variables, making it free from concurrent access, now you may 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, separating the view with the model Separate views from models is also often the MVC mode (Model-View-Controller).
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. Coordination with blackboards Use Blackboards to coordinate Workflow coordinate 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 rely on coincidence programming don't Program by COINCIDENCE
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. Estimating your algorithm steps Estimate the Order of Your Algorithms takes more time before you write code.
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 refactoring Refactor Early, refactor offen rewrites, 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 Design to Test when you have not written code yet. 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 more cultural. A little pre-preparation can greatly reduce maintenance costs and reduce customer service phones.
50. Don't use the wizard code you don't understand Don't Use Wizard Code You Don't Understand Wizard. 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, do not collect demand - excavate their Don't Gather Requirements - Dig for Them requires less existing on the surface. They are deeply buried below the layer assumption, misunderstanding, and political means.
52. Working with the user to think about Work with a user to think sowith to understand how the system is actually used, which 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" in abstraction, not real. Abstract can survive under "attack" from different implementation and new technologies.
54. Using project vocabulary Use a project Glossary If users and developers use different names to align the same thing, or worse, use 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 When you encounter a unlike problem, ask yourself the following questions:
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. Listening repeated doubts - waiting for you to start listen to nagging doubts - Start when'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. For some things "do" better than "Description" Some Things Are Better Done Than Described, you should tend to seize, design, and implement the same procedure - Different aspects of delivery of high quality systems. Don't fell into the specification spiral, at a moment, you need to start coding.
58. Don't do the slave's Don't Be a slave to formal methods if you don't put a technology into your development practical and capabilities, don't blindly use it.
59. Expensive tools do not necessarily produce better design Expensive Tools Do Not Product Baetter Designs CAUTION Suppliers' hype, industry dogma, and pricing tag temptation. Try not to consider how much money is taken into account in the output of the tool.
60. Around the feature, not working positions Organize Around FunctionAlity, Not Job Functions divides 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 the manual process Don't Use Manual procedures shell script or batch file to perform the same instructions 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 offen.test automatically. Compared to the test plan on the bookshelf, the test running during each construction is much more effective. 63. To wait until all tests, coding is completed, Coding Ain't Done 'Til All The Tests Run is like this.
64. Test your test by "deliberate destruction". Use Saboteurs To Test Your Testing deliberately leaders in a separate software copy to verify them.
65. Test status coverage, not code override Test State Coverage, Not Code Coverage to determine and test important program status. 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 a 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. Write the English as another programming language Treat English as Just Another Programming Language write a document like you write code: Comply with Dry principles, use metadata, MVC, automatic generation, and so on.
68. Built the document inside, don't squat outside Build Documentation in, Don't Bolt It On and the code separated document 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. Gently beyond the user's expectation GENTLY EXCEED YOURS 'Expections To try to surprise your users. 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.
