Book reviews, feelings, and quick reference to the "Practice of programmers"

In the "Praise" of "code Daquan", a student named John Robbins thought that "code Daquan" should be read every year. I think this suggestion also applies to this book.

Many of the ideas and arguments in this book are based on the author's years of experience and practice. It is difficult to easily write such ideas in this book for your understanding, let alone get them. Only after your own experience or experience can you fully understand the philosophy behind this book and concatenate those points into a line. Experience is gradually accumulated, so reading once a year will give you a new experience, unless you fully understand it.

For me, the reading is:
1. Read it, and we did it. Such as "shell game", "Source code control", and "source program design "...
2. I have read it, but we have not done that for some reason. "Contract-based design", "restructuring "...
3. Read it, but I didn't realize it before. "Strong edit", "Wait for you to prepare "...
4. I have not understood it, for example, "Blackboard "...

Of course, it also includes the "I don't know" content that I don't know. Therefore, it is certainly good for me to read it again in a year.

There are too many Literal translations:
1. Guru and mantra are acceptable for the literal translation of these terms? Or simply do not translate );
2. The translation of the Demeter rule is quite abrupt !!! There is also a liskov rule, but the English representation is retained ~~~
3. some English idioms, or cultural-specific usage, are very confusing, such as "fish" and "King's horses, it is best for the translator to understand and then explain it in the form of comments. (Of course, this requires a lot of translators. Directly Reading the English version does not solve this problem)

But in general, it has little impact on reading core content.

Chapter 2 effectiveness-oriented Philosophy
---------------------------
1. My source code gave me the cat.
A sense of responsibility and courage should be responsible for the consequences of your behavior, and be brave enough to admit your weaknesses and faults, rather than looking for boring excuses.

2 software entropy
"Entropy" is the total amount of "unordered" in a system, so "software entropy" is the total unordered amount in the software system. According to the principle of "broken windows, if you tolerate a flaw in the design or code of the software, the software entropy will inevitably grow rapidly until "software decay ".
A story similar to "broken windows" is that the bathroom in a small hotel is always corrupted and messy by passengers, so the lady-in-laW tried to clean the bathroom first, then add a flower in the basin, which is very clean and warm. Passengers cannot bear to destroy such a beautiful environment. From now on, the bathroom of the hotel is always clean.
Your code is an environment that others cannot bear to destroy.

3 stone soup and boiled frog
Shi toutang: Even if you don't have any resources, you can achieve one thing or a career as long as you have a good idea.
Boiled frog: The project is out of control without knowing it, but no one notices it-No big picture! The company's Niu once said: we need to work hard and look up at the road. Very simple, but also brilliant.

4. Good software
When balancing the quality, needs, and resources (personnel and time) of software, we generally think that quality is an element that cannot be compromised. We use these three factors as the three vertices of a triangle, to ensure that the triangle area remains unchanged, we must increase manpower or time when the demand increases. When the time or personnel decreases, we must also reduce the demand.
But here we tell you that the quality of software is part of the requirement, because the requirement comes from the user, and the quality requirement is also determined by the user. If the user is based on the market or term, you can accept software with edges. Pursuing perfection is a good idea, but you need to know when to stop: that is, the user feels good enough. Besides, early contact with users can give you valuable feedback.

5. Your knowledge assets
Investment knowledge is the same as investment financial assets.
Develop your own learning methods and skills, and establish your own knowledge management system.

6. Communication!
The importance of communication is self-evident. If you often deal with others, especially those in other groups, you will feel more deeply.
I want to understand the purpose of communication is very important: communication is not to express yourself, not to persuade others, nor to accuse and shirk, but to solve things in a more harmonious manner. Therefore, you must understand listening, be patient, be polite, be clear, and have a clear attitude ~~~

Chapter 4 effectiveness-oriented approaches
----------------------------------
7. hazards of repetition
The danger of repetition lies in the burden of maintenance.
The dry principle first lies in rejecting duplicates, and secondly in encouraging reusability.
I always see several PI constants and assert macro definitions in some code. This type of repetition is quite low-level and irresponsible. Why don't I search for it before I use it? It is as if you have searched for the question before asking a question in the Forum.

8. Orthogonal
I don't know why to create such a term. In my opinion, this is independence and cohesion, which is to minimize the dependency between components.

9 irrevocable
Is abstraction. If you want to switch between d3d and OpenGL, you want to switch between Oracle and SQL server? Encapsulate basic concepts with your own interface!

10 trace bullets
Iterative development and adjustment through continuous feedback. Recently implemented scrum is actually a development method of the same concept.

11 prototype and note
The prototype is for exploration and verification. The prototype is more suitable for research projects, while the drag bullet is more suitable for projects with clear solutions. The prototype is the code that is discarded when used up. You can ignore all the specifications here to build the prototype of the verification system as quickly as possible.
In fact, some local tasks can also be verified using the Prototype Method in the drag-and-drop method.

12 Domain languages
What is a domain language? I feel like it is more direct and advanced than programming languages to implement functions. In my experience, I have used some of the following:
1. Configure the system UI through an XML file. The system implements a parser to parse the file and create the UI at runtime.
2. Use a Perl script to parse a reg file into a header file and compile it into the Code. This parsing process will be called during the prebuild time.
3. In fact, I think the work done through the system API is also a domain language.

13 Estimation
In fact, estimation is everywhere in life and work. How long will it take you to buy a dish, how long it takes to cook dinner, and how long it takes to take a bath ~~~~ How long does it take to complete the separation of this module. You need to know what to complete, how to complete, and how to complete. There is a sentiment in the book: the unit you estimate will affect your interpretation. (Seconds? Minute ?... Or year ).
The key to improving estimation is multi-estimation and multi-feedback. There are two advantages:
1. Each time you identify the difference based on your estimation and actual cost, your consideration will become more comprehensive.
2. There are many estimated projects, so you can rely on your previous experience.

Chapter 4 basic tools
-----------------------
14 power of plain text
Plain text is the best and easiest way to represent cross-platform, cross-time (not outdated), and easy to understand and compare. There is a common misunderstanding that binary is more secure than text representation. In fact, it is more obscure. To ensure security, encryption is the correct solution.
The source code, resource files, HTML, XML, and registry files of the program are all plain text. If you want to design your own file format and prioritize plain text, unless you have storage space and efficiency considerations.

15 shell games
Although the shell in windows is not as powerful as * nix, it is enough to automate some daily operations. For example, we often use some BAT files for automatic configuration. In particular, when you use shell commands and Perl, a powerful text processing language, you will feel like a duck. In the past two years of code restructuring, I have learned a lot about the power of Perl + shell!

16. Strong editing
It is indeed a good suggestion to use an excellent editor. To do well, you must first sharpen your tools. Generally, N ++ is used more frequently in windows. Recently, we have considered switching to a more powerful and cross-platform tool, such as Emacs or VI.
In fact, this principle can be said to be broader. For those who often work in IDE, the IDE proficient in their work, such as Vs, is quite useful, and its efficiency improvement should be doubled.

17 source code control
In this age, I believe that SCM will be used as long as software is written. Our company uses perforce and many open source projects use SVN, mercury, or git, however, CVS has gradually declined. The "Source code let the cat eat" only happens in the program I wrote in college ~~~

18 debugging
For more information about the debugging methodology, see this book debugging: http://book.douban.com/subject/3228993 /.
The story "Rubber Duck" can be used as a reminder to remind you that you should explain the problem to the Rubber Duck before asking others. In fact, many times, when you straighten out the problem, the answer will naturally exist. Have you ever had this experience: After you finish your problem with your colleagues, you immediately realize how to solve it ~~~~ At this time, the other party may not understand what you are asking-this is the role of the Rubber Duck.

19 text manipulation
It is a pleasure to manipulate text. I realized this kind of fun after discovering the power of Perl and regular expressions. I run the shell command and use Perl to parse its output. In a few minutes, I can parse more than 30000 source files and modify the code in a complex way. At that time, you will feel very powerful ~~~
It's hard to imagine how I got there without Perl or regular expressions.

20 Code Generator
This is actually a special text manipulation, with the goal of automating work and avoiding duplication. Wizard is actually a code generator, and doxygen is also a kind, although it generates a code document. In our work, we have produced a header file based on an original reg file to compile it into the code.

Chapter 1 effectiveness-oriented paranoia
---------------------------------
21. contract-based Design
When writing a function, assert enters a parameter at the entrance, and the exit returns whether the call is successful. However, we did not officially name it the prefix and suffix conditions and comment them out. Of course, it will also check whether a certain status is true at the entrance and exit. This should be the "unchanged items" here ". I want to clarify these concepts so that we can have a clear idea when writing code to ensure the normalization of functions. When implementing a function, first think about its contract ~~~

22 dead programs do not lie
When there is a fatal error in the program, direct crash is a good choice. This is because errors are reported in the most explicit way to facilitate correction. If you try to conceal such errors, even though the program is still running, there is a potential danger. For example, the exceptions of the two iterations in C ++ may cause the program crash. If you try to swallow the second exception in the destructor, it actually hides the error rather than solves the problem.
Instead of living, it's better to give him a knife!

23 assertion Programming
This is an important part of Defensive Programming. If you think it is "impossible", Use assertions to ensure it will not happen. Of course, note that this is "impossible". Many beginners may think that assert occurs when a failure occurs. For example, process: to open a file, if it does not exist, create it first. When the file fails to be opened in the first step, many people may mistakenly use an Assert. In fact, this is a "possible" situation.

24. When to use an exception
For the error handling method, exception handling is better than the return value judgment: it reduces the condition judgment and brings together the code for error handling. However, the most useful in our work is the processing of return values.
In exception handling, a very important measure is to ensure that resources can be correctly released when an exception is thrown. In C ++, we can use raiI, while in C #, or in Java, we can use finally statements.

25 how to balance resources
Resource management
Several principles:
1. Who assigned and released
2. First allocated and then released --- in case the last allocation references the first allocation
3. Allocate resources in the same order in different places of the Code --- avoid deadlocks

Chapter 2 bending or breaking
----------------------------
26 decoupling and Demeter rule
Law of Demeter is a "Minimum knowledge principle ". The use of such a strange transliteration seems abrupt.
Decoupling includes logical decoupling and physical decoupling. The key is the minimum knowledge principle. If you don't know, try not to know. If you don't, try not to rely on it. When you write code to find that you need to include another header file: Think twice.

27 RMB Program Design
The basic point is not hard encoding;
The upgrade point refers to the software configuration information, which can be saved in the registry or configuration file as much as possible and can be dynamically configured.
Another improvement is that we need to encapsulate changes in software design. For example, after an interface is encapsulated, but if feasible, encapsulation beyond code is the most flexible.

28 time Coupling
The main focus is on concurrency. To consider concurrency, consider the following:
1. Whether a single operation is independent enough
2. Can multiple operations be performed in parallel.
Do not only consider concurrency in the program. Check the concurrency requirements of the workflow in your team in your work.

29. It is only a view.
MVC pattern. I think it is a special case of observer pattern. The decoupling between specific classes is realized through the interface, and the publishing/subscription mode is realized.
Everyone should be familiar with this.

30 blackboard
Is further decoupled, and even the common interfaces required in item29 are eliminated.
But I don't understand it ~~~

Chapter 2 when you encode
---------------------------
31. coincidental Programming
Knowing and knowing why;
If you are able to work, you must know why You can work. If you fail, you must know why you fail. Don't join us by coincidence.

32 algorithm speed
Use large O notation to analyze algorithm efficiency. Cultivate a kind of intuition. For some common algorithms, the process can express their large O representation, such as Bubble Sorting O (N ^ 2) and traversing O (n ). The figure provided in is quite good:
Http://www.flickr.com/photos/dbger/4488865262/

33. Reconstruction
I do not agree that many books have to be reconstructed and their reasons. Refactoring is always an art. You must make a balance between your ideal and your reality.
The book refactoring introduces many refactoring methods. But what we need more is a relatively reliable and efficient reconfigurator. At least C ++ is not doing well, and vs itself does not provide much, the reconstruction function of the VA plug-in is quite limited.

34 easy-to-test code
The code that is easy to test has very simple interfaces and very clear conventions, thus providing better quality. This is from the perspective of details and code. From the software point of view, we should provide a sound Log Mechanism and diagnostic function to precisely locate errors in the customer environment.

35 evil wizard
If you want to write a test program, you don't need to understand the Code. However, if you need to create a software based on the wizard, it is necessary to understand the code generated by the wizard. I think that's why "let's get down to MFC" is so popular. Everyone is actually aware of this problem.

Chapter 1 before the project starts
----------------------------------
36 challenges
It is impossible to find out the requirements at the initial stage of the project, because at that time, even the user did not know all the requirements, because the user's understanding of the needs is also a step-by-step process. I agree with the practices in scrum, gradually iterate, let users participate in the whole process, and give feedback, which actually helps users find out their needs.
Understand why a user wants to do something, rather than the current method. Because it may be wrong at the beginning, because you may have a better way-you are the one who provides the method.
Similarly, when you help others solve problems, you should also remember to explore the root cause, instead of following the way, because he may be wrong from the very beginning.

37. Solve impossible puzzles
Think out of the box.
It is very likely that the thought will be changed.

38 when you are ready
We seem to be easily at two extremes. Sometimes we are too radical to start coding before we think about it. Sometimes we are too procrastinating and reluctant to start coding. We always feel that we are not ready yet. In which case do you belong to? In fact, it is easy to judge in your heart. The key is how to overcome your own mistakes.

39 Standard traps
Some standards are described as complex but simple. It is a waste of effort for PD to write down the spec and make development harder to understand. This is also the benefit of introducing the user story in scrum: the issues that can be solved through communication do not require effort to write any spec. After all, spec is not an aim, but a means.

40 circles and arrows
There is no outdated method or optimal process. The key is to find a suitable process for your project and team. The pursuit of an advanced method is just a flow of tables and neglect the original. Again, the process is not an aim, but a means.

Chapter 4 effectiveness-oriented projects
----------------------------------
41 effective teams
Effective methods apply to individuals, and also to teams: Do not break the window; warm boiled frogs; communicate; do not repeat yourself; orthogonal; automation. In this case, the organization of the project team should be best divided by function, so as to have better orthogonal. Development is development, QA is QA, and PD is PD, and then frequent cross-team communication is inevitable. Our company is switching from this method to scrum team: QA, development, PD belongs to the same group, and the communication efficiency can be greatly improved.

42 ubiquitous Automation
In this regard, I have two creden:
1. Do not do what machines can do.
2. All things with fixed rules can be automated.
Many processes in software development can be automated. I think there are two advantages to the tedious work of automation: one machine is fast and good, and can be repeated; second, it is easy to generate a sense of accomplishment by converting tedious manual work into automated programs.

43 relentless tests
A good discussion about the test.
For bugs found on the basis of automated testing, you need to add cases for them and keep "tightening the network ".
However, there is no particular introduction to test first (TDD). In fact, TDD is considered a quite feasible programming methodology.

44. All data is written.
Write comments and documents... The key points are:
1. Do not repeat
2. Automation
For example, if you need a function export list in a DLL, do not maintain it yourself (do not repeat it), but write a tool to extract it from the DLL (Automated ).

45 Great Expectations
Do not exceed your expectations. "Gentle exceeding user expectations" may be the best strategy.
There is a range for the person's endurance. It should not be too low or too high ~~~ Er, Or, things must be reversed.

46 arrogance and prejudice
Sign you work !!!
Let others know that this is your work: Honor and Disgrace! This gives rise to a sense of pride and responsibility.
If you do not dare to sign your name in the code, ask yourself: Why?

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's not really relevant-he is still your problem, and he still needs to fix it.

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" No problem
"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-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 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 abstract, not realistic. Abstraction can survive under "attacks" with changes from different realities and 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" over "Description" for some things"
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
Test itself