4

私は約1年間iOSアプリを開発しています。その間に、アプリからアプリへと頻繁にリサイクルするかなりの数のクラスを開発しました。たとえば、テーブル ビューを記述してアプリ内設定を制御しやすくすることに関連するクラスがたくさんあります。

現時点では、これらのクラスを 1 つのアプリから取得して、次のアプリに貼り付けるだけです。私の質問は、静的ライブラリの作成と使用が容易になるのはどの時点でしょうか?

4

6 に答える 6

1

静的ライブラリにも問題があります。

  • コードが別のプロジェクトにあり、面倒になるため、静的ライブラリを使用すると、問題が発生したときに問題を修正する気が失せます。
  • GCC にはバグがありますが、カテゴリで定義されたメソッドは静的ライブラリから離れて最適化されます。ライブラリコードが既存のクラスの多数の便利なカテゴリで構成されている場合は良くありません。

したがって、実際のソース コードに依存関係を追加できるソリューションが必要です。このようにして厄介な GCC のバグを回避し、ボーイ スカウトのルールが奨励されます!

私たちのソリューションは、Rake に基づく単純な依存関係システムです。共有ライブラリのソース コードへのシンボリック リンクを作成し、ビルド サーバーでビルドするときにハード コピーを作成します(開発者自身のマシンで配布バイナリをビルドしないでください!)。

シンボリック リンクにより、開発者は共有コードを現在のプロジェクトの一部であるかのように編集できますが、クリーンアップやバグ修正などが常に単一のリポジトリに伝播され、共有ライブラリを使用するすべてのプロジェクトに利益をもたらします。

ビルド サーバー上のハードコピーにより、共有ライブラリにバージョンのタグを付けることができるため、App Store に送信した v1.0 の正確なビルドを永久に再現できます!

私の同僚は、ここで継続的な統合のためのビルド サーバーの設定についてブログを書いています。

私は彼にブログを書いて、Rake ベースの依存関係システムも共有するように頼みます。基本的に、Ruby スクリプトを使用したほんの数行です。

于 2010-11-25T16:07:58.473 に答える
0

別のプロジェクトにある静的ライブラリがあります。そうすれば、ライブラリを完全に開発し、単体テストなどを完了してから、それに依存する別のプロジェクトを作成して単純に再利用できます。

これは、カット/ペーストする必要がないことを意味します。また、バグを見つけて修正したり、ライブラリの機能を追加/変更したりする必要がある場合でも、簡単に回帰テストできることを意味します。

これで、そのライブラリを使用するすべてのプロジェクトが恩恵を受けることができます。

したがって、私のお金では、「便利なコード」のコレクションをライブラリに変えるときは、それを再び使用したいと思ったときです。

(もちろん、以前のプロジェクトからコピー/貼り付けして再利用する便利なコード スニペットをすべて持っていますが、それらは必ずしもライブラリにあるとは限りません。)

于 2010-11-26T11:00:45.780 に答える
0

私はさまざまなものの独自のライブラリを持っています。

合理的に一般的であると思われるもの、および将来のある時点で使用することを想定できるものをそれに追加します。

結局のところ、二度と使用しなくても、ライブラリに追加しても害はありません。

于 2010-11-25T15:46:23.517 に答える
0

コピーと貼り付けに飽きたらすぐに、ライブラリを作成する必要があります。または、最初のミス (ミス) コピーと (ミス) ペーストをすぐに行います。

または、よりビジネス的な用語で言えば、正味現在価値が正味現在費用を超える場合です。

于 2010-11-25T15:47:38.133 に答える
0

別の解決策は、サブモジュールをサポートするバージョン管理システム (git など) を使用することです。これらの各ヘルパー クラス (またはクラスのコレクション) を独自のリポジトリにまとめて、コードのメイン リポジトリにインポートできます。

このようにして、切り取りと貼り付けのエラーを心配する必要はありません。また、これらのクラスを改善すると、それらを使用する他のプロジェクトに (必要に応じて) 伝播できますが、バグ修正/テストのためにいつでも以前のバージョンにロールバックできます。

github exampleなどのサイトで、このようなヘルパー コードを見つけるのが一般的です。

于 2010-11-25T16:12:47.870 に答える
0

クラスを「チーム」に配布したい場合は、チームがコードに加える変更について心配する必要がないため、ライブラリの一貫性が保たれます。

または、クラスを API として別の開発チームに販売したい場合は、ソース コードを API ユーザーから隠すことができます。

私は便利だと思う「ユーティリティ」クラスをいくつか持っており、クラスファイルをソリューションにドロップする傾向があります。何よりも習慣から外れています。

于 2010-11-25T15:50:24.913 に答える