{"id":12102,"date":"2014-05-16T14:52:36","date_gmt":"2014-05-16T11:52:36","guid":{"rendered":"https:\/\/mozaicworks.com\/?p=7042"},"modified":"2014-05-16T14:52:36","modified_gmt":"2014-05-16T11:52:36","slug":"the-good-the-bad-and-the-ugly-code","status":"publish","type":"post","link":"https:\/\/mozaicworks.com\/blog\/the-good-the-bad-and-the-ugly-code","title":{"rendered":"The Good, the Bad and the Ugly code"},"content":{"rendered":"
Not long ago, one of my colleaques asked me what is the way that helps me more to learn. My quick answer was “Through stories”. I was sure about it because I have an experience to confirm it. This experience was the talk that Rebecca Wirfs-Brock<\/a> have given last year at I TAKE Unconference<\/a>. It was my first attendence to a keynote talk, the first time I was in front of an international software craftman and the first time I saw code from international big projects like “NASA X-ray Telescope InFOC\u03bcs” and Javascript. She had presented the code while telling us stories about it and these two were not the only ones. I will do a quick summary of all of them and of what I have learned.<\/p>\n With this story, Rebecca taught us how to deal with good code. By showing us how the code evolved with each sprint, what design decisions they took, what mistakes they made and how they solved them, she succeded to print into my mind the following quotes:<\/p>\n Sometimes if you want to see a change for the better, you have to take things into your own hands. – Clint Eastwood<\/em> More, for each quote there is a good coding practice to follow:<\/p>\n She presented that project as being a<\/p>\n Mess-View-Controller where some of the code is procedural, some is object-oriented, some global variables are used, and the database is a forest of related table.<\/p><\/blockquote>\n This is the case when a programmer can become very easily frustrated and ready to give up. We all know that dealing with legacy code<\/a> is one of the hardest parts of our job as software developers, but Rebecca has shown us that it can be done. Here is her recipe for safely changing and extending Moodle plaform:<\/p>\n 1. Figure out how a similar activity is done I found this story to be the most useful one. Even if the story is about a team’s experinces with refactoring their own bad code, its learnings can be applied also for refactoring someone else’s bad code. I see this story as a story of patience. Most of us, like the team from the story, want to transform bad code into good code just like that. And everytime we reach a dead end. Why? Because we are going to deep with many refactorings at once. The key it is to be patient and to take baby steps<\/a> in order to:<\/p>\n Prepare code to be increasingly refactorable through a simple, continuous, and sustainable set of refactorings.<\/p><\/blockquote>\n Each baby step it is a small improvement like:<\/p>\n and by adopting these practices in our way of coding we will reach bigger improvements. As Rebecca said, these actions are perfect to be done while freeing our mind from \u201cbackground\u201d problem solving.<\/p>\n These were the hard core stories. Most of us have dealed with bad code, but few of us have dealed with ugly code. Rebecca is one of the few. First, she has seen the ugly code, with bugs very difficult to find, originally written in MATLAB and translated in C for controling the NASA X-ray Telescope InFOC\u03bcs. Second, she knows about the technical debt<\/a> from Javascript libraries which makes defining new and compatible functions a real pain. Third, she knows how to handle these two cases. I will let you find out how by watching her talk from I TAKE Unconference 2013<\/a>.<\/p>\nThe Good: A Story of Consistent Error Reporting Evolution<\/h2>\n
\n Good code is its own best documentation. – Steve McConnell<\/em>
\n Good code is not beautiful code. – Rebecca Wirfs-Brock<\/em>
\n If the windows are not repaired, the tendency is for vandals to break a few more windows. – “The Broken Window Theory”, James Q. Wilson and George L. Kelling<\/em><\/p><\/blockquote>\n\n
The Bad: Moodle e-Learning Platform<\/h2>\n
\n2. Then:<\/p>\n\n
Our Bad: A refactoring experience<\/h2>\n
\n
The Ugly<\/h2>\n
The Good again<\/h2>\n