Reflecting back on the past six weeks, I recall moments of maddening rage. Sometimes I wanted to throw my laptop out of the window (shattering the glass in a brutal fashion), drive down to Florida, become a caddy at a golf course, and lead a simpler life. I restrained myself from doing so because I don't have a car and I haven't played golf in 6 years, and therefore it would take awhile for me to break into the caddying profession. Ruby on Rails is really all I've got (dramatic pause). So when I would get those ERROR MESSAGES because I made some aggregious ERROR because I am CARELESS and FOOLISH, I would take a deep breath, and read the error message, and it would tell me, "No ControllerForGalleries". And then I would add a Galleries_Controller, and pray that no one saw the vein in my forehead maddeningly pulsating.
Thankfully, the blinding 'error rage' subsided as I became more comfortable and familiar with error messages and the basic MVC framework of Rails applications. We approached the architecture of our applications through Error Driven Development, or "EDD". After enough practice, the errors acted like road maps; basic instructions on how to build our app. We successfully made an app modeled after Flickr with images, galleries, groups, followers, and more -- all great features that I can see myself using for my passion project and other future app creations.
It's hard to believe that we are now at Metis' half-way point. We have learned so much the past six weeks that I'm not even sure where to begin, so I won't delve into the nitty-gritty of the curriculum. Last week was refactoring week, and our last week of lectures. I saw refactoring week as a very poignant milestone in my developing career. As I described before, EDD is incredibly useful as it helps one construct the framework upon which your app is built. However, prior to refactoring week, we did not delve much into writing "clean code", nor learn proper design techniques. Infact, I had no idea that these were even "things" -- I thought, naively, that if the code worked, and app functioned properly, then that was that.
Refactoring has unveiled a whole new world to me. I felt the same way when we progressed from procedural programming to Object Oriented programming -- it just made sense. Grouping objects logically (OOP) made more sense to me than listing features chronilogically (procedural). These parts of programming -- the parts where I can feel the gears in my brain begin to turn and grind -- are the parts that drew me to the field in the first place. Yes, there are 'aha!' moments when your code is functional, but I achieve a much deeper sense of satisfaction and confidence when I can look at my app and notice that things are designed and structured in a manner that translates well. Strangely enough, I also feel a sense of accomplishment when I look at code I have written and notice that something isn't quite right. The fact that I am developing the skills to differentiate between good and bad code is encouraging to me; I feel that these abilities are what will follow me throughout my career as a developer, and will be skills that I will forver continue to hone and perfect.
Refactoring has forced me to really understand the inner-workings of my app. We intentionally wrote cluttered code, only to look back and refactor it. I am so, so grateful that this is the approach Metis took. This entire time, I felt that something was inherently wrong with the code we were writing for our mock-Flickr app. A lot of it did not logically make a lot of sense to me. Sure, it was OOP. Most of the business logic were in the models, and our controllers were pretty skinny. But these principles alone do not make for a strong app, and thus, many "code smells" began to emerge. Now that we are refactoring our app, I feel as though a weight has been lifted off of my app's shoulders. I'm not simply writing more code to implement features; I'm restructuring code to accomodate features, and refactoring code to make it as understandable and readable as possible. As a wise man once said, "Change is the only constant in programming", and thus, we must write our code to be as accomodating to change as possible. However, it is not expected that we write 100% clean, refactored code on the first go; it's a process. We know or sense that there is some flaw within our code -- an abstraction of sorts -- and from that, we set out to refactor it. As Sandy Metz points out, "You don't have to know where you're going to successfully refactor."
In conclusion -- while I may not be writing the best code right now, I'm happy that I'm becoming more adept at identifying problems within my code, and looking forward to working on the multitude of upcoming projects in the next six weeks. Metis has been an incredible experience thus far, and I am excited to begin to work more independently and hone the programming skils I have acquired from our lectures and Flickr application.