1MEIC08T01: WhatTheDuck - FEUP-MEIC-DS-2024-25/ai4sd GitHub Wiki
WhatTheDuck is an AI-powered assistant designed to boost your refactoring experience in VSCode. Not only is it a powerful tool, but it also takes the form of a Rubber Duck: the iconic problem-solving companion every developer needs.
Have you ever felt the urge to get an answer back from your Rubber Duck after you shower him with all your questions and thoughts? Well, now, thanks to WhatTheDuck, you can!
It will lend you the friendly wing you need when your code is in desperate need of refactoring. By preserving functionality and adhering to coding conventions, WhatTheDuck promises a revolutionary way of refactoring with AI integration.
Our main goals can be summarized in three simple statements:
- Improve the overall readability of the code
- Save developer's time
- Avoid future bugs due to bad code written today
While surveying similar projects to ours, we found out about the following applications:
-
ReSharper is a powerful tool that provides features such as coding analysis, code generation, code smells and error elimination, and more. However, it is designed for Visual Studio and not Visual Studio Code.
-
Refactoring is a built-in Visual Studio Code feature that provides refactoring options for TypeScript and JavaScript code. Nevertheless, it does not use Artificial Intelligence to generate its refactorings, contrary to WhatTheDuck.
-
Refact is an open-source AI coding assistant that provides multiple options to increase the developers' productivity. Nonetheless, it can become confusing with such a variety of possibilities. Moreover, there is a need to type your desired refactoring command, which might not be ideal.
Therefore, we can conclude that none of these implements precisely the same aspects as WhatTheDuck promises. We are proud to be presenting an innovative solution to such a well-known problem!
High-level class diagram
Activity diagram
Below, we present the architecture and design of our system, with the corresponding module explanations:
-
Gemini AI (Software System): This module represents the AI platform, utilising the Gemini API from Google AI Studio.
-
REST API (Container: ExpressJS with TypeScript): Serves as the intermediary service that facilitates interaction between external components and the AI system.
-
VSCode Extension (Container: JavaScript): This module enables user interaction with the AI model directly within the Visual Studio Code environment.
Since there were no restrictions imposed by the client on the technologies we could use, we were free to choose at our own will.
To build the backend API, we chose ExpressJS, which is a server framework based on NodeJS runtime. By choosing ExpressJS, it means that there is a vast ecosystem of libraries available which will allow us to fearlessly extend the functionalities of the backend of our system. In addition, ExpressJS is an excellent choice for building robust and fast APIs, which aligns with our project's goals.
We could have chosen another language for our backend other than JavaScript, citing performance issues. However, even though JavaScript is a garbage collected interpreted language, the main bottlenecks of our system are I/O operations, so the performance difference between a compiled and interpreted language would not be that noticeable.
Since VSCode is an electron app (i.e. a website inside a desktop app) we had two options for programming the Visual Studio Code extension: TypeScript or JavaScript. We ended up choosing the first one, due to its more complex type system that can help us avoid mistakes during development.
In addition, the client required the AI model to be free, since this is only one of 32 projects that is being developed. Therefore, we compared both locally and remotely hosted options and concluded that hosting the model ourselves would be too resource intensive. Then, we searched for an AI model with a good free plan and settled on Gemini. It allows for up to 15 requests per minute and 1500 per day, plus it has a well documented API.
Another technology we will be using is Docker, in order to ensure consistency in package versions as well as replication between developers' computers. Also, by containerizing early on, we make our product easier to deploy in the cloud or in our own infrastructure.
The prototype we implemented for Sprint 0 follows the exact decisions that were mentioned above. Moreover, we expect that no changes will be needed in the area of technology throughout development.
In order to further develop our system, there are some aspects one should take into consideration.
-
Docker: it is important to install it, for the purpose of running the backend.
-
TypeScript: our project uses TypeScript to prevent certain errors. It can be installed globally by running:
npm install -g typescript
-
VSCode Extension Host and VSCode API: for the development of the plugin.
-
API key: Navigate to the backend folder and run the following command:
cp .env.example .env
Then, add the API key (that can be generated here) to the
.envfile.
After installing Docker, to run the backend, navigate to the project root directory and run the following commands:
docker compose build
docker compose upThis will set up and launch the backend in a containerised environment.
Once Docker is running, you can simulate the current state of development by opening Visual Studio Code and choosing the option "Start Debugging" from the menu (or simply press F5). This will allow you to debug the application directly and see how the system behaves.
We follow some standard coding conventions:
- camelCase for variables and methods
- PascalCase for classes
- Consistent identation (4 spaces)
For now, we have yet to identify any security vulnerabilities as the development is still in its initial phase. However, we will be attentive to these concerns and document them in this section in the event they arise.
Every pull request is reviewed by two team members (other than the code developer), which represents an extra layer of quality assurance during the development process. Moreover, and although we did not build formal tests, our application was extensively tested during the development process.
Our plugin is currently available under the Extensions tab of VSCode. Simply search for WhatTheDuck and feel free to install it!
Following the installation, you will need to open the file containing the code you wish to refactor. After selecting that portion of code, you can choose one of the refactoring options available and let WhatTheDuck do its magic ✨
First of all, we are delighted by your interest in contributing to WhatTheDuck!
You should start by contacting our Scrum Master, so that she can guide you in your new journey.
However, keep in mind that there are some aspects which you may be asked to do:
- Develop new refactoring operations
- Improve already implemented refactoring options
- Expand the refactorings to other programming languages
WhatTheDuck is capable of applying one or multiple refactorings at once to a particular Java file, namely:
- Rename Variables
- Inline Temporary Variables
- Extract Variables
- Extract Methods
- Rename Methods
- Inline Methods
- Replace Temp with Query
- Remove Assignments to Parameters
- Remove Parameter
- Replace Magic Number with Symbolic Constant
- Consolidate Duplicate Conditionals
- Remove Nested Conditionals
It also features capabilities that allow the user to analyze/refactor:
- Multiple Files;
- Space Complexity;
- Time Complexity;
- Highlight Expensive Operations, such as Nested Loops;
Moreover, it is possible to preview WhatTheDuck's changes before applying them to your code! You can then accept or reject those changes. Below, we present a preview of WhatTheDuck's capabilities so far:
-
What went well
- Multiple refactoring options were added
- It is possible to select one or multiple refactoring options to apply at once to your Java file
- You can now preview the changes before accepting or rejecting them
- This means that we successfully completed all the predefined US for this sprint
-
What went wrong
- We tended to leave tasks until the last minute, so we need to improve our time management moving forward
-
What is still a problem
- We have detected no problems so far on our development
- What went well
- The Java Conventions are now taken into account
- What went wrong
- We had troubles with the integration of WhatTheDuck
- We couldn't do the User Story to add specific input to be taken account into account in the refactoring and finish the User Story to generate a new refactoring suggestion
- What is still a problem
- The lack of secrets in the integration
- What went well:
- Good Pace: The team maintained a steady and effective workflow pace throughout the iteration.
- High-Quality Work: The work produced was of excellent quality, well-developed, and met the project's standards and expectations.
- What went wrong:
- PR Management Issues: Pull Requests (PRs) were not reviewed promptly, causing delays in development.
- Coordination Challenges: When three groups merged into one, PRs required approval from other sub-groups, leading to a bottleneck.
- What is still a problem:
- Approval Workflow: The dependency on other groups for PR approvals remains an unresolved issue, hindering progress and team collaboration.
- What went well
- Managed to complete all USs and Work Items
- What went wrong
- Had some issues with pull requests, as the new code depended on old code that was altered as the project progressed
- What is still a problem
- Slight bugs in the implementations
- What went well
- We managed to fulfil all the US
- What went wrong
- Besides the "secret's issue" we believe that nothing went particularly wrong during this sprint
- What is still a problem
- There are no problems to solve anytime in the future
- What went well *
- What went wrong *
- What is still a problem *
- What went well
- Managed to implement all USs
- What went wrong
- Lack of git flow made it difficult to merge pull requests
- What is still a problem
- Some features could still be refined/improved
This project is being equally developed by: