<div dir="ltr">On Mon, Dec 15, 2014 at 9:57 AM, Btc Drak <span dir="ltr">&lt;<a href="mailto:btcdrak@gmail.com" target="_blank">btcdrak@gmail.com</a>&gt;</span> wrote:<br><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div>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.</div></div></blockquote></div><div class="gmail_extra"><br></div>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 &gt; 1MB of source code.  The first step was -always- raw code movement, a brain-dead breaking up of code into logical source code files.</div><div class="gmail_extra"><br></div><div class="gmail_extra">Refactoring of data structures comes after that.</div><div class="gmail_extra"><br></div><div class="gmail_extra">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</div><div class="gmail_extra"><br></div><div class="gmail_extra">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.</div><div class="gmail_extra"><br></div><div class="gmail_extra">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.</div><div class="gmail_extra"><br></div><div class="gmail_extra">-- <br><div class="gmail_signature">Jeff Garzik<br>Bitcoin core developer and open source evangelist<br>BitPay, Inc.      <a href="https://bitpay.com/" target="_blank">https://bitpay.com/</a></div>
</div></div>