1MEIC01T1: Refactor Rocket - FEUP-MEIC-DS-2024-25/ai4sd GitHub Wiki
Index:
- Vision
- Research
- Domain Analysis
- Architecture and Design
- Technologies
- Sprint Retrospective
- Development guide
- How to use
- Contributions
Vision
The “Refactor Rocket” provides a powerful tool that uses AI to automatically evaluate code with regard to established standards, providing feedback in practice to developers. By analyzing the code, the assistant can detect conformity to widely accepted coding guidelines. It would help developers not only to improve code quality but also to simplify the review process, ensuring consistency, reducing human error, and speeding up delivery. Such AI-driven assessment promotes high standards, improves maintainability, and increases software assurance in a wide range of domains.
Research
In the realm of V&V, Pylint, SonarQube, and Codacy are actually very strong tools equipped with static code analysis to improve code quality and discover certain syntax errors, code smells, and compliance situations with best practices. These tools are mostly used for the reason of coding standards enforcement and to also pinpoint the error before execution but the lack of their capability to look beyond the static analysis is their biggest disadvantage.
In contrast, our solution, using Gemini's ability to understand the code's logic and intent allows for more intelligent suggestions and potential improvements.
Domain Analysis
Architecture and design
Technologies
Python
The team chose Python as a backend due to the familiarity with it within the team. It provides a simple and fast method to set up the APIs which is great for building the backend services we need.
Django
As the backend framework building robust web applications with it is very easy. One of its main advantages is its focus on clean and reusable code, which helps the project sustain its usability as it continues to grow.
React
The initial motivation to use React in front-end development was due to the flexibility of React's component-based architecture that enables the codebase to be easily reused, thus facilitating the maintenance process.
Docker
The use of Docker was done to guarantee the similarity of environments during all the stages of development, from local testing to production.
Google Gemini (AI)
Enforced by the Stakeholders as the AI platform they wanted because it is more affordable and flexible and aligns with the final product objectives.
Prototype
In Sprint 0, our prototype can request an evaluation of a code submitted using Python to make a request to the Gemini component which responds with the evaluation. This setup was a proof of concept for the actual process of submitting the code and sending the evaluation request to the AI which in turn sends the responses. The desired frontend was designed with Figma.
Sprint Retrospective
Sprint 1
What went well?
The team worked very well together, allowing the decision-making process and task division to be an easy thing to do. We advanced AI calls by perfecting data insertion and output. Thus, it is obvious that there is progress in the way we, as a result, enhance results.
What went poorly?
We were too optimistic, and we took on more things than we could handle, causing to some issues remain unfinished. The connection with the infrastructure was not also completed as expected.
What can we do to improve?
We need to plan more realistically, committing to more achievable goals. Improving collaboration in the development stage will be a good solution to the challenges and should speed up the process while reducing some difficulties.
What ideas do we have?
Adopting pair programming and more regular check-ins to enhance teamwork and communication would be the alternative directions.
Scrum Board
Sprint 2
What went well?
Communication within the team improved significantly compared to the previous Sprint, facilitating better collaboration and more effective use of the resources provided. The progress made on the project indicates that tasks were being completed and some objectives were achieved.
What went poorly?
Despite user stories being either done or close to being done, the lack of integration between the current application and the struggles trying to solve a bug is a rather severe hit against the overall effectiveness of this Sprint.
What can we do to improve?
It can be crucial to introduce more flexibility into team roles, allowing members to take on different tasks with different code partners, which can boost productivity and feel at ease with the project, depending on our objectives.
What ideas do we have?
The team still needs to carry out more frequent checks. More meetings need to be held, even short ones, to “synchronize” the team on the tasks carried out, in progress and to be carried out. This could eliminate some of the inertia that exists due to the frustration of some blockage in the progress of the Sprint.
Scrum Board
Sprint 3
What went well?
Once the implemented changes in frontend development were made, the team achieved significant improvements, resulting in a clearer vision of the work that has been done in the backend. Collaboration within the team also improved, with members working more cohesively to complete tasks effectively. The integration with the main application was a success, which led to the delivery of a functional product, the main milestone of the project.
What went poorly?
Secrets were not tested and some issues were not implemented. Even though the team was working together, it was still difficult to communicate because of the scheduling and effectiveness of the meetings. Time management remained a concern by stretching some tasks out for longer than they should have been, leading to preventable delays and wastage of time.
What can we do to improve?
The team could benefit from stricter leadership, if the team sets rules and meetings everybody must commit to it. Also, identifying the blockages at the beginning of the sprint would help to minimize the delays and keep the progress more smooth.
What ideas do we have?
In the future, we will create clear and well-defined mid-sprint re-evaluations for tasks and features to ensure timely completion and to avoid unnecessary delays. Also, reassessing what should be done first based on our capacity at given challenges, and this way the workload should be more manageable.
Scrum Board
Development Guide
- All code regarding the backend must be created inside of
superhero-01-01/backend - All code regarding the frontend must be created in
avengers/frontend/assistants/superhero-01-01
To Run:
- Go to
superheroes/superhero-01-01/backend - Run
docker compose up - Go to
avengers/frontend/webapp - Run
npm run dev - In the webpage, add
/assistants/superhero-01-01to the link to open the assistant