The way of programmers ' cultivation--from small workers to experts

Terminology guru, Guru

Guru is a Sanskrit term that connotes someone a "teacher, guide, expert or master" of certain knowledge or field.

Law of Demeter, the laws of Delphi

The law of Demeter, abbreviated LOD, also known as the least knowledge principle (Principle of Least knowledge), is a design guideline for software development, especially for object-oriented programming. The law of Artemis is a concrete case of loose coupling. The principle was invented by Northeastern University in the late 1987 and can be summarized simply in one of the following ways:
-Each unit has only a limited knowledge of the other units: only the units that are closely related to the current cell;
-Each unit can only talk to its friends: can't talk to unfamiliar units;
-Just talk to your direct friends.

The name of this principle derives from the goddess of agriculture in Greek mythology, the solitary Artemis.
Many object-oriented programming languages use "." Represents the parsed operator of the field of an object, so the law of the Artemis can simply be stated as "using only one. Operator". Therefore, A.b.method () violates this law, and a. Method () does not violate this law. A simple example is that a person can command a dog to walk (walk), but should not direct the dog's legs to walk, it should be the dog to command control of its legs how to walk.
Advantages
The law of the Artemis makes the software better maintainable and adaptable. Because objects are less dependent on the internal structure of other objects, you can change the object container (container) without changing its caller (caller).
Misunderstanding the law of Demeter

Wang Guowei, the three realms of scholarship

Wang Guowei in the "human Cihua" said: "Ancient and modern into a big business, Brainiac, will pass through three kinds of state:" Last night, the West wind wither Green tree, alone on the high-rise, looking to the end of the road. "This is also the first border. "Emaciated end not regret, for Iraq to eliminate people haggard." "This second environment is also. "The crowd found him 1100 degrees, suddenly look back, the man is in, lights dim place." "This third environment is also.
Http://baike.baidu.com/view/955585.htm

Kiss principle

The kiss principle is English Keep It simple, Stupid acronym. The kiss principle refers to the principle of simplicity in design. At the same time, this principle is also used in business letters, computer software design, animation, engineering. There are many other versions of the original, including: "Keep it Simple & Stupid" (most commonly used in Western European literature), "Keep it Sweet & Simple", "Keep it Short & Simple", "Keep I T simple, sweetheart "and" Keep it Simple, Sherlock ".

Corba

CORBA (Common object request broker Architecture, common Object Solicitation Broker architecture, common object Request Broker architecture) is a standard object-oriented application architecture specification developed by the OMG organization. or CORBA architecture is a solution proposed by the Object Management Organization (OMG) to solve the interconnection of hardware and software systems in the Distributed Processing environment (DCE); The OMG organization is an international nonprofit organization whose role is to provide a common framework for application development, Develop industrial guidelines and object management norms to accelerate the development of object technology.

Fc

FC is a command-line tool for comparing files in DOS and Windows, using this command to compare the differences of two similar files in detail.

Babel

Babel (Hebrew:???? ???? Migdal Bavel, also translated Babel, Babel, or free translation for Babel), the Hebrew language in the "chaos" meaning. According to the 11th chapter of the Book of Genesis, human beings joined together to build the tower of hope that the tower could preach its name. In order to prevent human's plan, God lets the human speak different language, causes the human to be unable to communicate with each other, the plan therefore fails, the human has scattered the thing from here. This story attempts to provide explanations for the different languages and races that appear in the world.

Sermon

Preaching (English: Sermon) is a speech made by a prophet or pastor in Christianity. Sermons mainly include biblical, theological, religious, or moral topics, often explaining beliefs, laws, and so forth in the past and current contexts. The main elements of evangelism include interpretation, exhortation and practical action. The sermon was originally a Chinese word, referring to the doctrine of preaching Christianity.

Cobol

COBOL (Commonbusinessorientedlanguage) is the most widely used programming language in the field of data processing and is the first wide-ranging high-level programming language. In enterprise management, numerical calculation is not complicated, but the amount of data processing is very large. In order to solve the problem of management of the enterprise, some computer users in the United States organized a computer language COBOL dedicated to business processing in 1959 and was released in 1961 by the American Data Systems Language Association. The current COBOL has been developed into a variety of versions through continuous modification, enrichment and standardization.

Snoopy swears by the program

Not solved

Mantra (Mantra)

Mantra (Sanskrit:?????? (mantra) refers to sounds, syllables, words, phrases, sentences, and passages that are allegedly capable of "creating change". Their uses and types vary according to the schools and philosophies associated with mantra. Mantra originated in the Indian Vedic tradition, and later became an important part of the Hindu tradition, which was often used in Buddhist, Sikh and Jain religions to pray, eliminate disasters, and exorcise demons.

Heisenberg worm (Heisenbug)

In computer programming jargon, a heisenbug was a software bug that seems to disappear or alter it behavior when one Attem PTS to study it.
Https://en.wikipedia.org/wiki/Heisenbug
Http://www.infoq.com/cn/articles/exterminating-heisenbugs

Spaghetti Style Code

Spaghetti code is a kind of reverse pattern in software engineering, which means that the control structure of a program code is complex, confusing and difficult to understand, especially with many goto, exception, thread, or other unstructured divergent architectures. The reason for its naming is that the flow of the program is like a twisted tangle of faces. There are many reasons for the emergence of noodle code, such as inexperienced programmers, and complex programs that have been frequently modified over time. Structured programming avoids the appearance of noodle-style code.

Waiting to be solved

• C + + supports multiple inheritance, while Java allows classes to implement multiple interfaces. What is the impact of using these facilities on orthogonality? Is there a difference between using multiple inheritance and using multiple interfaces? Is there a difference between using a delegate (delegation) and using inheritance?

Quick Reference Guide for pragmatic Programmers

1. Take care of your skills
Care about Your Craft
If you are not able to develop software in a beautiful lake, why should you 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. offer a variety of options, don't look for lame excuses
Provide Options, Don ' t make Lame excuses
To offer a variety of choices, not excuses. Don't say things can not be done;

4. Don't tolerate broken windows
Don ' t Live with broken Windows
Fix them when you see bad design, wrong decisions, and bad code.

5. Catalysts for Change
Be-a Catalyst for change
You can't force people to change. Instead, show them what the future might look like and help them to be involved 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 see what's going on around you.

7. Making Quality a demand problem
Make Quality a Requirements lssue
Involve your users in determining the real quality requirements of the project.

8. Invest regularly in your knowledge assets
Invest regularly in Your knowledge Portfolio
Make learning a habit.

9. Critically analyze what you read and hear
Critically Analyze what do you Read and hear
Do not be the supplier, the media hype, or dogma around. To follow your own opinion and the circumstances of your project.
Analysis.

10. What you say is just as important as what you say
It's both what do you Say and the the-the-Say it
These ideas are useless if you can't effectively communicate your great ideas to others.

11. Don't repeat Yourself
Dry-don ' t Repeat yourself
Every knowledge in the system must have a single, unambiguous, authoritative representation.

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

13. Eliminate the effects of irrelevant things
Eliminate Effects between Unrelated things
A component that is self-contained, independent, and has a single, well-defined purpose.

14. There is no final decision
There is No Final decisions
No decision was cast on the stone. Instead, think of every decision as being written on the beach and doing well for the change.
Plan.

15. Use tracer bullets to find the target
Use Tracer bullets to Find the Target
Tracer bullets can help you track your goals by experimenting with various things and checking how far they are from the target.

16. Making prototypes for Learning
Prototype to learn
Prototyping is a learning experience. Its value is not in the generated code, but in the lessons learned.

17. Programming near problem areas
Program Close to the problem domain
Design and encode in your user's language.

18. Estimate to avoid accidents
Estimate to Avoid surprises
Make an estimate before you start. You will find potential problems ahead of time.

19. Iterate through the code on the Progress meter
Iterate the Schedule with the Code
Refine your project's time scale with the experience you get when you implement it.

20. Save your knowledge in plain text
Keep Knowledge in Plain Text
Plain text is not obsolete. It can help you use your work effectively. and simplify off-time and test.

21. Use the power of the command shell
Use the Power of Command shells
Use the shell when the graphical user interface is powerless.

22. Use a good editor
Use a-Editor well
The editor should be the extension of your hand; Make sure your editor is configurable, branch-extended and programmable.

23. Always use Source control
Always use Source Code Control
Source control is the time machine for your work – you can go back to the past.

24. To fix the problem, not to issue accusations
Fix the problem, not the Blame
Whether the bug is your fault or someone else's fault is not really very related – it's still your problem and it still needs
Correction.

25. Do not panic during commissioning
Don ' t Panic when debuging
Take a deep breath and think about what might be the cause of the bug.

"Select" Is fine.
"Select" Isn ' t broken
Bugs are rarely found in the OS or compilers, or even third-party products or libraries. Bugs are likely to be in the app.

27. Don't assume that you want to prove
Don ' t assume It-prove It
In the real world – use real data and justification conditions – to prove your assumptions.

28. Learn a text manipulation language
Learn a Text manipulation Language
You use a large part of your day to process text, so why not let your computer do some of the work for you?

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

30. You can't write the perfect software
You Can ' t Write Perfect software
Software cannot be perfect. Protect your code and users from the mistakes they can foresee.

31. Design by contract
Design with contracts
Use the contract to build the document and verify that the code is doing exactly what it declares to do.

32. Early crashes
Crash Early
The damage to the dead program is usually much smaller than the problematic procedure.

33. Use assertions to avoid things that cannot happen
Use assertions to Prevent the impossible
Assertions validate your various assumptions. In an uncertain world, protect your code with assertions.

34. Using Exceptions for exception problems
Use Exceptinos for exceptional problems
Exceptions can suffer from all the readability and maintainability issues of classic spaghetti code. Leave the exception to
Unusual things.

35. What to Do
Finish What you Start
Whenever possible, a routine or object that allocates a resource should also be responsible for releasing its allocation.

36. Minimize coupling between modules
Minimize coupling between Modules
Avoid coupling by writing "shy" code and applying the rules of the Artemis.

37. To configure, do not integrate
Configure, Don ' t integrate
To implement the various technology choices for your application as configuration options, rather than through an integration or engineering approach.

38. Put the abstraction into the code, and the details into the meta-data
Put abstractions in Code, Details in Metadata
Programming for the general situation, placing the details outside the compiled code base.

39. Analyze workflows to improve concurrency
Analyze Workflow to Imporve Concurrency
Take advantage of concurrency in your users ' workflows.

40. Design with the service
Design Using Services
Design according to the service – Independent, a well-defined, consistent interface behind the art of war object.

41. Always design for concurrency
Always Design for Concurrency
Allow concurrency, and you'll design a cleaner, less-hypothetical interface.

42. Separating the view from the model
Separate views from Models
To design your app based on models and views, get flexibility with inexpensive code.

43. Coordinate the workflow with a blackboard
Use blackboards to coordinate Workflow
The blackboard is used to harmonize completely different facts and factors while keeping the participants independent and isolated.

44. Do not program by coincidence
Don ' t program by coincidence
Rely on reliable things only. Pay attention to the occasional complexities and don't confuse lucky coincidences with purposeful plans.

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

46. Test your Estimate
Test Your Estimates
The mathematical analysis of the algorithm will not tell you every thing. Measure its speed in the target environment of your code.

47. Early refactoring, constant refactoring
Refactor Early, Refactor Often
Just as you would weed and rearrange in the garden, rewrite, redo, and re-architect the code as needed. To
Eradicate the root causes of the problem.

48. Designed for testing
Design to Test
Start thinking about testing problems when you haven't written your code yet.

49. Test your software, or your users will have to test
Test Your software, or Your Users would
Relentlessly tested. Don't let your users find bugs for you.

50. Do not use the wizard code that you do not understand
Don ' t use the Wizard Code you don ' t understand
Think that you can generate a lot of code. Make sure you understand all of this code before you merge them into your project.

51 do not collect requirements – tap them
Don ' t Gather requirements-dig for them
Demand rarely exists on the surface. They are deeply buried beneath the assumption, misunderstanding and political means of the layers.

52. Work with users to think like users
Work with a user to Think like a user
This is the best way to understand how the system will actually be used.

53. Abstraction lives longer than details
Abstractions Live longer than Details
"Investment" is an abstraction, not an implementation.

54. Using the Project glossary
Use a Project Glossary
Create and maintain a single source of information for the specialized 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 an issue that is impossible to solve, determine the real constraints. Ask yourself: "Does it have to be done this way?"
Does it really have to be done? ”

56. When you're ready to start again
Start when your ' re ready
You have accumulated experience throughout your life. Don't neglect the recurring doubts.

57. "Doing" is better than "description" for some things
Some things is Better done than described
Don't fall into the standard spiral

58. Don't be a slave to the formal method
Don ' t be a Slave to formal Methods
If you don't put a technology in the context of your development time and ability, don't use it blindly.

59. Expensive tools do not necessarily produce a better design
Costly Tools Don ' t produce Better disigns
Beware of the lure of vendor hype, industry dogma, and price tags. They are judged according to the value of the tool.

60. Organizing teams around functions
Organize Teams Around fucntionality
Don't separate designers from coders, and don't separate testers from data modelers. Build in the way you build your code
Team.

61. Do not use manual processes
Don ' t use Manual procedures
The shell script or batch file executes the same instruction again and again in the same order.

62. Early testing, frequent testing, automated testing.
Test Early. Test Often. Test automatically
It is much more effective to build a test run each time than a test plan on a shelf.

63. To pass the full test, the code is completed.
Coding Ain ' t ' Til all the Tests Run
That's it.

64. Test your test by "vandalism".
Use saboteurs to Test Your testing
Intentionally introduce bugs on separate copies of the software to verify that the tests can catch them.

65. Test status overrides, not code coverage
Test state coverages, not Code coverage
Identify and test important program states. Just testing the line of code is not enough.

66. A bug is only caught once
Find Bugs Once
Once the tester finds a bug, it should be the last time the tester has found it. The automated test should then
Check.

67. English is a programming language
中文版 is Just a programming Language
Document as you write code: Follow the dry principles, use metadata, MVC, auto-build, and more.

68. Build the document inside, don't tie it outside
Build documentation in, and Don ' t Bolt It on
Documents that are separate from the code are unlikely to be corrected or updated.

69. Gently exceeding the user's expectations
Gently exceed Your Users ' expectations
To understand your users ' expectations, then give them something a little more.

70. Sign your work
Sign Your work
The craftsmen of the past were proud to be able to sign their work. And so should you.

Check List

71. Languages to learn
Tired of C, C + + and Java? Try Clos, Dylan, Eiffel, objectve C, Prolog, Smailltalk, or Tom. Each of them has different abilities and different "flavors". Use one or more of these languages to develop a small project at home.

72.WISDOM Clutch Poem
What does want them to learn? What do you want them to learn?
What's their interest in what do you ' ve got to say? What are they interested in about you?
How sophisticated is they? How experienced are they?
How much detail do they want? How much detail do they want?
Whom does want to own the information? Who do you want to have this information for?
How can I motivate them to listen? How do you motivate them to listen to you?

73. How to maintain orthogonality
• Design independent, well-defined components.
• Keep your code decoupled.
• Avoid using global data.
• Refactor similar functions.

74. Things that should be made prototypes
• architecture
• New features in existing systems
• structure or content of external data
• Third-party tools or components
• Performance issues
• User interface Design

75. Architectural Issues
• Has the responsibility been well defined?
• Has writing been well defined?
• Is the coupling minimized?
• Can you identify potential duplicates?
• Is the interface definition and constraints acceptable?
• Can the module access the required data when needed?

76. Debug checklist
• Is the problem being reported as a direct result of the underlying bug or just a symptom?
• Bug really in the compiler? In the OS? Or is it in your code?
• What would you say if you explained the question to a colleague in detail?
• If the suspect code passes the unit test, is the test complete enough? What happens if you run unit tests with this data?
• Does the condition that causes this bug exist anywhere else in the system?

77. The law of the inking of the function
A method of an object should only call methods that are in the following cases:
• It itself
• Any parameters passed in
• The object it creates
• Component Objects

78. How to Carefully program
• Always be aware of what you are doing.
• Do not program blindly.
• Act as planned.
• Rely on reliable things.
• Create a document for your assumptions.
• Do not just test your code, but also test your assumptions.
• Pooh's job prioritization.
• Don't be a Slave to history.

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

80. Splitting the Goldys knot
When solving a problem that cannot be solved, ask yourself:
• Is there an easier way to do it?
• am I solving the right problem?
• What is a problem with this thing?
• What makes it so hard to solve?
• Does it have to be done this way?
• Does it really have to be done?

81. Various aspects of the test
• Unit Testing
• Integration Testing
• Inflammation and calibration
• Resource exhaustion, error, and recovery
• Performance Testing
• Usability Testing
• Test the test itself

The way of programmers ' cultivation--from small workers to experts