または fprint...">
Clever Geek Handbook

複数の依存フロントエンドを持つソフトウェアライフサイクル戦略の選択

ソフトウェアのライフサイクルは、現代のほとんどのプログラマーに知られています。



彼の最初のプログラムを書いている少年でさえ 



<?php echo "Hello, !  " ?>


または 



 fprintf( '   !\n');


プロセスを理解しています。



  1. タスクを考える-アイデアの段階
  2. 彼は、タスクと、それをどのように実装する必要があるかを考えます-要件の分析と精緻化、

    ソフトウェアモデルと実装計画の構築。 要するに、建築段階。
  3. プログラミング
  4. テスト。 「そこで起こったこと」
  5. 操作。


ステージ1〜5の間に、継続的に相互作用するプロセスがあります。



このために、あらゆる種類のウォーターフォール、スクラムなどがあります。



つまり、プロジェクトがいくつかのタイプのフロントエンドに膨らむと、

現代のITの世界では、顧客はオーディエンスを最大化して利益を最大化することを望んでいます。



このため、APIを介して集中型バックエンドと対話するフロントエンドのいくつかのタイプが存在する豊富なプロジェクトを確認しています。



一般的に、「標準の強力なプロジェクト」には3つのタイプのフロントがあります。



  1. サイト
  2. Androidのモバイルアプリケーション
  3. IOSモバイルアプリ


RESTを介してデータを交換するための単一の開発済みAPI。



私が信頼する良い例は、ソーシャルメディアです（YouTube vidosに基づくあなた自身のプレイヤーについての以前の記事を参照してください）



大規模なプロジェクトには、利益を上げるための3つのオプション、または

条件付きウェブ、アップル、アンドロイド。



プログラマーは、集中型バックエンドアーキテクチャと対話して、開発中の個人的な面に集中することが便利です。



そして、ここに記事のハイライトが表示されます。



事実は、上司の間の意思決定のトップレベルであるということです

後ろに行く新しい機能が形成されます。 しかし、「上司」は不完全な人なので、

それから彼は力をより低いレベルに下げなければなりません。



したがって、私たちの場合、原則として、各戦線上でも、彼らの「低レベル」の首長は階層的または正式な根拠に現れます。 何か

単純化のためのtimlidesのタイプ。



そして、一種の「開発ライフサイクル」の形で大規模プロジェクトを開発するタスク

ソフトウェアの動作はライフサイクルに分割されます。



また、「ミニ」ライフサイクルのプロセスを同期する際に問題が発生します。たとえば、新機能のWeb開発者より先に進んでいる場合、モバイル開発者を待つ必要があるためです。



そうしないと、新しい機能自体の意味が優先されなくなります。これは、私たち全員がWeb上にあり、スマートフォンのモバイルアプリケーションにいるからです。



このような状況で人的資源を最小限に抑えるために、新機能の導入を評価する方法について考えてみましょう。



ここで私は論文を発表します：



  1. いずれかのフロントで機能を実装する場合、後で他のフロントに追いつき、機能に合わせて調整できるように、他のフロントのサイクルを考慮するか、標準スタブをプログラムする必要があります。
  2. ソフトウェア開発サイクル全体のスキームを構築して、全員が条件付きでうまくいくと、機能は時間通りに実装されますが、少なくともフロントエンドチーム同士の独立性は失われます-その後、システム全体のフィードとアジャイルは関連性を失い、反復時間を増加させます開発。 要するに、より多くのチャタリングが発生し、コードの記述が遅くなります。
  3. 原則として、隔離された戦線はより高速ですが、その後、より人的コストの高い統合テストが必要になります。
  4. 現在実装されているスキーム-各フロントは最小限の相互作用で互いに独立して開発されますが、ここではITの基本の一部が失われます-バグが時々見られるゼロ以外のユーザーグループを取得します。


ここで、質問の哲学は、ユーザーが定義上バグを好まないということです。 また、顧客は利益を最大化しようとするため、システムの大規模な複雑化により、ソフトウェアの最終的なプロセスライフサイクルであるため、その最大化が何らかの形で遅くなります。



小規模なプロジェクトでは、このプロセスはさらに悪化します。多くのお客様は、バックエンドとWebが独自に実施され、機能の実装に対して定期的に均一なブレーキを受けますが、多くのお客様がリモートサイトにモバイル開発を行います。



一方、実装プロセスの正式な自動化には危険な障害があります。開発者の間では、ユーザーにローリングアップデートについて尋ねることが一般的です。



私のアイデアはそのようなアイデアです-ライフサイクルのメインタイプを維持し、この場合は独立した前線のサブタイプを持ちながら、1つの優先事項を覚えておく必要があります

戦線の種類（金銭的、歴史的な理由、その他の理由で）ですが、より高いレベルのサイクルの下位ユニットである必要があります。



つまり、優先ウェブフロントが週ごとのスクラムで機能する場合、モバイルフロントの内側のスクラムには、最初のダブルスクラム、つまり2週間が必要です。

混乱が始まります。 ただし、共通の大規模なバージョンのロールアウトは同時に行う必要があります。そうしないと、これを書いている記事の著者がいることになります。 考えてみましょう...


More articles:


All Articles