Swiftのlazyってなに？lazyの使い方。リファクタリングした箇所の紹介
lazyってなに？
The Swift Programming Languageに以下のように説明されています。
A lazy stored property is a property whose initial value is not calculated until the first time it is used. You indicate a lazy stored property by writing the lazy modifier before its declaration.
翻訳すると
遅延格納プロパティは、初期値が最初に使用されるまで計算されないプロパティです。 lazy修飾子を書くことで、遅延格納プロパティとして指定できます
簡単にまとめると
- 遅延格納プロパティ
- 初めてアクセスされたときに計算され初期値が設定される
- インスタンスの初期化が完了するまでに値がわからない場合に便利
lazyを使うようにリファクタリングした箇所
lazyを使う前のコード
private var hogeView = UIView() override init(frame: CGRect) { super.init(frame: frame) prepareHogeView() } required init?(coder aDecoder: NSCoder) { super.init(coder: aDecoder) prepareHogeView() } private func prepareHogeView() { hogeViewの設定 }
lazyを使ってリファクタリングしたコード
private lazy var hogeView: UIView = self.prepareHogeView() // いらなくなった override init(frame: CGRect) { super.init(frame: frame) } // いらなくなった required init?(coder aDecoder: NSCoder) { super.init(coder: aDecoder) } private func prepareHogeView() -> UIView { return hogeViewの設定 }
他にも使うと便利な箇所が多いので使ってみてください。
この記事とかわかりやすかったです。
hajihaji-lemon.com
『自分のチームは生産性の低い』と思ったら絶対に見た方が良い動画
Product Manager Conference 2017に行き、学びが大変多く、自分の中で整理してから、このブログで紹介していこうと思います。
今いるメンバーで「大金星」を挙げるチームの法則のセッションで紹介していた動画が印象的だったので紹介します。
生産性の低いチームって？
プランナー vs エンジニア
プランナー : 「〇〇な機能を作ってほしいです」
エンジニア : 「フワッとしすぎ！工数もかかりすぎるので、無理です。」
極端な例ですが、自分が考える生産の低いチームのイメージです。
生産性の高いチームって？
Googleの労働改革プロジェクトであるプロジェクトアリストテレスで、生産性の高いチームに共通していることを調査しました。
生産性の高いチームに共通していることは、「心理的な安全性」らしいです。
心理的な安全性とは
- 自分を安心してさらけ出せる
- 「このメンバーなら何を言っても大丈夫だ」と感じ、思ったことを発言できる
- 本来の自分と異なる仕事用の人格を演じることなくリラックスしている
生産性の高さは、リーダーのマネジメント力やエンジニアの技術力によっても変わりますが、共通して重要なことは、心理的な安全性というのは、経験上納得です。
心理的な安全性を高めるためには、下記のフローが必要だと考えます。
ハイネケンの動画を見るとこのフローが必要な理由がわかるのでぜひ見てください。
① お互いを知る
② 思ったことを発言できる
動画の概要
真逆の価値観を持つが2人が出会う (バーで会ってお互いの意見を言い合ったら絶対に喧嘩すると思う)
↓
お互いを知る
↓
自分の考えに関するインタビュー動画が流れる
↓
？？？
チームで仕事をするときは、「お互いのことを知る」→ 「思ったことを発言する」のフローを意識しようと思いました。
swift4対応で個人的にこれだけ覚えておこうと思った8つのこと
本業のアプリのSwift4対応が終わりました。(他の人がやってくれました)
Swift4で変更でこれだけは、覚えておこうと思ったことを紹介します。
① 数値比較で型の厳しさがなくなった
- uIntとIntで比較できる
② Stringが強化された、StringをいじるときはSwift4だと良い感じにできる
- Stringでもmap, foreachが使えるようになった
- Stringの文字列をcountで取得できるようになった
- 文字列を複数行で定義できるようになった
③ Dictionaryが強化された、DictionaryをいじるときはSwift4だと良い感じにできる
- Dictionaryにmerge機能
- Dictionaryにdefault値
- DictionaryにmapValue
- Dictionaryをグループ化できる
- filterの挙動が変更
④ Codableが現れた
⑤ swap関数を使って配列を変更できる
⑥ [クラス & プロトコル]って書き方ができる
⑦ privateのスコープ概念が変更
⑧ @objectMembersってできたよ
StringやDictionaryは、詳しい仕様変更全部を覚えるんじゃなくて(自分の記憶力問題)、強化されたってことを覚えておこうと思います(使っているうちに覚えるはず)
詳しく見たい人は、コードベースで解説しているこの記事が良いと思います。
テスト駆動開発とiOS(Swift)のテスト(XCTest)を見やすくするためのTIPS
テスト駆動設計
テスト駆動設計って知っていますか？
テスト駆動設計を知らない人は、この本やスライドを見てください
t-wada.hatenablog.jp
テストって重要ですよね。
わかっているんです。重要なことは。
でも全然書いてないんです。
先日、テスト駆動開発の著者(t_wadaさん)の研修を受ける機会があり、演習でテスト駆動を体感しました。(初めてiOSでテストを書きました)
感想
- テストから実装をすると格段に綺麗なコードが書ける
- テストから書くと言語仕様の理解が深まる
- 仕様の分解が必要なので仕様の理解が深まる
- テストが成功すると気持ち良い！Green！快感！
- 他の人がテストだけ見れば仕様がわかるので良いかも(ちゃんとやれば)
最初はテスト駆動開発なんて「何を言っているんだ。現実的なやり方じゃない」って思っていましたが、会社の規模やフェーズ/バグの影響度によっては、「テスト駆動開発って良いかもな」に変わりました。
iOSの場合、すべてをテスト駆動開発でするのは難しいですが、「テスト駆動開発って良いかもな」って考えを持ち、テストへの意識が変わったのが個人的には良かったと思っています。
iOS(Swift)のテスト(XCTest)を見やすくするためのTIPS
テストを見ただけで仕様がわかったほうが良く、そのためのTIPSになります。
お題
- 2の倍数か判定する
- 5の倍数か判定する
- 7の倍数か判定する
どっちが見やすいですか？
| パターン① | パターン② |
|---|---|
 |
 |
僕はパターン②が圧倒的に見やすいと思います。
以下を意識
何をするテストか - 具体的なテスト - 具体的なテスト
パターン②の書き方
方法は、クラスで分ける。
とても簡単でした。(他の人に教えてもらいました)
import XCTest @testable import SampleTest class _2の倍数を比較するメソッド: XCTestCase { func test_isMultipleOf2メソッドに2を代入するとtrueが返ってくる() { } func test_isMultipleOf2メソッドに3を代入するとfalseが返ってくる() { } } class _5の倍数を比較するメソッド: XCTestCase { func test_isMultipleOf5メソッドに5を代入するとtrueが返ってくる() { } func test_isMultipleOf5メソッドに6を代入するとfalseが返ってくる() { } } class _7の倍数を比較するメソッド: XCTestCase { func test_isMultipleOf7メソッドに7を代入するとtrueが返ってくる() { } func test_isMultipleOf7メソッドに8を代入するとtrueが返ってくる() { } }
このTIPSを気に入ったら使って見てください。
iOSアプリが「IPv6 networkで通信できない」って言われてリジェクトされたときの対応方法
最近、以下のメッセージがきてAppleにリジェクトされました。
今までこの指摘なかったし、IPv6環境で通信できていない...(できると思っていたけど)
We discovered one or more bugs in your app when reviewed on iPhone and iPad running iOS 11.1 on Wi-Fi connected to an IPv6 network.
原文
Guideline 2.1 - Performance - App Completeness We discovered one or more bugs in your app when reviewed on iPhone and iPad running iOS 11.1 on Wi-Fi connected to an IPv6 network. Specifically, we received a network error. Please see attached screenshots for details. Next Steps To resolve this issue, please run your app on a device to identify any issues, then revise and resubmit your app for review. If we misunderstood the intended behavior of your app, please reply to this message in Resolution Center to provide information on how these features were intended to work. For new apps, uninstall all previous versions of your app from a device, then install and follow the steps to reproduce the issue. For updates, install the new version as an update to the previous version, then follow the steps to reproduce the issue. Resources For information about testing your app and preparing it for review, please see Technical Note TN2431: App Testing Guide. For a networking overview, please review About Networking. For a more specific overview of App Review's IPv6 requirements, please review the IPv6 and App Review discussion on the Apple Developer Forum.
対応方法を調べてみると、IPv4でしか使えないAPI、IPv4 を前提とした変数/構造体を使っている場合にアプリの動作が止まったりするそうです。
対応がめんどくさそうだ...
とりあえず、IPv6環境で使えるのか試してみることに。
IPv6環境でiOSアプリの動作を確認する方法は、こちらを参考にしてください。
問題なく動く！！！
Appleに「IPv6環境でテストしたよ」ってことを証明するスクショを添付して「問題なく動きます」的なメッセージをしました。
何事もなかったように申請が通りました！^^
