Thursday, February 20, 2014

Refactoring Mindset

Today we have exercises out of our textbook  Software Development:  An Open Source Approach.

Unfortunately I have no idea how to approach these exercises.  The instructions are unclear and I'm not sure where to find...anything useful that's related to the exercise.  I MUST be missing something.

I learned all about "smelly" code in Chapter 5.  A portion of code emits a bad smell when it is not easy to read and could be improved.  There's a whole list of common types of bad smells.  I will list some of them for your perusal:
  • poorly named variable, method, or class
    • A guy who sat next to be in my first CSCI class ever, decided to be "cute" on a test and named his variables: cat, meow, dog, bark, etc- he was deducted many points- the professor was not amused.
  • duplicate code
  • long method
  • large class
  • too many/too few comments
    • apparently too many comments can hide bad code AKA the comments are "used as deodorant".  Is it wrong that I find this section hilarious?
  • data clumps
There are many more bad smells, but I'll stop at these.



So once the offensively smelly code is found, it is refactored.  This means modifying the code to improve its readability, efficiency, or modifiability.  Refactoring usually changes the size of the code base and makes the code more simple.
It is recommended by this text to develop a test suite while gathering requirements for a project and before any coding is started.  This type of software development is called test-driven development (TDD).  TDD is great because it keeps the client in the loop (the client explains the desired end result and what the system needs to do before they approve it).  TDD also motivates effective and focused code development.  Professor Omsted actually talked about this recently in CSCI 360- basically if you write the test suite first- it's like you have the answers to a test- you know what you're going to be tested on!

And then finally there is debugging.  A bug is a defect or flaw in the code base that causes or helps cause a failure (unacceptable behavior).  It is best practice to add a new test to the test suite that addresses the particular bug that has been corrected.

*UPDATE:
The class was given some time to work on the book exercises in class and I did get a little further with help from my classmates.  We were able to find the module in RMH Homebase that displays a shift's notes- calendar.php.  We were able to locate the "ugly" code and defined a new function called "predates(a,b)".


We inserted this as a new feature of the Shift class.
...Annnnnd that's as far as we got.





No comments:

Post a Comment