Skip to content

Instantly share code, notes, and snippets.

@mosser
Last active October 26, 2018 10:39
Show Gist options
  • Save mosser/c13a7d74b05f1c9a375589af2a4dde46 to your computer and use it in GitHub Desktop.
Save mosser/c13a7d74b05f1c9a375589af2a4dde46 to your computer and use it in GitHub Desktop.
Composing Code refactoring intership proposal

Composing Code refactoring

This internship proposition will be hosted at Université du Québec à Montréal (UQAM).

Summary

Software code is often subject to code refactoring. This is the essence tof test-driven development: (i) test, (ii) code, (iii) make test green, (iv) refactor. Refactoring is often performed manually, or with a support from the IDE. But the information that a given refactoring happened is lost, leading to the infamous "I told you so" versioning anti-pattern where 2 alternative design are constantly added and removed in the given system. We propose in this project to formalise the classical code refactoring and to remember their application, supporting developers at both level: (i) making easy to apply a refactoring to a given piece of code and (ii) reasoning on the sequence of refactoring made in a given project.

Project Description

We consider here the refactoring defined by Fowler in his seminal book. In the project, students will provide a framework where an expert can implement a refactoring rule. Then, according to the available catalogue, a developer will be able to select the rule to apply, configure it and automatically apply it to her source code. Then, The system will version this application in a way that the whole story will be available to support reasoning.

For example, a developer d asks the system to refactor a class C into C' (applying a renaming rule). The system will automatically apply the modification to the source code. The system will also warns the user that this class wal already named C' two month ago. The idea is to reason on the sequence of refactoring to provide a better support for end-user. In addition, it can also help conflict resolution when performing code merge (by computing the canonical sequence of refactoring to apply when refactoring were performed in ≠ branches).

It might be possible to extend this work into an internship.

Expected Skills

  • good knowledge of the Java programming language
  • affinity with code generation, reflexivity and metaprograming
  • logical reasoning

Requirements

The refactoring rules will be implemented in Java (e.g., using Spoon), and the project will cover well defined rules extracted from Fowler's book. The user will interact with the rules using a CLI as a minimal and viable product, and a possible integration into a classical IDE such as IntelliJ or Eclipse. The project will use Git as versioning control system to support refactoring versioning.

Expected results

  • a framework to express refactoring rules
  • experiments showing how the rules can be applied to Java code
  • Reasoning on sequences of refactoring rules to warn users or support better merge.

References

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment