Green field projects are certainly rare, but they hold a certain appeal over developers. The ability to ignore all the mistakes of the past, and instead focus on new architecture, new ideas and new methodologies is enticing. And yet, every pile of legacy code spaghetti out there was once a green field project, filled with the majestic hopes and dreams of the engineers who worked on it. What happens?
I know many developers who believe that code simply gets worse over time, that technical debt accumulations are inevitable and that bad decisions haunt us forever. But the truth is that code doesn’t rust. And that means that our ability to make changes is directly related to how well we create the code in the first place.
Few things bring out fights among programmers quite like a fight over documentation. There are many schools of thought, from “document every line” to “let the code self-document.” For the most part, PHP seems to have agreed on a generalized standard for documentation in code, called PHPDoc. Actual blocks of documentation are referred to as “Docblocks”*.
But within PHPDoc, there are many different styles and behaviors. And so, I have developed what I consider to be my “best tips” for documenting your code with Docblocks.
Towards the end of my talk at phpDay in Verona, I was asked by two developers which framework I thought they should learn: Symfony or Laravel. I understand the pressure that developers feel like they’re under to learn a framework, and to somewhat “predict the future” by figuring out what is likely to be popular in PHP for the next few years.
But my answer to them wasn’t what they expected. I told them that if they were new to PHP, that they should focus on learning PHP.
Despite what His Majesty, David Heinemeier Hansson may have said, unit testing is by no means dead. And, in fact, system testing is no more a complete testing strategy than 100% test coverage with unit tests. Let me explain.
Test Driven Development (TDD) is a philosophy that asserts testing is so important that the tests should be written first, to emphasize the design of the code. The idea is that by writing a failing test, and then writing code that passes that test, you end up with an overall better architecture.
In many development shops where I’ve worked, there’s a consistent struggle between developers who want to “do it right” and management that wants to “just get it shipped.”
The problem stems from the pride developers feel in their work coming up against the business realities faced by managers and company leaders, who are focused on making sure everyone gets a paycheck each Friday.
We’ve all seen it: we’re working along, and we come across code that just has a feel to it. It’s like déjà vu. You’ve seen this code before. You open another file – sure enough, there it is. The same code. Almost line for line.
In large code bases, it’s likely that there are dozens if not hundreds of similar behaviors that have to be completed more than once. And as code grows, is worked on by multiple developers, or just for the sake of speed, the same code gets copied or rewritten over and over again in different places.