「IDempiereコードへの貢献」の版間の差分

提供: iDempiere ja
移動先:案内、検索
細 (→‎貢献の方法:  誤字修正)
タグ: visualeditor
 
(同じ利用者による、間の4版が非表示)
28行目: 28行目:
 
そこで、私たちはこのチェックリストを作成して、誰もがより簡単に優れたコードを投稿し、このコミュニティの一員となり、継続的な支援と貢献で知られるようにすることを決めました。
 
そこで、私たちはこのチェックリストを作成して、誰もがより簡単に優れたコードを投稿し、このコミュニティの一員となり、継続的な支援と貢献で知られるようにすることを決めました。
  
−
=How to Contribute=
+
=貢献の方法=
  
−
This is a checklist of the main/minimum things that should be done to contribute in the core:
+
これは、コアに貢献するために行うべき主なそして最低限のことをまとめたチェックリストです。:
−
*If you need to change the database check the [http://wiki.idempiere.org/en/Contributing_to_Trunk#Changing_the_database Changing the database] chapter first.
+
*もしデータベースに返納を加えたい場合は、 [http://wiki.idempiere.org/en/Contributing_to_Trunk#Changing_the_database Changing the database] を確認して下さい。
−
''Note: If your development needs the database changes and you don't do this first. You will have to do it all over again''
+
''注意: あなたの開発がデータベースの変更を必要とする場合は、最初にこれをしないでください。あなたはそれをすべてやり直す必要があります''
  
−
*Every commit must be related to a Jira ticket. Please do not mix commits, if the new code needed a refactoring of old code, create one patch for refactoring and one for the actual solution (This makes it easier for review).
+
*すべてのコミットは Jira チケットに関連するものでなければなりません。新しいコードが古いコードのリファクタリングを必要とする場合は、リファクタリング用のパッチと実際のソリューション用のパッチを作成してください (これによりレビューが容易になります)。
−
*When you want to get data. The best way to do it is in the following order:
+
*データを取得したいとき。 それを行うための最良の方法は、次の順序です。:
−
**Model Classes. Most of the M classes in iDempiere have a get method to avoid reading from the database.
+
**モデルクラスを使用する。 iDempiereのほとんどのMクラスには、データベースからの読み取りを回避するためのgetメソッドがあります。
−
**Query Class.
+
**Queryクラスを使用する。
−
**DB Class (DB.get())
+
**DBクラスを使用する(DB.get())
−
**And finally JDBC, only if it is really needed as the impact in the memory is greater than the approaches above.
+
**そして最後に、JDBCは、メモリへの影響が上記のアプローチよりも大きいため、本当に必要な場合に限ります。
−
*Java classes, methods and variable formats. Follow the java standards (meaningful names, camel case). The code should be indented to improve its readability and maintainability.
+
*Javaクラス、メソッド、および変数形式。 Java標準(意味のある名前、キャメルケース)に従ってください。 コードは、読みやすさと保守性を向上させるためにインデントする必要があります。
−
*Make sure each java class has the GPLv2 Header.
+
*各JavaクラスにGPLv2ヘッダーがあることを確認してください。
−
*I think the most important one is the '''collateral analysis''' of your code. Even if you changed one line that you think doesn't have a huge impact. Make sure to know where this change affects the behavior in other classes, where is it referenced, and test the corresponding cases to check that you're not injecting new bugs with your contribution.
+
*最も重要なのは、コードの「担保分析」だと思います。 1行変更しても、大きな影響はないと思います。 この変更が他のクラスの動作に影響を与える場所、参照されている場所を確認し、対応するケースをテストして、貢献によって新しいバグを注入していないことを確認してください。
−
*Make sure you don't fall in one of the [http://wiki.idempiere.org/en/Contributing_to_Trunk#Common_Issues Common Issues]
+
* [http://wiki.idempiere.org/en/Contributing_to_Trunk#Common_Issues Common Issues] のいずれにも違反していないことを確認してください。
  
−
When you have finished the previous steps create the patch with a commit message including the ticket number in JIRA so it updates automatically between the repository and the jira ticket.
+
前の手順が完了したら、JIRAのチケット番号を含むコミットメッセージを使用してパッチを作成し、リポジトリとjiraチケットの間で自動的に更新されるようにします。
  
−
==Changing the database==
+
==データベースを変更する==
−
*If the database was changed and official IDs are needed:
+
*データベースが変更され、公式IDが必要な場合:
−
**First you need to [http://wiki.idempiere.org/en/Centralized_ID_Management Manage the Centralized IDs ]
+
**まずは [http://wiki.idempiere.org/en/Centralized_ID_Management Manage the Centralized IDs ]を確認して下さい。
−
**Then [http://wiki.idempiere.org/en/Generating_Migration_Scripts Generate the Migration Scripts]
+
**次に [http://wiki.idempiere.org/en/Generating_Migration_Scripts Generate the Migration Scripts]を確認して下さい。
−
**When generating a migration script is a good practice to set the right value for the DICTIONARY_ID_COMMENTS SysConfig key. The migration script will take it, while also helping other developers to know what is being worked on when they receive the email of an official ID assignment.
+
**システムコンフィグ設定のDICTIONARY_ID_COMMENTSに適切な値を設定することをお勧めします。 移行スクリプトはそれを受け取り、他の開発者が公式のID割り当ての電子メールを受信したときに何が行われているのかを知るのにも役立ちます。
−
*When you have successfully created your migration scripts name them with this format: '''yyyymmddhhmm_ticket.sql'''
+
*移行スクリプトが正常に作成されたら、次の形式で名前を付けます: '''yyyymmddhhmm_ticket.sql'''
−
*Add at the end of both migration scripts the register line e.g: ''SELECT register_migration_script('201504180139_IDEMPIERE-2556.sql') FROM dual''
+
*両方の移行スクリプトの最後に登録行を追加します e.g: ''SELECT register_migration_script('201504180139_IDEMPIERE-2556.sql') FROM dual''
−
*Copy the respective scripts into the PostgreSQL folder and the oracle folder (migration/i2.1z/...)
+
*それぞれのスクリプトをPostgreSQLフォルダーとoracleフォルダーにコピーします (migration/i2.1z/...)
  
−
==Changing the code==
+
==コードを変更する==
−
*When adding, removing or changing the signature of a public method. It's advised to regenerate the serialVersionUID.
+
*パブリックメソッドのシグネチャを追加、削除、または変更する場合、serialVersionUIDを再生成することをお勧めします。
−
*When changing the signature of a public method, better do an overload.
+
*パブリックメソッドのシグネチャを変更するときは、オーバーロードすることをお勧めします。
−
it helps others customize code or plugin can working.
+
他の人がコードをカスタマイズしたり、プラグインが機能するのを助けます。
  
 
[[Category:HowTo-Technical]]
 
[[Category:HowTo-Technical]]

2021年6月30日 (水) 09:10時点における最新版


 このコンテンツは、Diego Ruizと Thomas Bayen BXService GmbH所属により提供されています。 もし質問や改善の提案があったら、気軽にan emailまでメールして下さい。

このコンテンツは IDempiereコミュニティーへの貢献の一部です。

このチュートリアルの目的

このwikiの目的は、iDempiereのソースコード(Trunk)へのコミット(プッシュ)する事を目標とした改善等の開発方法を示すことです。 人々が心の中で考えてコード化した素晴らしい改良や貢献がたくさんあります。しかし、いくつかの詳細が不足しているために、それらはコミットされません。

共通の課題

iDempiereは偉大なオープンソースプロジェクトであるため、高い品質基準を持つ必要があります。 コードをコアにプッシュすることは、新しい開発を行う際にカバーしなければならないいくつかの意味合いを持っています。そのうちのいくつかを紹介します。:

  • PostgreSQL と Oracleの両方で動作しなければなりません。
  • 新しい機能は以前の機能を壊すことはできません。(これは当たり前のように聞こえますが、十分なテストをしないとこの間違いを犯しやすいです)
  • 下位互換性を確認しましょう。未使用のフィールドが見つかった場合は、多くの実装で人によって異なる方法で使用できると仮定してください。
  • コメント、メソッド、変数は英語でなければなりません。
  • 常にコミュニティでソースコードをレビューする人の事を考えてください - 理解しにくいコードはコメントした方が良いですが、コメントの必要性が過剰になると、名前やアルゴリズムが改善される可能性があります。
  • 大きなことや大きな変更には、大きなドキュメント(マニュアル、ユースケース、テストケース)が必要です。
  • 新機能のコードとリファクタリングのコードを混ぜるとレビューが大変です。どちらの場合も異なるコミットをお願いします。
  • 可能な限りSQLコードを避け、代わりにモデルクラスを使用して下さい。

人々がコミュニティーの事を気にせずに自分のニーズを満たすことだけを考えてしまうと、コードが通用しなくなり、進化させることはある時点で難しくなるか、不可能になってしまいます。

そこで、私たちはこのチェックリストを作成して、誰もがより簡単に優れたコードを投稿し、このコミュニティの一員となり、継続的な支援と貢献で知られるようにすることを決めました。

貢献の方法

これは、コアに貢献するために行うべき主なそして最低限のことをまとめたチェックリストです。:

  • もしデータベースに返納を加えたい場合は、 Changing the database を確認して下さい。

注意: あなたの開発がデータベースの変更を必要とする場合は、最初にこれをしないでください。あなたはそれをすべてやり直す必要があります

  • すべてのコミットは Jira チケットに関連するものでなければなりません。新しいコードが古いコードのリファクタリングを必要とする場合は、リファクタリング用のパッチと実際のソリューション用のパッチを作成してください (これによりレビューが容易になります)。
  • データを取得したいとき。 それを行うための最良の方法は、次の順序です。:
    • モデルクラスを使用する。 iDempiereのほとんどのMクラスには、データベースからの読み取りを回避するためのgetメソッドがあります。
    • Queryクラスを使用する。
    • DBクラスを使用する(DB.get())
    • そして最後に、JDBCは、メモリへの影響が上記のアプローチよりも大きいため、本当に必要な場合に限ります。
  • Javaクラス、メソッド、および変数形式。 Java標準(意味のある名前、キャメルケース)に従ってください。 コードは、読みやすさと保守性を向上させるためにインデントする必要があります。
  • 各JavaクラスにGPLv2ヘッダーがあることを確認してください。
  • 最も重要なのは、コードの「担保分析」だと思います。 1行変更しても、大きな影響はないと思います。 この変更が他のクラスの動作に影響を与える場所、参照されている場所を確認し、対応するケースをテストして、貢献によって新しいバグを注入していないことを確認してください。
  • Common Issues のいずれにも違反していないことを確認してください。

前の手順が完了したら、JIRAのチケット番号を含むコミットメッセージを使用してパッチを作成し、リポジトリとjiraチケットの間で自動的に更新されるようにします。

データベースを変更する

  • データベースが変更され、公式IDが必要な場合:
    • まずは Manage the Centralized IDs を確認して下さい。
    • 次に Generate the Migration Scriptsを確認して下さい。
    • システムコンフィグ設定のDICTIONARY_ID_COMMENTSに適切な値を設定することをお勧めします。 移行スクリプトはそれを受け取り、他の開発者が公式のID割り当ての電子メールを受信したときに何が行われているのかを知るのにも役立ちます。
  • 移行スクリプトが正常に作成されたら、次の形式で名前を付けます: yyyymmddhhmm_ticket.sql
  • 両方の移行スクリプトの最後に登録行を追加します e.g: SELECT register_migration_script('201504180139_IDEMPIERE-2556.sql') FROM dual
  • それぞれのスクリプトをPostgreSQLフォルダーとoracleフォルダーにコピーします (migration/i2.1z/...)

コードを変更する

  • パブリックメソッドのシグネチャを追加、削除、または変更する場合、serialVersionUIDを再生成することをお勧めします。
  • パブリックメソッドのシグネチャを変更するときは、オーバーロードすることをお勧めします。

他の人がコードをカスタマイズしたり、プラグインが機能するのを助けます。

Cookieは私達のサービスを提供するのに役立ちます。このサービスを使用することにより、お客様はCookieの使用に同意するものとします。