|
Hi, On 07/15/2016 02:16 AM, Erik Huelsmann
wrote:
Not entirely opposed to the idea, but I think the focus should be on the overall system design -- don't want to get sucked into too much module-by-module rewriting. I'm thinking we should be focused on three key design areas: - What is the desired user experience we want to have? The BDD tests are crucial for this, and we should develop those before doing any forking into parallel branches. - What sort of API can we put in place to act as a contract between the user experience, any external integrations, and the back end? - Do we have the best underlying data schema in place going forward? (E.g. the multi-currency stuff that Erik has created -- are there any other ways our current schema limits what LSMB can do effectively?) I think a strong focus on these 3 key areas will make our project progress based on a much more cohesive intention, rather than fighting fires/bugs/fixing things as they arise and doing battle with the old code... I would like to see us develop these 3 things first, define what we want the system to do and how we want it to behave -- and try to wrap as much of the old code in as possible. I do expect we may hit some big roadblocks in some parts of the code that are just not possible to wrap or fix without rewriting -- but how many of these have you already blown through and rewritten? I suspect with proper design, it may be possible to rewrite the implementation much more quickly, making the new code work the way it should work, and not just a better version of a crap design.
I don't think we need to focus on onboarding other developers. I do think we should start more marketing. I think the work Erik has been doing on BDD is fantastic, and if we start talking about it more, we're sure to attract other developers. And if we have a solid API and BDD framework, I think it will be easier to solicit contributions from new developers...
Totally agree here -- having something that mostly works and a bunch of companies using it, and evolving that to better tested, more reliable code is a big win. While I do think it's a good idea to start a fresh branch with only working code, that also becomes a huge barrier to contribution if nobody is using that code in production. It becomes such a massive undertaking with really far-off payoff. I mean, I would love if somebody would do this work -- AFTER we know what it should look like, with as much of the new design dropped into the currently working version as possible. As long as it got done at sometime useful, and didn't happen at the expense of having a working production version.
Maybe we can put new API/interfaces in as stubs, build out the whole design in the current release? Throw "unimplemented" exceptions where the new code isn't built yet, build the parallel functionality in the current release and migrate stuff over a chunk at a time? <snip>
Yes, exactly -- I think we should continue this approach. <snip>
Agreed... Happy to add more later, but gotta run, camping weekend ahead! Cheers, John Locke http://www.freelock.com |
------------------------------------------------------------------------------ What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic patterns at an interface-level. Reveals which users, apps, and protocols are consuming the most bandwidth. Provides multi-vendor support for NetFlow, J-Flow, sFlow and other flows. Make informed decisions using capacity planning reports.http://sdm.link/zohodev2dev
_______________________________________________ Ledger-smb-devel mailing list ..hidden.. https://lists.sourceforge.net/lists/listinfo/ledger-smb-devel