On Mon, Dec 15, 2014 at 10:20 AM, Jeff Garzik <jgar...@bitpay.com> wrote: > On Mon, Dec 15, 2014 at 9:57 AM, Btc Drak <btcd...@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/
That's exactly what happened during the modularization process, with the exception that the code movement and refactors happened in parallel rather than in series. But they _were_ done in separate logical chunks for the sake of easier review. The commit tag "MOVEONLY" developed organically out of this process, and a grep of the 0.10 branch for "MOVEONLY" is a testament to exactly how much code moved 1:1 out of huge files and into logically separated places and/or new files. Perhaps it's worth making "MOVEONLY" (which as the name implies, means that code has been copied 1:1 to a new location) use an official dev guideline for use in future refactors. Cory ------------------------------------------------------------------------------ Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server from Actuate! Instantly Supercharge Your Business Reports and Dashboards with Interactivity, Sharing, Native Excel Exports, App Integration & more Get technology previously reserved for billion-dollar corporations, FREE http://pubads.g.doubleclick.net/gampad/clk?id=164703151&iu=/4140/ostg.clktrk _______________________________________________ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
