Cory Fields [ARCHIVE] on Nostr: 📅 Original date posted:2014-12-15 📝 Original message:On Mon, Dec 15, 2014 at ...
📅 Original date posted:2014-12-15
📝 Original message:On Mon, Dec 15, 2014 at 10:20 AM, Jeff Garzik <jgarzik at bitpay.com> wrote:
> On Mon, Dec 15, 2014 at 9:57 AM, Btc Drak <btcdrak at 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
📝 Original message:On Mon, Dec 15, 2014 at 10:20 AM, Jeff Garzik <jgarzik at bitpay.com> wrote:
> On Mon, Dec 15, 2014 at 9:57 AM, Btc Drak <btcdrak at 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