Programmer's resonance-read "effective programmers"

ArticleDirectory

• Summary:

I recently read "effectiveProgramClerk, I feel a lot of GAINS. This is a rare good book for programmers. In the book, there are some simple principles, but the author collects, summarizes, and summarizes these things, and finally makes them into a book. In order to collect various tools and methods to improve efficiency, the author has suffered a lot.

I think the first part of this book summarizes some very good rules. I have extracted the following:

Rule:
1. Acceleration rules

Focus on essence, not form

The usefulness of an Application List is inversely proportional to its length.

Programmers spend a lot of time searching for things.

Flashy things are useless

Keyboard input is always faster than navigation

Preferred keyboard instead of Mouse

The address bar is the most efficient part of the Windows Resource Manager interface.

Spend some time learning all the hidden shortcuts at hand

Environment switching will consume time

Batch copy and paste is faster than repeated copy and paste operations

If you forget the history, you have to enter it again.

The command prompt embedded with a graphical tool allows you to have both the fish and the bear's paw

Learn the IDE shortcut in the context, instead of carrying a long list

When you enter a complex structure for the second time, make it a template.

If you want to perform the same operation on multiple lines of text, you should find the mode and record it as a macro.

Do not always input the same command

Spend a little time every day to make every day more efficient

2. Focus rules

The more concentrated the energy, the more careful the thinking

Exclude interference: isolate policies, turn off unwanted prompts, and create a quiet time

The larger the heap, the harder it is to find a needle.

Do not ask about the file tree. Search

Use multiple monitors

Virtual desktops can clean up a mess of windows.

3. Automation rules

Don't re-invent the wheel

Use selenium to browse Web pages

Do not waste time doing things that can be automated

Replace the batch file with Windows Power Shell

Tame the Subversion command line

Solving problems in a creative way will help solve similar problems in the future

The key to automation is ROI and risk mitigation.

Research work should be done in the time box.

Don't cut yak hair

4. Normative rules

For anything you do not build on your own, only one copy is saved in version control.

Use Standard build servers

Copying and pasting is evil, no matter what you copy and paste

Standardize project dependencies using virtual platforms

Do not make the object-relational ing tool (O/R ER) violate the standard principles.

Through expansion. Open Class or partial class to generateCodeAdd Behavior

Always keep code and data structures synchronized

Outdated documents are worse than no documents because they will mislead you.

Anything that requires hard work can make its creators stop

Whiteboard + digital camera over any case Tool

Generate all technical documents whenever possible

Repetition is the greatest resistance in software development.

Tools:

The book also mentions a large number of tools to improve efficiency, which are very good. I believe many people have their own lists. Below are some of the essential software on my computer:

1. Firefox and its various plug-ins

2. launchy the accelerator

3. Total commander

4. clipx multiple clipboard

5. emeditor Text Editor

6. vistual studio va plug-in

7. search and replace

8. Everything

9. Miranda IM

10 .....

Feelings:
1. Angry monkeys

In the second part of the book, I mentioned a lot of practical content. What impressed me most is the story of "angry monkeys:

"As early as 1960s (when scientists could do anything crazy), behavioral scientists conducted an experiment. They put five monkeys and a living ladder in a room and hung a bunch of bananas on the ceiling. The monkeys soon thought they could climb the ladder to eat bananas, but every time they were near a living ladder, scientists would fill the house with ice water. I think you can guess what will happen: A group of angry monkeys. Soon, no monkey will be near the ladder.

Then, scientists replaced one of them with another new monkey that had not endured ice water. The first thing the new monkey did was go straight to the ladder, but when it did, all the other monkeys beat it. It doesn't understand why, but soon learns: Don't get close to that ladder. Scientists gradually replaced the original monkeys with new monkeys until none of them were soaked in water, but they would still attack any monkeys close to the ladder.

What does this mean? Many practices in software projects exist because "we have always done that". In other words, it's because of angry monkeys."

Our team encountered numerous similar problems when developing C ++-related code specifications. For example, we had a long debate over whether to adopt the Hungarian naming method when formulating variable naming rules. Some people think that almost all the previously seen C ++ Code adopts the Hungarian naming method, and even all the APIS defined by Microsoft use this naming method. At the beginning, I also had the same questions.

Later, after careful analysis of the origins of the C ++ Hungarian naming law, we gradually felt that we were angry monkeys blindly following our predecessors and lacked the courage to break the tradition. C ++ has a special historical cause, and many standards have been precipitated and rarely changed. Let's take a look at the new ones.Programming Language, C #, python ...... They all abandoned Hungary's naming method. At the same time, they took a look at the current C ++ cutting-edge C ++ 0x and some of the books published now, and gradually gave up using Hungary's naming method. Because the meaning of the type is becoming weaker and weaker in the object model. So we finally gave up the old Hungary naming convention.

2. Agile Development

This book has a strong thoughtworks color, agile ideas throughout the book, including test-driven design, whiteboard, Pair programming. This also gave me a stronger interest in agility. Here is a story about test-driven TDD development:

"I remember the first time I started to modify code with some developers who were used to unit testing, I was also very nervous, because a lot of modifications often damage a lot of things, but they didn't seem to hesitate. Gradually, I also put my mind down, because I slowly realized that with the guarantee of testing, I can modify the code with confidence."

3. Interesting stories

There are also some interesting stories in the book. For example, when a friend of the author is programming with others, in order to develop the habit of using shortcut keys for the companion, whenever the companion does not use the shortcut keys, he will ask to undo the operation, and then ask to use the shortcut key to repeat the operation three times. Then, in his fierce eyes, his companions quickly mastered the shortcut keys.

Summary:

This book is very thin and contains a lot of truth. I believe that everyone who has read it will learn from it. After reading it, we should not limit it to some tips or details mentioned in the book. After all, there are many ways to provide efficiency and many rules, it is difficult for a book to be exhausted. We should learn from the book and constantly sum up the ideas in practical work and study to become a real "effective programmer "!