As a software developer, it's common to learn new practices every day. Although there are jokes about how the more a programmer ages, the more his lines of code counter goes sky high even to accomplish simple tasks, usually this process results in an overall improvement. People that start using source control don't go back; the ones that start using distributed version control do not go back to centralized systems; and so on.
I collected here some typical evolutions that occurs in object-oriented programmers. Follow an hypothetical programmer in its progress towards enlightenment...
Comments
First stage: he does not comment his code. Comments are not necessary to get a working application, right? So why wasting time over something the compiler just strips away? The flow is so simple. Of course after two weeks he does not understand anymore what the code does.
Second stage: he comments everything, and although it helps the comprehension of the code for other programmers, his comments are often redundant and fall inevitably out of sync with the code.
Third stage: he writes self-documenting code, and makes use of docblocks for inline Api documentation. Variables and data types have meaningful names, along with routines.
Properties
First stage: he exposes public properties over all classes. Why write a method when you can simply access them directly?
Second stage: he plainly says that public properties are wrong and fix the situation by using getters and setters over private variables. Although this improves the flow by allowing him to intercept accesses and modifications of the private properties, it still exposes data subject to changes to other classes.
Third stage: he favors encapsulation and makes fields private by default, without any getters nor setters. Fields become accessible only if the computation that involve them cannot be moved to the class itself.
Collaborators
First stage: he puts everything in the same class, which has a nice main() method.
Second stage: he factors out responsibilities in other classes, and creates collaborators in the constructor of the mediator object.
Third stage: he injects collaborators via init*() methods or via the constructor, and breaks dependencies via small and cohesive interfaces.
Static
First stage: all his methods are static, so he does not have to instantiate an object, an operation that is usually considered a treat to performance.
Second stage: he recognizes the static keyword as a marker for code artifacts that belongs to the class instead of the objects, like factory methods and collections of instances.
Third stage: he recognizes the static keyword as a procedural one, and factors out collective methods in a first-class object.
Testing
First stage: he does not test. This code is so simple it should work.
Second stage: he performs manual testing of the application, covering edge cases. He even writes test main() methods sometimes.
Third stage: he automates testing in unit and acceptance suites via frameworks that serve this goal. He gets to write the test ahead of the code and uses them as a design tool.
Of course some of this stages may be broken up in several sublevel ones, but I wanted to keep the list short.
Feel free to add superior stages if you have already reached them. We all have something to learn from each other. :)
