On Mon, Dec 15, 2014 at 9:57 AM, Btc Drak <btcdrak@gmail.com> wrote:
We all want to see more modular code, but the first steps should just be to relocate blocks of code so everything is more logically organised in smaller files (especially for consensus critical code). Refactoring should come in a second wave preferably after a stable release.

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.

--
Jeff Garzik
Bitcoin core developer and open source evangelist
BitPay, Inc.      https://bitpay.com/