Refactoring Techniques: Extract Method
A while back, I’d thrown out a question in the Laravel Slack channel asking people what the “must-reads” were for devs. Along with the obvious Uncle Bob books, someone (I believe it was Matt Stauffer) mentioned Refactoring - Improving the Design of Existing Code by Martin Fowler. I looked it up on Amazon and while it was available, I found myself questioning whether a book that was dated 1999 would have any validity in the “modern” coding world I find myself in… not to mention that it didn’t appear to be written for PHP, which is the primary language I use.
I’m glad to say that I put aside my doubts, followed the recommendation, and picked up a copy!
Initially I was disappointed to see that the examples are written in Java, a language I know nothing about. However, I’ve been surprised to see how the broader concepts, such as organization and classes, relate very similarly to what I find myself dealing with in the PHP/Laravel world.
Diving Into a Laravel Audit
Recently the Zaengle team was asked to look over an existing Laravel application and give a review of the overall state of the code. We were to act as an independent third party, between a new studio who had inherited the codebase, and the client, who was anticipating launching the product. The studio had some concerns about the quality of the code and wanted an independent review prior to picking up development on the project. Here are a few thoughts on the process I followed and several takeaways I had from the experience!
Testing 101: Escape Testing Paralysis!
Learning to write good tests is critical to being a programmer. We write tests to make sure the work is solid and doing what it's supposed to, while exerting as little effort as possible (we're not lazy; we're effective...). When I understood that, I determined that I was going to get great at testing. So naturally I started internet research: "Dear Google, show me 'best code testing practices.'"
I quickly gathered that there are a multitude of testing solutions with numerous opinions on each one. In the same way that children can choose blue LEGO bricks, red ones, or two green ones and then argue loudly about which choice is superior, I heard terms like unit testing, functional testing, integration testing, acceptance testing, etc., and all the debates on what should and shouldn’t be tested in our applications.
I soon found myself in testing-paralysis. My overloaded brain said I had to thoroughly understand each of these paradigms before I could begin implementing any kind of testing on my apps. (Which color LEGO is best?) I didn’t feel confident enough to implement any test, for fear of choosing the wrong test, so I resorted to saying, “Let’s just build the app, and I’ll circle back and test it later.”
Little did I know that even though I thought avoiding the tests was making my life easier, I was actually digging myself into a hole.
Page 4 of 4 (33 total entries)