The pragmatic programmer)

The pragmatic programmer)
The pragmatic programmer-from journeyman to master

1. care about your skills
Care about your craft
Unless you care about developing software beautifully, other things are meaningless.

2. Think! Your job
Think! About your work
Think about what you are doing when you do something. Keep thinking and criticize your work in real time. This will take up some of your precious time. The reward is to participate more actively in your favorite work, feel yourself in the various topics that are gaining control, and be happy with your continued progress. In the long run, your time investment will be rewarded as you and your team become more efficient, compile code that is easier to maintain, and reduce the meeting time.

3. Provide a variety of options and do not make excuses.
Provide options, don't make lame excuses
Do not say that things cannot be done; explain what can be done to save the situation. Do not be afraid to make requests or admit that you need help.

4. Do not tolerate broken windows
Don't live with broken windows
Do not keep the "broken windows" (poor design, wrong decisions, or bad code. If one is found, it will be repaired. If you do not have enough time to make proper repairs, take some action to prevent further damages and indicate that the situation is under your control.
If you find that the code for your team and project is pretty-well-written, well-designed, and elegant, you don't want to be the first person to get dirty.

5. catalyst for change
Be a catalyst for change
You cannot force people to change. Instead, we need to show them what the future may be and help them participate in the creation of the future.
Design things that you can reasonably ask for and develop them well. Once completed, I will show it to you and surprise them. And said, "It would be better if we add ." Pretend that is not important. Sit back in the chair and wait for them to start asking you to add the functions you originally wanted. People found that it was easier to participate in the ongoing success. Let them see the future, and you will let them gather around you.

6. Remember the big picture
Remember the big picture
If you hold a frog and put it in boiling water, it will jump out. However, if you put the frog in the cold water and then slowly heat it, the frog will not notice the slow changes in the temperature and will stay in the pot until it is cooked.
Don't be like a frog. Pay attention to the big picture. Constantly observe what is happening around you, not just what you are doing.

7. Make quality a requirement
Make quality a requirements issue
The scope and quality of your system should be defined as part of the system requirements. Let your users participate in the trade-offs, know when to stop, and provide enough software.

8. Invest in your knowledge assets on a regular basis
Invest regularly in your knowledge portfolio

Make learning a habit.
Continuous investment is very important. Once you are familiar with a new language or technology, move on and learn another one.
It doesn't matter whether you use these technologies in a project or put them into your resume. The learning process will expand your thinking, so that you can expand towards new possibilities and new ways of doing things. The "cross-flower pollination" of thinking 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 be able to learn from some ideas. For example, if you are familiar with object-oriented programming, you will write pure C Programs in different ways.
If you cannot find the answer, you can find the person who can find the answer. Do not leave the problem there.

9. Critically analyze what you read and hear
Critically analyze what you read and hear
Do not be hyped by suppliers or the media, or be around the topic. You need to analyze the information based on your own opinions and the situation of your project.

10. What you say is as important as what you say
It's both what you say and the way you say it

As developers, we must communicate at many levels. Most of our time is spent on communication, so we need to do it well.
These ideas are useless if you cannot effectively convey your amazing ideas to others.
Know what you want to say; Understand your audience; select the time; select the style; make the document beautiful; let the audience participate; be the listener; reply to others.
The more effective the communication, the more influential you are.

11. Dry principle-do not repeat yourself
Dry-Don't repeat yourself
Every piece of knowledge in the system must have a single, unambiguous, and authoritative representation. The difference is to express the same thing in two or more places. If you change one of them, you must remember to change other places. This is not a question you can remember, but a question you forget.

12. Make reuse easier
Make it easy to reuse
What you need to do is to create an environment where you need to find and reuse existing things, which is easier than writing them yourself. If it is easy to reuse, people will reuse it. Without reuse, you may have the risk of repeated knowledge.

13. Eliminate the influence between irrelevant things
Eliminate effects between unrelated things
We want to design self-contained components: independent, with a single, well-defined purpose. If components are isolated from each other, you will know that you can change one of them without worrying about other components. As long as you do not change the external interface of the component, you can rest assured that you will not cause problems affecting the entire system.
You get two main benefits: increasing productivity and reducing risks.

14. No final decision exists
There are no final decisions
Nothing remains the same-and if you rely heavily on a fact, you can almost be sure that it will change. Compared with the speed at which we develop software, the requirement, usage, and hardware become faster. With the dry principle, decoupling, and the use of metadata, we do not have to make many critical and irreversible decisions. Many people will try to maintain code flexibility, and you also need to consider maintaining flexibility in the fields of architecture, deployment, and vendor integration.

15. Find the target using a drag-and-drop bullet
Use tracer bullets to find the target
The drag bullet allows you to track targets by experimenting with various things and checking how far they are from the targets.
The drag-and-drop code contains complete error checks, structures, documents, and self-check for any product code. It only has incomplete functions. However, once you establish an end-to-end connection between various components of the system, you can check how far you are from the target, make adjustments as necessary. Once you are fully targeted, adding features will be easy.

16. Create a prototype for learning
Prototype to learn
Anything with risks. Things that have not been tried before, or things that are critical to the final system. Anything unproven, experimental, or questionable. Anything that makes you feel uncomfortable. Both can be researched by making a prototype. For example, architecture, new functions in the existing system, structure or content of external data, third-party tools or components, performance problems, and user interface design.
Prototype creation is a learning experience. Its value lies not in the generated code, but in the lessons learned.

17. Programming in the problem Field
Program close to the problem domain
Computer language affects how you think about problems and how you think about communication. Use your user's language for design and coding.

18. Estimate to avoid accidents
Estimate to avoid surprises
Make an estimation before proceeding. You will find potential problems in advance.
1) Select the unit that reflects the accuracy you want to convey;
2) Basic estimation tips: ask people who have already done this;
3) understand the question content;
4) Establish a rough and ready thinking model skeleton based on the understanding of the problem;
5) break down the model into components, find mathematical rules describing how these components interact, and determine the parameters of each component;
6) specify values for each parameter to find out which parameters have the greatest impact on the results, and strive to make them roughly correct;
7) perform multiple computations, change the value of key parameters, and then express your answers based on those parameters;
8) when asked to make an estimate: "I will answer you later ".

19. iterate the schedule table by code
Iterate the schedule with the code
Implement incremental development. Tracking your estimation capabilities, refining your conjecture about the number of iterations and the content that can be included in each iteration. Refining will become better than once, and confidence in the schedule will also grow. You will give the management department the most accurate progress estimation you can give.

20. Saving knowledge with plain text
Keep knowledge in plain text

Make sure that it is not out of date;
Leverage: Every tool can be operated on plain text;
Easier to test;
You need to ensure that all parties can use public standards for communications. Plain text is the standard.

21. Use shell commands
Use the power of command shells
Gui environments are usually limited by the capabilities they designers want to provide. When you want to quickly combine some commands to complete a query or some other task, the command line is more appropriate. If you use your shell command more, you will be surprised how much productivity it can improve.

22. A good editor
Use a single editor well
Select an editor to thoroughly 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 and think about how to complete text Manipulation: the necessary key-clicks will become an instinctive response. The editor will be an extension of your hands; keys will sing as you slide through text and thoughts. This is our goal.

23. Always use source code control
Always use source code control

Always. Even if your team only has one person, your project takes only one week. Make sure everything is under source code control.
Source code control is the machine of your work time-you can go back to the past.
Putting the entire project under the protection of the source code control system has a great hidden benefit: You can perform automatic and repeatable product building.

24. correct the problem instead of making a complaint.
Fix the problem, not the blame
Accept the facts: debugging is to solve the problem and initiate an attack accordingly. The bug is your fault or someone else's fault. It is not really relevant. It is still your problem.

25. Don't panic
Don't panic
Take a deep breath and think about the possible causes of bugs.

Always try to find out the root cause of the problem, not just the specific manifestation of the problem;
Collect all relevant data;
The best way to start fixing bugs is to reproduce them;
Visualize Your data;
Tracking: Observe the time-varying state of the program or data structure;
A very simple, but extremely useful technique for finding the cause of a problem is to explain it to others. You just step by step explain what the code is to do, and often let the problem jump out of the screen to declare your own existence.

26. "select" is correct
"Select" isn' t broken
Bugs may exist in OS, compilers, or third-party products-but this is not your first idea. There is a lot of possibility that bugs exist in the developing application code. Compared with the assumption that the library itself has a problem, it is generally better to assume that the application code is incorrect for the Library call. Even if the problem does belong to a third party, you must eliminate the bug in your code before submitting the bug report.

27. Do not assume that you want to prove it.
Don't assume it-prove it
Don't let away routines or code that are related to bugs because you "know" it can work. Prove it. In the actual environment -- use real data and boundary conditions -- prove your assumptions.

28. Learn a text Operation Language
Learn a text manipulation language
Why don't you let the computer do some work for you if you process text with a large amount of time every day?
Application Example:

Database schema maintenance;
Java, C # Attribute access;
Test data generation.

29. write code that can write code
Write code that writes code
Code generators can increase your productivity and help avoid duplication.

30. You cannot write perfect Software
You can't write perfect Software
Does this hurt you? No. Regard it as the principle of life, accept it, embrace it, and celebrate it. Because the perfect software does not exist. In the brief history of computers, no one has ever written a perfect software. You are unlikely to be the first. Unless you accept this as a fact, you will eventually waste your time and energy on chasing impossible dreams.

31. design through contract
Design with contracts
What is the right program? There are not many programs that declare the things to be done. Using documents to record such statements and verify them is the core of the contract-based design (DBC.
Here, the emphasis is on "lazy" code: be strict with what is accepted before the start, and promise to return as few as possible.
The biggest benefit of using DBC may be that it forces the problem of demand and assurance to come to the front-end. In design, it is simple to list the scope of the input domain, the boundary condition, and what the routine promises to deliver-or, more importantly, it does not promise to deliver anything-a leap towards better software development. If you do not make a statement about these issues, you will return to coincidental programming, where many projects start, end, and fail.

32. Early crash
Crash early
Dead programs do not lie.
When your code finds that something that is considered impossible has already happened, your program will no longer be able to survive. From this point on, everything it does will become suspicious, so it should be terminated as soon as possible. The harm of dead programs is usually much smaller than that of problematic ones.

33. If it cannot happen, Use assertions to ensure it will not happen
If it can't happen, Use assertions to ensure that it won't
Assertions verify your assumptions. Protect your code with assertions in an uncertain world.
Do not use assertions to replace real error handling. Assertion checks should never happen.

34. Apply exceptions to exceptions
Use exceptions for exceptional problems
An exception indicates even non-local control transfer-this is a cascading Goto. Exceptions should be retained to incidents. Programs that use exceptions as part of their normal processing will suffer from all readability and maintainability issues. These programs break the encapsulation: Through Exception Handling, routines and Their callers are tightly coupled.

35. start and end
Finish what you start
As long as possible, the routines or objects allocated to a resource should also be responsible for unallocation.

36. Minimize coupling between modules
Minimize coupling between modules

Write "Shy" code;
The DEMETER law of a function specifies that any method of an object should only call methods in the following situations:
1) itself;
2) input any parameters for this method;
3) any object it creates;
4) any directly held component object.
Physical decoupling.

37. Configuration required, not integration required
Configure, don't integrate
The details will mess up our neat code-especially if they change frequently. Drive them out of code. When we fight against it, we can make our code highly configurable and "soft"-that is, it is easy to adapt to changes.
Use metadata to describe application configuration options: tuning parameters, user preference, installation directory, and so on.

38. Put the abstract into the code and the details into the metadata.
Put into actions in code, details in metadata
However, we don't just want to use metadata for simple preferences. We want to configure and drive applications through metadata as much as possible. Our goal is to think in a declarative manner (specify what to do, rather than how to do it) and create highly flexible and adaptive applications. We do this by using a general principle: write programs for general situations and place the specific situation elsewhere-outside the compiled code library.
Maybe you are writing a system with terrible workflow requirements. Actions start and stop based on complex (and changed) business rules. Consider coding them in a rule-based system (that is, an Expert System) and embedding them into your application. In this way, you will configure it by writing rules instead of modifying code.

39. Analyze workflows to improve concurrency
Analyze workflow to improve concurrency
Time is a often overlooked aspect of software architecture. There are two aspects of time that are very important to us: concurrency (where things happen at the same time) and Order (the relative position of things in time ).
These two aspects are usually not taken into consideration when writing a program. When people first sit down to design the architecture or write code, things are often linear. That is the way most people think-always do this first and then do that. However, this thinking will lead to time Coupling: Method A must always be called before Method B; at the same time, only one report can be run; before receiving the button, you must wait for the screen to be re-painted. "Success" must occur before "tick.
This method is neither so flexible nor practical.
We need to allow concurrency and consider removing any time or order dependency.

40. Design with services
Design Using services
In fact, what we create is not a component, but a service-an independent and concurrent object located after well-defined and consistent interfaces.
By building your system architecture into multiple independent services, you can make the configuration dynamic.

41. Always Design for concurrency
Always Design for concurrency
First, you must protect any global or static variables to avoid concurrent access. Now you may be asking yourself why you need global variables at first. In addition, no matter what the call order is, you must ensure that you provide consistent status information.
When called, objects must always be in a valid state, and they may be called at the most embarrassing time. You must ensure that the object is in a valid State at any time that may be called. This problem often occurs in classes defined separately by the constructor and the initialization routine (the constructor does not bring the object into the initialized State ).
Once you have designed an architecture with concurrent elements, You can flexibly handle Application Deployment Methods: Standalone, client-server, or N-layer.

42. Separate views from Models
Separate views from Models
Model-View-controller ).

Model. The abstract data model of the target object. The model has no direct understanding of any view or controller.
View. Explains the model. It subscribes to changes in the model and logical events from the Controller.
Controller. Control the view and provide new data to the model.
By releasing the coupling between the model and the View/controller, you get a lot of flexibility at a low cost.

43. Use a blackboard to coordinate workflows
Use blackboards to Coordinate workflow
Use the blackboard to coordinate different facts and factors while keeping participants independent and isolated.
Modern Distributed Blackboard-like systems, such as elastic paces and T Spaces.

44. Don't rely on coincidental Programming
Don't program by coincidence

Always realize what you are doing.
Do not program blindly. Trying to build applications that you don't fully understand, or using technologies that you are not familiar with, is to be misled by coincidence.
Act as planned.
Rely on reliable things. If you cannot tell the difference in a specific situation, it is assumed that it is the worst.
Create a document for your assumptions. "Programming by contract" helps clarify the assumptions in your mind and convey them to others.
Do not just test your code, but test your assumptions.
Prioritize your work.
Do not make historical efforts. Do not allow existing code to control future code.
So next time something seems to work, but you don't know why, it's not a coincidence to be sure.

45. Estimate the order of your algorithm
Estimate the order of your algorithms
Before you write the code, estimate how long it will take.

46. Test your estimation
Test your estimates
Mathematical Analysis of Algorithms does not tell you everything. Measure the speed of your code in the target environment.

47. Early Reconstruction and frequent Reconstruction
Refactor early, refactor often
Rewrite, redo, and rebuild the code as needed. We need to eliminate the root cause of the problem. Do not tolerate broken windows.
For details about refactoring, refer to refactoring by Martin Fowler.

48. Designed for testing
Design to test
You can start to think about the test before writing the code. Test-driven development?

49. Test your software. Otherwise, your users must test the software.
Test your software, or your users will
Testing is a technology, but a culture. A little advance preparation can greatly reduce maintenance costs and reduce customer service calls.

50. Do not use wizard code that you do not understand
Don't use wizard code you don't understand
The wizard is amazing. You only need to click a button to answer some simple questions. The Wizard will automatically generate the skeleton code (skeleton Code) for you ). However, if you use a wizard but do not understand all the code it creates, you cannot control your own applications. You are not able to maintain it, and you will encounter great difficulties during debugging.

51. Do not collect requirements-explore them
Don't gather requirements-dig for them
Demand rarely exists on the surface. They are deeply buried under layer-by-layer assumptions, misunderstandings, and political means.

52. Work with users to think like users
Work with a user to think like a user
It is the best way to understand how the system will actually be used. The process of mining needs also begins to establish a harmonious relationship with the user group and understand their expectations and hopes for the system you are building.

53. abstraction lasts longer than detail
Abstractions live longer than details
"Investment" is in abstraction rather than implementation. Abstraction can survive under "attacks" from different implementations and new technology changes.

54. Use the project vocabulary
Use a project Glossary
If users and developers use different names to reference the same thing, or worse, and use the same name to reference different things, it is difficult for such a project to succeed.

55. Don't think outside the box-find the box
Don't think outside the box-find the box
When you encounter problems that cannot be solved, ask yourself the following questions:

Is there an easier way?
Are you trying to solve the real problem, or are you being distracted by peripheral technical problems?
Why is this a problem?
What makes it so hard to solve?
Must it be done in this way?
Does it really have to be completed?
Many times, when you try to answer these questions, you will find yourself surprised. In many cases, a new interpretation of requirements can completely eliminate the entire problem.
All you need is true constraints, misleading constraints, and wisdom to distinguish them.

56. Listen to repeated doubts-Wait until you are ready to start
Listen to nagging doubts-start when you're re ready
You have accumulated experience and wisdom throughout your life. When you are facing a task, if you repeatedly feel doubt or experience some reluctance, pay attention to it. You may not be able to point out the problem accurately, but by giving it time, your doubts may result in something more solid and something you can handle. Software development is still not scientific. Make your intuition contribute to your performance.

57. "Do" over "Description" for some things"
Some things are better done than described
You should tend to consider demand collection, design, and implementation as different aspects of the same process-delivery of high-quality systems. Do not fall into the norm spiral. At some point in time, you need to start coding.

58. Do not use form-based slaves
Don't be a slave to formal methods
If you do not put a technology into the context of your development practices and capabilities, do not blindly use it.

59. Expensive tools may not necessarily produce better designs
Expensive tools do not produce better designs
Be careful with the hypes of suppliers, industry rules, and the temptation of price tags. When examining the output of a tool, try not to consider how much it is worth.

60. Organize functions rather than work roles
Organize around functionality, not job functions
Divide your people into small teams to take charge of specific functions of the final system. Let the team organize itself internally based on their individual abilities.
However, this approach is effective only when the project has a responsible developer and powerful project management. Creating a self-reliant team and letting yourself flow is a catastrophic prescription.
Remember that a team is composed of individuals. Let every member shine in their own way.

61. Do not use manual procedures
Don't use manual procedures
Shell scripts or batch files execute the same commands in the same order again and again. We can automatically schedule backups, overnight builds, website maintenance, and anything else that can be done with care. Let the computer do repetitive, mediocre things-it will do better than us. We have more important and difficult things to do.

62. Early testing, frequent testing, and automatic testing.
Test early. Test often. test automatically.
Compared with the test plan that stays on the shelf, the test run at each build is much more effective.

63. coding is complete only when all tests are passed
Coding ain't done until all the tests run
That's it.

64. Test your test with "intentional destruction"
Use saboteurs to test your testing
Intentionally introduce bugs on individual software copies to verify that tests can capture them.

65. Test Status coverage, not code coverage
Test State coverage, not code coverage
Determine and test the status of important programs. It is not enough to test the code line. With real-time code coverage, the data you use for testing will still have a huge impact, and, more importantly, the order of your traversal code may have the biggest impact.

66. One bug is captured only once
Find bugs once
Once the tester finds a bug, it should be the last time the tester finds it. The system should be checked for automatic tests later.

67. regard English as another Programming Language
Treat English as just another Programming Language
Write documents like you write code: Observe the dry principle, use metadata, MVC, automatic generation, and so on.

68. Build the document in it. Do not leave it out.
Build documentation in, don't bolt it on
Documents separated from codes are unlikely to be corrected or updated. Using tools such as Javadoc and ndoc, we can generate API-level documents based on the source code.
Documents and code are different views of the same underlying model, but views are the only thing that should be different.

69. Moderately exceed user expectations
Gently exceed your users' expectations
Try to surprise your users. Please note that it is not to scare them, but to make them happy. We need to understand the user's expectations and give them more things. One additional effort required to add a user-oriented feature to the system will return again and again on goodwill.

70. Sign your work
Sign your work
We want to see pride in ownership. "This is what I wrote. I am responsible for my work ." Your signature should be considered as a quality guarantee. When people see your name in a piece of code, they should expect it to be reliable, written, tested, and documented, a real professional work, written by real professionals.
A Practical programmer.