|Welcome to the Monastery|
As the major contributor to their parent company's (Priceline) $4.8 billion annual revenue, $1.1 billion profit and $29 billion market cap., they appear to be doing something right. And given that their core business model has remained essentially the same since they were taken over in 2005, perhaps (part of) the secret that makes this Perl-based company stand out from its (original) peers, is that it hasn't succumbed to any of the fads that place the programming process and programmers above the business model.
Their basic business model hasn't changed; thus the required processes haven't changed much. When new code is required, it is very likely to need to do something very similar to stuff that already exists, and is proven to work.
You don't re-write (or refactor) code unless there is an identifiable, demonstrable reason that benefits the business revenue stream. Entertaining programmers is not such a reason.
Sure, there are times when it is possible to make the case that rewriting a piece of working code will benefit the business -- by improving performance; or simplifying (an existing, bad history of difficult) maintenance; or perhaps reducing runtime memory requirement by combining two or more similar piece of code into one. But the case needs to be made and demonstrated. First.
My take on opportunistic refactoring is different from the interpretation I read here. Rather than: I've got some time on my hands so lets go looking for something to change; I interpret it to mean: I am in this piece of code anyway -- due to a bug to fix or functionality to add or change -- and if I see something else here that can be (demonstrably) improved whilst I'm here, and then make a case for doing so.
First, I think your changes obfuscated rather than clarified that code:
The original code is instantly clear and readable to its purpose; the refactor involves 3 levels of mental indirection to undo what you did.
The training element of introducing the programmer to map is barely justification for such changes.
And finally, if you have the time to faff around refactoring test code, you are under-employed.
I'm not adverse to clever code; but there is nothing clever about that. It's not clearer. It's not simpler. It's not more efficient. It's not even less typing.
What would I have done?
Depends. If it was in test code; I'd probably insisted that the programmer that wrote it, described what it does and how it does it, in an adjacent comment, and then i'd pick holes in that description, until it was fully explained in excruciating detail. Something like:
And I would nit-pick that description until it was precisely, & exhaustively accurate.
I'm not suggesting the above is totally accurate; but the point is that teaching programmers to understand the consequences of their choices, is far more effective than laying down thou shalt/shalt not edicts.
If it was production code, I do the same; and then require it be changed to the ternary form.
With the rise and rise of 'Social' network sites: 'Computers are making people easier to use everyday'
Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
"Science is about questioning the status quo. Questioning authority". I'm with torvalds on this
In the absence of evidence, opinion is indistinguishable from prejudice. Agile (and TDD) debunked