優れたデベロッパの習慣

(音楽)

(拍手) おはようございます (拍手) Technology Evangelismチームの ジョシュです 世界中のデベロッパの皆さんと 一緒に仕事ができて光栄です 優れたアプリケーション開発の 手助けが我々のゴールです 皆さんとの会話から多くを学びます 皆さんが踏むプロセス そして 挑戦 目標 願望です 役立つツールやこつ 妨げとなるものも学びます 私たちが聞く話は少しずつ異なりますが 世界の地域を問わず 驚くほど多くの共通点があります クラフトといえば まずはデザインを考えるでしょう デベロッパやエンジニアも クラフトを行います クラフトの定義は 計画 作成 実行のスキルです スキル 気遣い 工夫を持って 何かを作ることです

手書きのコードには 見事なスキルが伴います ビルド時のテクニックや 選択には工夫が必要です 今日はそのクラフトと気遣いの話です コード Storyboard プロダクトに 気遣いを加えます 簡単なようですが デベロッパへの要望を考えると 難しい時があります

スキルの向上には時間を要します 献身 忍耐 集中が必要です 目的地への到達と同様に その過程を― 楽しむことが大切です

最初は意識的に集中して行うことを その過程で習慣に変えます

車の運転は経験と実践により 意識を集中して行う操作が 徐々に減少します 無意識の習慣になるからです アプリケーションの開発も同じです 悪い習慣ではなく 良い習慣を身につけることです

アプリケーションのビルドには 注意点が多くあります デベロッパとして気遣うべき 細かな点の多くは ユーザが見て 気付くことではありません しかし こういった点は感覚的に― パフォーマンス 信頼性 安定性に影響します 細かい点が多すぎて すべてに焦点を当てる暇はありません そこで 日常のプラクティスを見直し デベロッパとしての 作業の充実を図ります 日常のワークフローに 組み込むべきものを 自然に行う習慣にします それが のちに問題点や 無駄な時間を減らします 実践していることも 多いとは思いますが まだ習慣ではないかもしれません 実践意欲が湧くと思います まずは整理です 私はデベロッパですが 木工でもあります 私にとっては 現代社会からの逃避です

１つ確かなのは きれいな工房の方が 精巧な家具を作りやすいことです 雑然と散らかった作業台では 必要な道具や材料を 探すのが大変です 作業スペースの確保に 物を移動し続けます つまり 必要以上に時間がかかります アクシデントや間違いも増えます 多くのXcodeプロジェクトを見ますが ワークスペースの整理に 役立つプラクティスがあります 最良の配置が 最高の仕事を可能にします

Xcodeプロジェクトはグループによる 組織構造が便利です アプリケーションの各セクションの ファイルが一目瞭然となり バグの修正も迅速に行えます グループは 機能的な整理に最適で アプリケーション操作の 論理的な流れで整理します ファルタイプでの整理や グループを使わない場合 ソースファイルの関連性を 簡単に理解できなくなります

Xcodeプロジェクトと ファイルシステムの構造が 相互に一致するのも利点です Xcode 9以降 プロジェクト内に 新たなグループを作ると グループ内のファイルフォルダーも 作られます ソースコントロール内の プロジェクトや ファイルシステムが整理されます 構造がミラーリングされ 混乱と失敗が減ります

Storyboardは ユーザインターフェイスを 視覚的に構築する パワフルなツールです UI全体を単一のStoryboardに 構築するケースが見られますが Storyboard Referenceがあれば その必要はありません 主要セクションに 異なるStoryboardファイルを使い Referenceで連結します 個々の変更を特定しやすくなり 大きなチームでの作業も簡単です マージ時の コンフリクトのリスクを回避し 発生時も解決が楽になります 全ソースコードを 単一ファイルに入れないように 全UIも単一のStoryboardには 入れません

Xcodeのプロジェクトファイルを 最新の状態にすること 問題の蓄積の回避には必須です 定期的に行えば 取るに足らないタスクの１つです 最新でない場合 やがて問題が発生します Xcodeをアップデートする際 プロジェクトの設定やファイルを 最新フォーマットに アップデートできます 特別な理由がない限り 通知が出たらアップデートします Issue Navigatorの警告時も同様です 次に New Build Systemか確認します 初回リリースは2017年です 依存性管理と パフォーマンスが大幅に改善します Swiftパッケージの導入には 不可欠です

Xcode 10からデフォルトとなった ビルドシステムは Fileメニューの Project Settingsで確認可能です

木工は木片を保管しがちです いつか使う時のためです 箱が木片であふれ 収拾がつかなくなると ある事実を受け入れます この木片が使われることは 決してないという事実です デベロッパも同じ傾向がありますが 決断はより簡単です

プロジェクトは ソースコントロール下でしたね 不要なコードは取り除きます もしもに備えた コメントアウトではダメです 必要になることがあっても 履歴から取り戻せます 不要なものは手放します

もう１つ増やしたくないものが 警告です 自身およびチームのために 警告ゼロの慣行を確立します 警告がある場合コードは追加せず 記述中の警告は エラーとして都度 修正します 多数の警告を含む プロジェクトを見ますが 大半は蓄積されたものです 修正の時間がなく諦めたのでしょう こうしたプロジェクトでは 新しい警告が目に入りません

まとめます ワークスペースと プロジェクトの整理は アプリケーションの 長期的な発展に必要です グループでプロジェクトを整理 ファイルシステム構造にミラーリング 大きなStoryboardは Referenceで分割 プロジェクトファイルが最新か確認 古く不要なコードは削除

警告の都度 原因を突き止め修正 実践すれば プロジェクトが機敏になり 開発のワークフローの改善が 常に図れます

ソースコントロールで 大事なことの１つは プロジェクト設定時に 有効にすることです

ソースコントロールを 使わないのは 特に個人デベロッパのチームです 新たなXcodeプロジェクトの設定時に チェックマークを入れるだけです Gitを利用し ソースコントロール下に入ります 確認できるのは過去の変更履歴や コミットにより変更されることです エラーの発見にも役立ちます

Gitの有効時は 次の点に留意すると より便利で効果的になります

まず コミットは常に小さく 少しずつ定期的に 作業ブランチに追加します 変更はローカライズし 自己完結型で保ちます リグレッションの解決や ヒントが必要な時に振り返るためです また リグレッションの確率も 減少します 変更が小さいからです

次に 有用なコミットメッセージを書く こんな質問を 自分にする日が来ます “一体 何を考えていた？” コミットメッセージは 未来へのメモです コード変更時の状況や理由を 思い出させてくれます

個人デベロッパの方も 大きなチームのつもりで使い バグや新機能をブランチにします それらをまとめスカッシュしたら メインバッチ等に戻り 有用なコミットメッセージを使用 複数の選択肢とパターンがあるので うまく機能するものを 見つけてください そしてワークフローに統合します

これがトラッキングです 成功するアプリケーション開発に ソースコントロールは不可欠です プロジェクトの一環とし 通常のプラクティスにします コミットは小さく 有用なコミットメッセージを書く ブランチでバグの修正や 機能の働きの変更を 分岐して管理する

明確さと保守性に 大きく貢献するのが コードのコメントと ドキュメンテーションです チームメイトや自身の 道しるべのパンくずです 誰かが言います “コメントは不要 自己文書化コードだ” 賛成しません よく出来たコードは アルゴリズムが明確です その点では自己文書化ですが 最初にコードを記述した理由が 示されていません 大きなコンテクストにどう合うのか？

記述時のアプローチの 論理的根拠も不明です

優秀な同僚のデベロッパは 明確なコードの記述だけでは 終わりません 有用なレビューコメントを点在させ 将来の読み手を 作者の思考へと導きます 若手のデベロッパには より有益です プロジェクト開始時と終了時では 知識が大きく変化し 開始時と終了時の決断が 異なる可能性があります 良いコメントとは？ 読み手が使われた言語を 理解している前提で コードのステップなどを 説明するものです

加えて 各コードを記述した理由にも 焦点を置くべきです

これはよく見かける 価値の低いコメントの例です Swiftでコードを書く方なら 値を持つString型の定数と 分かるでしょう でも idとは何か 目的やハードコードされた理由も 不明です

少しのコメントで 値がある理由が分かりますが もう１歩先に進めます 定数と変数の名前で 明確さが増します mやiのように１文字や idやidxのようなものではなく より分かりやすい変数名にしましょう Xcodeのオートコンプリートなら 入力がほぼ不要 常にコードベースを通じて どんな識別子が 使われているか分かります

ドキュメンテーションも 利点は似ていますが 範囲はアプリケーションの枠を越えます

Appの記述は抽象化とアルゴリズムの レイヤの上にレイヤを作ります 大きく複雑になりそうなコードを 整え テストと再利用が可能な関数に 分類します ドキュメント化しなくても 頭の中でリライトします その関数を使うたびに そうせざるを得ません 通常 関数の実装の再考が必要な時 各パラメータの状況を見て どう変え結果を出すか理解します

ちなみにDocスタブの生成は とても簡単です 関数シグネチャの１行目に カーソルを置き optionとcommandとスラッシュです プレースホルダテキストが 自動生成され 空白を埋めて完了です

optionと該当の関数のクリックで Quick Helpポップアップに ドキュメンテーションが提示されます ネイティブSDKとSwiftの 標準ライブラリでおなじみでしょう

コメントとドキュメンテーション 少ない努力で大きな利益を生む 時間の投資の１つです プロジェクトを通して役立ちます 点在する有用なコメントが 理解を助けます 読み手を コメントの作者の思考に導きます 変数名は記述的に 関数 プロパティ 構造体 列挙型を ドキュメント化します

次にテストについてです 特にユニットテストです そこで マーシャルを紹介します Swiftとデベロッパツールの エバンジェリストで とても優秀な同僚です 歩くSwiftリンターでもあります

コードレビューを頼むと 洞察力のある 大量のコメントが返ってきます おかげでフォームと関数が 改善できます ある日 マーシャルは あることを勧めました ユニットテストです 正直 ユニットテストの記述の 十分な履歴はありません 利用経験もあり 潜在的価値も理解していますが つい最後に残してしまいます 実コードの実装を終える頃には テストをする気になりません ところが 先日のことです DubDub AppにLab Queuing機能の データモデルを実装する時でした マーシャルの声です

同時にユニットテストを追加し 構造体とDictionary型の ラウンドトリップを確認した方がいい 今後これが悪影響を 及ぼすのか不明でしたが 簡単なユニットテストを追加しました 実行し かなりの満足感を得ました 合格マークが出たからです 変更点を提出後 テストを再考したのは 数週間後 構造体に 追加データを組み込もうとした時です 構造体に変更を加え 実行時の問題はなし これで完了？ 変更の提出時 ユニットテストを思い出しました テストが捉えたのは Dictionaryデシリアライゼーションの 動作方法の変更漏れです きっとUI実装時にバグが発生し 原因解明に 手間取ることになったでしょう マーシャルの助言のおかげで ユニットテストが役立っています どういたしまして (笑い声) (拍手) 一見シンプルなコードのセクションでも 先ほどのとおり ユニットテストの記述は重要です コードの変形性が リグレッションの確率を上げます すべてのテストを行う時間がない場合 Xcodeが もう１つの目となります 通常の開発プラクティスに ユニットテストを実装し コミットの前に実行します 継続的インテグレーションの 要としても設定してください テストはユーザには分からない 細部の１つですが アプリケーションの使用体験に 大きな差が出ます データ破損があると 良い体験にはなりません

通常のワークフローに適した 分析形態があります いくつかは少し時間が必要ですが 他は手間なく バックグラウンドで作動します

便利なツールの１つが Network Link Conditionerです 開発はネットワーク性能の 高い場所で行われますが アプリケーションを使う 典型的な環境とは異なります そこで Network Link Conditionerです 有効時はネットワーク性能を 携帯電話と同等か それ以下に抑えます ローディングとレースコンディションの 問題の多さに驚くはずです

Scheme設定内の SanitizerとCheckerは 開発サイクルの 様々な問題を発見します Address Sanitizerは メモリの破損と バッファオーバーフローを監視 セキュリティのぜい弱性につながるため メモリの問題は最初から Address Sanitizerで除去します

Thread Sanitizerはシミュレータ内で アプリケーションのデバッグ時に使うと データ競合が発見できます 同期されていない ２つのスレッドがある時 いずれかが同じデータ上へ 書き込もうとするデータ競合

厄介なバグになることが多く プログラムが予想外の動きをします メモリの破損にもつながります

Undefined Behavior Sanitizerは 次のようなバグを見つけます ゼロ除算 オーバーフロー ミスアラインドポインタなどです 未定義の動作は クラッシュの原因です 予測不能な動作や 問題ない動作に見える場合もあり その時々で異なる結果を伴います とても厄介なバグです Sanitizerがバグの除去を助け 大惨事を防ぎます 最後はMain Thread Checkerです バックグラウンドスレッドの AppKit UIKit 他のAPIの 無効な利用を確認します メインスレッド以外で UIを更新すると 更新の失敗や不具合 データ破損などの原因になります 断続的に現れるこうしたバグは 発見が困難です パフォーマンスへの影響を抑えるため できる限り有効にしておきます

デバッグ中はパフォーマンスと リソースの利用に留意し システムリソースを 効率的に使用します まず デバッグゲージを利用 ビルドと実行の際は Debug Navigatorに表示されます CPU メモリ ディスク ネットワークの状況は ライフサイクル中 確認可能 すぐに分かるのは 予想外のServerへの接続や エンドポイントに起因する 帯域幅とバッテリーの消費です

最後にProfileとInstrumentsボタンを クリックすると より詳細な分析が実行できます 私がよく使うInstrumentは Time Profilerです 多くのサイクルを消費する コードが分かります 非同期が必要かもしれない処理は 制限するか スケーラブルでない形で実装できます

分析は幅広い課題ですが これらのツールは 有効にするだけです Network Link Conditionerで 典型的なネットワークを試す SanitizerとCheckerを できる限り有効にする デバッグのゲージの参照と アプリケーションのパフォーマンス フットプリントに留意 問題を深く掘り下げ 正確に対処するには Instrumentsで アプリケーションを分析 小さな努力を習慣にすれば アプリケーションのパフォーマンスと 信頼性が高まります

トロントにいた頃 車のガレージを 木工の工房に改造しました 居心地が良い 自分専用の空間でした ベイエリアに引っ越して以来 専用の空間はなく 地域共有の工房などを 利用しています 時々ストレスに感じるのが 設備や道具を シェアする必要があることです しかし 気付かなかった利点は 他の人とアイデアを交換できることです 手法に関する意見も得られます アプリケーション開発でいうと コードレビューです 単独でアプリケーションを 開発していた頃は 専用の工房と似て スピード感がありました

意見が１つだからです 欠点は同僚から学べないこと 言語 フレームワーク SDKのより良い手法が得られません 問題へのアプローチはいくつあっても もっと良い方法があります 簡潔さが際立つ方法や パフォーマンスや保守性に 優れた方法もあります 機能するからといって 正しいとは限りません 大幅に改善する可能性があります Appleではプロジェクトの コードレビューが必須です このプロセスを通じ多くを学びます コードのスタイルの一貫性が増し 必然的に信頼性も向上します チーム全体が 幅広いコードベースに精通でき 各自が対応できる バグや機能の範囲が広がります 経験豊かなデベロッパチームの 一員であることから その点は有利です しかし 個人経営者や 単独のプロジェクトの場合は？ 世界や地域のデベロッパ仲間と つながる方法を見つけ コードレビューを交換してみましょう

ミートアップや カンファレンスも使えます 開発プラクティスの一環とする― 優れたコードレビューとは？ まず 変更されたコードの各行を 時間をかけ理解します 目を通すだけでは無意味です

次に プロジェクトをビルドし 実行します 作者が実行したと考えないこと 最後のコミットがマージなら なおさらです

動作を確認 まず これにより テストでの確認を思い出し ユニットテストも合格 ビルドしても 壊れていないとは言えません

コメントと ドキュメンテーションを読む 両方ともありますよね？ スペリングや文法のミスを確認

変数名の スペリングも調べます 私はカナダ人なので Colourにuを入れるんです Colorを探す同僚はイライラします

一貫性のあるコードベースが のちの関数や変数の利用に役立ち 時間の節約となります

このプロセスで 一時的にスピードが落ちても 将来的にはユーザも守ります 潜在的な問題が減少するからです 更にデベロッパとしてのスキルが 類似する難題への対処に役立ちます

デベロッパが作成に努めるのは 小さく 洗練され 再利用やテストの可能なコードです 何度も同じコードを 作り直したくありません

パッケージとフレームワークは コードを一元的に保ち 移植可能な形で機能を提供します 他のアプリケーションからの 提供もあります AppにExtensionを組み込めば 共有コードのパッケージ化で バイナリサイズが縮小 メインAppとExtensionが フレームワークを共有するからです

パッケージの作成で コミュニティと成果の共有もできます Xcode 11では 密接に統合されています

アプリケーションは コードだけではありません フレームワーク パッケージ ライブラリにも 他の人に有用な ドキュメンテーションが必要です

パッケージとフレームワークで コードベースを分離し 複数のアプリケーションに 作業を広げることが可能 フレームワークで バイナリサイズを縮小

コミュニティとの成果の共有には 優れたドキュメンテーションが必須

最後に伝えたいのが 依存性です つまり 取り入れる際の 利点とリスクの理解です

Swiftパッケージ フレームワーク ライブラリの利点は多いですが

パッケージを使う前に 中身を知ることが重要です 潜在的に何が一緒に付いてくるか

依存性がどうデータに影響するのか コンテンツの責任者はあなたです ユーザデータの扱いも同様です フレームワークの 不要なデバイス情報の収集や 外部への送信がないことを 確認します

与えている依存性が 何に依存しているかも調査します 依存関係のある依存性を含むことは チェーン全体の成功に アプリケーションを委ねることです

他にも起こり得ること フレームワークが壊れたら？ メンテナンス不能になったら？ 消えてしまったら？

プロジェクトに 新たな依存性を導入するたび 各状況への対応策を持つことが重要です それがアプリケーションの未来を 左右します

未修正バグを解決できるか？ メンテナンスは自社対応？ 今後その依存性を 交換する必要があるか？ そのタスクに必要な作業は？

Swiftパッケージなどの 外部依存関係で効率が増し 既存ツールの再作成を回避できます

しかし 利用は慎重に 必要な動作だけに限定し ユーザのプライバシーを 必ず尊重してください

対策を確立しておくこと 破損や消失時の対応策です 新しい依存性を追加するたび これらの確認を習慣とすれば その利点を長期的かつ 最大限に活用できます

アプリケーション開発プロジェクトの 最後の10％というのは 最初の90％と同程度に長く感じます これらのプラクティスや原則を 習慣とすることで その感覚が薄れます

ワークスペースの整理で 効率的な作業が可能となり 実コードに集中できます

ソースコントロールで コードベースを追跡でき リグレッションの確率も減少 潜在的なバグの調査も促進します 役立つコメントと ドキュメンテーションの作成で コード見直し時の 認識の手間が減ります クラス 構造体 関数の利用時にも有用です ユニットテストでリグレッションの 原因となるエンコードを確認 SanitizerとCheckerは 継続的なコード分析を提供 手間なく バックグラウンドで実行されます ゲージとInstrumentは システムリソースの効率的な利用― パフォーマンスと問題点の 正確な追跡を可能にします コードレビューは スタイルや関数の評価だけでなく デベロッパのスキル向上への 大きな学びの機会です チームやコミュニティと共有します プロジェクトをパッケージと フレームワークに分割すると 複数のプロジェクトの作業と 共有ができます バイナリサイズにも有利です Swiftパッケージなどの 外部依存関係の利用は 効率アップと 既存の関数の再利用に役立ちます しかし 利用は慎重に ユーザデータの取り扱いを理解し 消失時の対策を講じます これらのプラクティスを習慣にするには 各フェーズで少し時間を取られます しかし 長期的には時間短縮となり アプリケーションが長持ちします 本日お話ししたアイデアや提案から デベロッパとしての発展を 考えてみてください 仕事の品質と持続性を向上できる プラクティス 意識的に努力し 無意識な習慣化 これで最も重要なことに 集中できます アプリケーションのユーザは 理由は明確に示せなくても あなたの愛情と気遣いを感じます すると 自分の作品に誇りが持てます ありがとうございました (拍手)