orientdb
orientdb copied to clipboard
Potential Refactoring Estimate
Summary I have identified a few classes with refactoring potential along with its estimated time to refactor, specifically OSecurityRemote.java. The estimated time is based on historical commits containing refactoring and the complexity of the involved classes. The class was refactored once on Aug 5, 2020 along with other classes in commit 36f52c52a5d6eb8d142671a516de9dcd66dedef3. Given the duration of the last refactoring, could it be possible to improve this class further? I am probably not qualified and experienced enough to point out the exact code needs to be refactored, given my limited knowledge of the project and codebase.
Urgency Low priority. For maintenance of code in the long run.
Hi, I am currently doing some research on Estimating Time Taken for Software Refactoring. Orientdb is one of my case studies being a highly popular project. Would appreciate your kind feedback on the appropriateness of the estimated time to refactor. I am specifically looking at potential for refactoring, such as breaking functions that are too long into shorter functions, or to remove code duplication. Would you agree that there could be some modification to the code to make it better in the listed classes? And if so, is the estimated time appropriate to carry out the improvement? I will be grateful for any help you can provide.
- OSecurityRemote.java - 2.5 hours
- OSecurity.java - 2 hours
- OSecurityShared.java - 2.5 hours
Thank you.
Regards, Alvin
Hi,
Estimate refactors is hard, for the specific case I see that there is some heavy logic in OSecurityShared that may need a bit of double check and cleanup that would take probably half a day, the other two class require less work, the only thing that is needed there for now is to throw away old deprecated logic when is possible to be not compatible to the past, that would take an hour more or less.
In any case this estimations are a bit wrong, I mean the code changing effort is not the biggest part of this refactor, is way more hard to understand the logic and the context where that logic exists, often as well logic could be moved across classes, this is not counted in this case.
Also one thing to count is that refactor may bring regression, so running tests to verify that no regressions are there is quite important, and I find myself spending time a lot after a refactor to identify what is the reason for a regression in case it happen, this may translate a few hours of code changing in few days debugging, that is a cost that need to be factor in the estimations.
Regards
Hi @tglman,
Thank you very much for your input! Your insights are very valuable in helping me improve. I understand that my estimations are not accurate in this context, but it is really helpful in understanding why my estimations are incorrect.
Regards, Alvin