40 good habits and behavioral ways for efficient programmers

Every good habit, the beginning will be corresponding to a dissenting sentence oh. 1 work "Out of the question, the first important thing is to identify the culprit and find that person." Once proven to be his fault, it is assured that such a problem will never happen again. "Accusations don't fix bugs, they point at the solution to the problem, not people." This is the positive effect of the really useful place. You may not believe it, but there are people who do not always put the problem to the top priority. Maybe you didn't. First self-reflection, when there are problems, "the first" reaction is what. A major mistake should be seen as an opportunity to learn rather than to accuse others. Team members work together and should help each other, rather than blaming each other. If you have not made any mistakes, you may not be working hard. 2 "You do not need to really understand the code, it is as long as it can work." Oh, it needs a little tweaking. As long as you add a few lines of code to the result, it works. Do it. Just add those lines of code and it should work. "The clumsy code worker would change the code without thinking, then quickly turn to the next one, and the good programmer would dig deeper and try to understand why it needed to add 1, and more importantly, he would figure out what other effects it would have." Dikes, Yixue, the catastrophe is a gradual evolution. Time and time again the quick fix, each time does not explore the root cause of the problem, has formed a dangerous swamp, and eventually will devour the life of the whole project. If a team member announces that a piece of code is difficult for others to understand, it means that it is difficult for anyone, including the original author, to maintain it. Please make it easier. 3 It's not right. "When Mr. L was introducing a new scheme, someone would say, ' This is a stupid design. are not considered thread safe. ' (It also implies that Mr. L is stupid). "In fact, the most suitable and most effective way to express it should be" Thank you, Mr. L. But I want to know what happens if two users log in at the same time. "Try to contribute to your good ideas, and if your ideas are not being adopted, don't be angry; don't give up the idea of a good idea because you just want to reflect your thoughts." 4. "The rats are going to tie a bell around the cat's neck so that when the cat patrols the perimeter, it can be alerted beforehand." Every mouse nodded and thought it was a brilliant idea. Then an old mouse came up and said, ' Well, who's going to stand up and tie the bells? There is no doubt that no mouse stands out. Of course, this wonderful plan is gone. Sometimes, a wonderful plan will fail because of lack of courage. Although the front is dangerous, you must have the courage to charge forward and do what you think is right. When you stand up bravely, if you are resisted by a person with a lack of background knowledge, you need to use the words they can understand. "More clearThe clear code "is unable to impress the businessman." Saving money, getting a better return on investment, avoiding lawsuits and increasing user interest will make the argument more convincing. 5 Tracking Change "software technology has changed so fast and unstoppable, and that is its nature. Continue to use your familiar language to do your old line, you can not keep up with the pace of technological change. "It's not enough if you just have the skills you need at work. That kind of work may not be there after a few years-it will be outsourced or obsolete, and you will be out. iterative and incremental learning; get to know the latest quotes, participate in local user groups, attend seminars, and read them eagerly. 6 Investing in the team "don't share your knowledge with others-keep it for yourself." You are the best in the team because of this knowledge, as long as you are smart enough, not to worry about other losers. "The team's developers have different abilities, experiences and techniques. Everyone has their own strengths. Different talent and background of people mixed together, is a very ideal learning environment. A learning-oriented team is a better team. Weekly, ask one person on the team to chair the lecture. He will introduce you to some concepts, presentation tools, or whatever the team is interested in. You can pick a book and tell people about some of the special content, projects or practices, whatever the subject. 7 Know how to discard "That's your usual way of working, and for a reason." This method is also good for you to use. You have mastered this method at first, and it is obvious that it is the best method. Really, don't change it ever since. "It's hard to break old habits and it's harder to be aware of the problem. The first step in discarding is to realize that you're still using outdated methods, which is also the hardest part. Another difficulty is to really discard the old habits. After all, cars are much stronger than wagon carriages. Instead of forgetting the old habits completely, use them only when using the right technology. 8 Breaking the casserole ask the bottom: "Accept someone else's explanation and tell you where the problem is, and see where it is." No need to waste time to get to the bottom of the question. Don't just be content with what others are telling you, keep asking questions until you understand the root of the problem. Ask "why," but ask the idea. When you ask "why", you may be asked: "Why do you ask this question?" ”。 Before asking questions, think about your reasons for asking questions, which will help you to ask the right questions. 9 Grasp the development rhythm "We haven't done code review for a long time, so we'll review all the code this week." "In many unsuccessful projects, there is basically a random schedule of work, and there are no rules. That kind of random arrangement is difficult to deal with. You have no idea what will happen tomorrow. However, agile projects have a rhythm and loop that makes development easier. Scrum has agreed that demand changes should not occur within 30 days to ensure that the groupThe team has a healthy development rhythm. (Scrum is an iterative, incremental software development process that is typically used for Agile software development.) Includes a series of process skeletons that practice and pre-define roles. Standing meetings are best held every day at a fixed time and place, such as around 10 o'clock in the morning. To develop such a habit, you are ready to attend a standing meeting at that time. 10 Let the customer make the decision "the developer is innovative and intelligent and knows the application best. Therefore, all key decisions should be made by the developer. Every time a business person gets involved, it makes a mess, and they can't understand the logic of our work. "In terms of design, developers must be involved in making decisions. However, in a project, they should not make all decisions, especially business decisions. Record the decision made by the customer and indicate the reason. A good memory is inferior to a bad pen. 11 making design guidelines rather than manipulating development "design documents should be as detailed as possible, so that low-level code workers just typed in the code." When you write code, you can't deviate from the design document, no matter what you find. "The design satisfies the implementation, without being overly detailed. Even if the design document has been submitted before, there are some unexpected scenarios. Keep in mind that the design presented at this stage is based on your current understanding of the needs. Once the code is started, everything will change. Design and its code implementation are constantly evolving and changing. The design can be divided into two layers: strategy and tactics. Pre-design is a strategy, usually only when there is no deep understanding of the need for such a design. Rather, it should only describe the overall strategy and should not go deep into specific details. 12 Rational use of technology "you've started a new project, and there's a long list in front of you about new technologies and application frameworks. These are good things and you really need to use all the techniques in the list. Think about it, your resume will be a nice one, with those great frameworks, your new application would have a very high technical content. "Does this technical framework really solve this problem?" (if needed, make a small prototype first) you will be tethered to it. (Some technology is pirate, once you use it, it will be locked up, it can no longer turn back.) We need to consider whether it is open technology or patented technology) how much maintenance costs. (Maintenance costs are expensive.) We heard that a project contract is to support a rule engine, the engine maintenance cost is $50,000 a year, but the database only 30 rules) do not need to develop what you can download. New technology should be like a tool that can help you work better and it should not be your job. 13 Keep Available "We found a problem when we tried it, you need to fix it now, put down your work, and fix the problem you just found." Don't tell anyone else-just let it work. "The submitted code should be ready to act." Run the test locally, check out the latest code, commit the code。 14 early integration, frequent integration "as long as there is no end to the development phase, do not waste time to think about how to integrate your code, at least until the development of the same time, you can consider it." "One of the main features of agile is the continuous development, not the Notwith two days to work. Especially when several people develop the same function together, the code should be more frequently integrated. Never make an explosion-like integration. Code integration is a major source of risk. To avoid this risk, only early integration, continuous and regular integration. 15 Automate deployment Early "No problem, you can install the product manually, especially for quality assurance personnel. "The system can run on your machine, or it can run on the developer and Tester's machine, but it also needs to be able to be deployed on the user's machine." Quality assurance personnel should test the deployment process. Delivery starts from day one and automates deployment of applications from the start. If maintaining the installation script becomes difficult, it is likely to be an early warning indicating a high maintenance cost. 16 using demos to get frequent feedback "customers are constantly changing their needs, causing us to seriously postpone." They should think of everything they want at once and give us those needs. "The demand is like a flowing ink. You can't freeze demand just as you can't freeze markets, competition, knowledge, evolution, or growth. Even if you do freeze, it's probably freezing the wrong thing. Inconsistent terminology is a major cause of misunderstanding of demand. Therefore, a project glossary needs to be maintained. People should be able to access it publicly, usually in a wiki or intranet. After the project has been launched for some time, you should be in a comfortable state where the team and the client have established a healthy and creative relationship. 17 Using short iterations, incremental release "We have developed a beautiful project plan for the next 3 years, listing all the tasks and deliverables. As long as we release the product, we can occupy the market "give me a detailed long-term report, I will give you a doomed project." For large projects, the best way is to step forward, which is the core of the agile approach. Leaps and bounds greatly increase the risk, small steps forward to help you to grasp the balance well. 18 Fixed price means betrayal promise "for this project, we have to have a fixed quote." Although we do not know the specifics of the project, we still have to have an offer. "Fixed-price contracts can be a big challenge for agile teams. We've been talking about how to work in a continuous, iterative, and incremental way. But now some people come running around and want to know how much time and cost it will take. Software projects are inherently fickle and non-repeatable. 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 now, you have to provide a fixed price, then you need to learn the realGood evaluation 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're a good programmer too-unit testing can only be a waste of time. "Unit tests provide feedback unit tests to make your code more robust unit testing is useful when you are confident that the backend unit test is a trusted document unit test is the learning tool 20 to use it to implement it first" go ahead and complete all the library code. There will be plenty of time to see how the user thinks. Now just throw the code over the wall and I'll make sure it's fine. "Many successful companies live by eating their own dog food. In other words, if you want to make your product as good as possible, you should actively use it first. Before programming, write tests first. First write the test, you will stand in the perspective of the code users to think, and not just a simple implementation, this is very different, you will find that because you want to use them, so you can design a more useful, more consistent interface. 21 different environments, there are different problems "as long as the code can be run on your machine, who will care if it can work on other platforms, you do not have other platforms." "A colleague's code failed and finally found the culprit: one. The API in the net environment behaves differently on Windows XP and Windows2003. platform, resulting in a different result. Run unit tests on each supported platform and environment using the durable integration tool, and be proactive in finding problems rather than waiting for a problem to come to you. 22 Automated Acceptance Testing "Well, you now use unit tests to verify that your code is doing what you expect." Send it to the customer. We will soon know if this is the user's desired function. "Critical business logic has to be rigorously tested on its own, and ultimately needs to be approved by the user." However, you can not pull the user, a module to confirm. So you need to be able to automatically compare what users expect and actually do. FIT (fit.c2.com), an integrated test framework, is useful for defining test cases and comparing test results data more easily with HTML tables. 23 Measure real Progress "report the progress of your work with your own schedule. We will use it to make the project plan. Do not worry about the actual working hours, fill 40 hours a week. "The timetable is difficult to realistically reflect the completion of the work, so it cannot be used for planning, evaluation or performance evaluation." Have you ever heard a developer report a task completed in 80%? However, after a day, week after week, the task is still completed 80%. It makes no sense to arbitrarily measure with a ratio. So instead of calculating the percentage of work done, you should determine how much work remains to be done. If you initially estimated that this task would take 40 hours, after 35 hours of development,You think you need another 30 hours of work. That's a very important measure (it's important to be honest here, to conceal the truth) and focus on the function, not the schedule. 24 Listen to the user's voice "the user just complains." This is not your fault, the user is too stupid, even the use of manuals can not understand. It is not a bug, but the user does not understand how to use it. They should have known more. "Whether it's a bug in a product, a bug in a document, or a bug that's understandable to the user community, it's a team problem, not a user's problem." For some software, unlucky users must configure fuzzy system files that contain some magic numbers, or the system will not run at all. The system has neither an error message nor a crash, just a large black screen and a bucket with a large "exit" button. Behind every complaint lies a fact. Find out the truth and fix the real problem. There are no stupid users, only stupid, arrogant developers. "That's the way it is." "That's not a good answer. Your users will probably read all the documents and remember all of them. But it may not. 25 code to clearly express the intent "the code that works and is easy to understand is certainly good, but it makes people feel smarter and more important." People give you money because you have a lot of brains, so let's see how smart you really are. "There are two ways to design software," says Hoare. One is designed to be as simple as possible, and obviously without defects. Another way is to design as complex as possible and without obvious flaws. (Hoare created the ALGOL 60 programming language and invented the fast sorting algorithm.) Received the Turing Award in 1980. The number of code reads is much more than the number of writes, so it's worth the effort to make it easier to read when writing. The quality of this code can be imagined when developers are surrounded by code like a group of bystanders, feeling fearful, confused, and helpless. See an example: Coffeeshop.placeorder (2);//By reading the code, you can roughly understand that this is the next order in the coffee shop. But 2 stands for what it means.
Coffeeshop.placeorder (2 */Large cup */); You may want to add some comments. But annotations are sometimes designed to help trap poorly written code.
public enum Coffeecupsize
{
Small,
Medium,
Large
}
Coffeeshop.placeorder (Coffeecupsize,large);//If you use the enumeration values, the code is at a glance. You should allow yourself or anyone else on your team to read the code you wrote a year ago, and read it once and know its operating mechanism. 26 Communicate with code "to explain exactly what the code does, each line of code is annotated." Just tell us what to do if you don't have to worry about how to encode it. "The source code can read, not because of its annotations, but because it is elegant and clear." Try to avoid the use of cryptic variable names. (i is commonly used for cyclic index variables, and STR is commonly used to represent strings.) If you use STR to denote a cyclic index variable, it is really not a good idea to use a comment where the code can explicitly pass the intent. Annotations that explain what the code does are less useful. Instead, the comment explains 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. Every item must be in the best condition. "Instead of taking the time to improve performance by 1 per thousand, it may reduce development input, reduce costs, and make it more valuable as soon as the application is marketed." If the additional resources and energies are being invested in the future, it is necessary to make sure that the investment will be rewarded. (In most cases, it will not be rewarded) 28 incremental programming "The real programmer writes the code, and the worked is a few hours, not even a head." Don't stop to compile your code, just keep writing down. "If you don't test your code, make sure you don't have a problem, you don't have to do it for hours, or even a few minutes in a row," he writes. Instead, you should use an incremental programming approach. With incremental programming and testing, you tend to create smaller methods and more cohesive classes. You should always evaluate the quality of your code, not when you make a lot of small adjustments, rather than modifying many things at once. After you've written a few lines of code, you're desperate to build/test. When you don't get feedback, don't go too far. 29 Keep It simple "by writing the most complex program in history, you will get a reputation and recognition, not to mention keeping your job." "Andy used to know a guy who was obsessed with design patterns and wanted to use them all. Once, write a code program of about hundreds of lines. He has successfully applied 17 design patterns to the poor program before being discovered by others. -This should not be the way to write agile code. The problem is that many developers tend to confuse input efforts with procedural complexity. If you see a solution given by others and evaluate it as "very simple and easy to understand", chances are that you will make the designer unhappy. Many developers take pride in the complexity of their own programs, if they can hear "WOW, this is difficult, must have spent a lot of time and energy to do it. Then they met with a proud smile. Instead, developers should be proud of their ability to create a simple and usable design. Simplicity is not humble. 30 writing the cohesive code "you have to write some new code to see which class is now open in the IDE, just add it." If all the code is in a class or component, it is convenient to find it. "Cohesion is used to evaluate the functional relevance of a member in a Build (package, module, or accessory). The high degree of cohesion indicates that each member has completed a functional feature or a set of functional features together. A low degree of cohesion indicates that the functions provided by the individual members are mutually irrelevant. Classes are also subject to cohesion. If a class's methods and properties work together to accomplish a function, the class is cohesive. However, do not divide some things into a lot of small parts, and make it lose the practical value. When you need a sock, a box of cotton can not give you any help.   31 Let's not ask "don't trust other objects." Get the information you need from someone else, then handle it yourself and make your own decisions. Don't give up the chance to control others. " Tell = command, ask = Query
Command and query separation mode, is to divide the functions and methods into two types of command and query, and recorded in the source code, so that the command codes are put together, and all the query code together.
It is absolutely impossible to allow a seemingly innocent "query" to modify the state of an object. 32 Replace by contract "deep integration is great. If you need other classes of functions, just inherit them directly. "The key way to maintain system flexibility is that when new code replaces the original code, other existing code will not be aware of any differences."
If you're not sure what kind of commitment an interface makes, or what needs it, it's hard to provide a meaningful implementation of it. 33 Logging The problem solving log "does not often encounter déjà vu in the development process." It doesn't matter, the problem that has been solved before, can still be solved now. "Facing problems is a way of life for developers. When the problem happens, we want to remember how it was solved the first time, and hopefully we can get it done faster next time. However, sometimes we can't remember how the last time it was fixed.
Don't fall two times in the same place.
For better results, maintain a log of the problems you've encountered and the solutions we call daily logs (Daylog).
You can choose any format that meets your needs, and the following may be helpful: date of issue
Problem Brief
Detailed description of the solution
Cite an article or URL to provide more detail or information about any snippets, settings, or Screenshots of a dialog box, as long as they are part of the solution, or help to understand the details more deeply.
Be sure to change the above information into a computer-searchable format. 34 warnings are errors "the compiler's warning message is only for those who are too careful and too nerdy to watch." They're just warnings. "Some warnings are benign byproducts of overly picky compilers, but some are not. For example, a warning about unused variables may not have a bad effect, but it is possible to imply that some variables are being used incorrectly.
Checking in code with warnings is just as bad as checking in code that has errors or does not pass the test. 35 to the question conquer "to debug an obvious error, just go through the code of the entire system and do it all over again." After all, you don't know where the problem might be, and that's the only way to find it. "The positive effect of unit testing is that it forces the formation of code hierarchies. To ensure that the code is testable, it must be freed from the perimeter code.
The first step in understanding complex problems is to separate them.
Many of the application's code did not notice this when it was written, making separation particularly difficult. Each component part of the application is entangled with each other: to take this part separately, the others will follow. In these situations, it's a good idea to take some time to extract the code of interest and create a test environment that allows it to work. 36 Report All exceptions "do not let the debugger of the program see those strange exceptions." It is your responsibility to deal with them. Wrap up everything you call, and then send your own definition of the exception. "The author has been hit by the use of a very popular open source library. A method that the author invokes should have created an object, but the results are null, and the investigation has been long gone without a clue. Fortunately this library is open source, so he downloaded the source code, and found the problem of the calling method. The method thinks that some necessary components are missing from her system. This underlying method throws an exception with related information. However, the upper method secretly uses an empty catch code block with no exception handling code, ignores the exception, and throws a null. Later, the author installed the corresponding components, the problem solved. 37 Provide useful error messages "Don't scare users, scare programmers, and give them clean and tidy error messages." "When designing a landing page, when the user loses the wrong password, we suggest which information is better:" Unable to perform operation "," couldn ' t login ... "or" Error validating password "
Error messages help solve the problem. When a problem occurs, you can study the details of the problem and the context in which it occurred. 38 scheduled meeting time "the more meetings are arranged, the better. In fact, we have more meetings to arrange. "The stand-up meeting, the first introduction of scrum and a practice highlighted by extreme programming, is a great way to bring teams together and let everyone know what's going on right now." As the name implies, participants are not allowed to sit in the Legislative Council, which ensures that the meeting will be expedited. Once a person sits down, the meeting lasts longer because of comfort.
To ensure that the Council issues are not divergent, everyone can only answer the following three questions: What was the harvest yesterday?
What do you plan to do today?
What obstacles are facing everyone is looking forward to the meeting, hoping to get to know each other's progress and work on hand, and not afraid to bring out the problems they encountered in public discussion. 39 Architects must write code "our expert architects will provide a well-designed architecture for you to write code for." He's got a lot of experience and a high salary, so don't waste his time with stupid questions or difficulties. "These architects usually get involved at the start of a project, draw a variety of designs, and then leave before important code implementations begin." There are too many such "PowerPoint architects". Because feedback is not available and the design evolves over time, their architectural design work will not be very effective.
The designers of the new system must be personally committed to the implementation. 40 Implementing the code collectively "Don't worry about the annoying Bug,joe coming back next week after the holiday is over." Let's think of a stopgap before you do that. "It should not be the same as the state claiming ownership of the territory, declaring the individual's ownership of the code." Any team member who is important to understand the context of a piece of code should be able to handle it. If a piece of code has only one developer to deal with, the risk of the project is virtually increased.
It is more important to solve the problem and make it meet the expectations of the user than to find out who has the best idea and whose code is the most rotten.
In a large project, if everyone could change any code at will, it would make a mess of the project. The collective ownership of code does not mean that it can be destroyed arbitrarily.Five years of programmer life 15 suggestions to the IT newcomer, also the old programmer's introspection and summary Relax your heart. It backbone is still very popular, regardless of domestic and foreign, do your career planning no doubt: Move to the developer's foreground and "money scene" a bright Programmer level 10 grade, your level belongs to which level. some misunderstandings in Java programming language Not every programmer is fit to start a business, even if you've worked for ten years The software developer is as fierce as a tiger Terminal China Mobile phone sales have reached tens of millions, 80% for the smart machine programmers do not do "sand Monk", pick the death of the credit, No. 71 Classic Android face questions and answers-important points of knowledge involve