To the ranks of better programmers

The best way to learn is to have a good teacher. He teaches you different skills according to your different stages, and the teacher not only teaches you to practise, but also teaches you to be a man, to make you inner and outward in shape. Teach you some truth, you may not quite understand at that time, but wait for you to practice many days, after twists and turns, there is a day enlightened, and then to learn to do things, with less effort, great diligence; there is a good mentor naturally is my lucky thing, but the actual work is very rare, perhaps the predecessors of the occasional point of inspiration, But the most plain and reliable approach comes from reading.

How do you get started in the face of the job?

Unlike the vast majority of application books that programmers read, the first thing you talk about is attitude. Treat errors, untidy code, teamwork, and learning.

"My source let the cat eat." ”

1. We are proud of our capabilities, but for our shortcomings---our ignorance and our mistakes---we must be honest.

The best way to make a mistake is to admit your mistake and give a workable plan. Instead of looking for ridiculous excuses.

2. Do not leave "broken windows" (poor design, wrong decision, or bad code) not repaired. Find a fix one.

In the face of untidy code, it is like a broken window. You should find one and fix one. This is similar to our first reading of the code clean-up, where bad code pollutes the environment and eventually breaks down the entire project. Keep neat habits, find dirty code should be corrected in time.

The story of a stone soup, a few soldiers with a pot of stone, greet the villagers each out of the material, the results of a pot of delicious food stew. and mapping to life, most of the projects have to go through the process from 0 to 1, to do it requires the efforts of all parties. While everyone defends their own resources, people find it easier to take part in the successes that are taking place, to give them a glimpse of the future, and you will be able to gather them around you . Reminds me of a sentence: "If you want to build a boat, do not encourage people to wood, to assign jobs, to give orders." What you should do is to teach people to yearn for the vastness and vastness of the sea. --Saint--Exupery "

What people need is guidance, not restraint. In the face of learning, the face of increasingly changing technology? Knowledge management is like financial investment

3. Knowledge investment always gets the best return. Your knowledge and experience is your most important professional asset. Unfortunately, they are "aging assets" with the advent of new technologies, languages and environments, your knowledge will become obsolete.

We like to think of all the facts that programmers know about computer technology and the areas of application where they work, and all of their experience as their intellectual assets. Managing knowledge assets and managing financial assets are very similar:

1) Serious investors regularly invest in----as a habit.

-Invest regularly in your knowledge assets.

2) Diversification is the key to long-term success

-The more skills you have, the more you can adjust.

3) Smart investors balance their assets with conservative assets and high-risk, high-return investments.

It's not a good idea to buy all the money for risky stocks that could suddenly crash, and don't put all the technical eggs in one basket.

4) Investors try to buy low and sell high to get maximum return.

Java has just learned that it may be risky, but for those who have already moved to the top of the field, they have made very big returns.

5) Re-evaluate and balance assets periodically.

--Relive what you've learned.

The author gives three suggestions:

1) Learn at least one new language every year

2) read a technical book every quarter

3) also read non-technical books

What can be practiced?

Thought has a certain understanding, how to do next?

1.DRY (don ' t repeat yourself) principle: Every knowledge in a system must have a single, unambiguous, authoritative representation.

The main reason to avoid duplication is to reduce the cost of maintenance. The repetition of the text is not only the repetition of the code, but also the redundant annotations, superfluous design (attributes), encourage reading of other people's source code and documents, whether formal or informal, to learn, also do not because others read your code and distressed.

2. If the components are isolated from each other, change one of them without worrying about the rest of the components. Writing an orthogonal system can increase productivity and reduce risk.

Orthogonality shows some kind of non-dependence and decoupling in computer. If a thing changes without affecting other things, then these things are orthogonal. Orthogonal systems are easier to test and facilitate reuse; Another interesting variant of orthogonality is aspect-oriented programming, the familiar (Aspect-origin programming) AOP; In a project team, if the organization of the team has a lot of overlap, Every change will require the entire team to have a meeting, all of whom will be affected. This is also an orthogonal problem.

3. The purpose of prototyping is to answer a series of questions, which are much cheaper and quicker to develop than the products that are put into use. Prototyping is a learning experience. Its value is not in the generated code, but in the lessons learned.

Carmakers, for example, may create a clay model for testing air-wind tunnel experiments and a light-wood model test process. The difference between prototypes and tracer Bullets is that the prototype code can be discarded when it is used.

4. A language that is too simple may be easy to parse, but it may be obscure, so it is recommended to use a more complex and readable language first. The initial effort will yield many times the rewards of reducing support and maintenance costs.

The more the underlying language is more efficient, the more difficult it is to understand. Not only performance, time is an expensive cost.

工欲善其事 its prerequisite

1. Tools to magnify your talents. The better your tools, the more skilled you are, and the higher your productivity.

Instead of understanding the various development tools (editors), you should have a familiar, shortcut, command line that uses third-party plugins and so on.

2. Tool is the extension of the hand, it is recommended to master an editor, good editor should be configurable, extensible, programmable, auto-indentation, class IDE

You may think of the universe the first IDE, let you the unicorn arm faint seizure.

3. If you use the GUI to complete all tasks, you will miss some of your environment's abilities. The advantage of GUI is that what you see is what you get, and the disadvantage is what you see and what you gain.

Do not rely too much on the interface operation, remember some common commands, very helpful to improve efficiency.

4. One of the many benefits of source control is that it is a huge undo key. Good source control system can track changes, who changed this line of code? What is the difference between versions? Which file was most frequently changed. You can also manage the branches of the tree species, such as stable versions, new feature releases, and pre-release versions.

Coding is not just a person's business, it's not just a matter of the moment, cooked using a source control technology (GIT/SVN) to record your code.

5. To fix the problem, not to issue accusations; to find the root of the problem, not the specific manifestation of the problem

We have all met a dialogue like this: a: "xx problem", B: "I am not a problem on the computer ah" ..., the bug is your fault or other people's fault, not really very related. It's still your problem. Debugging may encounter repudiation, blame, the pretext of the foot, or even indifferent, this return to the first chapter of the first section of the attitude, to accept the fact: debugging is to solve the problem . Debugging issues that need to be considered

1) is the problem being reported as a direct result of the underlying bug or just a symptom?

2) where is the bug located? Is the problem with your code, or is there a problem with the component being called.

3) How do you explain the problem to your colleagues in detail?

4) If the suspect code passes the unit test, is the test complete enough?

5) Does this condition of the bug still exist elsewhere in the system?

6. Write code that can write code

When a carpenter faces a task of repeating the same thing, they trickery, make fixtures or templates so they can make a piece of work over and over again. The fixture takes away complexity and reduces the chance of error, allowing craftsmen to focus more freely on quality issues. Again, it is appropriate that you can use the code generator to increase your power.

To the Heights

1. Dealing with computer systems is difficult, it is more difficult to deal with people, we spend more time figuring out people's relationships, and the best way to ensure that both sides are Frank is the contract. The contract provides for your rights and responsibilities, as well as the rights and responsibilities of the other party. There is also an agreement on the consequences of failure by either party to comply with the contract.

according to the contract design , the document records the procedure declaration, and verifies each function or method in the software will do something, the beginning and the end all need to satisfy certain condition, the inheritance and the polymorphism is the object oriented language the cornerstone, is the contract can truly shine the domain.

2. There are many times when a program crash is your best choice, rather than bypassing the execution and even writing bad data to an important database.

The dead program does not lie . Exceptions to Java or C #, if not captured, penetrate to the top of the program until the program terminates and displays the stack information. The death program is much less harmful than a procedure with a disease.

3. Exceptions should rarely be used as part of the normal process of a program; exceptions should be kept to unexpected events.

For example, if you try to read a file in code and the file does not exist, should you throw an exception? This depends on the fact that if the file should be there (an important configuration file) then the exception should happen-something unexpected has happened. On the other hand if you do not know whether the file exists, then you can not find the file is not an exception, the return error is appropriate.

4. As long as the programming, we have to manage resources: memory, transactions, threads, files, timers-all the limited number of things. Many developers do not have a plan for allocating and releasing resources.

Write code to start and finish: such as the reading of the file, each time the opening has a corresponding closure. For a program that needs more than one resource at a time, the resource allocation is reversed in the reverse order of resource allocation; different places refer to the same group of resources in the same order (for example, a applies for Resource1, is applying for Resource2, and B applies for Resource2, are applying for Resource1, then these two processes will wait forever); In exception handling, ensure that the resource is freed before the program exits. The finally block in Java or C # makes it possible to do some processing when an exception occurs, and it is also a good thing to check the use of resources.

5. A key concept for creating flexible code is the separation of the data model from the view of the model (view is performance).

There are many systems that do not have to depend on relationships that are very difficult to maintain (and very expensive) and tend to be highly volatile. To minimize the direct coupling of the module. But decoupling also has a price, in practice sometimes need to write a large number of packaging methods, just transfer the request to the entrusted, these methods will bring the runtime cost. So there will be a compromise, through the opposite, so that the module tightly coupled in exchange for performance improvements. Therefore, do not decouple to understand the decoupling, to balance.

6. Most people think in a linear way, first A and B, which brings time coupling, we need to consider concurrency, and release any reliance on time or order, so that flexibility can be achieved.

Concurrency is considered at design time, which makes it easier to meet scalability or performance requirements.

7. Metadata is data about the data. Is any data that describes the application

Model metadata in ASP. Modelmetadata is a good example. Metadata is used to make highly configurable systems such as algorithms, database products, middleware technologies, and user interface styles as configuration options, rather than through integration or engineering implementations.

when you encode ...

This attitude is one of the biggest reasons why many programs are ugly, inefficient, poorly structured, non-maintainable, and completely wrong, if only the mechanical design translates into executable statements.

1. Learn to estimate the time of your algorithm and find the right algorithm. For example, when the collection is very small, the performance of the direct insert sort will be as good as the quick sort, and you will have less coding and debugging time.

The time of the overhead can be estimated based on the complexity of the algorithm. For example, some common algorithms, simple loops : It is possible that O (n) time increases linearly with N; nested loops : If another loop is nested within the loop, the complexity of the algorithm is O (m*n), which is O (n^2); dichotomy: Your algorithm divides things into two in each loop, so the complexity is logarithmic o (log (n)), divide and conquer : Divide the input and process it independently on two parts, and then combine the results with an O (NLN (n)); : As long as the algorithm takes into account the arrangement of things, its running time may be out of control. If it comes to factorial, 5! = 120.

2. Rewriting, re-doing, and re-architecting code together is called refactoring.

You should consider refactoring the code when the following features appear:

1) Repeat, you found a violation of the dry principle.

2) Non-orthogonal design (one module change will affect the other module).

3) Outdated knowledge, things have changed, demand has shifted, your understanding of the problem deepened. The code needs to keep up with these changes.

4) performance. To improve performance, you must move the feature from one area of the system to another.

3. Test your software, or your users will have to test it. Testing is a technology, but a culture. No matter what language you use, try to get this culture into the project.

Write code that is easy to test and do not rely on testers to test. Make sure it is OK before the code is handed out or submitted.

Talk about projects and requirements

If you have a feeling that your project is doomed to failure, perhaps you can now suggest ending it and saving some money for the funder.

1. When digging for demand, find out why users do specific things, not just the way they do it at the moment. Your development must solve their business problems, not just meet their stated needs.

2. Become a user of the product. Work as a user and think as you do.

We can easily be sucked into the "just add another feature" of the huge vortex, often the demand side changed and changed. But the ultimate goal of our work is to make things happen, not just knock out the code. To understand the needs, understand the user, will make a good product.

3. Don't think outside the box, but find the box.

Sometimes project design is not a clue, or it is found that the code is difficult to write, or the problem seems to be unresolved. The ' box ' here refers to the boundaries of various constraints and conditions, and the key to solving the puzzle is to determine the various constraints that are added to you and determine the degrees of freedom you have so that you can find a solution.

4. Don't be a slave to the form method.

We like to have some techniques and methods, but we believe that blindly adopting any technology without putting it into your development practice and ability environment will surely disappoint you.

Remember, focus on effectiveness

1. Quality is a team problem, and the most diligent developer who is assigned to a team that doesn't care about quality can hardly keep his passion for correcting trivial issues. The team as a whole, should not tolerate broken windows (small, no correction of imperfect), must be responsible for the quality of the product.

The quality of the product is the sign of the team.

2. The manual process does not guarantee consistency, nor can it guarantee repeatability.

Driving internal automation, such as Project compilation, is a trivial task that should be reliable and repeatable, and ccnet can be used under. Net. Write the program not to let the program tired. Use tools or develop your own tools, using automation solutions.

3. Finding bugs is like netting fishing, we capture small fish with small nets (unit tests), and catch sharks with coarse nets (integrated tests). Sometimes the fish will try to escape, so in order to catch the swimming in the project pond, more and more cunning fish, to fill up any loopholes found

This metaphor is good. The test is divided into three areas, what to test, how to test, and when to test.

Test

4. Try to make the document a form of online publishing so that readers can learn what is up-to-date and what has changed.

Similar to tools such as Javadoc and doc++, API-level documentation can be generated based on the source code. Documents and code are different views of the same underlying model, and do not make documents into second-class citizens.. NET can be used sandcastle to generate documents based on XML annotations, or to create online. The document was done and was a walnuts posterity move.

5. The success of the project is measured by how much it satisfies the user's expectations. Users begin with the imagination of what they need to come to you, which may be incomplete, inconsistent, or technically impossible. But like Christmas kids, they put in some feelings and you can't simply ignore it.

The following chapters have risen to the project manager's point of view, although just as a member of the team, having these awareness is a good team consciousness, not simple I speak very well on behalf of others can cooperate with me happily.

6. Encourage the signature on your work, "This is what I wrote, I am responsible for my work." ”

---restore content ends---

To the ranks of better programmers