On 20/09/13 04:57, Mark Canonical Ramm-Christensen wrote: > *Rules of Thumb for Code Cleanup* > > But, for everyday work, I'm also very aware that we need some shortcuts, > and rules of thumb. We can't make every single code cleanup decision by > trying to weigh all the costs and all the benefits. > > Given that Juju is a product that already has real users, and has grown > to a significant size I would like to propose a set of rules of thumb > that make sense to me: > > * knowingly acquiring significant (as in will cost a lot later) > technical debt a bad idea and new debt should be an exception rather > than the rule. > * we need to pay down debts/when we see that they are starting to > cost something/ in terms of further development work. > > The second rule might need a bit of unpacking it means: > > * doing drive-by cleanup as we write new features, > * refactoring and de-duplicating existing code to remove impediments > to progress as needed to build new features > > But it does not mean: > > * going through a massive cleanup effort to we fix every naming > inconsistency > * finding and purging every possible bit of code duplication everywhere > * finding the perfect solution to every question of where to draw the > lines of abstraction, and then going back and fixing all the code to > match that ideal abstraction layer
While this is somewhat off topic, I agree with these rules of thumb. > Reading "Clean Code" could be about a lot of things. It could be about > forging a team with a shared understanding of code quality. That would > be amazing and valuable. Or it could be about double guessing every old > decision, and trying to fix everything that ever "went wrong" up to this > point in the project -- which would be painful and a complete waste. > > My hope is that this book helps us all grow a shared vocabulary of code > quality, and to improve the speed and fluency with which we can handle > code quality questions. I agree entirely here. I found a lot of benefit from reading this book, even though a lot of it seemed like common sense and things I have done for ages. It is nice to be able to point at a book and say "see, it isn't just me that thinks like this". Don't get me wrong, there are some things that I don't agree with in the book, but I think that everyone will have that, and most likely, have it in different places. But I do feel that the aim is to have a common understanding and vocabulary around what clean code means. The intent was always forward looking, not to navel gaze and look back at past decisions. > So, to sum up my view on all of this: growing the capacity of the team > is my number one goal, because it makes /everything/ easier in the future. Agreed. Tim -- Juju-dev mailing list [email protected] Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju-dev
