iOSプログラマーのハンマー、ハンマー、マイクロメーターに関するメモ

私がシニアiOS開発者であるとインタビューですでに説得していた良い瞬間に、私は頑固であると感じました。 私は同じようなコードを書いています、私は同じような方法で問題を解決します、そして、さらにどこで開発するかが明確でないという感覚。 私が遭遇したのはこの問題だけではなかったと思います-新しいアイデア、コンセプト、方向性の欠如。 この気持ちを克服するのに役立つツールとフレームワークについてお話したいと思います。



ここの開発者のほとんどは、4人のギャングのような男を読んでいたと思います。 インタビューでさえ全員がパターンという言葉を聞き、幸運な人はより悪い（またはより少ない）より悪い言葉（命令的、機能的、モナド、反応性、その他の恐怖）を聞いた。 一般に、ソフトウェア開発の世界ではかなり多くの明るくて面白いアイデアが出回っていますが、幸いなことに、それらのすべてが言葉の抽象化の形でのみ存在するわけではありません。 この記事では、適用されたツールについてはあまり話さず（ほとんどの作業時間に出会うのは彼と一緒ですが）、理解を必要とするツールの例についてお話したいと思います。 どのように（およびどの）ツールが設計、コード作成のプロセスを変更するかについてお話ししたいと思います。







私の意見では、この記事は中級レベルの開発者にとってはかなり複雑になりますが、ここにすばらしいツールをリストします。コードとアプリケーションの例を読むと、開発に非常に役立ちます。 経験豊富な開発者にとっては、この情報のかなりの部分は確かに知られていますが、あなたにとって役に立つ何かが見つかると信じています。 少なくとも、恥ずかしくて恐ろしいことに、この記事で説明したことのほとんどにかなり遅れて会ったからです。



一般的に、実践が示すように、最も有用なソリューションは通常非常に簡単です。 主な最適化は、ほとんどの場合、O（n log n）の代わりにO（n）の漸近的な振る舞いを持つアルゴリズムを選択することではなく、コードベースを整理する方法を選択することにあります。 独自のコードに苦労する時間が少なくなると、コードの改善により多くの時間を費やすことになります。 したがって、前回UITableViewにPullToRefreshを実装する201番目のポッドよりも、コードの整理に多くの時間を費やそうとしました。 そして、私が知っているいくつかの方法を共有したいと思います。

• 最初の最小の章では、それほど複雑ではないが便利な3つのフレームワークから始めます。 むしろ、すぐに完全な深さに飛び込むことなく、開始する場所を得るために。
  
  
  • ココアポッド
  • マジカルレコード
  • 約束キット
  
  
  
• 2番目の章では、アプリケーションまたはその重要な部分、つまり開発プロセス全体に深刻な影響を与えるアイデアや概念の基礎となるフレームワークをリストします。 それらを最大限に使い始めるには、それらに基づいて少なくとも2、3の小さなアプリケーションを作成することをお勧めします。これらは、新しい機能を設計するときの思考に大きな影響を与えるからです。
  
  
  • 純粋なmvc
  • 灰のフレームワーク
  • 反応性ココア
  • componentKit
  
  
  
• 3番目の章では、テストと、テスト可能なコードを作成できるものについて説明します。
  
  
  • 期待
  • OCMock
  • 血の魔法
  
  
  
• 第4章は、コードに組み込むことができるフレームワークではなく、コードの作業を容易にするツールに専念します。
  
  
  • 発電機
  • ファストレーン
  • YACC / LEX

許しを事前にお願いします。 ビルボ・バギンズが言ったように：

私はあなたの良い半分をそれが2倍悪いことを知っています、そして私は私がそうするべき半分の薄い半分を愛しています。

だからここにいる-この記事では、提案されたツールの詳細な分析は十分ではありません（ここにはコードも1行もありません！）-主観的な感情と使用の推奨のみです。 また、多くのツールがあり、それぞれが個別の分析に値します。

しかし！ これらのレビューがあります-そして、各ツールについて、その使用例、ドキュメント、関連情報を見つけることができる場所を示しようとしました-良い、それは本当に十分以上です。



それでは始めましょう。

第1章はじめに

ココアポッド

この楽器について聞いてくれない人はおそらくここにいないでしょう。 プロジェクトの外部依存関係管理ツール（サードパーティ）。

あなたはここでそれについて読むことができます 。 誰もがすべてを完全に知っているので、ここでは彼について特に説明しません。 そして、知らない人のために、あなたはここを読んで 、iOS開発者のためのこのツールが必須であることを考慮に入れることができます。 使用への移行により、新しいアプリケーションのプロトタイピングにかかる​​時間が大幅に短縮され、独自の炉床を作成することで、再利用可能なコードを作成するプロセスが大幅に統制されます。



長所

• 信じられないほど簡単なプロジェクトの依存関係管理。 新しいものの追加はたった1行で完了します。
• 再利用可能なコードを、再利用を促進する便利でシンプルなコンテナにパックする機能。
• アプリケーションのコードから依存関係のコードを分離します。これにより、サードパーティツールキットのコードを変更する誘惑が軽減されます（もちろん、これは便利で必要な場合もあります。依存関係モジュールの最初の更新前）。

短所

• 依存関係を追加するプロセスは非常に単純化されているため、これらの依存関係の多くがくしゃみごとにプロジェクトに追加されないように注意して監視する必要があります。 そして、これがプロトタイピングに適している場合-そして、長命のプロジェクトに-これは重要な質問です。すべてのサードパーティが完璧というわけではありませんが、間違いの責任はあなたにあるからです。
• 奇妙なものが必要な場合は、ときどきそれを調べなければなりません。 たとえば、ある時点で、ターゲットごとに異なるアーキテクチャを正しく組み立てるようにプロジェクトを教えるのにかなりの時間がかかりました。 おそらく今では簡単で快適になっていますが、事実は残っています。

マジカルレコード

データベースフレームワーク。CoreDataのラッパーです。 詳細はこちらをご覧ください 。

MagicalRecordは、以前にあらゆる方法でCoreDataを避けた場合でも、CoreDataの使用を開始するのに役立ちます。 CoreDataが燃えている家でコーヒーとどのように機能するかを理解せずにMagicalRecordを使用して比較したことがあります-私はそれを理解できますが、私の個人的な経験から-私は、実用的なタスク。



MR自体は、Objective-CのActiveRecordコンセプトの適応です。 この概念は、データベースを操作する際の焦点をデータベースとテーブルから個々のレコードに移し、データベースとの基本的な操作をそれらに関連付けます。 つまり、「テーブル-このレコードを削除する」の代わりに、「レコード-失敗」または「レコード-作成、変更、本質に対応するすべてのインスタンスを提供する」と言います。



これを使用すると、データベースのラッパー内のコードの量を大幅に削減できます。 さらに、データベースを操作するためのはるかに簡単で安全なコードを書くことができます。



長所

• 多くのCoreDataレーキを隠し、レコードの初期化、保存、変更に必要なコードを大幅に削減します。 子コンテキストでの作業を簡素化します。
• 最初はデータを使用した非同期作業に焦点を当てていたため、UIがハングすることはありません。
• 低エントリーしきい値-このフレームワークを使用すると、データベースの長所を感じることができますが、地獄のすべての深さまでは通じません。

短所

• コードのすべての非同期部分と同様に、テストでカバーすることはかなり困難です。
• さらに、データベースを操作する他の方法と同様に、アーキテクチャレベルでデータベースの正確性を保証する必要があります-アプリケーションが同じ場所で一度に読み書きを試行しないようにします（いいえ、成功しますが、ここにあなたが本当に好きではない結果があります）
• 述語、クエリ、その他の記述を完全に軽減するわけではありません（このようなことを期待するのは奇妙だから、これが直接の欠陥だとは言えません）

PromiseKit

Promiseのような概念を使用するためのフレームワーク。 詳細については、 こちらをご覧ください 。

つまり、これはアクションのチェーンの形式で非同期コードを使用して作業を編成する方法です。 なぜこれが必要ですか？

1.非同期コードは、実行中のスレッドに関係なく、シンプルで線形になります。 彼の目の前で、彼の厳格な構造-何となぜ満たされます。 1つの画面で、次のロジックを配置できます。2つの構成ファイルをダウンロードします。 それらが来たら、妥当性をチェックしてください。 その後、ある種のアニメーションを開始し、結果を表示します。

2.非同期コードは、アトミックでカプセル化され、再利用可能になります。 非常に多くの場合、非同期操作のカプセル化を破壊する誘惑があります。たとえば、いくつかの一般的な変数を使用すると、非同期コードの変更が難しくなります。

3.実行チェーン全体のエラー処理の快適な機会があります。 非同期コードのチェーンを書いた人は誰でも、チェーンが長くなればなるほど、エラーを正しく処理することが難しくなり、コードが複雑で扱いにくくなるという事実に遭遇しました。



長所

• 非同期操作の実行のグラフの構築を大幅に簡素化します。 1つの操作を別の操作または他のいくつかの操作の直後に開始するのは簡単です
• チェーン実行のさまざまな段階で発生するエラーの処理を大幅に簡素化します（特に、すべての操作が完全に成功し、他のすべての操作で意味がない場合にのみアプリケーションのチェーンが意味をなす場合）
• 非同期操作を正しくカプセル化できるようにすることで、アプリケーションのさまざまな場所での複数の使用を大幅に促進します。

短所

• 約束を処理するときは、まだメモリに注意する必要があります
• 「コード」ではなく、「コードを呼び出すラッパー」での作業に慣れるには時間がかかります
• デバッグ中の不便。

第2章アーキテクチャフレームワークなど

PureMVC

詳細については、 こちらをご覧ください 。

おそらく、モバイルアプリケーションの開発中に対処しなければならなかった最初の主要なアーキテクチャフレームワークの1つです。

要するに、これは、MVCパターンをより小さなエンティティに正式に分解したものです。

1. VO（値オブジェクト）-CoreData Entityでよく知られています

2.プロキシ-奇妙な名前であるにもかかわらず、モデルのラッパーを表します-モデルの非自明なゲッター（アグリゲーター）もデータへのアクセスを担当します

3.メディエーター-MVCでコントローラーを検討するより一般的なものは、ビューの表示を制御し、そこからの信号を処理します。 ファサードを介して送信される通知をサブスクライブできます

4.表示-さて、表示は表示です。 情報の視覚的表示を担当するコード。

5.ファサード-アプリケーションの実行中に常に存在するシングルトンエンティティ。 Proxy、Mediator、およびCommandクラスのすべてのオブジェクトは、作成時に登録する必要があります

6.通知-ファサードを介して送信されるメッセージ。 購読しているすべてのメンバー、メディエーター（およびそれらのみ）を受け取ります。

7.コマンド-フローアプリケーションが記述するもの-コマンドパターンに従う-は、メモリに保持されることなく起動、実行、終了されます。これは、実行されたコードによる通知です。



長所

• アーキテクチャの安全性の素晴らしいマージン-私の例では、すべてが数年間コードに注ぎ込まれ、深いリファクタリングの可能性と適切な技術プロセスの出現を確認するために開発が起きずに生きました。
• ラピッドプロトタイピング-アーキテクチャはすでに十分に評価されています。 また、この構造を使用した経験がある場合は、非常に迅速に行うことができますが、同時にモジュール式の反復形式でアプリケーションの機能を向上させることができます。
• 非常に正式な構造（プロジェクトで使用し始めた場合）を無視するのはかなり困難です。これは、すべてのプロジェクト開発者が統一された方法でコードを記述するという事実につながります。

短所

• すべての重要なモジュールは実際にはシングルトーン（この場合、シングルトンファサードに登録されている）であるため、不正なコードを書く機会が非常に多くあります。これは、プロジェクトが暗黙的な依存関係を構築するあらゆる機会を非常に迅速に持つことを意味します
• デバガの地獄。 明示的なバインディングはほとんどありません。実行チェーンに沿って進むには、エンティティを象徴する線に沿って移動し、このエンティティが登録されている場所を見つけ、それに関連付けられたクラスを見つけて、そこに行く必要があります。 準備が整うまで繰り返します。 スタックのネストの深さは完全に宇宙の値に達します（私は自分の目で100を見ました）

灰のフレームワーク

詳細については、 こちらをご覧ください 。 ユースケースもそこにあります。

具体的には、このフレームワークはゲーム開発により適していますが、ある時点でアプリケーションがステートレスでなくなったと言える場合、少なくともこのことを理解することは有益です。

要するに、これはEntity-Component-Systemパターンを実装し、次のエンティティセットで動作するフレームワークです。



1.エンティティ-実際には、いくつかのエンティティ（説明を簡単にするために、このフレームワークにより適しているため、この場合はゲームテーマの例を使用します）。 たとえば、プレーヤー、敵、または障害物。 さらに、エンティティはそれほど明示的なアクター（アクションオブジェクト）にはできません。たとえば、Optionsポップアップ、lifeBar、またはたとえばレベル全体です。 特定のコンポーネントセットに関連付けられた最小限の情報で動作します。

2.コンポーネント-データを持つアトミックコンテナ。 たとえば、位置、速度、破壊可能性、...

3.フィルター-エンティティセット全体ではなく、それを通過するもののみを取得できるようにするためのフィルター。 コンポーネントキーのセットです。 したがって、フィルターにキー「位置」と「速度」が含まれている場合-移動しないエンティティ、またはゲーム以外のエンティティ-は通過しません。

4.システム-エンティティ変更の性質の説明。 フィルターされたエンティティのセットで動作し、何らかの形でそれを変換します。 たとえば、重力システム。 フィルターを通過するエンティティ（位置、速度、加速度、重力の影響を受けやすい）を取得し、重力の影響を考慮して加速度を再計算します。

またはMovementSystem-位置、速度、および加速度を持つすべてのエンティティを取得し、加速度の値によって速度を変更し、速度の値によって位置を変更します

5.ワールド-特定の順序ですべてのシステムの更新を要求するオブジェクト。



実際、このフレームワークは、従来のOOPのやや珍しい観点からオブジェクトの動作を提供します。オブジェクトは変化に反応するのではなく、システムを介して独立して反応および変更できるオブジェクトを見つけます。



長所

• ロジックを直交エンティティに分割し、互いに干渉しないモジュールの観点から考える
• 文字の変更のしやすさ（動作）、新しい文字の追加のしやすさ。
• ステートマシンは設計フレームワークに組み込まれています。 したがって、キャラクターとリアクションのセット全体を切り替えることができます。

短所

• これは特効薬ではありません。 ステートマシンはすぐに複雑になり、コードを制御できなくなります。 その中に何がどのくらいあるべきかを非常に明確に理解する必要があります。
• モジュールの直交性と完全なステートレスは、頭の中では非常に美しい概念ですが、実際には維持することは非常に困難です。 また、コンポーネントの外部にある共有データは、非常に迅速に、1つのスレッドではあるものの、競合状態タイプの多くの困難とバグの可能性につながります。

反応性ココア

おそらく、今日のiOS開発のための最も重要なサードパーティフレームワークの1つです。 これについて詳しくは、 こちらとハブで読むことができます -私はそれを行うことを強くお勧めします。 彼は、iOSのメインパターン（MVC）をアナログMVVMに置き換えることを提案し、その使用においてはリアクティブプログラミングに依存しています。

つまり、リアクティブプログラミングは、データストリームの操作に焦点を当てた開発パラダイムです。 通常の開発（必須）中に、「プログラムはAを実行し、次にBを実行し、次にCを実行する」というスタイルの開発者プログラムの場合。 A、B、およびCがさまざまなアプリケーションモジュールにある重要な論理操作である場合（そのようなブロックの数が増えると）、プログラムの接続性が高まり、その複雑さとサイズが増大します。

長時間の操作に対するさまざまなモジュールのこのバインディングの最も有名な例は委任パターンですが、すべての問題を解決するわけではありません。

• 一度に複数の他の人を開始するためにこの操作を完了する必要がある場合はどうなりますか？
• アプリケーションの異なる時間にこの操作を開始するためにさまざまなエンティティが必要な場合はどうなりますか？
• 1つの操作に関連付けられたコードは多数のモジュールに散在しており、その変更は困難です。
• アクションのチェーン（特にその中間）に新しい操作を追加するには、原則として、かなり大量のコードが必要です。

Reactive CocoaとMVVMが提供するもの：

• 操作はモジュールに結合され、そのインターフェイスでラッパーが実行可能コード、いわゆる信号とコマンドに対して作成されます。
• 従来のMVCとは異なり、信号ベースのアーキテクチャにより、中間層なしで関連エンティティを直接関連付けることができます。

私自身にとって、ReactiveCocoaはPromiseKitのアイデアの開発であり、それらをアプリケーションアーキテクチャのレベルまで拡大していると考えています。



ReactiveCocoaがPromiseKitの長所と短所を継承しているという事実に加えて、以下を追加したいと思います。

長所

• アプリケーションのアクションシーケンスは、より少ないコードを使用するため、一目で把握しやすくなります。つまり、アプリケーションの動作を理解しやすくなります。
• アクションのシーケンスによる操作の容易さ-中間ステップの追加、サイドステップの追加または削除は簡単です。

短所

• Reactive Cocoaを使用したコードデバッグは非常に困難です。
• シグナルの扱いやすさは、アプリケーションの接続性の制御不能な増加を引き起こし、チェーンが長くなり、互いに交差すると、その実行の制御を失うのは非常に簡単です
• この種の他の多くのフレームワークと同様に、アプリケーションの重要なセクションでそれを避ける方が良いです-それは非常に高速ではありません。

componentKit

Facebook開発チームからの最近のプレゼント。 こちらで詳しく読むことができます 。 あなたのことは知りませんが、インターフェースを解決する方法として、何度もHTMLとCSSを悲しげに見ました。 つまり、 宣言的UIと呼ばれるものについてです。

要するに-ウィキペディアによると、これは「作成方法」ではなく「作成されたときの姿」に焦点を当てたエンティティを記述する方法です。 ComponentKitは、iOS開発の外観がAutoLayoutで見られるアイデアの開発です。コンセプトは、1つのインターフェイス要素を変更することで、UIの残りの部分が正しく見えるように多くの操作を行う必要がありません。 古いUIKitで一部のUIViewのサイズを変更する場合-それに関連する他のすべてのUIViewの位置を再計算する必要があり、座標を操作するための非自明なコードにつながる場合がありますが、このビューはビューから20ピクセル、つまりより高く、 30-これは低い-サイズをどのように変更しても、この比率は変更されません。

ComponentKitは、この点でさらに前進しました-標準エンティティ向けのかなり多数のソリューションを提供します。

• CollectionView / TableViewを使用した便利な作業。これは、通常の配列の作業と同様に、固定のdataSourceを使用するのではなく、テーブルを埋める作業を必要としません。 （「そのようなインデックスパスではなく、そのようなセルがあります」-「そのようなセルをテーブルのそのような場所に置く」）。 異種データを含むテーブルを構築する必要がある場合（たとえば、不動産を賃貸するためのアプリケーションで住宅の説明ページを構築する-1つのページに、さまざまな動作を行う多数の異なるタイプのセルがある場合）
• 要素の状態は、複数の文字を一度に説明する機会を提供します。要素は、コンテキストに応じて、異なる.xib、異なるクラスなどに配布する必要なく、それを使用できます
• さまざまなデバイスの解像度と画面の向きに等しく適した要素のコレクションを宣言的に記述することができる便利な適応型レイアウト（これはすべてAutoLayoutで実行できますが、宣言はより柔軟です）

長所

• コード内のインターフェイスの説明。ただし、簡潔で適応可能な形式。
• 標準コンポーネントのスマートソリューション

短所

• コンポーネントの耐性-多くのアニメーションで変更可能なインターフェースを作成したい場合、これはあなたの選択ではありません。
• フレームワークの目新しさはもちろん相対的な欠陥ですが、その使用に関する問題が発生する可能性があります。

第3章テスト

テストについては、多くの異なると言います。 良い面と悪い面。 誰かがテストは銀の弾丸であると言います、誰か、それとは逆に時間がかかりますが、私の意見では-これはプログラマーの開発における重要な段階の1つであり、あなたがそれを判断する前に、これは絶対に必要です通過します。

また、この最近の記事を読むことをお勧めします-これは、iOS開発者が利用できるツールの表面的でありながら快適な概要を提供します。

真剣に言えば、TDDはおそらく開発者としての私にとって最も影響力のある概念です。 そして重要なことは、自動テストにより回帰を回避し、コードをより速く記述できるようにし、加えた変更について心配する必要がなくなることです。 自動テストの主な利点は、すべてのコードをテストできるわけではないことです。 テストのおかげで、 DRYやSOLIDなどの略語が意味をなします。

期待

リポジトリのページとその親リポジトリで詳細を読むことができます 。 十分な数の使用例があります-使用を開始するのに十分です。



コード内の場合：

1.多くの暗黙的な依存関係があります（たとえば、シングルトーンを使用して、または使用せずにプルします）。これらの依存関係をすべて満たす必要があるため、このコードのテストは非常に困難です。 また、アプリケーション開発の観点から、これらの同じ暗黙の依存関係のコードの変更は、コード内の未知の数の場所に未知の方法で影響を与えます。 間違いなく悪い。

2.コードに非ステートレスリンクがさらにある場合、状態の可能なすべての組み合わせでモジュールのバンドル全体をテストする必要があるため、このコードはテストが困難です（つまり、テストケースの数が指数関数的に増加します）。 また、アプリケーションの開発の観点からは、状態の各組み合わせに何らかの種類のバグが存在する可能性があり、接続されたモジュールが期待する状態にならないリスクが非常に高くなります。 また、コードに追加するものはすべて非常に高い価格です。

3.コードがDRYでない場合、繰り返されるコードのそれぞれに対してテストを作成する必要があり、作業量が増加します。 また、アプリケーション開発の観点から見ると、繰り返しコードの健全性を維持する複雑さは、繰り返し回数に比例します。



そして、はるかに。

したがって、テストコード自体がよりサポートされ、それ自体がよりシンプルで、変更が容易であることがわかります。 そして、一般的に、それはそれ自体でブレークスルーを保存します。

そして、あなたのコードをテストするための最良の方法-私たちはテストしています-テストでそれをカバーすることです。 私が時間をかけて正しく理解すれば、ほとんどのテストの必要性はなくなります。なぜなら、あなたはすでにテストコードを書く習慣がありますが、その時間に到達する必要があるからです。



そのため、Specta / Expectaバンドルは、 BDDのスタイルでテストを記述するためのフレームワークです。



長所

• BDDアプローチ自体は、テストコードとテストが対応する仕様の両方を1つのソースに持っているという点で優れています。 それに基づいて、ITスペシャリストだけでなく、QAスペシャリストとビジネス側の顧客の両方と議論できるドキュメントを生成することができます。
• フレームワークはシンプルでエレガントです。これにより、テストを読みやすくし、テストをサポートするリスクを減らすことができます（テストをテストする必要がなくなります）。

短所

• 実際、実際のアプリケーションをテストするときは、レーキにレーキがあります。このすべてのレーキを実行する必要があります。 非同期データベースのテスト、UIのテスト、および一般的に非同期のテストには、真剣な検討と熟考が必要です。
• 一時的な短所ですが、このツールのXcodeとの統合は最近不安定になっています

OCMock

詳細についてはこちらをご覧ください 。

残念ながら、テスト時に、コードを大幅に複雑化することなく、外部および暗黙的なモジュールの依存関係を完全に排除することは常に可能とは限りません。 そして、ここでOCMockが助けになります-外部オブジェクト（システムフレームワークを含む）の動作をエミュレートし、すべての外部の影響（ネットワーク接続速度、予期しないエラー）からモジュールを隔離し、保証されたクリーンなコンテキストで作業できます（サーバーはそれを返します、 , , , , NSUserDefaults , , , e）。



このツールは、「サンドボックス」の観点からすぐに考えることを学習し、SOLIDの原則をエンタープライズコーディングスタイルに完全に従うことはできません。これにより、「完全にクリーンなコード」と「単純なコード」のどちらを選択するかを選択できます。



長所

• 外部依存関係のあるモジュールをテストするプロセスを大幅に簡素化

血の魔法

habrazhitel- 1101_debianの 1つによって開発されたフレームワークについては、こちらをご覧ください。

おそらく、このフレームワークをテストのトピックの横に記載したいと思います。テストフレームをどのように記述するかという質問に答えるのに役立つからです。

この記事では、暗黙の依存関係などの恐ろしいことについて繰り返し書いてきました。そして、それらを取り除くための第二の方法（最初は奇妙なことに開発したモジュールの全てから削除することができ、依存関係のかを理解するためのコードで思慮深い外観です- 。効果的な方法をくそ）で依存性の注入の -つまり、すべての暗黙的な依存性を明示的にする必要があります。



要するに、暗黙的な依存関係を取り除くために、モジュールを完全に独立し、テスト可能にし、同様に重要なのは再利用可能にすることです。言い換えれば、.hファイルは、このモジュールが動作するために正確に使用するものを完全に理解するのに十分でなければなりません。まず、オブジェクトのテストを大幅に促進します（モジュールが機能するために必要なモジュールのリストを知っていることが保証されており、OCMockまたはその他のアクセス可能な方法を使用してそれらをすべて濡らすことができます）。第二に、これは私たちに質問について考えるもう一つの理由を与えます：「しかし、このクラスは実行されているコードについてあまりにも多く知っていますか？多分それをいくつかに分けますか？または、これらの依存関係を個別のモジュールに論理的にグループ化する方法がありますか？」



長所

• , -. , , 4-5 .
• - — , , .

4.

mogenerator

シンプルな、しかし日常の開発において非常に便利なツールで、抽象データベースモデルとコードでの表現との接続を容易にします。詳細については、こちらをご覧ください。要するに、モデルの更新がカスタムロジックに影響を与えないように、モデルの更新が最も簡単で簡単な方法でモデルを操作するためのコードを整理するのに役立ちます。

私にとってこのツールの基本的な利点は、それが私にとって最初のツールになったことです。これにより、ランタイム以外の膨大なコードの世界を簡単に発見できます。プログラマー：

タスクは、このためのツールを使用して解決する必要があります。すべてのObjective-Cタスクに最適な言語ではなく、すべてのタスクに最適な言語ではありません-ランタイムは適切なランタイムです。さらに、プロジェクト内で知識を単一のコピーで提示する必要があります（コード自体だけでなく、広義のDRY）。

モデルとその表現の対応を手作業で監視する必要があるのはなぜですか？

実行時にデータベースを埋める理由-展開前にデータベースを生成できる場合

分離ドキュメントのコピーが複数ある理由-コード内のコメントから生成できる場合

外部サービスと連携する統合テストの場合、スクリプトを使用してコンテキストを準備することが非常に可能です（テストユーザーを作成し、プロファイルを入力します...）。



そして、外部ツールによって解決される他の多くの多くのタスク（これらの1つについては、この記事の最後でもう少し詳しく説明します）。



私がmogeneratorが好きな2番目の側面は、生成されたコードと記述されたコードを一致させるためのエレガントなモデルを示したことです。そして最後に、モデルを操作するためのボイラーコードの量をわずかに減らしました。



長所

• .xcdatamodelモデルを変更する方がはるかに快適になります
• ツールは適切に構成可能であり、生成されたコード、プロジェクト内での配置に影響を与えることができます。同時に、使用を開始するには、最小限の設定が必要です

ファストレーン

こちらで詳細を読むことができます。

要するに、これはプロジェクトの可能な限り継続的な配信を促進するために設計されたツールのセットです。

次のことができます。

• アプリケーションを構築する
• ビルドのアプリケーション設定を変更する
• スクリーンショットを撮る
• テストを実行する
• に申請書を提出する
• これに関する便利な通知を送信する

などがはるかに



前のものは、外部ツールの世界に入るのに役立ちますようまた、このツールは、（AppleScriptを、バッシュ、PythonやRubyのスクリプト言語を使用することを検討してください ） プロジェクトのヘルプの仕事に。私にとって非常に長いプロセスだったので、そのすべてのステップは非常に有用で重要だと思います。さらに、このツールはDSLなどの興味深いトピックを提起します。このトピックは非常に複雑なので、独自のDSLを作成する前に（この記事の最後のセクションで簡単に説明します）、それらの意味を理解するために使用する成功例を見つけることを強くお勧めします。FastLaneは、DSLが非常に非常に健全である理由の最も顕著な例の1つです。



長所

• シンプルで便利で機能的。
• よく知られているContinous配信サーバー（たとえば、Jenkinsなど）と統合します
• アプリケーションをデプロイ、テスト、準備するかなり複雑なスクリプトを作成できます。そして、それについてあなたに書いてください（例えばSlackで）

短所

• 検出されません。本当に便利なツールキット

YACC / LEX

そして最後に、この素​​晴らしいカップル、DSLの世界での重火器、そして独自の言語を作成するための最も強力なツールの1つです。それについては多くの場所で読むことができますが、特に、ハブに関する記事がいくつかあります。

• http://habrahabr.ru/post/191252/
• http://habrahabr.ru/post/231731/

このツールは非常に複雑ですが、適用範囲が驚くほど広いため、それらに精通することをお勧めします。

• — , DSL -, JSON/XML/… .
• , , , ( - , -, - -.)
• DSL - ( ) . ( YACC/LEX — ObjC Swift Ruby ( DSL — , ))

一般に、これが適しているタスクの範囲は膨大です。



長所

• 言語のセマンティクスを記述するための非常に便利な形式。
• 非常に高いランタイム実行速度（C言語パーサーコードは言語表記から生成され、非常に簡潔なASTを生成します）
• 非常に広い範囲-それは望みです。この言語では、本格的なプログラミング言語の本格的なインタプリタを書くことができます

短所

• エントリーの非常に高いしきい値-何か重要なものを書くには、脳を激しく壊す必要があり、初めて長い時間がかかります。
• このことをランタイムで使用する場合、メモリ管理はすべての負担を負います。

結論の代わりに

もちろん、一方ではまだ非常に重要で便利なことはたくさんありますが、言及していない（または知りませんが、私に推薦してくれればとても感謝します）が、一方で、詳細に分析されていない、多種多様な（恐ろしい！）異種のマテリアル。しかし、これらのすべてのプロジェクトには素晴らしいドキュメントがあります。私はあなたの質問に喜んで答えます。あなたの意見の中にさらに詳細な説明が必要な場合は、これに関する私の経験を喜んで説明します。

この場所を読んでくれてありがとう。またね