アプリケーション開発者は、次の製品の開発に取り掛かるために、製品を開発してリリースしなければならないというプレッシャーに常にさらされています。開発者がどれだけ細部まで気を配りたいと思っても、時間をかけてアプリを仕上げることは、開発者にとって許されない贅沢です。
細部にまで気を配ることは、最終的な利益にとって健全なことです。確かに、論理的でよく管理されたエクスプローラーのフォルダー構造には、派手な新機能やおしゃれな UI のような「驚き」の要素はないかもしれません。しかし、よく構築されたアプリには、費やした余分な時間の投資以上のメリットがあります。
- 技術的負債を最小限に抑える
- アプリのメンテナンスが容易になります
- 開発者をプロジェクトに参加させやすくなります
最小限の労力で最大限の洗練度を得るために、アプリケーションのビジネス機能要件以外で、よりクリーンでメンテナンスしやすいアプリケーションを構築するための検討領域の例をいくつかまとめました。 Mendix.
セキュリティ、セキュリティ、セキュリティ
開発とテストの過程において、セキュリティへの配慮は常に念頭に置いておく必要があります。しかし、セキュリティの実装全体を定期的に見直し、最小権限の原則を維持することをお勧めします。これは、通常、さまざまなレベルの権限を持つ複数の開発者がいる場合に特に重要です。 Mendix 同じアプリケーションを同時に開発する経験。
エンティティレベルのセキュリティを維持する
エンティティと属性の CRUD 権限を確認してください。適切な場合は、Xpath 制約を適用して、エンティティの CRUD アクセス権をさらに制限します。たとえば、アカウント オブジェクトが自分に属している場合にのみ、属性への読み取りアクセスを許可します。
もう 1 つの考慮事項は、「新しいメンバーの既定の属性権限」を「なし」に設定することです。開発者は、各属性の読み取り/書き込みアクセス権を自動的に設定して後から考えるのではなく、よく検討することをお勧めします。
機密定数のデフォルト値を空白にする
定数（環境変数）のデフォルト値をすべて空にする 極秘データ (例: API キー) 機密情報を定数のデフォルト値として保存しないでください。
デフォルトの「MxAdmin」管理者ユーザーの名前を変更する
私はお勧め 改名 または、デフォルトの管理者ユーザーをカスタマイズします。
モデリング
モデラーの警告に対処する
適切な場合には、推奨事項を実装する 「警告」タブ カスタム作成されたモジュール用。
アプリケーションログを確認し、改善の機会を特定する
アプリケーション ログには、モデリング エラーの症状を特定するのに役立つ豊富な情報が含まれています。以下の例では、警告メッセージは、代わりに明示的にコミットする必要があるアプリケーションで自動コミット動作が発生していることを通知しています。
MxAssistベストプラクティスボットを聞く
当学校区の MxAssist ベスト プラクティス ボット 何千もの匿名化されたデータの統計分析から共通のアンチパターンを学習します Mendix アプリも組み込まれています Mendix マイクロフロー、ドメイン モデル、ページ、セキュリティなどを開発するためのベスト プラクティス。ボットの推奨事項を確認し、適切な場合は実装します。
ハウスキーピング
ドメインモデルを読みやすくする
以下の例をご覧ください。プロジェクトに参加する新しい開発者にとっては、右側のデータ モデルの方が理解しやすいでしょう。
マイクロフローを読みやすくするために色を使用する
By デフォルトの色を適用する 選択したマイクロフロー/ナノフローアクションに適用すると、読みやすさが大幅に向上します。
上記のスクリーンショットをざっと見れば、マイクロフロー ロジック内のサブマイクロフロー呼び出し (緑) とログ記録アクション (灰色) を簡単に識別できます。
未使用アイテムのクリーンアップ
カスタム作成したアプリケーション モジュール内の未使用の項目をクリーンアップするか、「未使用」としてマークします。プロジェクト/アプリ エクスプローラーをクリーンな状態に保ちながら、未使用または除外された項目を参照として保持する場合は、それらを「未使用」フォルダーに配置します。
マーケットプレイスモジュールを更新し、 Mendix スタジオプロ
マーケットプレイスモジュールと のバージョン Mendix スタジオこれにより、最高レベルのセキュリティと安定性が確保され、次に必要なアップグレードの影響が最小限に抑えられます。
結論
覚えておいてください。本番環境にデプロイするたびに、クリーンで整理された最適化されたアプリケーションを維持することで、アプリケーション エンジンが「十分に機能」し、次のイテレーションに備えることができます。私が共有した推奨事項を、製品イテレーションの最後に 1 回限りの大規模な演習としてではなく、通常の開発サイクルの一部として組み込むと、作業が容易になります。
このブログで取り上げたポイントは、本番環境へのデプロイ前にアプリケーションを磨き上げるための包括的なリストではありません。以下の記事には、さらに役立つ提案が記載されています。