Programmer's Practice

Quick Reference List
1. care about your skills
Care about your craft
If you don't care if you can develop software beautifully,

Why do you need to spend your life developing software?

2. Think! Your job
Think! About your work
Turn off the autopilot and take over the operation. Constantly criticize and evaluate your work.

3. provide various options and do not make any excuses.
Provide options, don't make lame excuses
It is necessary to provide various choices, rather than excuses. Do not say that things cannot be done; Describe what can be done.

4. Do not tolerate broken windows
Don't live with broken windows
When you see bad designs, wrong decisions, and bad code, correct them.

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.

6. Remember the big picture
Remember the big picture
Don't focus too much on details, so you forget to check what is happening around you.

7. Make quality a requirement
Make quality a requirements issue
Let your users participate in determining the real needs of the project.

8. regularly invest in your knowledge assets
Invest regularly in your Konwledge portfolio
Make learning a habit

9. criticize and 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
These ideas are useless if you cannot effectively pass on your amazing ideas to others.

11. Do not repeat yourself
Dry -- don't repeat yourself
Every piece of knowledge in the system must have a single, unambiguous, and authoritative representation.

12. Make reuse easier
Make it easy to reuse
If it is easy to reuse, people will reuse it. Create an environment that supports reuse.

13. Eliminate the impact between irrelevant transactions
Eliminate effects between unrelated things
Design self-contained, independent components with a single, well-defined purpose.

14. No final decision exists
There are no final decisions
No decision is cast on the stone. On the contrary, every decision should be considered written on the beach and planned for changes.

15. Find the target using a drag-and-drop bullet
Use tracer bullets to find the target
Drag bombs can experiment with various things and check how far they are from the target to allow you to track the target.

16. Create a prototype for learning
Prototype to learn
Prototyping 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
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.

19. iterate the schedule table by code
Iterate the schedule with the code
Extract the time scale of the project with the experience you gained during implementation.

20. Save knowledge in plain text
Keep knowledge in plain text
Plain text is not outdated. It can help you effectively use your work and simplify debugging and testing.

21. leverage the power of Shell
Use the power of command shells
Use shell when the graphic user interface is powerless

22. A good editor
Use a single editor well
The editor should be an extension of your hands; Make sure that your editor is configurable, scalable, and programmable.

23. Always use source code control
Always use source code control
Source code control is the machine for your working hours-you can go back to the past.

24. correct the problem instead of making a complaint.
Fix the problem, not the blame
The bug is your fault or someone else's fault. It is not really relevant-he is still your problem and still needs to be corrected.

25. Do not panic during debugging
Don't panic when debuging
Take a deep breath and think about the possible causes of bugs.

26. "select" is correct
"Select" isn' t broken
Few bugs are found in OS, compiler, or even third-party products or libraries. The bug is likely to be applied.

27. Do not assume that you want to prove it.
Don't assume it-prove it
In the actual environment -- use real data and boundary conditions -- prove your assumptions.

28. Learn a text manipulation language
Learn a text manipulation language
If you process text for a large amount of time every day, why not let the computer do some work for you?

29. write code that can write code
Write code that writes code
Code generators can improve your production efficiency and help avoid duplication.

30. You cannot write perfect Software
You can't write perfect Software
Software cannot be perfect. Protect your code and users from foreseeable errors.

31. design through contract
Design with contracts
Use the contract to create a document and check that what the Code does is exactly what he declares to do.

32. Early crash
Crash early
The harm of dead programs is usually much smaller than that of problematic ones.

33. Use assertions to avoid impossible events
Use assertions to prevent the impossisble
Assertions verify your assumptions. Protect your code with assertions in an uncertain world.

34. Apply exceptions to exceptions
Use exceptions for exceptional problems
Exceptions may be plagued by all the readability and maintainability Problems of the classic pasta-style code. The exception is retained to the exception.

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
Avoid coupling by writing "Shy" code and applying the meter rules.

37. Configuration required, not integration
Configure, don't integrate
You need to implement the various technical options of the application as configuration options, rather than implementation through integration or engineering methods.

38. Put the abstract into the code, and put the details into the metadata.
Put into actions in code, details in metadata
For general programming, place the details outside the compiled code library.

39. Analyze workflows to improve concurrency
Analyze workflow to improve concurrency
Use the concurrency in your users' workflows.

40. Design with services
Design Using services
Design Based on the service-independent concurrent objects after well-defined and consistent interfaces.

41. Always Design for concurrency
Always Design for concurrency
To allow concurrency, you will design interfaces that are more neat and have fewer assumptions.

42. View and model Separation
Separate views form models
You need to design your applications based on models and views to get flexibility with low-cost code.

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.

44. Don't rely on coincidental Programming
Don't program by coincidence
Rely only on reliable things. Pay attention to occasional complexity. Do not confuse lucky coincidence with purposeful plans.

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
Just as you will weed out the garden and reconfigure it, rewrite, redo, and rebuild the code as needed. We need to eliminate the root cause of the problem.

48. Designed for testing
Design to test
When you haven't written the code, you still need to think about the test.

49. Test your software, or your users will have to test
Test your software, or your users will
Relentless testing. Do not ask your users to find bugs for you.

50. Do not use wizard code that you do not understand
Don't use wizard code you don't understand
Wizard Code can generate a large amount of code. Before you merge them into your project, make sure you understand all the code.

51. Do not collect requirements-mine 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 and 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.

53. abstraction lasts longer than detail
Abstractions live longer than details
"Investment" is an abstraction, not a reality. Abstraction can survive under "attacks" that come from different realities and changes in new technologies.

54. Use the project vocabulary
Use a project Glossary
Create and maintain a single source of information for the terminology and vocabulary used in the project.

55. Don't think outside the box-find the box
Don't think outside the box-find the box
When encountering problems that cannot be solved, determine the true constraints. Ask yourself, "Must it be done in this way? Does it really have to be completed ?"

56. When you are ready
Start when you're ready
You have accumulated experience throughout your life. Do not ignore repeated doubts.

57. "Do" something better than "Description"
Some things are better done than described
Don't fall into the norm vortex-at some point in time, you need to start coding.

58. Do not act as 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 be able to make better designs
Costly tools don't produce better designs
Be careful with the hype of suppliers, the industry dogma, and the temptation of price tags. They should be judged based on the value of the tool.

60. organize teams around Functions
Organize teams around functionality
Do not separate the designer from the coders, or separate the tester from the data Modeler. Build a team by building code.

61. Do not use manual procedures
Don't use manual procedures
Shell scripts or batch files execute the same command in the same order again and again.

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. encoding is complete only when all tests are passed
Coding didn't done until all the tests run
That's it.

64. Test your test with "intentional destruction"
Use saboteurs to test your testing
Deliberately reference bugs on individual software copies to verify that the 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.

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. After the automatic test, check the corresponding information.

67. English is a programming language
English is just a programming language
Write documents like you write code: Observe DIY principles, use original data, 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 trimmed or updated.

69. Moderately exceed user expectations
Gently exceed your users' expectations
You need to understand your users' expectations and give them more things.

70. Sign your work
Sign your work
Craftsmen of the past are proud to sign their work. This should happen overnight.

Check List

71. language to learn
Tired of C, C ++, and Java? Try Clos, Dylan, Eiffel, Objective C, Prolog, smalltalk, or Tom. Each of them has different abilities and different "Flavors ". Develop a small project at home in one or more of these languages.

72. Wisdom Poetry
What do you want them to learn? What do you want them to learn?
What is their interest in what you 've got to say? What are they interested in?
How sophisticated are they? How rich are they with experience?
How much detail do they want? How many details do they want?
Whom do you want to own the information? Who do you want to possess this information?
How can you motivate them to listen to you? How do you make them listen to you?

73. How to maintain orthogonal
The design is independent and well defined.
Keep your code decoupled
Avoid using global data
Refactoring similar functions

74. Things that should be prototyped
Architecture
New functions of existing systems
Structure or content of external data
Third-party tools or components
Performance problems
User Interface Design

75. Architecture Problems
Is the responsibility well defined?
Is writing well defined?
Is coupling minimized?
Can you determine the potential Repetition?
Are interface definitions and constraints acceptable?
Can the Module Access the required data as needed?

76. debug check list
The problem being reported is the direct result of the underlying bug, or is it just a symptom?
Is the bug really in the compiler? In OS? Or in your code?
What do you say if you explain this question to your colleagues in detail?
If the code passes the unit test, is the test complete enough? What happens if you use this data unit test?
Does the condition that causes this bug exist anywhere else in the system?

77. De Moter Law of the Function
The method of an object should be called in the following situations:
Itself
Any input parameters
The object it creates.
Component Object

78. how to program carefully
Always realize what you are doing
Do not program blindly
Act as planned
Relying on reliable things
Create a document for your assumptions
Do not just test your code, but test your assumptions.
Prioritize your work
Do not be slaves of History

79. When to refactor
You found a violation of the dry principle.
You find that things can be more orthogonal.
Your knowledge has been extended
Demand evolved
You need to improve performance

80. Split the gordis knot
Ask yourself:
Is there an easier way?
Are I solving the correct problem?
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?

81. Test aspects
Unit Test
Integration Test
Verification and Verification
Resource depletion, errors, and recovery
Performance Testing
Availability Test