I understand that for smaller projects keeping methods in the main view controller (namely viewDidLoad
) is the way forward, but for bigger projects im thinking this cant be the way apps are organised - the m file would be chuffing huge! also there would be thousands of declarations at the top! Im nowhere near building an app that big but i'm intrigued, would you put them in a separate file and call them when they're needed? or is it just a case of scroll past the declarations and use pragma marks to find what your looking for?
1 に答える
基本的に、これは iOS アプリケーションを開発するための特定の質問ではなく、ソフトウェア アーキテクチャの問題であり、単一の回答にまとめることのできないより多くの知識が必要です。
しかし、物事が通常どのように機能するかを把握するには、最初にペンと紙でプロジェクトを計画する必要があります.主要コンポーネントのいくつかのERDをプロットし、各パーツが何を担当するかを決定し、そこからプロトタイプ バージョンのコーディングを開始します。
単純なプロジェクトを立ち上げて実行すると、コードのクリーンアップを開始し、さらに計画を立て、コードのテストを開始します。テストがどれほど重要かを説明することはできません。
また、プロジェクト (ソース コードではなく、プロジェクト自体) を管理するためのソフトウェアも必要です。タスクと誰が何をするかを追跡するためのasanaのようなものです。
あなたのコードを一緒に作業している他の人による上書きから安全に保ち、バージョン間で物事を管理し続けるために、いくつかの王様のリビジョン管理リポジトリをセットアップする必要があります.GitはXCodeによって箱から出してサポートされています!
コード作成の部分では、ある種のパターンを学び、それに従う必要があります。iOS プロジェクトや他のほとんどのプロジェクトは現在、MVC 構造に従っています。これは、クラスがどれだけ大きくなるか、どのように方向転換せずに通信するかという質問に答えます。混乱に!
はい、あちこちでプラグマとコードのトリックが必要になりますが、プロジェクトが大きくなったときに物事を保守可能に保つために、常にパターンと規則に従う必要があります。
繰り返しますが、これは良いスタートとは言えません。実際に大規模なプロジェクトに取り組むには、多くの経験と知識が必要ですが、それは素晴らしいことです。
良い仕事を続けてください。常に質問をしなければならないことを常に覚えておいてください。決して怖がらないでください:)
編集 1おそらく私の最後のヒントである、アジャイル ソフトウェア開発 について読むためのヒントを追加するのを忘れていました:)