[Feature Request] Refactoring of Simulation / Util Code (I.e. Tidy Up Initiative)

オープン
  • 何か問題がありますか？
#3,247 コメント 4 件 リアクション 0 件 担当者 0 名 GitHub で見る

メンテナーはふだん 1 日以内に返信

まだ誰も着手していません。

評価

難易度
5/5
見積もり時間
1週間以上
初心者へのやさしさ
35/100
issue の種類
リファクタリング
明瞭さ
説明が足りない
活発さ
静か
技術スタック
java
領域
backend

調査の方向性

The issue describes an ongoing series of small refactors, mentioning Quaternion.java, utility and simulation classes, and their corresponding unit tests. Start by reading a specific class and its tests to understand their purpose and existing coverage; the issue does not identify a bounded task or test entry point. Done for an individual contribution means a focused refactor with any needed test improvements and, where relevant, paper equation or page references in the Javadocs.

索引モデルが issue の本文から書いたものです。

説明

Is your feature request related to a problem? Please describe.
The Simulation side of the core module has a lot of code smells / gremlins that we haven't gone back to tidy up. This has led to difficulties refactoring some of the simulation code in the past. Furthermore, it makes the on boarding of new contributors more difficult (for example, key methods, directly linked to equations within Sampo's original paper, are not signposted to, leaving it as an exercise for the reader to deduce)

Describe the solution you'd like
Simply? A Tidy up from the bottom, working our way upwards. I have already started to do some refactoring of the Quaternion.java class in my own private repo, and this is what ultimately inspired this issue.

Describe alternatives you've considered
The alternative would be to simply leave the code as is, and continue to accept that some aspects of codebase will be difficult for new contributors to begin parsing through / understanding.

Additional context
This issue would not be resolved by a singular PR, but rather be an ongoing effort of many small PRs that would link directly to this issue.

I also believe anyone contributing to this issue should get the benefit of learning more about OR's core codebase from their efforts.

As such:

  • I believe this issue can be marked as "good first issue", with the idea that they are spending the time looking at core classes (such as those in util / simulation), gaining a comprehensive understanding of the class, and using that understanding to propose refactors.

  • I believe this issue could very well be a signposted "good first issue" i.e. a primary suggested issue to consider doing PRs for. A lot of contributors bounce off of OR due to the messiness of some of the codebase (god knows I was one of them for a time haha), so leaning into that by having an issue that is designed to address that problem could see us retain some more potential contributors.

  • I believe this issue's related PRs should not include LLM work, as the main benefit of this issue is not the cleanup, but the understanding that would be gained by those contributing to it.

  • Any work on classes that utilize calculations / concepts from Sampo's original paper (e.g: Such as Quaternions) should reference the equation number / page number corresponding to the code within its javadocs).

  • When refactoring a class, its corresponding Unit Tests should be analyzed and refactored too if there is missing test-cases, lacking code coverage etc. Essentially, no class' Unit Tests should be assumed to be ideal when they are the focus of a PR relating to this issue.

主要言語
Java
スター
3.1k
フォーク
703
平均マージ
22時間 16分
マージ済み PR（30日）
27

環境構築

はじめの一歩

  1. issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
  2. 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
  3. リポジトリをフォークし、ブランチを切って変更します。
  4. issue 番号を参照したプルリクエストを送ります。

openrocket/openrocket のほかの issue

openrocket/openrocket の issue をすべて見る

似ている issue

Java の issue をもっと見る

新しい issue をメールで受け取る

初心者向けの GitHub issue を短くまとめたダイジェスト。