Agile development: 45 habits of efficient programmers [reprinted]

I. Attitude determines everything

1. The highest priority should be to solve the problem, not to find the culprit. The accusation cannot fix the bug.

2. Speed is not up to speed: time and energy should be invested to keep the code Clean and bright. Without in-depth understanding of the real problem and possible consequences, you can quickly modify the code. This only solves the surface problem and will eventually lead to major problems.

3. Wrong people: without personal emotions, you are not blindly accepting all opinions. Use appropriate words and reasons to explain why you disagree. Don't condemn, don't judge, just simply express your point of view. Because negative comments will kill innovation.

4. overcome all the difficulties and move forward: refactoring of low-quality code may require a lot of courage, but if you compromise on this, the problem will deteriorate further. When you do not understand the code, do not easily deny and rewrite them. It is not courage, but reckless.

2. Endless learning: we must learn new technologies and methods, and discard outdated and outdated development methods.

1. Tracking changes: you do not need to be proficient in all technologies for iterative and incremental learning, but you need to be aware of the industry trends to plan your projects and career.

2. Investing in the team: the team members are complementary.

3. Discard: when learning a new technology, discard the old habit that will stop you from moving forward.

4. Break the casserole and ask the question to the end: You can't just ask why, but you can't just satisfy the superficial symptoms that others tell you, and think about the reason before asking a question, because the other party may ask "Why are you asking this question"

5. Grasp the development pace: at the end of each day, test the code, submit the code, and there is no residual code, and iterate with a fixed and regular length.

3. Deliver the software that users want to use: early integration and frequent integration, enabling release and easy deployment to users

1. Ask the customer to make a decision: the coder should not make a decision on the business side, explain the problems in a language that the business owner can understand, and ask them to make a decision.

2. Let the design guide instead of manipulating the development: the design can be implemented without too much detail. Strict requirements-design-code-testing are derived from idealized waterfall development. Agile development can avoid excessive design.

3. Use technology properly: do not develop anything you can download. Each technology has advantages and disadvantages, whether it is an open source product or a commercial product, framework, tool, or language, be sure to understand its advantages and disadvantages.

4. Keep publishing: Remember a simple workflow, run the test locally, check out the latest code, and submit the code.

5. Early inheritance and frequent integration: To keep subsystems growing without system integration, you can put yourself at an increasing risk step by step.

6. implement automatic deployment in advance.

7. Use the demo to get frequent feedback.

8. Use short iterations and incremental releases: Short iterations make people feel focused and efficient, and can see an actual and definite goal. A strict deadline forces you to make tough decisions without long-standing pending issues.

9. A fixed price means a breach of commitment.

4. agile feedback

1. Guardian Angel: write code that can generate feedback. Nunit, JUnit

2. Use it to implement it again: TDD, test, driven, and development test-driven development. Before programming, write test first, so that you can design more useful and consistent interfaces.

3. Different environments have different problems: tests must be performed on multiple platforms and multiple compiling environments.

4. automatic acceptance test.

5. measure the actual progress: it is best to judge the progress based on the actual time spent instead of the estimated time.

6. Listen to the user's voice: The fact is hidden behind every complaint of the customer to find out the truth and fix real problems.

Five agile Coding

1. clearly express the intent of the Code: the priority of the Code clarity level is prior to the execution efficiency, and it is necessary to write clear code instead of clever code.

2. Communicate with code: Do not wrap your code with comments. With carefully selected names and clear execution paths, the Code does not need to be commented out.

3. Dynamic Evaluation trade-offs: There is no optimal solution, only the most suitable solution, and dynamic evaluation trade-offs between performance, productivity, elegance, cost, and time to market.

4. incremental programming: using incremental programming and testing will tend to create smaller methods and more cohesive classes, rather than blindly writing a lot of code at a time. On the contrary, you will often evaluate the code quality, instead of making many minor adjustments at a time, rather than modifying many things at a time.

5. Keep it simple: do not make yourself forced to design too much or complicate the code too much. Be proud to be able to create a simple and usable design. Do not use design patterns, principles, and difficult technologies unless otherwise irrefutable.

6. Compile the code for cohesion: Make the functions of the class as concentrated as possible, and make the components as small as possible.

7. tell us not to ask: do not rob other objects or component jobs, tell it what to do, rather than asking him what to do.

8. Replace according to the contract: the liskov replacement rule. Any inherited derived class object must be able to replace any used base class object without the need to know any difference. Use inheritance for is-a and delegate for has-a or uses-.

6. agile debugging

1. Record the problem solving log: do not fall twice in the same place. You may wish to maintain a log that maintains the problem encountered and the corresponding solution.

You can use the following entries:

1) problem occurrence date

2) Problem Description

3) detailed solution description

4) reference an article or website

5) screenshots of any code snippets, settings, or dialog boxes

2. Warning is an error: Check in the Code with a warning is the same as the Code with an error or failed to pass the test.

3. Individually solve the problem: when solving the problem, you must isolate the problem domain from its surroundings. before launching an attack to the problem, you must first find your problem resolution log.

4. Report all exceptions: and handle each exception.

5. Provide useful error information: it is easier to find error details. When a problem occurs, you need to show as many support details as possible, but do not let them fall into it.

VII. agile collaboration

1. schedule regular meetings.

2. The architect must write code.

3. Implement code collective ownership: rotate the tasks of different modules in different fields of the system. Possible?

4. Become a Mentor: helping Team members improve their skills while improving their skills.

5. Allow yourself to find a solution: as a mentor, you should encourage and lead everyone to think about how to solve the problem, rather than giving the answer directly.

6. Share the code after preparation: do not submit unfinished code or code that has not passed the test.

7. Perform code review: When the code is just completed, it is the best time to find the problem.

Basic check list:

1) can code be read and understood?

2) Are there any obvious errors?

3) Will the Code have adverse effects on other parts of the application?

4) Is there repeated code?

5) Is there any part that can be improved or reconstructed?

8. Even if progress and problems are reported, do not make a statement in advance.

8. agility

1. A new habit is required.

2. Use new habits to save projects on the verge of failure.