News Feed
Jobs Feed
Sections




News Archive
feed this:

Looking for more information on how to do PHP the right way? Check out PHP: The Right Way

NetTuts.com:
Refactoring Legacy Code Part 1 - The Golden Master
March 24, 2014 @ 12:56:32

NetTuts.com has kicked off a new series of posts looking to help you get a handle on that big pile of legacy code you're having to work with. In part one of their "Refactoring Legacy Code" series they talk about the "Golden Master", a method of testing all the things before starting on changes.

Old code. Ugly code. Complicated code. Spaghetti code. Jibberish nonsense. In two words, Legacy Code. This is a series that will help you work and deal with it. In an ideal world, you would write only new code. You would write it beautiful and perfect. You would never have to revisit your code and you will never have to maintain projects ten years old. In an ideal world... Unfortunately, we live in a reality that is not ideal. We have to understand, modify and enhance ages-old code. We have to work with legacy code.

They start with a definition of what "legacy code" is and link to a codebase they'll guide you through for refactoring. They talk some about understanding the code and scanning through it to get an overall feel for it. They recommend some testing techniques (including the Golden Master) and include the code to create it and some of the sample output.

0 comments voice your opinion now!
tutorial refactor legacy code series part1 goldenmaster

Link: http://code.tutsplus.com/tutorials/refactoring-legacy-code-part-1-the-golden-master--cms-20331

Allan MacGregor:
Design Patterns in PHP Using Factories
January 21, 2014 @ 09:39:32

Allan MacGregor has a recent post to his site looking at another design pattern (previously he discussed dependency injection), this time it's the use of factories.

The factory pattern is one of the most commonly used Design Patterns, it is useful when we need to choose between several interchangeable classes at runtime. By using factories we are also separating the creation of an object from the actual implementation. We can define a factory as a simple design pattern that give us a convenient way to instantiate objects. A factory is capable of creating different types of objects without necessarily knowing what type of object is actually being created.

He talks some about the problems that factories try to solve and some of the common implementations - simple, abstract and the factory method. He also covers some times when it's useful to use the pattern (including the creation of complex objects). The rest of the post includes sample code showing the creation of a Product class, creating them manually and the refactor over to a factory created method, making it more flexible for products in the future.

0 comments voice your opinion now!
design pattern factory introduction refactor product

Link: http://coderoncode.com/2014/01/19/design-patterns-php-factories.html

KillerPHP.com:
What is Refactoring PHP Code?
January 17, 2014 @ 09:16:40

If you're relatively new to programming, there's a term you might have heard floating around but not really understood - "refactoring". If you're interested in learning more about it and want a gentle introduction of how it works in PHP to help make your code better, check out this introductory video from Stefan Mischook.

In a nutshell: It is the process of code refinement - taking messy code and reorganizing it into much more manageable (cleaner) chunks. Refactoring is such an important part of coding, that I slap my programmers on back of the head, if they fail to refactor their code!

He talks about refactoring being something that's done constantly, not just later down the line. He also talks about when to refactor and suggests a few methods that you can use. You can watch the video either in the in-page player or over on YouTube for a larger size.

0 comments voice your opinion now!
refactor code video screencast introduction

Link: http://www.killerphp.com/articles/what-is-refactoring-php-code/

DZone.com:
Practical PHP Refactoring Encapsulate Downcast (and Wrapping)
November 04, 2013 @ 12:44:06

On DZone.com Giorgio Sironi has posted a refactoring recommendation around the handling of the data and types in your PHP code. He suggests the move from just a simple variable to a Value Object (noting that it's not really needed in PHP, but can provide a "richer interface" to work with the data).

Statically typed languages sometimes encounter the problem of downcasting: the compiler is only able to guarantee a basic type, and the object contained instead is an instance of a richer subtype. [...] You'll never need to downcast objects: variables can contain handlers to objects or even scalars without compile-time checks. Casting with (ClassName) is not even supported by the language (while casting a non-object with (object) will give you a stdClass.)

He starts by talking about scalar values in PHP and a simple form of downcasting - using the casting notation included in the language. From there he moves into the conversion into Value Objects and some of the updates (like docblocks) that would come with their use. He outlines some steps towards the conversion and provides an example set of scripts showing the conversion process.

0 comments voice your opinion now!
refactor scalara value variable valueobject downcast

Link: http://css.dzone.com/articles/practical-php-refactoring-38

Andrew Podner:
Make it Testable-No Matter how Painful it is
April 04, 2013 @ 09:39:27

In a new post Andrew Podner recommends that, as you're doing your day to day development, you try your hardest to create testable code, no matter how painful it is.

I look at the situation we have gotten into by having this problem [of replacing a large legacy application], and frankly, it is like the tech version of 'Scared Straight'. The paranoia of such a far reaching application within the enterprise that absolutely has to deploy successfully and also be very flexible to meet the needs of the future have driven me to the point of near madness in trying to make sure this thing is bulletproof, enter Test Driven Development.

He includes an example situation he recently was faced with in his code...and opted for the "easy" way out (difficult to test). He talks some about the issues, dependencies and coupled code this has created. He does, however, show a solution to the issue - passing in the dependencies as they're needed, not defining them in the method.

For me, writing custom apps in an enterprise environment is not about rapid deployment and looking like a hero. It is about deploying software with a design life of 7-10 years, because the change management involved in deployment is not something you want be be doing over and over again. Testable code with 100% coverage of unit tests, well developed integration testing, and prolific use of tools like PHPUnit & Selenium are part of the development culture because while speed is important, durability is even more critical to business.
0 comments voice your opinion now!
testable code unittest tdd testdriven refactor dependencies

Link: http://unassumingphp.com/make-it-testable-no-matter-how-painful-it-is/

PHPMaster.com:
Preventing Code Rot 101 Unit Testing
February 28, 2013 @ 13:41:32

On PHPMaster.com today they've published a new article from Remi Woler about preventing "code rot" in your applications through the use of unit testing. He advocates that tests, when applied correctly, can help make refactoring easier and safer, allowing you to change your code and know things stlll work.

Unless you're working on a fresh project right now, the codebase you work with most likely has such code you take for granted. And the more challenging your current assignment (or fresh project) is, the more likely it will become a legacy part as well on short notice. Since it's infeasible to fully comprehend all problems that your codebases solve, as well as all their solutions, something else needs to be done to prevent code rot. One way or the other: the code needs to be refactorable to live happily ever after.

The breaks down the steps that a unit test should follow on its most base level - assemble the environment to test inside, act on the code and assert that the output was as expected. He walks you through each of these steps, detailing what's involved and including some sample code to illustrate. He also includes a few tips on the successful application of tests like:

  • Don't forget to write integration/acceptance tests as well.
  • Name your unit tests verbosely.
  • Write unit tests for bug fixes.
  • Never change the code under test.
0 comments voice your opinion now!
unittest coderot refactor application steps tutorial


Andrew Podner:
Rock On, Refactor, or Re-roll?
February 28, 2013 @ 09:36:44

In his latest post Andrew Podnet looks at a common situation for developers during one project or another. It's the struggle whether to "rock on" and keep developing a project as it's planned, refactor what's already there into something new or re-roll the whole thing completely, scrapping it for a possibly better structure.

I went to my standard code library, developed on my own over a period of 3 or 4 years and starting piecing together a core application that I could start building on. I worked on this application diligently from June to September, and I would say in that time I had made it 70% of the way through the app. I was being relatively careful about doing manual functional tests, and I felt good about what I was doing with the application where security practices were concerned. Then 2 things happened almost simultaneously that really put a wrench in the works.

He was working on a project for several months, but due to other circumstances, he had to set it aside for a while. When he came back, he had a new perspective on things and saw lots of places in the code that things could have been done different/better. The post goes through some of his thought process and how it relates to the three "roll on", "refactor" or "re-roll" the current state of the application. He does have a reminder for developers facing the same situation, though:

The whole reason I am writing this post, other than to just get my thoughts down and help make the call, is to illustrate the importance of remembering that as developers, one of our key objectives for the client is to deliver value. This is a fact that can sometimes get away from us.
0 comments voice your opinion now!
refactor reroll rockon development method opinion


Brandon Savage:
When To Write Bad Code
January 29, 2013 @ 11:14:51

Brandon Savage has posted some of his thoughts on when it's okay to write bad code in your development lifecycle:

I've been there myself. I recently needed to prototype something. As I sat down to work on it, I had absolutely no idea how I was going to write the component I was working on. And so, I started working - without a plan, without writing tests, without designing an architecture, and without really knowing how the component was going to end up. You know what? The component came out working, but when I was done it was ugly. Totally ugly. The code was bad. But I had a solution, and a solution that worked.

He points out that sometimes, doing things "the right way" can stifle creativity and experimentation - two things that a developer needs to solve the problems they face day to day. He notes that refactoring is a part of their job and moving from a rough prototype to a finished product often improves this skill and can find issues not discovered before.

This does NOT mean that developers can push bad code into a repository. Nothing lives longer than temporary code; see to it that your finished code is always good.
0 comments voice your opinion now!
bad code opinion prototype experiment creative refactor


Keith Casey:
Refactor vs Rebuild New Years make New Beginnings
January 09, 2013 @ 09:23:31

Keith Casey has an interesting new post to his site looking at a common dilema among development groups - whether refactor or rewrite is a better option for the state of the current codebase when it comes time for a change.

In software development, we're spoiled. We can write a single line of code and do some interesting things. If we add a framework, that single line of code is backed up by thousands.. and can do even more impressive things. [...] I can't tell you how many people have pitched me to "rewite web2project using [framework x]." At first pass, it sounds like a great idea. We can lay the foundation for doing things "right." We can use the latest and greatest tools, technology, and concepts. Even better, we don't have to figure out all that old crappy code! It's open source so it's free anyway. Everyone wins! How many times have you looked at an application and thought "I could rebuild that in a weekend!"

He points out the "seductive" nature of this kind of thinking and some of the things that it can hide from your immediate vision. These are things like: the lessons that were learned and implemented in the current code, catch up vs new development on the project and the possibility of "killing the community" as they'd no longer know which part of the project to contribute to.

He suggests instead of worrying about a rewrite, that development groups worry more about managing technical debt in their applications and reducing that piece by piece instead.

0 comments voice your opinion now!
refactor rewrite opinion technicaldebt


PHPMaster.com:
The Single Responsibility Principle
November 22, 2012 @ 11:58:06

On PHPMaster.com today Alejandro Gervasio has a new tutorial posted about the Single Responsibility Principle - a guideline that states that each class should only have one "area of concern" and not try to do to much.

One of the most notorious consequences of this rational associative process is that, at some point, we effectively end up creating classes that do too much. The so-called "God class" is quite possibly the most extreme and coarse example of a structure that packages literally piles of unrelated operations behind the fence of the same API, but there are other subtle, more furtive situations where assigning of multiple roles to the same class are harder to track down. [...] What the principle attempts to promote is that classes must always be designed to expose only one area of concern and the set of operations they define and implement must be aimed at fulfilling that concern in particular and nothing else.

He starts off with a typical violation of the principle, showing a class that not only handles user data but also includes the functions to work with the database directly as well (insert/update/delete). He refactors this into a few much more manageable classes - a mapping class to handle the database interaction and a "User" class representative of a true user object.

0 comments voice your opinion now!
single responsibility principle srp class tutorial refactor



Community Events











Don't see your event here?
Let us know!


component series introduction language release facebook install opinion composer application hhvm symfony2 performance framework podcast hack code security unittest package

All content copyright, 2014 PHPDeveloper.org :: info@phpdeveloper.org - Powered by the Solar PHP Framework