Outline of my refactoring goals

[Mervill]

Hi 👋

I thought I'd write down some of my thoughts on refactoring the project for readability, organization and (hopefully) expansion. As I think I've said in the past, I'm a big fan of this project, but my skills in calculus and circuity are still somewhat lacking. What I think I can bring to the project in the short term is a refactoring effort which I hope will make it easier for existing members to maintain and easier for new members to join the project. In the mid-to-long term I also want to look into improving the performance of the app with large and extra-large circuits.

Please reply with feedback!

Generally these are in order of priority/need

• Reduce the number of lines in CirSim.java by separating concerns.
  • Overall I think this is the most important goal. I've already summited one pull request that starts to separate code into more easily managed files. I think it will go a long way toward making the project easier to manage and navigate.
  • Ideally CirSim.java should contain only code directly related to ticking/solving the simulation (runCircuit() and decedents), I know this probably wont happen any time soon (if at all). It's an aspirational goal.
• Organize UI code under circuitjs1.client.ui.*
  • Both code that gets extracted from CirSim.java and files that already exist like AboutBox.java should be reorganized under a ui folder/namespace.
• Create a Platform.java class for the JavaScript based native code where appropriate.
• Investigate streamlining the process of adding new circuit elements.
• As a result of other refactoring, having a folder that contains only CircuitElm and the other circuit elements.
• Reorganize Graphics / Draw related code
  • I haven't looked deeply into this yet, but I think doing a survey of the Graphics related code will yield some easy refactoring wins.

[pfalstad]

Looks great. Splitting up CirSim.java would be really nice.

[fritzw]

Refactoring is a great idea, I applaud your effort and I agree that it would improve readability and maintainability. However, I'd be cautious to make large changes when there are no automated test cases. Every refactoring step has the risk to introduce subtle bugs, and it is impossible to test the whole application manually after each step.

So one of the first steps should be to write some unit tests and some integration tests. Ironically, this would probably be much easier after refactoring and separation of concerns.

[ataricom]

True, but everything should begin with an outline. I know next to nothing about formal testing in Java or js, and the only "test" files I can find in the source is a folder test circuits, so it looks like incorporating actual testing into the repo then that would be a fantastic place to start.

ETA: @pfalstad, I mean absolutely no disrespect and hope that wasn't harsh. I'm used to python and having a test suite written out completely separately from the rest of the code.