Including today, there are six business days remaining in 2013 (five if you are lucky enough to get New Year’s Eve off). My brother used to call this week “the lost week” – there’s hardly anything to get done because so many people are on vacation or preoccupied with setting goals for the new year. But the downtime provides a perfect opportunity for the aspiring software developer to do the one thing they are always told there’s no time to do: make the code better for better’s sake.
With few deadlines and plenty of free time, most developers can get a few hours of refactoring in to their code towards the end of the year. They can rearchitect sections that were implemented with haste in September; they can write tests for sections that were untested in April. Put another way, the “lost week” can be redeemed.
Friday, December 21st, 2012 @ 7:00 am |
Comments (0) |
Categories: Best Practices, Friday Inspirations, Object-Oriented Development
Tags: PHP, refactoring, object-oriented, object oriented programming, software development, Christmas, last week of the year
Last week, I began working on something that didn’t pan out. For whatever reason, I went down the wrong path, and ultimately abandoned the task I was working on. In discussing it with my boss, he mentioned to me that it was better to realize early on that something wouldn’t work than to trudge onward, insisting that it be finished due to the “sunk cost” of the time already spent.
This got me thinking about how often we consider the “sunk cost” in our decision-making process, especially when it comes to our software development.
Monday, May 10th, 2010 @ 7:00 am |
Comment (2) |
Categories: General PHP, Opinion, Technology
Tags: development, refactoring, fallacy, sunk cost, rewriting
Nearly a decade ago, Joel Spolsky came up with a method by which to evaluate software development shops that has come to be known as the Joel Test. This crucial test evaluates a software development company on the basis of twelve criteria points; Spoksly said that “a score of 12 is perfect, 11 is tolerable, but 10 or lower and you’ve got serious problems. The truth is that most software organizations are running with a score of 2 or 3, and they need serious help, because companies like Microsoft run at 12 full-time.”
(more…)
Wednesday, November 4th, 2009 @ 1:00 am |
Comment (15) |
Categories: Technology, Best Practices
Tags: joel test, Best Practices, refactoring
Last week, I did a talk at the Frederick Web meetup about tips and tricks for improving your object-oriented code. A lot of these tips were adapted from a fabulous presentation by Stefan Priebsch but the ideas are by no means original to him, and they’re exceptionally good ideas when you’re talking about object-oriented code. Slides are at the end of this blog post, and I’m happy to do this talk over again for local groups.
#1 Use Objects. Lots of Objects
This point is taken directly out of Stefan’s slides, because it’s such a good point. There seems to be a perception in the PHP world that using lots of objects is slow, cumbersome, or plain difficult to maintain. But the reality is that this is not true at all (for example the object model in PHP 5.3 is vastly improved over older models).
Wednesday, October 28th, 2009 @ 1:00 am |
Comment (13) |
Categories: System Architecture, PHP 5, Technology, Best Practices
Tags: refactoring, OOP, composition vs inheritance, dependency injection
This entry is part of an ongoing series involving the review of a code sample and it’s refactoring. For the original code sample, see here.
The topics discussed in this entry may be fairly advanced. Please feel free to ask questions, and discuss best practices.
If you’ve been following this series from the beginning, take a moment to look at the original code sample and compare it with where we are now. We’ve come a long way!
There is one last area that I want to address, and this has everything to do with object-oriented principles and code reusability. For those who are familiar with OO programming, they realize that the use of classes does not make something object oriented by nature. In this final part of the series, we’ll move one step closer to being object-oriented, by introducing the concepts of request and response objects.
At the moment, our object takes arguments like most functions do. This has some limitations. The first limitation is that the object must be aware: that is, it must have an understanding of the request it is being passed, and the response that it is getting from Twitter, as well as the response it will give back to our application. This means that in the event that something ever changes about the way that response is organized, we have to change this code, explicitly. I would like to avoid that.
(more…)
Monday, September 21st, 2009 @ 1:00 am |
Comment (6) |
Categories: Best Practices, System Architecture, PHP 5
Tags: refactoring, OOP, Peer Review, code review
This entry is part of an ongoing series involving the review of a code sample and it’s refactoring. For the original code sample, see here.
There are a number of fundamental concepts in object-oriented design that we should take notice of. One of these concepts is abstraction. This is what we will focus on today and in the next entry.
This article will focus on the constructor method. There are a couple of problems, namely that the constructor itself does a lot of actual work. Also, we have the cURL setup done in the constructor. This object is a Twitter object, not a cURL object; this means that we should decouple the cURL functionality and abstract it into a separate object of its own. This not only will make our object more true to it’s functionality as a Twitter object, but will allow for greater reuse (since we’ll be able to use the cURL object for more).
There’s some debate about whether or not you ought to write things like wrappers for native PHP functionality. One thing that is missed in the “don’t write a wrapper for cURL!” argument is that a good wrapper for HTTP requests shouldn’t be limited to cURL. In fact, it should make use of fopen(), file_get_contents(), etc. in the case that cURL doesn’t exist. A good object would test for this, and change its behavior based on preset rules. (strategy pattern, anyone?)
(more…)
Wednesday, August 26th, 2009 @ 1:00 am |
Comment (11) |
Categories: Best Practices, System Architecture
Tags: refactoring, PHP, objects php 5
| « Older Entries |