Diverse developer blog

株式会社Diverse(ダイバース) 開発者ブログです。

Matching Dev Meetup #4 でコーディング以外のエンジニアリングについてお話しました

どうもこんにちは、暑くて食欲が減退しているのに体重は落ちない @imaizume です。

暑さのせいでついつい進むビールが原因ですね(笑)

 

さて先月17日に、株式会社イグニスさんにて "Matching Dev Meetup #4" が開催されました。

matching-dev-group.connpass.com

Matching Dev Meetupは、マッチングサービスを運営する企業が主催する開発者向けの勉強会です。

過去の回でも弊社の社員が発表をしています。

diverse-tech.hateblo.jp

note.mu

 

4回目となる今回のテーマはズバリ「エンジニアリング全般」。

私は10分LTにて、入社時から2年半程携わっているPoiboyでのプロジェクトマネジメントにまつわるお話をさせていただきました。

speakerdeck.com

 

内容は、Poiboyで実際に取り組んできた新旧のプロジェクトマネジメント手法を比較しつつ「エンジニアリングとは何か」を改めて考えるといったものになっています。

この話をしたのは、普段Poiboyで仕事をする中で「そもそもエンジニアリングとは何だったっけ??」という疑問を抱いていたことがきっかけでした。

プログラミングを仕事にしていると、普段「エンジニアリング=プログラミング」という認識でいることもあるかと思います。

 

そんな折、発表中にも引用した「エンジニアリング組織論への招待」という本を読んだのですが、その中に「エンジニアリングとは『曖昧さを減らす行為』」であると書かれていました。

人は見えないものや知り得ないものに対しては対処ができないため、そうした曖昧な要因を減らすことで生産的にプロジェクトを進めることができるというのです。

 

詳細は同書を読んでいただきたいのですが、プログラミングも曖昧さを減らす行為の1つではあるものの、それ以外でも曖昧さを減らすことは可能ということになります。

今日開発手法の主流となっているスクラム開発で行うプランニングやKPTといった手法も、この「曖昧さを減らす」ことが一つの目的となっているわけです。

例えば1スプリント内にこなせる・こなした具体的なタスク量が見えるように可視化することや、タスクの優先度の決定基準を特定の人の中ではなく全員が認識できる外に置くことなどです。

 

そのためエンジニアリングは「エンジニアだけが行うこと」ではなく「誰でもできること」という認識を持つべきではないかと思いました。

また最終的な目的が曖昧さの削減であれば、それを達成するために行動することこそが真のエンジニアリングであるということをお話させていただきました。

 

参加者の方からも多くのフィードバックをいただきました。

 

他には、実際に取り組んでいる開発プロセスの改善活動やフレームワークなどの紹介、大規模なチーム構成におけるマネジメント・情報共有手法などについての発表がありました。

弊社でやったことがない手法も多く取り上げられていたので、今後のプロダクト開発に取り入れていきたいものがたくさんありました。

f:id:incheon-special:20190808181912j:plain

株式会社イグニスさんのイベント会場

なお会場のイグニスさんですが、イベントスペースが大変きれいで司会進行もスムーズにされていたのが印象的でした。

またノベルティのステッカーが大変可愛らしかったです ‼️

 

今後マッチング業界を盛り上げていくため、Diverseはこれからも社内の取り組みを積極的に発信していきます!

TreasureData主催 PLAZMA 2019 KANDA にてLookerとの共同セッションに登壇しました


こんにちは、次の技術書典が近いのに前回買った本を全く読み進められていないiOSエンジニアの @imaizume です。

7月16日に神田明神ホールにて行われたPLAZMAに私と熊埜御堂の2名が登壇したので今回はそのご報告になります。

f:id:kmnmm:20190718144147j:plain

plazma.red

PLAZMAはTreasureDataが主催するユーザー向けイベントで、Diverseでも以前より社内DBとしてTreasureDataを使用していました。

また今回のイベントはDiverseが昨年から導入しているBIツールであるLookerがスポンサーをしていたことから、合同セッションでの登壇機会をいただくこととなりました。

なおLookerの概要や導入経緯についてはwantedlyでも紹介していますので併せてご覧ください。

www.wantedly.com

セッションでははじめにLookerからの概要説明や導入実績等が紹介されました。

現在は日本でも20社以上が導入していて、その中でもDiverseは最初期の段階で導入しているという点もお話させていただきました。

その後Diverse側にバトンタッチし、Lookerの導入背景や抱えていた課題、導入の効果や利用時のノウハウなどを紹介しました。

(残念ながら当日のスライドについては現時点では非公開です)

 

Lookerを導入する以前は、ビジネスで必要なデータがある場合、都度エンジニアにSQL発行を依頼していたため、クエリーの属人化が進んでいました。

また可視化のためスプレッドシートで管理されているデータも多く、集計時のバグ修正や計算ロジックの管理ができないといった課題を抱えていました。

さらにビジネス側の要件で算出条件を変更する場合には、複雑なクエリを修正する手間がありました。

 

しかしLookerではクエリの条件をWeb UI上で入力することでLookMLにより自動的にSQLが発行されるため、クエリの属人性を下げることができます。

Spreadsheetに頼っていた可視化も、ダッシュボード機能を使うことで常に最新のデータを必要な形で見れるほか、普段見たい情報が集約されるため必要なシートを探す手間がなくなりました。

加えて、条件修正もLookMLでの定義追加やWeb UI上での設定変更で実現するためSQLの修正が不要となり、エンジニア以外のメンバーでもほしいデータを容易に取得することができるようになりました。

 

このようにデータの活用が難しかったDiverseが、Lookerによりデータドリブンな企業に近づいていることをお伝えしました。

当日はエンジニア以外にマーケティングや分析の担当者をはじめ様々な方が参加されており、登壇後の懇親会でも導入を検討してる企業の方から質問を受けるなど好評をいただくことができました。

 

DiverseでもまだLookerで見れないデータや扱える人が限定されているといった問題がありますが、こうした課題も今後徐々に解消していくため日々努力を続けています。

ぜひこうしたデータドリブンなサービス作りに興味がある方は、ぜひDiverseの社員までお声がけください。

PORT Firebase × Flutter を開催しました

id:kikuchy です。

先日開催されたStampさんのイベント PORT Firebase × Flutter を弊社Diverseオフィスで開催 & kikuchyが登壇いたしました。

stamp.connpass.com

PORTは主にFirebase関連の勉強会を企画されているイベントプロジェクトで、過去にも様々な企業やテクノロジとのコラボ回を実施されています。
今回はFirebaseとFlutterの組み合わせ、というテーマでした。


(当日のライブストリーミング)


kikuchyは『Flutter x Firebase Crashlytics』というタイトルで、
FlutterアプリケーションにクラッシュレポートサービスのCrashlyticisを導入して運用した際に判明した問題とTipsを紹介させていただきました。


導入対象のアプリは、先日このブログでもお伝えした、婚活サービスのyoubrideです。

developer.diverse-inc.com

実務で使用する際の運用方法についてお話できたので、Flutter開発のお役にたてば、と思います。




次の登壇者のパネルディスカッションでは、アプリのアーキテクチャ、youbirdeアプリでのテスト構成、CIの構成、クロスプラットフォーム採用の是非などについてもお話させていただきました。

FlutterはFirebaseなどを使ったプロトタイピングと相性が良いので、ビジネスロジックの状態をStatefulWidgetに押し込めたりしがちです。
BLoCパターンやScopedModelパターンなどでWidget外にビジネスロジックの状態を切り出し、StatefulWidgetには表示ロジックの状態管理に徹してもらうようにすると、状態の抽象化や結合度の低下に貢献できるでしょう。


youbrideではBitriseをCIに使用していて、PR作成時にテストの実行、PRのマージ時にビルドとデプロイを自動で行うようにしています。
ビジネスロジックの単体テストを自動で行っており、実行も2〜3分程度で終わるようになっています。

プロジェクトの開始時に、まずは「ビルドが通るか」だけを確認するタスクのみでもCIを導入して、使えるようにしておくと良いでしょう。
後からCI環境を整備すると面倒になりがちであったり、リポジトリに動作しない状態のコードを混ぜる危険性を少なくできるためです。


また、FlutterはワンソースでiOS/Android両方に対応できることがウリの一つですが、結局プラットフォーム依存の機能を使用する場合やビルド周りなどでそれぞれの知識が必要になります。
そのため、慣れていないのであれば、iOS/Androidのどちらか一方に注力する選択肢を取ったほうが無難でしょう。
(youbrideチームは、クライアント開発できるエンジニアが全員iOS/Android両方ともできたのでうまく行っています)




懇親会ではクライアントでのgRPC採用の話題で大いに盛り上がりました。



(懇親会の様子)



gRPCは共通の定義ファイルから、サーバー/クライアントのRPCに関わるコードを自動生成してくれるため、
APIの定義から実装をとても楽に行なえます。
また、やり取りするデータはProtocolBuffersでシリアライズされているため、JSONと比べると軽量で、通信時間の短縮も見込めます。

youbrideでは将来的にWebサイトもPWA化し、フロント <-> サーバの通信はgRPC Web(ブラウザ上で使用するgRPC)で行う案も出てきていたので、
gRPC Webではまだ双方向のリアルタイムストリーミングができていない、などの制限があるというお話を聞くことができて大変助かりました。


Flutterでマッチングアプリの開発をしてみたい方は @kikuchy または他の弊社エンジニアへ、お気軽にDMやリプライをください!
まずはご一緒にご飯を食べにいきましょう!!

歴史ある婚活サービスyoubrideがFlutterを採用しました

最近はすっかりFlutterエンジニアになってます。id:kikuchy です。
Diverseが提供するサービスの一つに、youbrideという婚活サービスがあります。

youbride.jp


この6月に、youbrideはAndroidアプリのデザインリニューアルを行いました。

f:id:kikuchy:20190613192344p:plain
youbrideアプリのデザインが大きく変わりました!


変わったのは見た目だけではありません。
新アプリには、マルチプラットフォームフレームワークのFlutterを採用しています。

flutter.dev

近々、iOSアプリもFlutterで開発したバージョンに置き換える計画が進行中です。

そして、APIサーバーもRuby on Railsを使ったものに置き換えています。

rubyonrails.org


サーバーとクライアント間の接続にはgRPCを使用しています。

grpc.io


f:id:kikuchy:20190613200308p:plain
構成はこうなっています


なぜyoubrideでFlutter / Ruby on Rails / gRPCを採用することになったのか?
それは、youbrideに発生していた種々の問題を解決するためでした。

youbrideを取り巻いていた問題

仕様の複雑化とコードの複雑化

youbrideは今年で運営19年目を迎える、長寿サービスの一つです。
私達、今のチームが運営を手がけるより前にも、複数の会社を渡り歩き、複数のチームが開発・運営に携わっていました。

歴史あるサービス故に、サービス方針などで迷走した時期もあったのでしょう。
複雑な仕様や把握が難しい仕様が存在し、それを表現するコードも複雑になっていました。
複雑故に依存関係も読みきれず、不要かどうかわからないコードが放置されデッドコードになっている箇所もあります。

エンジニアの人数が少ない問題

現在、youbride担当チームは以下のメンバーで構成されています。

  • エンジニア …(サーバー/クライアント合わせて、外部委託の方も合わせて)5人
  • デザイナー … 1人
  • PO兼PM … 1人

膨大な仕様とコードに対して、対応できる人員が少なすぎます。
そんな状況だったので、一つの機能改修をするための影響範囲の調査だけで半日〜数日かかることもあり得る状況でした。

求人

youbrideのサーバーアプリケーションのコードはPerlで書かれていました。

Perlでの開発・運用をしたいエンジニアさんの数は少なく、採用の現場ではPerlエンジニアの募集がとても難しい、という声も上がっていました。

問題解決のために

コードの削減

少人数での開発を可能にするには、保守する対象のコードを削減する必要があります。

特にクライアントアプリケーションについては、マルチプラットフォーム開発ができる仕組みを使うことで、UIに関するコードやビジネスロジックをiOS/Androidの間で一本化できます。

また、ツールによる補助などを使用して、省力化できる部分は省力化したいところです。

仕様の単純化

利用者の皆様に御迷惑をかけてしまうため、サービス仕様については急に大きな変更をすることはできません。
せめてプログラム的な内部仕様は単純化したいものです。

そこで、サーバー - クライアント間の通信仕様の管理を簡単にできるものを探すことになりました。

人気の言語の採用

求人の対象は主に日本国内で、特にサーバーサイドで人気が高く、応募者が集まりやすい言語を選定することになりました。


技術選定

上記の要件に合致するものとして、最終的に以下のものを選択しました。

クライアント

Flutterを採用しました。

決定当時に普及の兆しが見え始めていたこと、
ロジックだけでなくUIも共通のコードで記述できること、
エコシステムが強力だったこと、
いざとなればプラットフォームの機能を簡単に使用できることなどが主要因です。

PWAにすることも検討されていましたが、iOS SafariではまだPush APIを使用できないことから、不採用となりました。

サーバー

Ruby + Ruby on Railsを採用しました。

国内の求人数が多いこと、
モダンな言語であり人気があること、
開発メンバーが慣れていることなどが主要因です。

JVM言語(KotlinやJavaなど)の使用も検討されていましたが、
メンバーのJVMサーバーのチューニングなどの運用経験が皆無であることなどから見送りとなりました。

インターフェイス

サーバ - クライアント間のインターフェイスにはgRPCを使用することになりました。

サーバーとクライアントの間での共通認識が作りやすいこと、
バイナリベースなプロトコルで、HTTP 2.0を使用できて高速に通信できること、
通信部分の実装をほとんど自動生成できることが主な要因です。

Swagger (OpenAPI)も俎上に上がりましたが、通信速度などの点でgRPCに軍配が上がりました。

実際に採用してみて

クライアント

途中経過の話は、以前にQiitaに投稿したことがありますので、合わせてご覧ください。

qiita.com

Developer Experience

FlutterはとてもDeveloper Experienceの良いフレームワークだと感じています。

アプリを実行したままコードの変更を反映させるHot Reloadがとにかく高速で、
これを経験してしまうと、通常のAndroidアプリのビルド時間にも耐えられなくなってしまうほどです。

また、(React風の)宣言的UI構築はとても直感的で、Viewの現在の状態を考える必要がなく、楽にコードを書くことができました。

高速な動作、使い勝手

Androidのアプリケーションとしてリリースを行いました。
FlutterデフォルトのLook & FeelがMaterial Designであるということもあり、通常のAndroidアプリケーションと使い勝手は何ら遜色ありません。

ビルド後のサイズも、今まで公開していたAndroidクライアントと全く変わらないサイズ(約15MB)になっています。
FlutterアプリケーションはDartのエンジンなどを積んでいるため、サイズは大きくなることを覚悟していましたが、軽く済んだのはとても嬉しい誤算でした。

サーバー

再設計による疎結合化、単純化

Perlで書かれていたサーバはいわゆるFat Controllerな設計になっており、適切なレイヤー化ができていませんでした。

今回、サーバーのコードもリライトする際にレイヤーを見直すことで疎結合な実装を実現でき、テスト駆動開発ができるようになりました。

同時に、Perlでは多用されていたメタプログラミングを廃し、IDEによる補助を強力に受けられるようになりました。

ちょっとした動作確認が簡単

Ruby on Railsの採用で、rails cコマンドによる対話的環境で、簡単な動作確認が手元で行えるようになりました。
テストを書くほどではなく、少し値の形式を確認したいだけ…など、といったときに、心理的なハードルを低くして動作させることができるようになっています。

これまではサーバーを立ち上げて、試したいコードパスを通るリクエストを投げなければいけませんでした。


インターフェイス

gRPCは通信にHTTP/2を、データフォーマットにProtocol Buffersを使用したRemote Procedure Callの仕組みです。
共通のインターフェース記述言語(IDL)を用意し、そこからサーバー、クライアント用の実装を自動生成します。

インターフェースの曖昧さ解消

これまで、サーバー - クライアント間ではREST(っぽい)APIを定義し、HTTP/1を介してJSONフォーマットでデータをやり取りしていました。

また、Perlの値を安直にJSONへシリアライズすると、真偽値が"1"/"0"と、数値も文字列型として出力されてしまいます。
以前のクライアントアプリケーションはこれをなんとなく変換して使っていたのですが、
以前のメンテナがいなくなってしまった今は、果たしてこの値が真偽値として扱うことを期待されているのか、そうでないのか、判別できません。

gRPCには共通のIDLに型宣言でき、Enumも定義できることから、値域について混乱することがなくなりました。

実装の簡略化

gRPCはIDLからサーバー/クライアント向けのコードを生成できるため、具体的な通信にかかるコードを記述する手間をほとんど無くすことができました。

IDLの.protoファイルは専用のリポジトリで管理しています。
このリポジトリでPull Requestが通ると、CIでコードの生成を行い、サーバーとクライアントのリポジトリに自動的に生成したファイルを含んだPull Requestを生成するようにしました。

f:id:kikuchy:20190611155053p:plain
protoファイルの変更から自動生成されたPR

ドキュメントもGithubリポジトリのWikiに自動でPushされるようにしています。

f:id:kikuchy:20190703204200p:plain
ファイルの変更後、自動的に更新されるRPCのWiki

ファイルの生成について特別気にすることがないため、とても開発が楽になりました。

課題

抱えていた問題のだいたいを解決することができましたが、新しい要素の採用故に生じた問題もあります。

クライアントの課題

言語

Flutter SDKはDart言語で記述されており、Hot Reloadなどの仕組みもDart言語を前提に作られています。
Flutterが出た当初はDartに対する不満も多く見られましたが、バージョン2.3になってだいぶ改善してきたように思います。

しかし現状ではまだ大規模開発を行う上で不満は残ります。

特に現在のDartはnull安全ではなく、予期しない入力によってnullを期待しないメソッド引数にnullが入ってしまった場合などに簡単に例外が生じます。
人間はミスをしがちな生き物であり、人間の注意だけでこうしたミスを防ぐのは困難なので、できれば型システムでnullが入る可能性があるのか否かを明示してほしいと切に感じます。
null安全性については今後のDart言語のバージョンアップでの採用が決まっているため、
プロダクションで採用するならば、個人的にはnull安全が導入された後のタイミングをおすすめします。

しかし悪い言語だということではありません。
言語仕様レベルでの非同期処理のサポート、クラスとインターフェイスの同時宣言、Collection If/Forなどコードを書きやすい機能も揃っています。

クラッシュレポート

現在はFirebase Crashlyticsにクラッシュレポートの蓄積を行っています。
(現在、Firebase CrashlyticsはFlutterを公式にはサポートしていません)

レポートの送信はfirebase_crashlyticsプラグインを用いて行っていますが、例外によってはDartのスタックトレースが送信されていないケースがままあります。
(スタックトレースを得られない原因は目下調査中)

また、スタックトレースが得られても、Widgetのレンダリングプロセスの途中で起きた例外は、Flutter SDKのクラス名が並ぶばかりで、ユーザーコードのどこで例外が起きたのかわからないこともあります。

そのため、現在は例外の原因究明に大きなコストがかかっています。
Firebase CrashlyticsがFlutterに正式に対応してくれるのを待っています。

gaurunとfirebase_messagingの相性

youbrideはgaurunを用いてPushサーバーを運用しています。

AndroidアプリケーションがリモートからのPush通知を受けるにはFirebase Cloud Messagingを使う必要があり、firebase_messagingプラグインはFlutterでのPush受信のデファクトスタンダードになっています。

ところが、firebase_messagingはFirebaseのコンソールなどから送信された形式のペイロードを想定した作りになっているため、gaurunが送信するペイロードとは形式が合わず、gaurunからPush通知を送ってもクライアント側で表示されません。
gaurun側の修正予定もない、とのこと)

結局、プラグインに頼らずに、Push通知の受信を実装することになりました。

サーバーの課題

gRPCの運用経験

弊社内でgRPCを使用したプロダクトはyoubrideが初めてです。
そのため、大規模サービスでのgRPCの運用経験がありません。

インフラ構成なども手探りで進めているので、今後なにかトラブルがあったら怖いのは間違いないです。

ただ、大事故に至らないように調査はしていますし、今後知見をためていくことができれば不安は小さくなるでしょう。

インターフェースの課題

サーバーがCPUを使い切らない?

現在はgrpc gemを使用していますが、どうやらgrpc gemにはCPUを使い切ってくれない問題があるようです。

今のところはまだこれが問題にはなっていませんが、そのうちに問題になる時が来るかもしれません。



youbrideチームは、iOSアプリもFlutterで作ったものに置き換えるべく作業を続けています。

これだけ歴史の長い大きなサービスでFlutterを採用しているケースは、国内初なのではないかと思います。
今後もDiverseはコミュニティに知見を還元してゆきます\\ ٩( 'ω' )و //

potatotips #62で「Firebase Remote Configの運用で知ったこと・知っておくと良いこと」を発表しました

こんにちは、iOSDC 2019のCfPに当選して夏が忙しくなりそうな @imaizume です。

今年のiOSDCでDiverseはブーススポンサーになりました! 参加される方はぜひ遊びに来てくださいね!!

 

さて、先月18日に合同会社DMMさんで行われた potatotips #62 にLT登壇させていただきましたので、今回はそのご報告になります。

potatotips.connpass.com

potatotipsは、iOSとAndroidの両プラットフォームの開発者が集い、アプリやモバイルの周辺技術にまつわるTIPSを共有するという勉強会です。

今回はGoogle I/O 2019とWWDC 2019の後ということもあり、両プラットフォームとも新しく発表された機能に関する発表が多く見受けられました。

そんな中自分は、Firebase Remote Configの運用で得たノウハウについての発表をさせていただきました。

Firebaseは両プラットフォームで使うことのある技術のため、potatotipsでのトピックにも最適と思いお話させていただきました。

当日の資料はこちらに公開させていただいております。

speakerdeck.com

 

Firebase Remote Configは、アプリ内にあるロジックを遠隔で操作可能にするソリューションです。

一部のユーザーに対して通常と異なる画面を表示したり、限定的に新機能を利用可能にしたりする、いわゆるA/Bテストに必要な機能を実現できます。

アプリ側での実装は、Firebaseからパラメーターを読み込む処理を数行書くだけで良いため、既存のプロダクトに簡単に導入できるというメリットがあります。

また専用の管理画面が用意されており値を入力して保存するだけで反映されるため、運用・管理のコストが低いのも特徴です。

 

自分の所属するPoiboyチームでは、昨年暮れからRemote Configを利用したA/Bテストによる施策の効果検証を10件以上行ってきました。

その中で現在に至るまで、チーム内で実装・運用とも試行錯誤を重ねてきました。

詳細は資料に載せたのでそちらをご覧いただきたいのですが、今回は主に増加するパラメータの管理方法として現時点でのベストプラクティスと、エンジニア以外のメンバーにとっても運用がしやすくなるようなノウハウをお伝えしました。

 

 

 

LTの冒頭でRemote Configの概要を知っているかどうかを参加者に質問したところ、7割以上の方が「知っている」と回答されていました。

どのサービスでも、施策の効果測定でA/Bテストの仕組みは欠かせないものなのでRemote Configは注目されているのだなと感じました。

 

しかし一方で「実際に利用している」と答えた方は全体の半数程度でした。

懇親会でRemote Configを使わない理由について聞いたところ「A/Bテストのための仕組みを自前で実装している」と話す方が複数名いらっしゃいました。

特に大きな会社だと基盤や数値分析を専門とするチームがあり、A/Bテストの実装についてはモバイルエンジニアは担当しないというケースが多い様子でした。

 

また別の理由として「A/Bの振り分けに詳細なユーザー属性を指定したいから」という声も聞かれました。

こちらについては、Firebase A/B TestingやRemote Configの設定時にAudience (ターゲットユーザーグループ)を対象に含めることで、属性に基づくターゲットに絞っての検証が可能です。

高精度な属性情報が必要な場合は追加のプロパティをFirebaseに送ることもできますので、自前実装を考えている方はFirebaseの利用を検討してみても良いでしょう。

 

これまで自分は「A/BテストならとりあえずFirebaseを使えば大丈夫」という考え方だったので、自前実装との比較ができとても参考になりました。

またA/Bテストの進め方や組織体制などについても参加者と意見を交わすことができ、大変有意義なTIPS共有会となりました。

なお今回はお話できなかったログ送信や数値測定周りのお話も、今後機会があればしたいなと思っています。

 

Diverseでは、こうした施策の効果測定を始めとした数値分析にも力を入れています。

最近ではLookerというBIツールも導入し、FirebaseでのA/Bテストの結果検証にも利用しています。

Looker導入の経緯についてはこちらの記事もぜひご覧ください。

www.wantedly.com

 

アプリ開発だけでなく数値分析や施策の効果検証などにも興味があるエンジニアさん、ぜひ一度お話しませんか!

お気軽に @imaizume またはお近くの社員までどうぞ、ご連絡をお待ちしております!!

iOS Test Night #10 で「iOSアプリのテストを書きたいのに書けないあなたへ」というタイトルで発表してきました

みなさん10連休はいかがお過ごしですか、iOSエンジニアの @imaizume です。

自分は技術書典 6で買い込んだ積読本にようやく目を通しています。

 

さて前回のOtemachi.swift #3に続き、4/16に株式会社DeNAさんで行われたiOS Test Night #10に登壇して参りました。

testnight.connpass.com

iOS Test Nightは今回が記念すべき第10回で、今回も主にiOSでのテスト手法やCI関連の発表がされていました。

ちなみに過去に行われた回では弊社の @kikuchy が登壇したこともあります。

developer.diverse-inc.com

そんな中今回、自分は初登壇のLT枠で「iOSアプリのテストを書きたいのに書けないあなたへ」という発表をさせていただきました。

speakerdeck.com

自分が入社以来携わり続けているPoiboyでは、恥ずかしながらつい最近までテストコードがほぼが存在しませんでした。

テストのメリットを感じつつも長い間導入できなかった要因はいくつかありますが、その一つに「iOSアプリのテストの書き方が分からない」というものがありました。

大学の授業や入社後の研修でテストの書き方自体は習っていましたが、それは題材のコードが明示的な入出力関係を持っていたためでした。

一方スライド内でも紹介している通り、iOSアプリのコードは必ずしも入出力が明確なものばかりではなく、テストを書こうと思ってもうまく書けず失敗を重ねていたのでした。

その後、明示的な入出力があって小さなコードを選んでテストを書き始めたところ、徐々にテストを書くことができるようになりました。

また実際のプロダクトで起こったことを例に、テストが書きにくそうなコードも書きやすいコードに変えていくための手法として、依存注入と抽象化、また設計を行う前段としてのモジュール分割も紹介させていただきました。

f:id:incheon-special:20190425205049j:plain

iOS Test Night #10 での発表の様子

今回は自分と同じようにテストをうまく書けないという方に向けて発表をいたしましたが、既にテストに慣れている方や他の登壇者からも、発表に対してのポジティブな感想をいただくことができました。

また発表中に紹介した「テストを書きやすいところから書く」という方針に対し、@kariad_uu さんからこのようなご意見もいただきました。

懇親会でもこのテーマでお話しさせていただき、やはりテスト経験のある開発者にとっては、簡単なテストは作業に近くなってしまいモチベーションも下がるという点には自分もまさに同意でした。

一方自分の場合は、iOSでのテスト経験が0でとりあえずの練習をしたかったこと、またチェックマークの数自体が増えることにモチベーションを持っていたこともあり、これまでは特にこの点を気にしていませんでした。

ただ今後は、実効性が高いロジックに有用なテストを書いていくということを意識して、よりレベルの高いテストを実践していきたいと思いました。

 

他の発表者で個人的に気になったのは @susieyy さんの「Snapshot Testing」でした。

Snapshot Image UI Testingというテスト手法は、目的の画面のスクリーンショットを撮影し実際の動作と差が出ていないことを確認するための手法で、スライドにもある通りレビュー負荷の軽減や画面カタログを容易に作成することができます。

またiOSSnapshotTestCaseというフレームワークにより、これをUITestではなくUnitTestのレイヤーで行うことができます。

github.com

自分のいるPoiboyでも、リリースごとにQA担当者に実機を使って表示上の不具合を発見してもらっていますが、デバイスも多様化も相まって負担が大きいことは紛れもない事実です。

そのため今後は同手法を活用してデバッグの高速化を目指したいなと思いました。

 

懇親会では他社でのテストにおける悩みや知見をお話したり、今回お話できなかった組織的な側面についての意見交換もさせていただくことができました。

また懇親会では珍しいカレーの提供がありました、大変美味しかったので自分は2杯もいただいてしまいました(笑)

 

このようにまだまだ発展途上な部分もありますが、Diverseではこうした新しい技術へのチャレンジもサポートしています!

ぜひ自分と同じくアプリのコード・設計改善に興味がある方は、お気軽に @imaizume までDMなりコメントなりをいただければと思います。

Otemachi.swift #03 にて「循環的複雑度を上げないためのSwiftプログラミングTips」という発表をしてきました

こんにちは、try! Swiftの参加者との飲み会で一番盛り上がったネタは最新のAndroid端末についてでした、iOSエンジニアの @imaizume です。

さて今回は4/10に日本経済新聞社さんで行われたOtemachi.swift #03での参加・登壇報告になります。

nikkei.connpass.com

Othemachi.swift は、その名の通り大手町近辺の企業で主催されている地域Swiftイベントです。

会場提供並びに主催は日本経済新聞社さん、ホールの壁には戦後の日経平均株価の推移が書かれていたりして、まさに日本を代表する新聞社という感じの会場でした!

今回のイベントで、自分は「循環的複雑度を上げないためのSwiftプログラミングTips」というタイトルの5分LTをさせていただきました。

speakerdeck.com

循環的複雑度は、プログラムの複雑さを定量的に表す指標の1つで、言語によらず条件分岐の数をベースとした数式で表すことができます。

過去に自分は会社で「プロダクトコードの循環的複雑度(CCN)を下げる」という個人目標を設定し取り組んだことがありましたが、その際単にif文を減らすだけではCCNを下げることができませんでした。

そこでいろいろと調べたり試行錯誤したりするうちに、抽象化やデータ構造の変更といった手段が必要であることがわかりました。

実際にCCNを計測することはなくても、コードの複雑性を減らすために使えるテクニックとして、明日からの開発に取り入れていただけるような内容にまとめられたのではないかな思いました。

f:id:incheon-special:20190425180829j:plain

Otemachi.swift #3 での登壇の様子

参加者の方からもTwitterや懇親会で多くの反応をいただき嬉しい限りです。

 

またこんなご感想もいただきました。

今回はCCNを下げることを目的とした書き方を紹介しましたが、実際はオーバーエンジニアリングとなりかえって可読性や利便性が下がる可能性もあります。

そのためご指摘の通り、自分も開発効率に影響をしない範囲で複雑性を下げていくことが大切だと思いました。

 

当日の発表は日経電子版アプリの広告流入計測にまつわるお話や、アプリ内課金に関する発表のほか、テストやSwiftlint、Firebaseから、さらにはSwift 5に関するトークなど多岐にわたりどれも大変面白いものばかりでした。

特に個人的にはTsukasa Komiyamaさんの「5分でわかるSwift 5のRaw Text」での内容が気になりました。

これまで文字列リテラルを生成する際にダブルクオート(")をエスケープしたい場合にはバックスラッシュ(\)を使う必要がありました。

Swift 5のRaw Textは、バックスラッシュの代わりにシャープ(#)を使うことができるという仕様です。

自分は過去にRubyで開発をしたときに%q記法のエスケープを使っていたので、この変更は個人的にはかなり嬉しいと思いました。

発表でもあった通り、メタプログラミングやjson、xmlをStringとして直書きする場合などには特に有効な方法だと自分も思いました。

 

併設のカフェスペースで行われた懇親会でも来場した開発者の方々と発表や開発について意見交換をすることができ、大変有意義な会となりました。

今後も開発で得られた知見を積極的に外へ公開していきたいと思います。

ぜひ今回の発表やそれ以外でも何か気になったことがあれば、お気軽に @imaizume までコメントを頂ければと思います!