From Programmer to Programmer
Re: To refactor or not to refactor by KAMIL MANOJKUMAR DHULESHIA and To refactor or not to refactor by YU HONG TAN
Refactoring is changing an application’s or a bunch of code’s internal implementation while keeping its external functionalities.
Refactoring is to improve code’s quality, readability, understandability etc.
Refactoring is an important part in TDD when all the tests are written first, and then code is altered/refactored to pass all the tests.
So to refactor or not to refactor? My answer is YES
Why programmers refactor their code? Well, I believe no programmers like their code to be smelly.
Kamil said refactoring is not an ideal thing to do 5 minutes before deadline. I agree. Refactoring is time consuming, and it is too risky to alter to code at the last moment. It is better to leave it for the next release.
But Kamil also said when to refactor is when you need to fix a bug. It’s not right my friend, a bug is what causes your code to work incorrectly. Fixing a bug is not refactoring. The only exception is when you are doing TDD, while you write your unit tests first.
Another thing I don't agree with Kamil is when to refactor is when adding function. Kamil himself just said in his blog “Refactoring does not add any functionality to the code but it does make the code more efficient”. Did he confused himself? Modifying the code to add a function is not called refactor. Functionalities are to be kept unchanged while refactoring.
Refactoring is simply a process to eliminate repetitive code in a software system without changing the behavior of the actual system – Yu Hong said. It’s not completely wrong, but refactor is not that simple. How's about making your code more readable and understandale?
I strongly disagree with Yu Hong saying “There are times that the code for that system that is being refactored is too complex; it is not worth the time and money to process any further refactoring the code”. More complex the code is, more likely it needs refactor. After all, a complex code is made up from many simple one. Refactor helps simplifying the code, give it a better shape, which is ready for being reused and maintained.
There’s one important thing that both Kamil and Yu Hong missed, automated tests are essential and perquisites while refactoring. Tests guarantee refactoring won’t break the code, or make sure the code’s functionalities unchanged.
Bibliography
1. What is Refactoring http://c2.com/cgi/wiki?WhatIsRefactoring
2. Software Refactoring http://www.refactoring.be/talks/tom-mens/refactoring.pdf
Wednesday, October 21, 2009
Thursday, October 1, 2009
TDD When to and When not to
TDD When to and When not to
From Programmer to Programmer
1. What is TDD?
TDD is Test Driven Development, a software development technique that relies on the repetition of a very short development cycle: First the developer writes a failing automated test case that defines a desired improvement or new function, then produces code to pass that test and finally refactors the new code to acceptable standards. (http://en.wikipedia.org/wiki/Test-driven_development)
2. When to use TDD
2.1 Productivity and Quality are must-have
TDD is a way to design software for testability. TDD ensures all code is covered by tests. Moreover, testing and debugging each small part is easier than testing and debugging the whole system.
With TDD, developers spend more time for testing, and less time for coding. As developers write unit tests for their own code, and only the necessary codes are written to pass the test, TDD means quicker, goal-oriented, cleaner and simpler coding. In addition, developers are kept on track.
Well-written unit tests can be used as an important part of documentation ? reduces document.
So, TDD makes software more stable, reliable and testable.
2.2 Goals and Requirements are clear and fixed at the beginning, or rarely and slightly change
In TDD, developers refactor their code to improve it while keeping the functionalities. If there is no clear goal or requirement, it is not only troublesome to decide with test should be used, but refactoring may also be a nightmare when functionalities are totally changed.
With TDD, when there’s a new implementation, the first thing to be considered is how it will be used, not how to build it nor how to implement it ? more user-oriented. However, a clear goal with detailed requirements is preferred. If how user interacts with the new implementation is unknown, we can not use TDD.
2.3 Developers are experienced in testing
One good thing about TDD is that developers must fully understand requirements to write tests.
Another good thing about TDD is that there are many testing tools that help developers save time and effort.
3. When not to use TDD
3.1 Experimentation and thrown-away products, they are for understanding, learning new things or getting feedbacks
Application Development is driven by Test, not by Usability or Scalability… while they may be things that we want to get feedbacks.
TDD slows down the process as many refactoring have to be done during developing. In case of experimental products, time and effort are essential.
3.2 Agile Development, when there are a lot of unknown
Changes of UI and API often cause tests to fail.
TDD requires a clear goal, but in Agile Development, requirements are unclear and often change. Therefore, every time requirements are changed, tests need to be rewritten.
3.3 Developers have no or few experiences in testing
If developers have no skill in testing, it may happen that unnecessary tests are written, or the whole system is not test-covered. And both cases promise no good things.
It is nearly impossible to measure how many tests are enough or how to 100% tests the system. Poor design will lead unnecessary tests. It is a waste of time, money and effort.
Integrated (and complicated) test must be also considered. Other while, all parts may pass the test but the whole system does not.
It is hard to write test for Interface, Database, and Concurrent Programming.
Good unit tests require testing skills and experiences. Testing a whole system need various testing techniques and testing tools.
Bibliography
1. Functional Test Driven Development, http://bizdriven.blogspot.com/2005/11/functional-test-driven-development.html
2. If you do Test Driven Development all the time, you’re doing something wrong, http://www.thekua.com/atwork/2008/02/if-you-do-test-driven-development-all-the-time-youre-doing-something-wrong
3. Introduction to Test Driven Design, http://www.agiledata.org/essays/tdd.html
4. Kiessig, R. (2007). Companywide cumulative TestDriven Development.
5. Sinaalto, M. (2006). The impact of test-driven development on design quality.
6. Test Driven Development - Is it good or bad?, http://msmvps.com/blogs/paulomorgado/archive/2007/03/29/test-driven-development-is-it-good-or-bad.aspx
7. Test Driven Development, http://pooya.khamooshi.com/Pages/MyArticles/TDD.aspx
8. What’s the best argument to convince developers to learn TDD?, http://stackoverflow.com/questions/913458/whats-the-best-argument-to-convince-developers-to-learn-tdd
9. When TDD Goes Bad #1, http://weblogs.asp.net/jsgreenwood/archive/2004/11/26/270503.aspx
10. When TDD Goes Bad #2, http://weblogs.asp.net/jsgreenwood/archive/2004/12/29/343963.aspx
11. Y. Dubinsky and O. Hazzan. (2007). Measured Test-Driven Development: Using Measures to Monitor and Control the Unit Development. Journal of Computer Science
From Programmer to Programmer
1. What is TDD?
TDD is Test Driven Development, a software development technique that relies on the repetition of a very short development cycle: First the developer writes a failing automated test case that defines a desired improvement or new function, then produces code to pass that test and finally refactors the new code to acceptable standards. (http://en.wikipedia.org/wiki/Test-driven_development)
2. When to use TDD
2.1 Productivity and Quality are must-have
TDD is a way to design software for testability. TDD ensures all code is covered by tests. Moreover, testing and debugging each small part is easier than testing and debugging the whole system.
With TDD, developers spend more time for testing, and less time for coding. As developers write unit tests for their own code, and only the necessary codes are written to pass the test, TDD means quicker, goal-oriented, cleaner and simpler coding. In addition, developers are kept on track.
Well-written unit tests can be used as an important part of documentation ? reduces document.
So, TDD makes software more stable, reliable and testable.
2.2 Goals and Requirements are clear and fixed at the beginning, or rarely and slightly change
In TDD, developers refactor their code to improve it while keeping the functionalities. If there is no clear goal or requirement, it is not only troublesome to decide with test should be used, but refactoring may also be a nightmare when functionalities are totally changed.
With TDD, when there’s a new implementation, the first thing to be considered is how it will be used, not how to build it nor how to implement it ? more user-oriented. However, a clear goal with detailed requirements is preferred. If how user interacts with the new implementation is unknown, we can not use TDD.
2.3 Developers are experienced in testing
One good thing about TDD is that developers must fully understand requirements to write tests.
Another good thing about TDD is that there are many testing tools that help developers save time and effort.
3. When not to use TDD
3.1 Experimentation and thrown-away products, they are for understanding, learning new things or getting feedbacks
Application Development is driven by Test, not by Usability or Scalability… while they may be things that we want to get feedbacks.
TDD slows down the process as many refactoring have to be done during developing. In case of experimental products, time and effort are essential.
3.2 Agile Development, when there are a lot of unknown
Changes of UI and API often cause tests to fail.
TDD requires a clear goal, but in Agile Development, requirements are unclear and often change. Therefore, every time requirements are changed, tests need to be rewritten.
3.3 Developers have no or few experiences in testing
If developers have no skill in testing, it may happen that unnecessary tests are written, or the whole system is not test-covered. And both cases promise no good things.
It is nearly impossible to measure how many tests are enough or how to 100% tests the system. Poor design will lead unnecessary tests. It is a waste of time, money and effort.
Integrated (and complicated) test must be also considered. Other while, all parts may pass the test but the whole system does not.
It is hard to write test for Interface, Database, and Concurrent Programming.
Good unit tests require testing skills and experiences. Testing a whole system need various testing techniques and testing tools.
Bibliography
1. Functional Test Driven Development, http://bizdriven.blogspot.com/2005/11/functional-test-driven-development.html
2. If you do Test Driven Development all the time, you’re doing something wrong, http://www.thekua.com/atwork/2008/02/if-you-do-test-driven-development-all-the-time-youre-doing-something-wrong
3. Introduction to Test Driven Design, http://www.agiledata.org/essays/tdd.html
4. Kiessig, R. (2007). Companywide cumulative TestDriven Development.
5. Sinaalto, M. (2006). The impact of test-driven development on design quality.
6. Test Driven Development - Is it good or bad?, http://msmvps.com/blogs/paulomorgado/archive/2007/03/29/test-driven-development-is-it-good-or-bad.aspx
7. Test Driven Development, http://pooya.khamooshi.com/Pages/MyArticles/TDD.aspx
8. What’s the best argument to convince developers to learn TDD?, http://stackoverflow.com/questions/913458/whats-the-best-argument-to-convince-developers-to-learn-tdd
9. When TDD Goes Bad #1, http://weblogs.asp.net/jsgreenwood/archive/2004/11/26/270503.aspx
10. When TDD Goes Bad #2, http://weblogs.asp.net/jsgreenwood/archive/2004/12/29/343963.aspx
11. Y. Dubinsky and O. Hazzan. (2007). Measured Test-Driven Development: Using Measures to Monitor and Control the Unit Development. Journal of Computer Science
Subscribe to:
Posts (Atom)