Write tests. Not too many. Mostly integration
At the assert(js) 2018 conference, Kent C. Dodds dissects this tweet by Guillermo Rauch:
Write tests. Not too many. Mostly integration.
— Guillermo Rauch (@rauchg) December 10, 2016
Value objects like a pro
On the Hackernoon site Nicolò Pignatelli wrote a good guide on how to write Value objects in a good way.
This is the list you must always check it against:
- it is immutable and no setters defined;
- it reflects the semantics of the domain;
- it shows how information flows and is transformed during runtime;
- it hasn’t default or useless getter methods;
- it can be compared to other Value Objects of the - - same class by reading private properties directly
https://hackernoon.com/value-objects-like-a-pro-f1bfc1548c72
Join 9,500+ smart developers
Get my monthly newsletter with what I learn from running Spatie, building Oh Dear, and maintaining 300+ open source packages. Practical takes on Laravel, PHP, and AI that you can actually use.
No spam. Unsubscribe anytime. You can also follow me on X.
"Always fresh, useful tips and articles. Carefully selected community content. My favorite newsletter, which I look forward to every time."
A pair of helping hands when naming things
In a new post on his blog Sebastian De Deyne shares a few services and tools he uses to help him with naming things.
One of the hardest (and sometimes frustrating) tasks in a programmer's day-to-day workload is naming things. When I have a hard time finding that perfect word, I generally wind up in one of two situations:
- I have a plausible name in mind, but I'm not entirely satisfied with it
- I have no idea what I could possibly name it
Luckily, there are tools out there that can be of help.
https://sebastiandedeyne.com/posts/2018/a-pair-of-helping-hands-when-naming-things
Optimize programming by optimizing for scannability
Michael D. Hill posted a great new video on his blog where he makes the case for optimizing for scannability.
As programmers trying to ship more value faster, we want to optimize first around the part of the work that we spend the most time on, and that is scanning code– formulating little, tiny questions and flipping through the code looking for the answers. We optimize for scanning by focusing our attention on sizing, grouping, and, above all else, naming.
http://geepawhill.org/optimizing-a-program-and-programming/
Where a curly bracket belongs
My colleague Brent has some good thoughts on where to place curly brackets.
Dedicating a whole blogpost to curly brackets might seem like overkill but I believe it's worth thinking about them. Not just because of one curly bracket, but because there's a bigger message in all this. Thinking about how we read and write code not only improves the quality of that code, it also increases our own and others ease of mind when working with it. It can improve the fluency of your work and free your mind to think about real important stuff.
https://www.stitcher.io/blog/where-a-curly-bracket-belongs
17 Tips for Using Composer Efficiently
Martin Hujer shares some pretty good tips for working with Composer.
Although most PHP developers know how to use Composer, not all of them are using it efficiently or in a best possible way. So I decided to summarize things which are important for my everyday workflow.
The philosophy of most of the tips is "Play it safe", which means that if there are more ways how to handle something, I would use the approach which is least error-prone.
https://blog.martinhujer.cz/17-tips-for-using-composer-efficiently/
Organizing code into domain modules
In a new post to his site Mathieu Napoli makes the case for organising your code based on it's function rather than it's type.
We recently discussed 2 topics seemingly unrelated with my colleagues at Wizaplace: how to organize code? How to organize teams? ... Organizing code into domain modules is not a silver bullet but it forces to better understand the problem we are solving and better structure our code.
http://mnapoli.fr/organizing-code-into-domain-modules/
Atomic commits: telling stories with Git
Frederick Vanbrabant published another delirious rant on his blog. This time it's about atomic commits.
Atomic commits, sometimes also called micro commits, is the practice of explaining your thought process in the form of commit messages and code. It comes down to documenting the way to the solution.
https://frederickvanbrabant.com/2017/12/07/atomic-commits.html
Symmetry is a hallmark of clean code
???? Symmetry is a hallmark of clean code. Symmetrical code is not only easy to read, but also predictable. Here are a few areas to check your code for symmetry. pic.twitter.com/jGVdR0aek7
— Jason McCreary (@gonedark) November 30, 2017
Read more [twitter.com]
The Cost Of JavaScript
Probably you know that that keeping the disk & transfer size of a JavaScript file low is pretty important. But have you considered the time needed to parse and compile the code? In this great post on Medium Addy Osmani, an engineer at Google, explains the complete cost of having JavaScript on your page.
As we build sites more heavily reliant on JavaScript, we sometimes pay for what we send down in ways that we can’t always easily see. In this post, I’ll cover why a little discipline can help if you’d like your site to load & be interactive quickly on mobile devices. tl;dr: less code = less parse/compile + less transfer + less to decompress
https://medium.com/dev-channel/the-cost-of-javascript-84009f51e99e
Shorthand comparisons in PHP
My colleague Brent published a new blogpost on how the ternary and null coalescing operators work in PHP.
You've probably used the ternary ?: and the null coalescing ?? operators in PHP. But do you really know how they work? Understanding these operators makes you use them more, resulting in a cleaner codebase.
Removing comments is one of the best drivers towards clean code
???? Pushing yourself to remove comments is one of the best drivers towards clean code. Here's a few tips on how to spot and replace comments that may be unnecessary… pic.twitter.com/STIK6AIKXt
— Jason McCreary (@gonedark) 16 november 2017
Read more [twitter.com]
Symmetry in naming is a powerful tool
? Symmetry in naming is a powerful tool I never gave the weight it deserves. Embrace the visual relation! A common example in Vue: pic.twitter.com/QEBbHDUvWY
— Caleb Porzio (@calebporzio) November 9, 2017
Read more [twitter.com]
Airplanes and Ashtrays
Harry Roberts makes the case for making technical debt visible instead of trying to hide it.
This means that, although far from ideal, the impact of these hacks is well contained and signposted, meaning that they won’t slip through the cracks and remain hidden in the codebase for the next five years.This pragmatism and lack of stubbornness can make your codebase much more malleable, resilient, and ultimately much more useful. Everything is a compromise.
Writing clean code
Jason McCreary, creator of Laravel Shift, wrote a down a two part series on how to write cleaner code.
To measure our change, we should ask: Did we improve readability?Admittedly a bit subjective, but you push yourself to stay objective. I've been pair programming for the last two years. Developers tend to agree on fundamental readability. Where we differ at the edges. These nuances can lead to some pretty great discussion.
...
The answer to did we improve code readability may vary from developer to developer and project to project. But always ask the question…
https://dev.to/gonedark/writing-clean-code https://dev.to/gonedark/writing-clean-code-part-2-9fn
Don't design your emails
You can spend a lot of time to make emails look pretty, but it might be better to just don't style them at all. Greg Kogan did some A/B testing an concluded that sending plain emails results in more opens, clicks, replies, ...
Why are the plain emails crushing the performance of designed emails?
- They're less likely to be caught in spam filters. Having less HTML and fewer non-text elements such as images lowers the likelihood of triggering spam filters. You can use a free spam checker to validate this by testing plain and designed emails.
- They're less likely to go into the "Promotions" tab in Gmail (used by ~16% of all email users), for the same reasons above. From my testing, the plain emails typically end up in the Updates tab and some times even in the primary tab. Of course, the text in the email also affects this.
- They don't look like advertisements. The second the recipient interprets your email as an ad, promotion, or sales pitch—and it does take just a second—its chances of being read or acted upon plummet towards zero. A plain email leads people to start reading it before jumping to conclusions.
- They feel more personal. It's no handwritten note, but it's much more personal than an over-designed email with the recipient's first name crammed somewhere inside.
Writing code that speaks
Caleb Porzio gives some good advice on how to make code more readable in this talk given at Erie Day of Code 2017.
A few ways to clean up conditional code
A few ways to clean up the conditional code that forms most of your codebase. From simple to nested to spotting unnecessary conditions. ? pic.twitter.com/qGVaDl3TKt
— Jason McCreary (@gonedark) October 26, 2017
Lies you've been told about testing
In his excellent talk given at Laracon Online 2017, Adam Wathan argues that testing in isolation leads to brittle test and that integration tests are much more valuable.
Write tests. Not too many. Mostly integration.
In a fantastic post on his blog, Kent C. Dodds makes the case for focusing on writing integration tests, and stop going for 100% code coverage. Amen to that!
You may also find yourself testing implementation details just so you can make sure you get that one line of code that’s hard to reproduce in a test environment. You really want to avoid testing implementation details because it doesn’t give you very much confidence that your application is working and it slows you down when refactoring. You should very rarely have to change tests when you refactor code.
https://blog.kentcdodds.com/write-tests-not-too-many-mostly-integration-5e8c7fff591c
