Chapter 1 Agile — The Path to effective Software Development
define
There is a common misconception that agile means fast, and the faster the swifter — based on dictionary definitions. It was originally called “Lightweight processes”, but some attendees didn’t like being seen as lightweight fighters jumping around the ring, so they used the word “agile”. Other misconceptions are that agile is all code and no documentation; Agile requires refactoring rather than design; Agile iterations are about keeping them to a minimum, so many times an hour.
Agile Development Manifesto
A development approach that focuses on people, teamwork, fast response to change, and working software. “Agile approaches respond quickly to change, emphasize teamwork, and focus on concrete, actionable goals (making software that actually works). This is the spirit of Agile.”
nature
We do continuous development, continuous feedback. The sooner you catch the problem, the easier it is to fix it, so fix it right now.
why
Why continuous development? Because software development is such a complex intellectual activity, any problems you leave behind will either be lucky and not unexpected, or the situation will get worse and get worse until it gets out of control. When problems accumulate to a certain point, things become more difficult to solve and ultimately impossible to reverse. Faced with such problems, the only effective solution is to continuously push the system forward and improve.
Way to work
Agile teams tend to be small teams, or larger teams broken up into smaller teams (about 10 people). All members of the team work together, preferably in separate workspaces if possible, sharing code and necessary development tasks, and working together most of the time. Also work closely with customers or users of the software and show them the latest systems as early and as often as possible. Use automation tools to continuously build (continuous integration), test systems, and refactor code.
Chapter 2 Attitude is everything
As a member of a team, you should approach things positively and do things for the better development of the project
1, do things
Problems should be solved first, and colleagues should help solve them, not find the root of the problem
“It’s reassuring to admit that you don’t know the answer. A big mistake should be treated as an opportunity to learn, not to point fingers. Team members should work together and help each other, not blame each other.”
More haste, less speed
Some code can be fixed quickly, but without getting to the bottom of the problem, the underlying problem will be buried and it will take longer to break out
“As long as we keep doing quick fixes, the clarity of the code keeps getting lower and lower. Once you get to a point where problems accumulate, clean code is no longer there, just a cloud.”
“A thousand miles of levees, collapse of the nest, catastrophe is gradually evolved. One quick fix after another, each time without getting to the root of the problem, creates a dangerous swamp that eventually swallows the life out of the whole project.”
To the matter not the person
Just express your opinion and be polite when there is a disagreement. If the team fails to reach an agreement, it can set a deadline, establish an arbitrator, and support the decision already made
“There is no best answer, only a more appropriate solution. “Setting deadlines can help you make decisions when things get tough and move forward.”
Overcome all difficulties and forge ahead
Identify problems and have the courage to bring them up with other team members and bosses
“Do the right thing. Be honest and have the courage to tell the truth. Sometimes it’s hard to do that, so we have to be brave enough.”
There is no end to learning
The software development industry is a constantly evolving and ever-changing field that requires constant learning by individuals and teams
5. Track changes
Is constantly learning new knowledge, because software technology is constantly updated
“You can smell new technologies coming in and know they’ve been released or launched. If you have to switch to a new technology, you can do it.”
6. Invest in your team
Have a good team study, communication atmosphere, dinner, reading, etc
“On a team, it’s not enough that you’re technically good. If the rest of the team doesn’t know enough, the team doesn’t work as well as it should: a learning team is a better team.”
Know how to give up
The abandonment of old technology, including the abandonment of technological thinking habits
“Breaking old habits is hard, and it’s even harder when you don’t realize it.”
8. Break the casserole
Ask why, so you can find some potential problems, so you can understand more deeply
“In order to understand a question, we need to ask more than five ‘why’ questions gradually.”
9. Pace development
Work should be arranged in a planned and regular way, without changing requirements, and iteration time should be as periodical as possible
“There needs to be a consistent and steady pace of project development. Edit, run tests, code review, iterate consistently, and release. It’s easier to dance if you know when to start the next beat.”
Chapter 4 delivers the software users want
In agile development, users’ needs are the dominant, frequent and regular update, show to users, and constantly modify the direction of progress
10. Let the customer decide
Do not try to decide by yourself, because of the difference of ideas, the last is very likely to redo, when the customer does not have a good idea, to give their own suggestions
“Business applications need developers and business owners to work together to create them. It should feel like a good, honest working relationship.”
11. Let design guide rather than operational development
Draw UML diagrams, think about the disadvantages and benefits of different options, and start coding. Note that the design is also current and may change during coding
“Good design should be right, not precise. That is, everything it describes must be correct and should not involve details that are uncertain or subject to change. It’s a goal, not a prescription.”
12. Use technology wisely
Find the problem first, then find the right technology based on the problem, don’t just use the technology for the sake of using it, need to consider the feasibility of the technology, change, maintenance costs
“New technology should be like a new tool that helps you do your job better. It shouldn’t be your job by itself.”
13. Keep it publishable
Keep major releases ready for release, and new branches can be created for massively changing requirements. Workflow: Run tests locally, check out the latest code, commit code
“The best way is if you have a continuous integration system that automatically integrates and reports the results of the integration.”
14. Integrate early and frequently
Integrating code several times a day, rather than uniformly, reduces the problems that integration can cause.
“If you really get it right, integration is no longer a burdensome task. It’s just part of the coding cycle. Integration problems are small and easy to solve.”
15. Automate deployment early
A system should have a deployment environment several days in advance of development, rather than waiting until it goes live, to avoid many problems. Repetitive deployments can be a waste of time, so consider using an automated deployment tool.
“It’s all supposed to be invisible. Installation or deployment of the system should be simple, reliable, and repeatable. Everything is natural.”
Use demos to get frequent feedback
1 to 2 weeks to demonstrate the project to customers, let customers give feedback, help to help the future direction of the project.
“Success in software development is how close you are to the customer’s expectations at the end of the day. Every precise location you calculate is an opportunity to show the customer what has been done so far, and it’s time to get feedback. This feedback can be used to correct your direction as you move on to the next leg of your journey.”
17. Use short iterations and release incrementally
Shorten the release cycle, and if it’s a big system, break it up into lots of useful smaller systems. Short iterations feel focused and productive.
“The best way to tackle big projects is to take small steps, which is at the heart of agile. Big jumps dramatically increase the risk, and small steps help you get the balance right.”
Fixed price means betrayal of commitment
Software development has requirements change at any time, there are some small problems, these are difficult to estimate, so it is more important to break the project function.
“Your estimates will change throughout the project — they’re not fixed. However, you’ll feel more confident and more aware of what you can accomplish with each iteration. Your assessment skills will improve over time.”
Chapter 5 agile Feedback
The Importance of Testing
Guardian angel
Unit testing is important, and it’s best to automate it.
“Think of the results of a unit test as if it were the same as a compiler — if the test doesn’t pass (or doesn’t pass), it’s just as bad as if the compile didn’t pass.”
Use it first and then implement it
Let yourself stand in the user’s point of view, first to use the product (interface), in order to better design
“TDD (Test Driven Development) gives you the opportunity to think through how you’re going to use it before you write code (or at least before you get too deep into implementation). It forces you to think about usability and convenience, and makes your design more pragmatic.”
Different environment, there are different problems
To test different versions of different systems, automate testing. Many companies will save on hardware, but this will take a lot of time for software developers, and the actual cost is higher.
“The hardware cost of building the machine is equivalent to a few hours of developer time.”
Automatic acceptance testing
Automated testing verifies various exceptions and normal data, ensuring robustness and saving time
“FIT, which stands for Integrated Testing Framework, is useful in making it easier to define test cases using HTML tables and compare test result data.”
Measure real progress
When working on a task, do not use the percentage of work completed, but use the number of hours left to complete the work. When realizing that the work is longer, give real feedback immediately. The next estimated time should be multiplied by the coefficient of the last time.
“Your estimates fluctuate for a period of time, sometimes underestimating, sometimes overestimating. But over time, your assessment will get closer to the truth and you’ll get a better sense of how long the task will take.”
“Just because you work 40 hours a week doesn’t mean you have 40 hours of coding. You need to subtract meetings, phone calls, emails and other related activities.”
Listen to your users
Products should be simple and easy to use, and users should give reasonable and friendly tips when using mistakes
“There are no stupid users, only stupid, arrogant developers.”
“Whether it’s a bug in the product, a bug in the documentation, a bug in the understanding of the user community, it’s a team problem, not a user problem.”
“Developers can be tempted to cut corners to save time when completing tasks. However, these shortcuts tend to delay the onset of a problem rather than solve it completely. “When the time pressure builds up, problems eventually pop up in front of the project team and upset everyone.”
Chapter 6 agile Coding
Some key points and habits of agile coding
25. Make your code clear
- Code should be readable, and clarity should take precedence over efficiency
- Use more enumerations and less displacement operators
- Code specification makes code easy to understand and reduces unnecessary comments and documentation
“You should be able to read code you wrote a year ago, or anyone else on your team, and know how it works just by reading it once.”
Communicate with code
- 1 Method names are important
- Avoid using cryptic variable names
- 3. We will go to great lengths to replace the names we are used to with long and complicated ones
- 4 Comments should be concise, stating purpose and function
“The source code is readable not because of the comments, but because of its elegance and clarity — the correct use of variable names, the proper use of whitespaces, the clear separation of logic, and the simplicity of the expressions.”
27. Dynamic evaluation trade-offs
Don’t overdo one thing, such as performance and UI, and spend some time on other weak areas that can be improved quickly
“Even if you can’t cover everything, you should feel like you’ve got what’s most important — the features that customers value.”
Incremental programming
Incremental focus on split functionality and testing, with a focus on incremental improvements to maintainability
“Incremental programming and testing tends to create smaller methods and more cohesive classes. You’re not blindly writing a bunch of code all at once. Instead, you constantly evaluate the quality of your code and make lots of small changes from time to time, rather than changing lots of things at once.”
29. Keep it simple
Don’t use design patterns. Use them on demand
“One of the best ways to evaluate design quality is to listen to your gut. Intuition is not magic, it is the accumulation of experience and skill.”
Write cohesive code
To write highly cohesive code, do a single function in a class, but don’t break it down too much
“Keep your classes as focused as possible and your components as small as possible. Avoid creating large classes or components, or creating a hodgepodge of classes that cover everything.”
Tell, don’t ask
Commands are separated from the query mode. When querying, do not retrieve the internal state of a class, etc
“As the caller of a piece of code, the developer should never make any decisions based on the state of the called object, let alone change the state of the object. Such logic should be the responsibility of the called object, not yours. Making decisions for that object outside of itself violates its encapsulation principles and provides breeding ground for bugs.”
32. Replace according to the contract
The difference between inheritance and delegation: a new class can replace an existing class, is-A relationship, with inheritance, the new class just uses the existing class, has-a, use-a relationship, with delegation
“The Liskov substitution principle tells us that any inherited derived object must be able to replace any used base object, and that the user does not have to be aware of any differences. In other words, a piece of code that uses a method from a base class must be able to use an object from a derived class without making any changes of its own.”
Chapter 7 Agile Debugging
Development process debugging some attention points, exception handling
33. Log problem resolution
To document the occurrence and resolution of problems, new and recurring problems can be quickly resolved
“Share your logs with others, not just one person. Put it on a shared network drive so others can use it. Or create a Wiki and encourage other developers to use and update its content.”
Warning is wrong
Do not commit code with warning errors, which can introduce unknown risks and increase the test effort
“Find a way for the compiler to raise the warning as an error. If the compiler allows you to adjust the reporting level of warnings, set the level to the highest so that no warnings can be ignored.”
On the problem one by one
Writing code is logical to be clear, so that each module is easy to be removed, when there is a problem, it is necessary to test the module step by step, than the overall test is easier to find the problem point
“The first step in identifying complex problems is to isolate them.”
36. Report any exceptions
Exceptions should not be ignored. It is possible to ignore the current page without problems, but this can easily lead to other association problems
“When something goes wrong, you know you can get an exception thrown. And there’s no empty exception handler.”
Provide useful error information
Developers should assume that they are new users to use, error information as detailed as possible, convenient for users and convenient for their troubleshooting problems
“Error messages help solve the problem. When a problem occurs, you can examine the detailed description of the problem and the context in which it occurred.”
Chapter 8 agile Collaboration
Other aspects of agile development include team meetings, communication, coaching, code reviews, and issues thrown out
38. Schedule regular meetings
In the company’s stand-up meeting, standing will shorten the meeting time, to ensure that the topic will not diverges, stand-up meeting each person only answer the following three questions:
- 1 What did you learn yesterday
- What do you plan to do today
- 3 What obstacles are facing
“Use rikhoi. Instant meetings allow the team to reach a consensus. Keep meetings short and tight.”
The architect must write code
The architect should be involved in part of the implementation of the code, and the lead developers on the project should be involved in the design of the project
“As a designer, you can’t design effectively without understanding the nuts and bolts of the system. You can’t understand a system very well just by looking at some highly generalized, sketchy design.” “Good design starts with motivated programmers. Active programming can lead to deep understanding. Don’t use architects who won’t code — you can’t design without knowing what the system is really like.”
The implementation of code collective ownership
For multi-person development, everyone should know the code for the entire project so that the risk is reduced and the code is frequently reviewed, refactored, and maintained. Both the person who wrote the code and the person who changed the code will be more careful and less likely to make mistakes.
“Rotating tasks around the team so that each member has access to different parts of the code improves the knowledge and expertise of the team as a whole.”
Be a mentor
Share your knowledge with your team members to improve both yourself and the team
“Teaching and learning: A good idea is not diminished by many people knowing it. When I heard your idea, I got the knowledge, and your idea is still great. In the same way, if you light mine with your candle, I gain light without darkening your surroundings. Good ideas, like fire, can lead the world without weakening themselves.”
Allow everyone to think of their own way
Help your co-workers improve their problem-solving skills by offering some guidance before helping them
“Give a man fish, three meals; Teach a man to fish and use him for life.”
43. Share code when you’re ready
When submitting code during development, ensure that the submitted code works properly and is compatible with other developers
“Make sure all the unit tests pass before you commit the code. Using continuous integration is a great way to keep your code in source control problem-free.”
44. Do code reviews
Having code reviewed by other people after it has been written improves code quality
“Code reviews are ongoing with development activities, and relatively small amounts of code are addressed at a time. The review feels like an ongoing part of the project, rather than something to be feared.”
Timely reporting of progress and problems
When the project is not going well and will delay the progress, actively inform other parties to find a solution to the problem, and will not be a surprise to others
“Keep progress and problems informed. Post status updates, new ideas, and current topics of interest. Don’t wait for someone to ask about the status of the project.”
Epilogue of Chapter 9: Go Agile
Good habits are important
“Just one new habit makes a huge difference to the team.”
Personal summary
Finished reading the book, to have a new understanding of agile development, this book is not dry books, not when it comes to specific knowledge, only classification in agile development about its attention points, the book is easy to understand, also can give a lot of the real example, there is no professional, so for each level of the developer is appropriate for reading. Especially for software developers who are just starting out, this book focuses on habits at work, not just code styles, coding habits, but habits of working with all kinds of things, or workflows, that can be very helpful for software developers who are just starting out. With good habits, coding efficiency and technology can be improved faster. Of course, for other developers who have not developed good habits, reading is also necessary.
Although the book is said to be an agile development practice, many of the chapters should be common to all types of programmers and even staff, such as the previous work attitude, endless learning, problems feedback and so on. Before, I summarized each chapter and summary in a simple sentence, which I thought was convenient for me to review later. In each section, I also quoted a good working habit of personal tasks in the book. Every time I glanced back at it, it didn’t take much time, but it was also helpful for my work.
The definition of the agile development in the book, and not before my personal cognitive agility, there may be a lot of people and I used to like, just from the literal meaning to understand, in fact the agile is the pursuit of large projects, long-term stability of the team’s development efficiency of agile, and eventually these for a few small projects, or only do the first phase of the project is not much use to try, But there are some lessons to be learned, such as feedback communication, short iterations, problem throwing, and so on. Agile development is in order to avoid large deviations in some large projects and waste a large number of human and financial resources. The layout of the project is divided into functions, modularity, short iteration and automation, which can be changed and amended constantly to advance towards the correct demand, rather than to find that it is the opposite direction when all the functions are completed.
Many of the habits pointed out here are indeed very helpful for our daily work, can improve their own work efficiency, better improve technology. In many points, and now the company also has a lot of places, feel not bad, you can also try to execute, of course, all this is not going to perform, after all, everyone and the company’s situation is different, this is according to their own requirements, habits are suitable for their own is the best, Of course, other people’s good habits also want to learn.