Resume of the Practices of an Agile developer – part 3
Moving on to chapter four, there is no perfect project; there is no software on this world that could resist the effect of changes. It is inevitable that the software requirement will change, because the nature of improvement, the requirement of the software will likely to change. One thing to remember is, developer should realize that not all the decisions on development should be taken by the software developer. It is important to involve the customers on every decision that could affect their business. It is dangerous to decide for yourself; therefore you should be able to decide what you shouldn’t decide. Every time you face the customer to present a demo of your software, present the details of your software in a language they can understand.
Just as important a design is for development process, do not let design dictate you. Design should only be as detailed as needed to implement. Design should be similar to map, it is point you to the right direction, show you the goal and constraint, but not the detail of the journey itself. By using this design as a map, we will be able to evolve the design, not dictated by the design.
Don’t go blindly picking up a framework just because it is nice to put up on your resume, there are several questions that you had to ask yourself before you use a technology : Does it really solve the problem ?, Will you be tied to the technology ?, and how about the maintenance cost ?. all of this questions are essential to your decisions to use a certain framework, tools or a language.
Always keep your code simple and maintainable, don’t build what you can download. Because the less code you write, the less you have to maintain. Choose the technology that you needed, determine your needs first, and then evaluate the technologies for this certain problem. Also, you have to keep your code executable, by doing this; we will always have a code that stable and executable every time we wanted to run it. There are few tips to keep your code executable, first run on your local machine, second check the latest source version to avoid incompatibility. Lastly after you test everything, and sure that there are no conflict you could check in your latest software.
Integration of software is usually put in the least important section of our agenda, but this book encourages us to integrate early and integrate often. By integrating early you get to see how subsystem interact and operate. The earlier we understand and address the issues found on the early integration, the less work we have to do on fixing them.
It is also important to keep your deployment automated at the early stages of the projects lifetime. It is to ensure that the person who uses our release able to understands and gave feedback as an improvement to our design and code. Frequent feedback are essentials to agile development, because the nature of the requirement which is as fluid as an ink. Requirements are never frozen. Nobody’s mind or perspectives are frozen in time, especially your customers.
In the ideal world of software development, we must be able to deliver a product that the customers came to wanted, not the products that the customers came to asked for. The feedback provided by the customers in the software demos are essentials to the improvement of the software currently developed.
One test is worth a thousand expert is the first sentence that greets us in the opening of the next chapter, chapter five. This chapter describe to us about the agile feedback. All of the feedback we got from the user, QA and other people are turned into a code eventually, and code must eventually be tested. The testing methods provided in this chapter included the unit testing and the benefits of unit testing. Unit testing provides an instant feedback, unit testing make your code robust, and so on. A good unit test can warn you about problems earlier.
There are techniques known as Test Driven Development, where we only code, after writing a failing unit test for that code. The test comes before the code. By using TDD, we are viewing our code from a different perspective, we see the code from the user perspective, not he implementer or developer. The better the design is, doesn’t mean that there will be more classes. TDD can be used as design tools to help us make a better code.
When there are things that are different, chances are it will make a difference. To avoid this case, we must thoroughly test and run a unit test on each supported platform and environment combination. Find the problems, before they find you. After all the effort you took to make an output out of the program, you must make sure, that the output you are getting at is correct, therefore we must check the result with the actual data from the user / customers. Create a test case for core business logic. Have your customers test this in isolation, and exercise them automatically as part of the test run.
The importance of time keeping is also the main point in this chapter; we must always measure the real progress of our work. Focus on where you are going!, make a timesheet to keep record of your progress. Even without the timesheet, some developers have difficulties to focus on reality. You have to measure how much of your time is left. Every complaint that you hear, holds a truth, find the truth and fix the real problem!
There are two ways to create a software design; one way is to make it so simple there are obviously no deficiencies. And the other way is to make it so complicated, there are no obvious deficiencies. The code that you wrote must clearly communicate your intent and must be expressive. By doing so, our code will be readable and understandable. Once our code is not confusing, it will also avoid some errors. Write the code to be clear, not to be clever.
To communicate your code, there are two ways; the first way is to use the code itself. And the second one is to use comment to explain non technical issues. Source code should be understandable for its clarity and elegance, not for its comments. Do not comment your source code to cover up the mess.
The big deal in most documentation is naming, if you could name your code to actually mean something, or explains what it’s doing, then, it is a good name. If the name conveys nothing, then it’s a bad name. The worse thing is when the name made you lost. With a well chosen name and a clear execution path, the code needs very few comments, But the most important thing is, do not use comment to substitute a good code.
Code in incremental fashion, are also important for developer. Don’t code for hour, even minutes, without stopping to check where you are going. When you code incrementally, little by little you will make a smaller methods and a more cohesive classes. A simple code, simplicity is good. Simplicity does not mean simplistic, amateurish and foolish. But it is more difficult to achieve than a mere complex code. One way to measure the quality of the design is to listen to your intuition. A good design will make you feel comfortable.
Upon writing a code, we will have to count the cohesion factor. Cohesion is the measures of how functionally related the members of components are. A higher cohesion value means that the members work toward one feature or set of features. Lower value cohesion indicates that the members provide a disparate set of features.
Everlasting Memory of LIFE 
No trackbacks yet.