On the QaFoo blog they've posted an article sharing advice about refactoring to extract logic to services when there's no testing to cover the code.

When you are refactoring in a legacy codebase, the goal is often to reduce complexity or separate concerns from classes, methods and functions that do too much work themselves. Primary candidates for refactoring are often controller classes or use-case oriented service classes (such as a UserService).

Extracting new service classes is one popular refactoring to separate concerns, but without tests it is dangerous because there are many ways to break your original code. This post presents a list of steps and checklists to perform extract service when you don't have tests or only minimal test coverage. It is not 100% safe but it provides small baby-steps that can be applied and immediately verified.

The article talks about some of the primary risks when performing this kind of refactoring and how their extract method recommendations could case some of those issues. The tutorial then breaks down the process into the small steps:

• Step 1: Create Class and Copy Method
• Step 2: Fix Visibility, Namespace, Use and Autoloading
• Step 3: Check for Instance Variable Usage
• Step 4: Use New Class Inline
• Step 5: Inline Method
• Step 6: Move Instantiation into Constructor or Setter
• Step 7: Cleanup Dependency Injection

While that seems like a lot of steps to take, they're all pretty small. They include a series of code snippets giving you an example to work from, making these small steps to refactor current functionality into a Solr service class.

On the QaFoo blog there's a tutorial posted to their blog sharing one of their basic refactoring techniques: the "extract" method:

Refactoring is the process of restructuring code without changing its behaviour and the technique "Extract Method" is one of the most important building blocks of refactoring.

With extract method you move a fragment of code from an existing method into a new method with a name that explains what it is doing. Therefore this technique can be used to reduce complexity and improve readability of code.

In this post I want to explain the mechanics of extract method using an example so that you have a checklist of steps when performing this refactoring. Extract method is a technique that you can use even without tests, because the potential risks of breaking are manageable when you follow the steps.

While things like PHPStorm provide their own "extract" functionality to help with refactoring, they want you to understand the manual steps involved. They start with a sample method that mixes controller logic with low level query logic. They break the process down into a few steps:

• Identify code fragment to extract
• Create empty method and copy code
• Identify undeclared variables that must be arguments
• Identify variables that are still used in old method
• Call new method from original method

They also include a "risky" checklist with a few questions to ask about the refactor to see what extra steps might need to be considered.

In this new post to his site Jani Hartikainen suggests a few things you can do to help make your code "self-documenting" and more readable down the line (or for other developers).

Isn’t it fun to find a comment in code that’s completely out of place and useless? What if you could write fewer comments and still keep the code easy to understand? One of the primary ways to do this is making your code-self documenting. When code is self-documenting, it doesn’t need comments to explain what it does or its purpose, which is great for making the code easier to maintain. As a bonus, with fewer comments, it’s less likely they’ll be crap! In this article, I will show you several ways you can make your code document itself.

He breaks it up into a few different sections, each with some code examples and descriptions:

• Naming things
• Extract functions
• Introducing variables
• Defining class and module interfaces
• Code grouping

He finishes up with a few smaller tips including "don't use strange tricks" and "use named constants". What do you think makes for good self-documenting code? Share some of your own thoughts on the post.

In this new tutorial from the SitePoint PHP blog about using the Distill tool to extract information and files from remote archives.

Perhaps you are building an application which depends on archives; for example, you constantly have to download archives and extract files from them. There are many libraries out there that can help you get files extracted from an archive, and a new player in town capable of doing this job is Distill. With Distill, you can easily extract an archive into a specified directory. You can also give multiple archives to Distill and let it pick the most optimal one, as per a strategy you define yourself.

He walks you through the setup of the tool (installed via Composer) and some of the basic usage. He creates a simple "Extractor" object setting the Distill object and an "extract" method that handles the actual functional part of the process. He also adds some configuration constants to the class for size checking, compression speed and random strategy types (Distill will pick the most optimal). He then makes a "chooser" method to pick the best one and calls the "extract" method to get the results.

NetTuts.com is back with the latest part of their "Refactoring Legacy Code" series for PHP. In this latest article (part 10) they work on pulling apart longer methods into smaller, more manageable chunks.

In the sixth part of our series we talked about attacking long methods by leveraging on pair programming and viewing code from different levels. We continuously zoomed in and out, and observed both small things like naming as well as form and indentation. Today, we will take another approach: We will assume we are alone, no colleague or pair to help us. We will use a technique called "Extract till you drop" that breaks code in very small pieces. We will make all the efforts we can to make these pieces as easy to understand as possible so the future us, or any other programmer will be able to easily understand them.

This "extract 'till you drop" mentality (from Robert Martin) has you look at a piece of code and find the logic and lines that can be split out and isolated without removing functionality and interaction. They include some random code from a Stack Overflow post (checking if a number is a prime) and show how to split it out, making the logic and structure less complex and more understandable. They start with a unit test to ensure the result is the same post-refactor and fixing a few bugs along the way. They split it out into two different methods and move it from a more linear approach to something recursive.

On the SitePoint PHP blog David Francis has written up an example showing how to create a "lorem ipsum" alternative in PHP. The "lorem ipsum" functionality generates text to put into layouts or prototypes of pages. It's named this way because the first two words are traditionally "lorem ipsum."

Lorem Ipsum generators are well known and are useful for generating text copy during website development. [...] t’s good that we have a wide selection of text generators, but how exactly are these generators made? Can we use PHP and MySQL to build our own? That’s exactly what we’ll tackle in this article. We won’t develop a fully working website; what we will cover are the essentials for building a site such as Fillerati.

He suggests using something from Project Gutenberg (a collection of public domain books and other written works) with the HTML markup already included. His personal choice is On the origin of the Species. He uses a simple PHP script to extract the content from the downloaded document to find useable paragraphs (don't want ones that are too long or short). He then takes that same data and populates a few database tables with it and includes the script to extract them and place them in the page. This could easily be adapted into a view helper for your favorite templating language or framework.

PHPMaster.com has posted the second part of their series covering connecting PHP to a legacy Access database. In part one they introduced you to working with the data and how to extract the object. In this new part they look at specific file types and how to pull out their data.

In this second part we’ll learn how to extract Acrobat PDF documents and take a brief look at a selection of image formats. The only similarity that PDF, GIF, PNG, etc., have when stored in an Access database is that they are all wrapped in an OLE container consisting of a variable length header and trailer. As we shall see, the trailer can be ignored as it was with the package discussed in Part 1. The header is more useful, but doesn’t contain all the information we need.

They get into the details of the headers for each type of object and include screenshots of what they look like in a hex viewer. The code for the complete class is included in the post, making it easy to drop in and get started with your transition from database object to external file.

In this new post to PHPMaster.com, Aurelio De Rosa covers an interesting use of PHP that could be handy in certain circumstances - extracting a section of a WAV audio file using the Audero Wav Extractor library.

Although PHP is well known for building web pages and applications, it can do more than that. I recently needed to extract a piece of audio from a WAV file on-the-fly and let the user download it through his browser. I tried to find a library that fit my needs but wasn’t successful and had to write the code myself. It was a good opportunity to study in depth how a WAV file is made.

He starts off with an overview of what a WAV file is, how it's structured and how you can correctly figure out where in the binary data of the file the section you want is located. He then introduces the library and shows how to use it to extract "chunks" from the WAV file. He also includes an example of pulling out a chunk and saving it off to another file.

In this new post to the Umpirsky.com development blog, they show you how to use poedit to extract translations from Twig templates.

By default, Poedit does not have the ability to parse Twig templates. In Twig documenation there is a simple example which shows how to extract translations. This can work with few modifications, but I wanted to make reusable tool which will allow you to parse Twig templates just like you do with plain PHP templates.

The result is the Twig-Gettext-Extractor that's set up inside Poedit as a parser command for "*.twig" files. This automatically extracts the information so that the editor can read the data from the template.

On the WebSpeaks.in site, there's a recent tutorial posted showing how you can extract the contents of a zip file from inside a PHP application.

Sometimes you may want the users on your site to upload the zip file and then check what are the contents of that zip file. In this article I will tell you how to extract the contents of the zip file. I temporarily extract the zip files to a directory and then delete it afterwards. You can chose to keep the extracted content if you want.

The tutorial walks you through the code, showing you how to use their "ZipArchive" class to grab the file, extract the contents and display a list of the "child files" inside it. You can see a live demo of it in action or just download the source and dive right in.