The case for maintainable code

Developers and their employers are often at odds over matters like clean or beautiful code and with good reason: neither ships a product or increases sales. Most end users don’t care what the code looks like, as long as the product works and meets their needs. That means that beautiful code goes out the window when the rubber meets the road and crunch time sets in.

The fact of the matter is that framing code discussions in terms of beauty or attractiveness doesn’t help the case for getting code that’s clean. But there’s another way to frame the discussion that makes more sense, and achieves both the goal of writing clean code and meets the needs of most businesses: the concept of maintainable code.


What about “final” and “private”?

There was much discussion on Twitter about the concepts of using “final” and “private” in objects, and what exactly the best practices are. The conversation seemed to boil down to three distinct questions:

  • Should an object be open for extension, and expose its internals for that purpose?
  • Does exposure of those internals create a de facto contract with children for their behavior?
  • Should software only be used as intended by its designers, or should it be modified, extended and changed by the end user to fit certain, specific goals?


Take the summer session of The Object-Oriented PHP Masterclass

masterclasslogoA large number of people told me that they couldn’t make the February class of The Object-Oriented PHP Masterclass, and that they hoped I’d teach it again soon.

Well, if you’re one of those people, I have great news for you: the Object Oriented PHP Masterclass is back, and registration is open!


Breaking the Single Responsibility Principle

Whenever I give lessons on the Single Responsibility Principle, I always teach that object creation is a job, and that it should be separate from classes that are using the objects. (more…)

How to know if your remote workers are working

Let’s get right down to it: many managers worry about whether or not their employees would work or goof off if they were allowed to be remote. It’s a huge fear; it requires faith in your employees, since you can no longer see them or glance at their screen from time to time. Employees are expensive to have on board, so you’d rather they spend their time actually solving problems rather than playing Sudoku or watching Star Trek on Youtube.

And yet, there are dozens if not hundreds of companies that are partially, mostly or completely remote. From Automattic to Github, these companies have figured out how to get things done while partially to fully remote. And the good news is, so can you.


Creating services you won’t hate

The biggest complaint people have about object-oriented design is where they put all the “glue code” that ties together a bunch of objects and makes them work well. For many, this place is the controller, but as I’ve covered before, most of this logic belongs in the model. In fact, the model should be where all business logic resides. And yet, it can still seem difficult to figure out precisely how to manage all of these behaviors in one place and still follow the best practices of object-oriented design and development.

But there is a way to accomplish this that won’t make you crazy. It’s accomplished by making use of “services” – bits of code that act as the “glue code” for all the different objects that have to operate.


« Older Entries Newer Entries »