LoginSignup
46
35

More than 5 years have passed since last update.

iOSアプリ開発チームビルディングのTODOリスト

Last updated at Posted at 2018-05-12

はじめに

私ごとですが、現在、iOSアプリ開発チームの立ち上げを行なっております。
その中で、実施したこと、実施予定のこと、をまとめてみました。

「こんなこともやっといた方が良いよ!」というアドバイスをコメントいただけると大変助かります。:pray:

<ご注意>

  • 執筆時点の開発環境はXcode9.3 + Swift4.1です。
  • 本稿の内容は私個人の見解であり、所属企業における立場、戦略、意見を代表するものではありません。

学習

Swiftの基礎

入門として、以下のような事項を学習しました。

  • 変数と定数
  • Optional
  • 制御構文
  • 関数とクロージャ
  • クラス
  • Protocol
  • Extension
  • エラー処理

Xcode と iOS Framework

  • iOSシミュレーターの使い方
  • View周りの基本
  • アラートダイアログとアクションシート
  • 画面遷移
  • Auto Layout
  • URLRequestによるWeb API連携
  • UserDefaultsへの保存と読み出し
  • Core Dataによるデータ永続化

ライブラリの評価

HTTPクライアント

  • 標準のURLRequestと、Alamofireと、APIKitを評価しました。
  • 最小限の手間でコードが簡潔になることから、ライブラリを使うこととしました。
  • AlamofireとAPIKitでは、それぞれ一長一短あるかと思いますが、機能の豊富さとアップデート頻度が決め手となってAlamofireを選択しました。

ローカルデータベース

  • 標準のCore Dataと、Realm Swiftを評価しました。
  • Realm Swiftは、学習コストが低いこと、コードが簡潔に書けること、アップデート頻度が決め手となって採用を決めました。

ユニットテストの利用方針

  • ロジック部分は標準のXCTestを使い、UI周りはテスト仕様書を書いて実動作で確認することにしました。
  • XCUITestは、テストコードの保守が大変そう(負債になりそう)な感じなので採用を見送ろうと思っています。実際どうなんでしょう…:rolling_eyes:

Storyboardの利用方針

  • 最近は『1Storyboard-1ViewControllerが良いよ』というWeb記事を良く目にしますので、それを原則にしました。

(参考リンク)
StoryboardのBestPracticeについて考える(1) 〜Storyboardの分割〜

コーディング規約

  • Swiftの静的解析ツールSwiftLintを導入することにしました。
    • 設定ファイル(.swiftlint.yml)は、ほぼデフォルト設定ですが、1行の文字数を制限する「line_length」は無効化しました。Xcodeが自動生成するコードもエラーになってしまい、煩わしいため…
  • XCTestのテストメソッドに関しては、『ソースコメントに「テスト条件」「期待結果」を記載すること』と規約として定めました。
    • その他の規約を文書化するのは、書くのも読むのもメンテするのも大変なのでやめました。(多分Swiftのバージョンアップに追従できない…)

ローカライズ方針

  • 原則として、利用場面(画面ごとなど)によって言語リソーステーブルを分けることとしました。
  • そうしないと、Localizable.stringsが肥大化して分かりにくくなりますし、キー名の命名規約等を決めなければならなくなりますので…

(参考リンク)
iOSアプリの国際化対応の勘所とTips集(Swift版) - 文脈によって言語リソーステーブルを分割する

バージョン管理

  • 全社的にGitHub Enterpriseを利用していますので、それに乗っかります。
  • 小規模チームですし、GitHub Flowをベースに、簡素なブランチモデルで運用しようと思っています。
  • .gitignoreの定義については、GitHubのサンプルが公開されているので、ほぼそのまま採用しました。

これから実施したいこと

  • MBaaSの調査
    • どのサービスを使うのかは案件次第になりそうなのでちょっと後ろ倒しになっておりますが、必須ですよね。
  • Continuous Integration(CI)環境構築
  • コードレビュー観点の整理
    • 漫然と実施しても時間を浪費するだけなので、整理してガイドを作りたいと考えています。
    • しかし、コードレビューを実施する目的(検出したい課題は何か)まで立ち戻って考えると、結構難しいですね…
  • 実機テスト
    • 全機種/OSへの対応

その他は案件の特性によって、立ち上がり時期に調査する感じですかね…
何かアドバイスがありましたらコメントをいただけますよう、重ねてお願いします!:bow:

46
35
0

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
46
35