This is my opinion as well.  In the Linux kernel, we often were faced with a situation where you have a One Big File driver with > 1MB of source code.  The first step was -always- raw code movement, a brain-dead breaking up of code into logical source code files.

Refactoring of data structures comes after that.

While not always money-critical, these drivers Had To Keep Working.  We had several situations where we had active users, but zero hardware access for debugging, and zero access to the vendor knowledge (hardware documentation, engineers).  Failure was not an option.  ;p

Performing the dumb Break Up Files step first means that future, more invasive data structures are easier to review, logically segregated, and not obscured by further code movement changes down the line.  In code such as Bitcoin Core, it is important to think about the _patch stream_ and how to optimize for reviewer bandwidth.

The current stream of refactoring is really a turn-off in terms of reviewing, sapping reviewer bandwidth by IMO being reviewer-unfriendly.  It is a seemingly never-ending series of tiny refactor-and-then-stuff-in-a-class-and-make-it-pretty-and-do-all-the-work.  Some change is in order, gentlemen.

--