Clever Geek Handbook

モバイルアプリケーションの最も価値のないバックエンドを作成する方法







バックエンドなしではモバイルアプリケーションが実行できないことはほとんど知られています。







あなたがモバイル開発者であるなら、あなたはそのようなあごひげを生やしたおじさんに出会ったに違いありません。 または、母乳でphpを吸う、長い髪のかがんだアニメシュニクだったのかもしれません。

いずれにせよ、彼らのほとんどはモバイル開発に遭遇したことがなく、自分自身を第一人者と見なす人もいます。







特にそのような場合のために、アプリケーションのバックエンドを台無しにする方法に関する有害なヒントのリストを用意しました。







良い読書をしてください。

サーバー開発者の場合：









この記事を同僚に見せたとき、多くのバックエンド開発者もいくつかの痛い点を共有することにしました。









役に立つヒント



身近な状況で一緒に笑うことは素晴らしいことですが、それとは別に、私たちが自宅で使用するより効果的な実践をいくつか共有したいと思います。 外部のモバイル開発者と協力する必要がある場合でも、非常に便利なAPIとプロフェッショナリズムに常に感謝しています。







それ以降のヒントはすべてバックエンドに関連していますが、モバイル開発者であれば、これを読むことも興味深く有用です。 結局のところ、まず第一に、変更に興味を持っているのはあなたです。







ドキュメント



これは、モバイル開発者向けのインターフェースです。 有益であるだけでなく、読みやすく、目を楽しませてください。 奇妙に聞こえますが、ドキュメントが認識されやすくなればなるほど、ドキュメントをすばやく簡単に操作でき、プロセスでの質問が少なくなります。







最も簡単で便利なオプションは、Swaggerを使用することです。 最初の外観には、多くの要望がありますが：







ただし、 フォーマッタを使用すると問題なく改善できます。









それは素敵で快適なことが判明しました。 代替として、 Apiaryを使用できますが、コードとドキュメントを分離する必要がありますが、これは望ましくないか、レンダリングに煩わ​​されます。







均一性



モバイル開発には困難があります-多くのソリューションとフレームワークは非常に遅いです。 特定のリクエストの形式だけを受け取って変更することはできません。または、非常に困難です。 特定の場合にのみ特定のフィールドの名前を変更することは不可能であるため、貧しい開発者は声を叫び、その下に松葉杖を刺そうとします。







すべてが全体的である必要があります。どこでも同じ名前、1つの対話形式（できればJSON）などです。







要求と応答のパラメーター名がモバイルアプリケーションの対応するクラスのフィールドと完全に一致する場合は特に便利です。 奇妙に聞こえますが、デベロッパーの生活が楽になるので、ストアからチョコレートを運ぶことになります。







いくつかの場所では、単純化がばかげたことになります。たとえば、Realm（モバイルデータベース）への保存は、jsonからほとんどすぐに実行できます。 興味深い場合は、モバイルアプリケーションでミドルウェアを削除する方法について個別に説明します。







iOSに着信オブジェクトを保存するサンプルコード：



サーバーからデータベースへの任意のエントリに対する1つの汎用メソッド。 いいですね







画像についても同じことが言えます。 「終了」する必要のない写真にすぐにリンクが来たら最高です。 そして同じルールで-リンクの名前はどこでも同じでなければなりません。







モバイルアプリケーションの特定の情報ブロックについて、Googleで画像を検索する必要がある場合がありました。 その結果、アプリケーションが参照する画像への擬似リンクを作成し、サーバー内でGoogleで適切な画像を探してリダイレクトします。 そして、このアプリケーションの場合、これは最も普通のpicchaのように見えますが、これはもう少し長く考えるだけです。







充足



サーバーで作業している場合、通常はすべてがリクエストの同じスコープ内にあり、データを書き込むためにトランザクションを開いて順番にプッシュするだけで十分です。 すべてが分離され、予測可能で線形です。







モバイルアプリケーションにはそのようなものはありません。 すべてが非同期に回転しているため、異なるリクエストからのデータの整合性を維持したい場合、これはマルチスレッド、強烈なクリティカルセクション、優先度の割り当てを伴う最も複雑な操作に変換されるため、ブレーキのヒントはありません。 モバイル開発者のインタビューでスレッドの同期に関する質問が最初の質問の1つになっているのも不思議ではありません。







これで、モバイル開発者がすべてが単一のリクエストで送信されるようにしようとしている理由を理解できましたか？ 彼らが今日家を出るかどうかによります）







そしてもちろん、一部のデータを非同期にロードする必要がある場合、それらを共通のヒープに押し込む必要はありません。これを理解する必要があります。







結局のところ、アプリケーション設計を開いて、APIを作成している画面が何で構成されているかを確認するのが面倒ではありません。 モバイルの同僚と相談し、データを提供する最善の方法と、その後のリクエストがモバイルに依存するかどうかを判断します。 たぶん、この特定のリクエストでは、十分と思われるよりも少し多くの情報を提供する必要があります。 しかし、それはその後の仕事をクライアントでより便利で楽しいものにします。 そのような些細なことを手伝うと、あなたは長い間思い出されるでしょう。 そして、彼らは温かく彼らの職業生活全体を覚えています。







同じ段落に、デバッグ情報を含めたいと思います。 コメントのリストをリクエストした場合は、これらのコメントがあることを確認してください。 同じ種類のデータを保存するのに1分かかります。モバイル部門のパートナーにとっては、これは安心です。







安定性



私が別に注意を払いたいアーカイブポイントです。 常にAPIを確認するか、さらに良いことに、テストでそれを実行してください。 バックエンドの各バグは、クライアントの10に相当します。 結局のところ、サーバーとユーザーの間には、サーバーを非難する前に除外しなければならない多くのレベルの抽象化があります。







各バグは、ユーザー、テスター、モバイル開発者の時間を費やします。 あなたには最大の責任があり、あなたの間違いは会社に最も大きな損害を与えます。







おまけとして、少なくとも開発の時点で、きれいな活字があれば素晴らしいことです。 ドキュメントを見なくても、サーバーから送られてきたものを把握する必要がある場合があります。







読みやすいのは次のとおりです。













またはこれ：













違いは、私には思えますが、顔にあります。

最も重要なことは、バトルサーバー上でプリティプリントをオフにすることを忘れないでください。







おわりに



ルールは実際には1つであり、非常に単純であると全員に伝えたいだけです。同僚にあなたの仕事から歯を削るように強制しないでください。







次回はGoに移行し、クライアント上のビジネスロジックの巨大な塊を取り除き、アプリケーションバイナリを3分の1以上削減する方法について話します。







More articles:


All Articles