New client, new project, new developers - same old story on code monkey approach to designing and implementing objects.
I am again gently enforcing these two simple rules:
The objects must be simple to use, not (just) easy to make. E.g. do not expose a date as string even if XML xs:date types becomes strings in .NET and strings are easy to code for you - rather make it simple to use the object by converting the string to and from a real .NET DateTime value.
There is no such thing as "throw-away code" if it enters the source control system. You will not have time, due to time preasure, to come back at a later time to do things right in throw-away code that you write due to time preasure. Therefore all code that you check-in must be production quality code.
In addition, I try to enforce this principle: There should be no green code (comments) in the code. All comments should be considered a missed opportunity to use 'Refactor - Extract Method' and use of the comment as the basis for the new method name.
2 comments:
I also push to make "green code" obsolete in my team but not everyone like it. Can you give me a few "how to convince your boss to drop comments" tips?
Well, here in Norway bosses don't have the power to change the mindset of developers; so I convince one developer at the time during everyday work.
Don't keep "can come in handy" code block if you have a source control system, the YAGNI principle applies to it anyway.
Post a Comment