「IDempiereコードへの貢献」の版間の差分
Hideaki Hagiwara (トーク | 投稿記録) 細 (→共通の課題) |
Hideaki Hagiwara (トーク | 投稿記録) 細 (→貢献の方法: 誤字修正) タグ: visualeditor |
||
| (同じ利用者による、間の4版が非表示) | |||
| 28行目: | 28行目: | ||
そこで、私たちはこのチェックリストを作成して、誰もがより簡単に優れたコードを投稿し、このコミュニティの一員となり、継続的な支援と貢献で知られるようにすることを決めました。 | そこで、私たちはこのチェックリストを作成して、誰もがより簡単に優れたコードを投稿し、このコミュニティの一員となり、継続的な支援と貢献で知られるようにすることを決めました。 | ||
| − | = | + | =貢献の方法= |
| − | + | これは、コアに貢献するために行うべき主なそして最低限のことをまとめたチェックリストです。: | |
| − | * | + | *もしデータベースに返納を加えたい場合は、 [http://wiki.idempiere.org/en/Contributing_to_Trunk#Changing_the_database Changing the database] を確認して下さい。 |
| − | '' | + | ''注意: あなたの開発がデータベースの変更を必要とする場合は、最初にこれをしないでください。あなたはそれをすべてやり直す必要があります'' |
| − | * | + | *すべてのコミットは Jira チケットに関連するものでなければなりません。新しいコードが古いコードのリファクタリングを必要とする場合は、リファクタリング用のパッチと実際のソリューション用のパッチを作成してください (これによりレビューが容易になります)。 |
| − | * | + | *データを取得したいとき。 それを行うための最良の方法は、次の順序です。: |
| − | ** | + | **モデルクラスを使用する。 iDempiereのほとんどのMクラスには、データベースからの読み取りを回避するためのgetメソッドがあります。 |
| − | ** | + | **Queryクラスを使用する。 |
| − | ** | + | **DBクラスを使用する(DB.get()) |
| − | ** | + | **そして最後に、JDBCは、メモリへの影響が上記のアプローチよりも大きいため、本当に必要な場合に限ります。 |
| − | * | + | *Javaクラス、メソッド、および変数形式。 Java標準(意味のある名前、キャメルケース)に従ってください。 コードは、読みやすさと保守性を向上させるためにインデントする必要があります。 |
| − | * | + | *各JavaクラスにGPLv2ヘッダーがあることを確認してください。 |
| − | * | + | *最も重要なのは、コードの「担保分析」だと思います。 1行変更しても、大きな影響はないと思います。 この変更が他のクラスの動作に影響を与える場所、参照されている場所を確認し、対応するケースをテストして、貢献によって新しいバグを注入していないことを確認してください。 |
| − | * | + | * [http://wiki.idempiere.org/en/Contributing_to_Trunk#Common_Issues Common Issues] のいずれにも違反していないことを確認してください。 |
| − | + | 前の手順が完了したら、JIRAのチケット番号を含むコミットメッセージを使用してパッチを作成し、リポジトリとjiraチケットの間で自動的に更新されるようにします。 | |
| − | == | + | ==データベースを変更する== |
| − | * | + | *データベースが変更され、公式IDが必要な場合: |
| − | ** | + | **まずは [http://wiki.idempiere.org/en/Centralized_ID_Management Manage the Centralized IDs ]を確認して下さい。 |
| − | ** | + | **次に [http://wiki.idempiere.org/en/Generating_Migration_Scripts 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を再生成することをお勧めします。 |
| − | * | + | *パブリックメソッドのシグネチャを変更するときは、オーバーロードすることをお勧めします。 |
| − | + | 他の人がコードをカスタマイズしたり、プラグインが機能するのを助けます。 | |
[[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を再生成することをお勧めします。
- パブリックメソッドのシグネチャを変更するときは、オーバーロードすることをお勧めします。
他の人がコードをカスタマイズしたり、プラグインが機能するのを助けます。
