375
316

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

More than 5 years have passed since last update.

優れた開発者の習慣:Apple系ソフト開発者以外にもオススメのWWDC2019で発表されたセッション和訳

Last updated at Posted at 2019-06-12

初投稿です。
先日、WWDC2019に行ってきたのですが、そこである素晴らしいセッションに出会いました。

"Great Developer Habits" (優れた開発者の習慣)
by Josh Tidsbury

SwiftUIでもなければ、iOS13の新機能でもない。
一見するとあまり花のないセッションタイトルでしたが、内容はとても素晴らしいものでした。
忘れ去られるにはもったいないセッションでしたので、トピックを要約・和訳させていただきました。

Apple系の開発者に依存しない内容がほとんどです。
ぜひ、自分の開発体制を見直したりする一助としていただければと思います。

この記事の元セッション

セッションのビデオ(約35分)

導入

私たちのチーム(Technology Evangelism)は真に素晴らしいアプリをデベロッパーの人たちに作ってもらうために存在している。
今日紹介するTipsを用いて、アプリの実装に気をかけてほしい(craft in care)

デベロッパーが真に気をかけていることは、アプリのカスタマーからは直接目に見えるものではない。ただそれらのことは、パフォーマンスや信頼性に大きく影響する。
今日はその中でも以下の8つに焦点を絞って紹介する。

Organize(整理する)

雑然と物が散らかる作業場では、道具を探すのに時間がかかってしまうし、アクシデントも起こりやすい。
ソースコードのファイルや、ストーリーボードは種類ごとにまとめることで、シンプルになり、関係性がわかりやすくなり、不具合の修正にかける時間が減る

  • グループを用いて、機能ごとにソースコードファイルをまとめよう
  • プロジェクト構成とファイル構成を一致させよう
  • 巨大なStoryboardsを分割しよう
  • プロジェクトファイルやビルドシステムを最新のものにしよう
  • いつか使うかもしれないと消さずにコメントアウトしたcode scraps(ゴミコード)は、すぐに消そう。(それらは決して使われることはないし、たとえ必要になったとしてもログから遡ることができる)
  • Warningはワークアラウンドではなく、根本原因から直そう

Track(追跡する)

  • Gitなどの履歴管理システムを使おう
  • 一つ一つのコミットは小さく・独立した内容にしよう
  • 有用なコミットメッセージを未来の自分のために書こう
  • バグ修正や機能追加のためにブランチを活用しよう

Document(文書化する)

たまに、”I don’t need comments, my code is self-documenting”(私にはコメントなんて必要ない、コード自身がドキュメントだからね)とかいう人がいますが、私は賛同しかねます。

このような意味のないコメントと、何を指しているのかわかりにくい変数名の代わりに

// A constant string id value
let id = xxxxx-xxxxx-xxxxx

以下のように、その変数がここで定義されている背景や、なんのために使うのかという理由を書くようにしましょう。

// The permanent identifier for this application when interacting
// with the CMS, provided by the vendor of the CMS.
let cmsApplicationIdentifier = xxxxx-xxxxx-xxxxx

Xcodeを使っていれば、option + command + /(スラッシュ)で、自動的にドキュメントの下書きを生成してくれます。
あとは空欄を埋めるだけで完成です。

  • コメントは将来の理解のために重要である
  • 良いコメントは、背景や理由を含んでいる
  • 叙述的な変数名や一意な名前を付けよう
  • ドキュメントをソースコードに含めよう

Test(テストする)

  • 後悔しないために、ユニットテストを書こう
  • コードをコミットする前に、ユニットテストを走らせよう
  • CI(継続的インテグレーション)環境を構築しよう

Analyze(分析する)

  • Network Link Conditionerを使って、貧弱なネットワーク環境をシミュレートしよう
  • SanitizersとCheckersを使おう(メモリ衝突やバッファオーバーフロー、データリソース、0除算、理由もなく毎回結果が変わるバグなどを検知する助けとなるツール)
  • パフォーマンスと効率をDebug Gaugesを使って計測しよう
  • Instrumentsを用いて問題を精査しよう

こうした細かな積み重ねが将来的なパフォーマンスと信頼性につながります

Evaluate(評価する)

  • コードレビューを開発の一環に含めよう
  • エンバグする可能性を削減できる他にも、互いの知識を共有することで経験値を積むことができる
  • 全ての変更行を理解しよう
  • ビルドしよう
  • テストを走らせよう
  • 書式やスペル、構文の校正をしよう

Decouple(切り離す)

  • 機能的な区切れ目を特定し、切り離そう
  • 成果を他のアプリでも使い回そう
  • Extensionsを用いて、効率を上げよう
  • 努力の成果をより広いコミュニティにシェアしよう
  • ドキュメントは重要
  • バイナリサイズの削減にも繋がる

Manage(管理する)

  • コミュニティやオープンソースプロジェクトは責任持って利用しよう
  • 徹底的に依存性を理解しよう
  • プライバシーの尊重を確保しよう
  • 依存性がなくなったりメンテナンスされなくなったりした時のために、対策を練っておこう

The Last 10%

  • これらの1つ1つの作業には少しの時間が費やされるが、その一方で大きな時間の削減につながる
  • これらのことを癖にして自動的にできる様になろう
  • そして、もっと大切なことに頭を使おう
375
316
4

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
375
316

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?