Agile Python Development and the Laundry list
We need method to the madness!
There are apparently two, one is waterfall and the other agileWhen?
Manifesto for Agile Software Development was produced in February, 2001.
Why Agile?
Is more pragmatic, as it knows that not everything can be documented at the beginning of a project. But it does put in place some rigorous checks to accommodate these changes!
So that any change can be accommodated, with good communication, iterative design and development.
Agile development can be applied in any project, both testing tools and build automation tend to be very language specific. Python too has these tools.
Jargons again!
Agile methodologies
- XP - Extreme programming -- focuses almost exclusively on the developer and development techniques
- DSDM - Dynamic Systems Development Method -- focuses completely on processes
- there could be many more.
Spirit of it from manifesto!
Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan
Agile methods has collection of various techniques:-
Laundry list
on-site customers - person using the product.
pair programming - being a solo role since the beginning of my career I know how it feels to be banging your head alone to a computer, its better for two to be doing this.
sys metaphor - using the same names all around the program and treating anything else as bugs, IDEs refactoring tools help in changing names across the system.
IDEs are integrated development environments, like Pycham, Eclipse and etc.
Refactoring is the practice of simplifying and clarifying code when ever possible.
Documentation - yes you read it right! there is documentation too but it should be minimal. It should be limited to that which is necessary to ensure that participants in the development process can communicate.
Simple Design is fulfilling requirements of the user stories and nothing more. the code is the design, should be as simple as possible.
Principle for it:-
- DRY - Don't repeat yourself, when you see the same thing being done again and again in your code, refactor! May be create a method or something also called as DIE - duplication is evil.
- YAGNI - "You aren't gonna need it" -- "do the simplest thing that could possibly work" (DTSTTCPW) no point in carrying the useless burden around.
- KISS: is an acronym for the design principle "Keep it simple, Stupid!".
Better raw than wrong - just say things in simple and direct way.
Short Iterations - The customers and the dev team meets on regular intervals, generally every week and discussion on what has been done, give a demo may be and then plan for what needs to be done in the coming week. This is to avoid any tragic surprises to the client.
Collective Code Ownership - it's not one man or his fathers property, due to pair programming, the strong attachment to the code is dissolved.
Producing short iterations is made possible through automation. There is automation from the Developers desk to the production environment. Human touch is only needed when things go wrong!
It is human to err and hence manual process should be avoided.
Continuous reflection: Is ongoing analysis of how development is going on.
documenting everything that is being done can CYA! Trust me, I've realised this in the hard way, so no matter which company you are in keep shouting and bragging on what you are doing and if possible give them some jazzy acronymos or create a buzz word so that others are intimidated on hearing it. This is how this God forsaken industry operates unfortunately.
Continuous Integration:
Have you saved the file, or do you have a back up, if this words make your heart skip a beat then you should remember to check in the code into the repo as often as possible as a single place keep all the artifacts necessary to produce the build.
This could include build scripts, tool scripts, properties files, installation scripts, third-party libraries, tests, and tool configurations (e.g., IDE configuration files).
Since the program is built, installed, executed, and tested throughout development. This guarantees that there will be no deaths in the team at the time of production!
Test Driven Development:
Tests are written before the actual code is written to solve the problem.
Types of tests are
Unit tests or programmer tests is level of methods and functions. With this tests changes are easy to make as they detect the bugs immediately. Unit tests fall into two broad categories: programmer tests and customer tests. What they test distinguishes them from each other.
- Programmer tests prove that the code does what the programmer expects it to do. They verify that the code works.
- Customer tests (a.k.a. acceptance tests) help to ascertain that the code behaves the way the customer would expect it to. It verifies behaviour at the level of classes and complete interfaces.
Unit testing is a part of regression testing.
Regression tests identify bugs that have been seen before and that had been fixed. Unit tests should run fast else, programmers will not run them and that could lead to a lot of bugs at the end.
Two of the most common tools in Python for unit testing are unittest and Nose.
Functional testing verifies that the complete application works as expected. Functional testing is done by QA department who are directly integrated into the development process. It verifies that customer sees what they would expect to see and no bugs have crept in.
I still haven't got Agile, what the heck is it?
It simply means that you will have the requested app or program at the earliest even though it might not have the full functionality of the finished application!
