Freek.dev

Jeroen Moens posted a, very well written, article on paying technical debt in a legacy codebase.

How can you get a legacy codebase under control and bring it to a new level of maturity? This post summarises my advice and lessons learned from years of working on a large legacy web application.

http://marketing.intracto.com/paying-technical-debt-how-to-rescue-legacy-code-through-refactoring

On a sidenote: as an Artisan I always like to sneak in a little Laravel in legacy projects. There are a lot of Illuminate components take can be used independently outside Laravel. If you want to do this too take a look at Matt Stauffer's Torch repo on GitHub.

Read more

When starting out programming many developers are quite happy when their code just works. More seasoned programmers know that making working code is just a first step. Not improving your initial code will lead to professional suicide (not my phrasing, I'm sure I've read this in a book at some point).

In an article on his blog, Colin DeCarlo demonstrates how an initial solution can be vastly improved in just a few iterations.

From time to time a friend and I play a programming game that I consider to be a version of Code Golf. Typically, the goal of Code Golf is to solve some challenge using as little bytes as possible. In the version of the game we play however, the limitation is the use of certain language features. Specifically, we try to use as little variables, conditionals and explicit loops as possible.

...

My method to accomplishing these challenges is to first write the algorithm in the simplest, most straight forward manner and then chip away at that solution until I’ve satisfied the challenge conditions.

The focus in the article is on removing conditionals, and limiting the use of variables. Keep in mind that, in most cases, this shouldn't be your main goal. Maximizing the readabilty is what your should pursue. Don't try to be too clever or terse. In some cases limiting conditionals and variables goes hand in hand with improving readability, in other cases not. It all depends on context.

Read more

Sandi Metz on her blog:

If you find yourself passing parameters and adding conditional paths through shared code, the abstraction is incorrect. It may have been right to begin with, but that day has passed. Once an abstraction is proved wrong the best strategy is to re-introduce duplication and let it show you what's right. Although it occasionally makes sense to accumulate a few conditionals to gain insight into what's going on, you'll suffer less pain if you abandon the wrong abstraction sooner rather than later.

http://www.sandimetz.com/blog/2016/1/20/the-wrong-abstraction

Read more

Matthias Noback, author of "Principles of Package Design", published the first article in a new series on programming best practices on the iBuildings blog. The subject of the first article is reducing complexity.

Inside your method or function bodies, reduce complexity as much as possible. A lower complexity leads to a lower mental burden for anyone who reads the code. Therefore, it will also reduce the number of misunderstandings about how the code works, how it can be modified, or how it should be fixed.

https://www.ibuildings.nl/blog/2016/01/programming-guidelines-php-developers-part-1-reducing-complexity

Read more

It is known by now that every codebase large enough (in terms of lines of code or people collaborating to it) should follow any code standard. Here at Coolblue we weren’t different and were using our own coding standard.

But codebases evolve. And our codebase – that has been supporting one of the most visited ecommerces in The Netherlands – needed to be upgraded to a coding standard that’s a little bit more up to date.

This is the process we follow to move into PSR-2.

http://devblog.coolblue.nl/tech/converting-big-php-codebases-to-psr2/

In the past months we converted several of our old projects to PSR-2 with Fabien Potencier's coding standards fixer and had zero issues doing so. Hurray for standardized code.

 

Read more

A really great talk by Sandi Metz in which she refactors a nasty block of conditional code to a few small, understandable objects.

https://www.youtube.com/watch?v=8bZh5LMaSmE

Read more

Watch a very instructive live coding session with Matthias Verraes.

Under the pressure of deadlines and endless change requests, under the weight of years of legacy, code becomes unmaintainable. With the right tools, techniques, and mindset, any codebase can be brought under test, and be refactored towards a better architecture. Let's skip the theory and dive straight into the spaghetti code. In a live coding session, I will demonstrate how you can start refactoring your way out of a mess today.

Read more

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.

http://www.brandonsavage.net/the-case-for-maintainable-code/

Read more

Got to love Illuminate\Support\Collection.

http://vimeo.com/115719437

 

Read more