Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Identify core areas of code base #404

Open
michielbdejong opened this issue Apr 7, 2020 · 3 comments
Open

Identify core areas of code base #404

michielbdejong opened this issue Apr 7, 2020 · 3 comments

Comments

@michielbdejong
Copy link
Collaborator

In order to maximise impact of code-cleanup, I want to find out which areas of the code base are "core" and which areas areas are more expendable (i.e. it would be possible to use rdflib.js without ever touching those).

@michielbdejong
Copy link
Collaborator Author

Under src/ there are 5891 lines of JS and 7259 + 446 + 135 = 7840 lines of TS.
Some things we'll definitely need:

  • src/blank-node.ts (101)
  • src/fetcher.ts (2124)
  • src/formula.ts (935)
  • src/index.ts (119)
  • src/literal.ts (187)
  • src/n3-parser.js (1570)
  • src/named-node.ts (113)
  • src/serializer.js except statementsToXML (965 - 306)
  • src/store.ts except applyPatch (1137 - 95)
  • src/statement.ts (132)
  • src/serialize.ts (102)
  • src/uri.ts (214)

Total: 101 + 2124 + 935 + 119 + 187 + 1570 + 113 + (965 - 306) + (1137 - 95) + 132 + 102 + 214 =

7298

So that's 7298 / (5891 + 7840) = 53%.

@michielbdejong
Copy link
Collaborator Author

Sorry, as @megoth pointed out I forgot about src/update-manager.ts, so then the estimate would be (7298 + 1142)/(5891 + 7840) = 61%.

There may also be more parts we can skip, even in these files. For example, I already excluded statementsToXML and applyPatch from the count, but there may be more like that, so consider 61% to be an upper-limit estimate.

@emmettownsend
Copy link

Without going through it here, we already have the write up and so we know the recommendations we need to follow.
But in general my thoughts on refactoring in this context:

There are many strategies that can be used but some of them are not on the cards for us at the moment because of time constraints. We have dates that we need to deliver dependent products by.

Some of the files are way too big and need to be broken up. We need to consider cohesiveness, loose coupling, testability and separation of concerns. I would not be in favour of refactoring a file at a time because

    1. We do not know that the individual files are cohesive and doing a file at a time will risk not breaking it up properly
    1. We most likely do not need all the code in every file right now so lets only refactor what we need first.

As we create the current product we should refactor rdflib like this:

Start:

  • Pull out a function or class that we need to use into a new library
  • Determine the next dependency that function has
  • Goto Start

This way we only need to refactor the code that we need right now. We will eventually refactor it all but we don't have the need or the time to do it all at once.

You will end up with just the code we need to refactor.

cubedcod added a commit to cubedcod/WebServer that referenced this issue Jul 16, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants