This site is the archived OWASP Foundation Wiki and is no longer accepting Account Requests.
To view the new OWASP Foundation website, please visit https://owasp.org
Difference between revisions of "CRV2 CodeReviewAgile"
m |
m |
||
| Line 4: | Line 4: | ||
==Some definitions about Agile== | ==Some definitions about Agile== | ||
| − | The Agile name is an umbrella for quite a lot of practices that range from programming, to testing, to project management. | + | The Agile name is an umbrella for quite a lot of practices that range from programming, to testing, to project management and everything in between. |
Agile has some key practices that could affect the way the code is reviewed. | Agile has some key practices that could affect the way the code is reviewed. | ||
| − | Agile Development is well suited for code review, as two of its key practices are "pair programming" and "peer review". AD incorporates code review in itself | + | Agile Development is well suited for code review, as two of its key practices are "pair programming" and "peer review". AD incorporates code review in itself, in what traditionally was seem as another phase. |
| − | Agile blurs the difference between developing and testing, and so | + | Agile blurs the difference between developing and testing, and so does with code review. It is not an external activity. |
| Line 26: | Line 26: | ||
| − | + | ||
| Line 35: | Line 35: | ||
It is so fundamental, that the xDD pervades Agile, test first, test earlier | It is so fundamental, that the xDD pervades Agile, test first, test earlier | ||
| − | == | + | ==Continuous integration== |
it triggers the tests and often static code analysis too. it makes detection of integration problems arise very quickly. | it triggers the tests and often static code analysis too. it makes detection of integration problems arise very quickly. | ||
| Line 56: | Line 56: | ||
Refactoring is the art of changing the code with out changing its behavior. The problem is that thanks to the heavy testing, you can trust that the interface does not change, but behind it, the code can be very volatile. You have to review the code continously, another argument for peer review and automatic static analysis. | Refactoring is the art of changing the code with out changing its behavior. The problem is that thanks to the heavy testing, you can trust that the interface does not change, but behind it, the code can be very volatile. You have to review the code continously, another argument for peer review and automatic static analysis. | ||
| + | |||
| + | |||
| + | ==Code Reviewing an Agile Project== | ||
| + | |||
| + | If you are going to review an Agile Team project code, the best thing that you can do is give this guide to that Team as early as possible and most of your work will be done for you. | ||
| + | |||
| + | In order to review an Agile Project, you will have to extend the review to the tests and ... | ||
| + | |||
| + | |||
References: | References: | ||
http://martinfowler.com/articles/continuousIntegration.html | http://martinfowler.com/articles/continuousIntegration.html | ||
| + | |||
| + | http://refactoring.com/ | ||
| + | |||
| + | http://dddcommunity.org/ | ||
Revision as of 02:08, 20 June 2013
Charly, remember that it's "code review guide", not "testing guide"
- 1 Some definitions about Agile
- 2 Pair Programming
- 3 Peer Review
- 4 Life Cycle
- 5 Clean Code and "Smells"
- 6 The role of testing
- 7 Continuous integration
- 8 The role of automatic static code analysis in the Agile Methodologies
- 9 Test Driven Development
- 10 Behavior Driven Development
- 11 Domain Driven Design
- 12 Refactoring
- 13 Code Reviewing an Agile Project
Some definitions about Agile
The Agile name is an umbrella for quite a lot of practices that range from programming, to testing, to project management and everything in between.
Agile has some key practices that could affect the way the code is reviewed.
Agile Development is well suited for code review, as two of its key practices are "pair programming" and "peer review". AD incorporates code review in itself, in what traditionally was seem as another phase.
Agile blurs the difference between developing and testing, and so does with code review. It is not an external activity.
Pair Programming
This technique is quite controversial, but when its adopted it has the benefits of making better code, as there is one programmer supervising cooperatively the other one's work. If both programmers know this guide, they will apply it continuously.
Peer Review
This one is enforced by the usage of tools like .... that ask another user for a code review before commiting to the versioning system.
Life Cycle
AD tries to keep the code review as near as possible to the development phase, there is no such thing as develop, test, code review cycle.
Clean Code and "Smells"
The role of testing
It is so fundamental, that the xDD pervades Agile, test first, test earlier
Continuous integration
it triggers the tests and often static code analysis too. it makes detection of integration problems arise very quickly.
The role of automatic static code analysis in the Agile Methodologies
Test Driven Development
It aims at code simplicity due to the need of making it testeable
Behavior Driven Development
....
Domain Driven Design
....
Refactoring
Refactoring is the art of changing the code with out changing its behavior. The problem is that thanks to the heavy testing, you can trust that the interface does not change, but behind it, the code can be very volatile. You have to review the code continously, another argument for peer review and automatic static analysis.
Code Reviewing an Agile Project
If you are going to review an Agile Team project code, the best thing that you can do is give this guide to that Team as early as possible and most of your work will be done for you.
In order to review an Agile Project, you will have to extend the review to the tests and ...
References:
