ストーリーボードは、iOS で複数のビュー コントローラーとそれらの間の遷移を処理するエレガントな方法のようです。
ただし、複数の開発者が同じストーリーボード ファイル内のビュー コントローラーに変更を加えた場合に何が起こるか、および結果としてマージの競合が発生する可能性があることを懸念して、今までそれらを使用することを避けてきました。
中程度の複雑さの本番アプリで、これについて多くの実践的な経験をした人はいますか?
あなたの評価はどうですか? この点で、絵コンテは「プライムタイム」の準備ができていますか? それとも、単一の開発者または小規模な開発チームに適していますか?
(そして、複数のストーリーボード ファイルへの「シャーディング」などの回避策はどうですか?)
意見？
ありがとうございました！
少し背景：
私の5人のチーム、4人の開発者、およびQAは、かなりの量のストーリーボードを利用したかなり大規模なプロジェクト（5万行以上のコード）を完成させました。少なくとも10種類のストーリーボードがあり、その多くはナビゲーション構造の5レベルまたは6レベルの深さにあります。
さらに、Perforceによるバージョン管理に大きく依存しており、1日に数十回のチェックインが行われます。
私の経験：
ストーリーボードで解決策を処理することを考える必要は一度もありませんでした。これらは、2つの主な理由から、バージョン管理で非常にうまく処理されます。まず、1つを開くと、バージョン管理と非常にうまく機能する、適切に構造化されたXMLであることがわかります。次に、ストーリーボードでは、詳細やコードを追加する前に、常にUI構造全体をレイアウトする必要があります（これが要点です）。これは、各メンバーが個々のViewControllerを取得して実装し、他のチームの取り組みから隔離されたままであるため、チームコーディングソリューションに非常に役立ちます。
ただし、接続の巨大なネズミの巣を簡単に進行させることができるので、いくつかの「シャーディング」を行うことをお勧めします。
ついに：
オンラインで少し見てみると、ストーリーボーディングに対して多くの否定的な反応が見られます。これは、あるビューから次のビューにデータを渡すのが「面倒」になる可能性があるためです。ただし、このような状況に陥っている場合は、MVCの基本原則にすでに違反しています。ビューを使用してデータを保存および管理するべきではありません。最初は魅力的で簡単ですが、プロジェクトが基本を超えていくと、最終的には問題が発生します。
マージの競合は、Apple がまだ解決していない大きな問題です (Xcode 4.6 を含む)。場合によっては、ストーリーボードのコンテンツを表示するだけで変更されることがあります。変更は nib の無害な内部動作のように見えますが、2 人が変更を加えずにストーリーボードを表示し、ファイルを保存してからコミットすると、マージ方法がわからない競合が発生する可能性があります。しばらく前にこれについてバグを報告しましたが、既知の問題の重複としてマークされています。
これをサポートするこれらの質問も参照してください。
http://robsprogramknowledge.blogspot.com/2012/01/uistoryboard-best-practices.html