45 habits of efficient programmers-3

Before reading this article, please first understandProgramMember's 45 habits "-2.

Each issue involves 15 topics. These 45 habits are listed in the three phases. Each time they are not greedy, they are greedy. If you are free, you must savor these 15 habits.

Note: Each good habit starts with a reversed sentence.

 

16 use the demo to get frequent feedback

"Customers constantly change their requirements, resulting in a serious delay. They should think about all the things they want at one time and then give them to us ."

The demand is like a flowing ink. You cannot freeze demand, just as you cannot freeze the market, competition, knowledge, evolution, or growth. Even if you have actually frozen, it is likely that you have frozen the wrong thing.

Inconsistency is a major cause of misunderstanding. Therefore, you need to maintain a project glossary. People should be able to access it publicly, usually on the Wiki or intranet.

After the project starts for a period of time, you should enter a comfortable state. The Team and the customer have established a healthy and creative relationship.

17 use short iterations and incremental release

"We have made beautiful project plans for the next three years, listing all the tasks and deliverables. As long as we release products at that time, we can seize the market"

Give me a detailed long-term report, and I will give you a project destined to be finished.

For large projects, the best way is to move forward with small steps, which is also the core of agile methods. Large strides greatly increase risks. Small strides can help you grasp the balance well.

18 A fixed price means a breach of commitment

"For this project, we must have a fixed quotation. Although we still do not know the specific situation of the project, there is still a quotation ."

Fixed-price contracts will be a major challenge for agile teams. We have been talking about how to work in a continuous, iterative, and incremental way. But now some people come over and want to know how long it will take and how much it will cost.

Software Projects are inherently changing and cannot be repeated. If you want to give a fixed price in advance, you will almost certainly not be able to comply with the development commitment.

If you have no choice but to offer a fixed price, you need to learn exactly the right assessment skills.

19 guardian angel

"You don't have to spend that much time and effort on unit testing. It will only delay the progress of the project. Well, you are also a good programmer-unit testing will only waste time ."

Timely feedback for unit testing

Unit test makes yourCodeMore robust

Useful design tools for unit testing

Unit Testing is your confident background

Unit testing is a trusted document

Unit testing is a learning tool

20 first use it to implement it

"Move forward, complete all the library code first. There will be a lot of time to see how users think. Now you only need to throw the code over the wall. I promise it will be okay ."

Many successful companies rely on eating their own dogs. That is to say, if you want to make your product as good as possible, you must actively use it first.

Write test before programming.

If you write a test, you will think from the perspective of the Code user, not just a pure implementer, you will find that because you want to use them, you can design a more useful and consistent interface.

21. Different environments have different problems.

"As long as the code can run on your machine, who will be concerned about whether it can work on other platforms, and you don't need other platforms ."

A colleague's Code failed and finally found the culprit: the API in A. NET environment has different behaviors on Windows XP and Windows2003. Different platforms lead to different results.

When using persistent integration tools to run unit tests on every supported platform and environment, you need to actively locate the problem rather than wait for the problem to come to you.

22 automated Acceptance Test

"Well, you are now using unit tests to verify that the Code has completed what you expected. Send it to the customer. We will soon know whether this is a feature that the user expects ."

The key business logic must be strictly tested independently and approved by the user. However, it is impossible for you to pull the user and check the modules one by one. Therefore, you must be able to automatically compare user expectations and actual work.

FIT (fit.c2.com) is an integrated test framework. It is very practical and can easily use HTML tables to define test cases and compare test result data.

23. measure the real progress

"Report the progress with your own schedule. We will use it for project planning. You don't have to worry about the actual working hours. You can fill up 40 hours a week ."

The schedule is difficult to reflect the actual completion of work, so it cannot be used for planning, evaluation, or performance evaluation.

Have you ever heard a developer report that a task has completed 80%? However, after one day, one week, and one week, the task is still 80% completed.

It is meaningless to use a random ratio for measurement. Therefore, we should not calculate the percentage of work completion, but determine how much work is not completed. If you initially estimated that this task would take 40 hours, and after 35 hours of development, you think it would take another 30 hours. Then we get a very important measurement result (honesty is very important here, and it is meaningless to conceal the truth)

Focus on the function, not the calendar.

24. Listen to your voice

"Users complain. This is not your fault. It is because the user is too stupid to understand the user manual. It is not a bug, but the user does not understand how to use it. They should have known more ."

Whether it is a product bug, a document bug, or a userCommunityA bug is a team issue, not a user issue.

For some software, unlucky users must configure the fuzzy system files that contain some magic numbers, otherwise the system will not run at all. The system neither prompts nor crashes, but displays a large black screen and a "quit" button.

There is a fact hidden behind every complaint. Find out the truth and fix the real problems.

No stupid users; only stupid and arrogant developers.

"It is like this ." This is not a good answer.

Your users may read all the documents and remember all the content. But it may not.

25 The Code should clearly express its intent

"The code that can work and is easy to understand is certainly good, but it makes people think that intelligence is more important. It's because someone else gives you money. Let's see how smart you are ."

Hoare says, "There are two ways to design software. One is to make the design as simple as possible without obvious defects. Another way is to design as complex as possible without obvious defects ."

(Hoare creates ALGOL 60Programming LanguageAnd invented quick sortingAlgorithm. Received the Turing Award in 1980 .)

Code Reading times far exceed writing times, so it is worth a little effort to make it easier to read.

When developers are surrounded by code like a group of onlookers who see UFOs and feel fear, confusion, and helplessness, the quality of this code can be imagined.

Let's look at an example:

Coffeeshop. placeorder (2); // by reading the code, you can see that this is the next order in the coffee shop. But what does 2 mean?
Coffeeshop. placeorder (2/* large cup */); // you may wish to add some comments. However, annotations are sometimes used to make up for missing codes that are not well written.
Public Enum coffeecupsize
{
Small,
Medium,
Large
}
Coffeeshop. placeorder (coffeecupsize, large); // If the enumerated value is used, the code is clear at a glance.

Let yourself or anyone else in the team understand the code you wrote a year ago, and read it only once to understand its operating mechanism.

26 communicate with code

"To precisely explain what the code has done, add comments to each line of code. You don't have to worry about the encoding. Just tell us what we have done ."

Source codeIt can be understood, not because of the annotations, but because it is elegant and clear.

Avoid using mysterious variable names whenever possible. (I is often used for loop index variables, and STR is often used to represent strings. It is not a good idea to use STR to represent the variable of the cyclic index)

Do not use comments when the Code clearly conveys the intent.

The comments used to explain the Code are not that useful. On the contrary, the comment should explain why the code is written like this.

27 dynamic evaluation trade-offs

"Performance, productivity, elegance, cost, and time to market are critical factors in the software development process. Each item must be in the ideal state ."

Rather than spending time improving the performance by 1‰, it may reduce development investment, costs, and make the application market more valuable as soon as possible.

If you invest additional resources and energy for future benefits, you must confirm that the investment must be rewarded. (In most cases, there will be no return)

28. incremental Programming

"A real programmer writes code for a few hours without interrupting the head. Don't stop to compile your code, as long as you keep writing down !"

If you do not test your own code and make sure there is no problem, do not contact for several hours or even programming for several consecutive minutes. Instead, incremental programming should be adopted.

Using incremental programming and testing tends to create smaller methods and more cohesive classes. You should often evaluate the code quality and make many small adjustments from time to time, instead of modifying many things at a time.

After writing a few lines of code, you will be eager to perform a build/test. Do not go too far without feedback.

29 keep simple

"By writing the most complex programs in history, you will be well known and recognized, not to mention saving your job ."

Andy once knew a guy who was fascinated by design patterns and wanted to use them all. At one time, I had to write a code program with hundreds of lines. Before being discovered, he has successfully applied 17 design patterns to the poor program. -This should not be the way to write agile code.

The problem is that many developers tend to mix effort with program complexity. If you see the solutions provided by others and comment that they are "very simple and easy to understand", it is very likely that you will make designers unhappy. Many developers are proud of the complexity of their own programs. If you can hear "wow, this is very difficult. It must have taken a lot of time and effort to make it ." Then they met with a proud smile. Instead, developers should be proud to be able to create a simple and usable design.

Simple and not simple.

30 compile cohesion code

"You need to write some new code to see which class is opened in IDE, and then add it directly. It is very convenient to find all the code in a class or component ."

Cohesion is used to evaluate the functional relevance of members in a build (package, module, or accessory. A high degree of cohesion indicates that each member has completed one feature or a group of features. Low cohesion indicates that the functions provided by each member are irrelevant.

Class should also follow cohesion. If the methods and attributes of a class complete a function together, this class is cohesive.

However, do not divide some things into many tiny parts, and make them lose practical value. When you need a sock, a box of Cotton Threads won't help you.

ArticleReproduced from: http://roclinux.cn/