DroidKaigi2018で告知されていたKotlin Fest2018に参加してきた。LT枠で申し込んだが、数分で枠が消えて間に合わなかった。実は10月にアムステルダムで開催されるKotlin Conf2018にも参加予定で、CfPを出していたが通らなかった。もっと実力をつけて来年再チャレンジする。
最近はアプリのKotlin化をチームで推し進めているが、今のコードをKotlinらしく書くことはできる。しかし、言語レベルでより良いコードにするにはどうするべきか、Kotlinを使ってもっと良い設計にするにはどうするべきかと考えきれていないので勉強している。勉強になるセッションが多かったのでメモを残しておく。資料は↓にすべてあるので、記事の読み込みをスムーズにするためにも貼らない。
Kotlin Fest 2018 - 資料一覧 - connpass
Kotlinで改善するAndroidアプリの品質｜あんざいゆき
Androidの話はあんまりしませんという出だしのとおり、Effective Java第二版の内容をベースにJavaのベストプラクティスをKotlinではどのように書き換えられるか、どのようにその恩恵を受けられるかという発表内容で面白かった。よくKotlinを書くにはJavaの知識が必要だと言われるが、Javaを知り、その問題をどのようにKotlinで解決する方法が提供されているのかを知るのも大切だ。Null安全に書けるなどはそのほんの一部でしかない。
JavaでのBuilderパターンはよく使われる手法だが、改めてKotlinで必要なときはあるのだろうかと考えるとあまりない。Builderパターン最高のエッセンスはメソッドチェインできることではなく、インスタンス初期化時に代入する値の名前を適切に決められることと、意味のあるまとまりで代入ができることだと理解できた。こういった古くから親しまれているパターンをどのようにKotlinらしく書いていくべきかというのを考え始めるには打って付けの題材だった。
Kotlinのdataクラスはとにかく強力なのだが、書かなくていいコードが増えるということは、それだけ暗黙的に理解しておかないといけないコードが増えるという意味でもある。最近AbemaでequalsやhashCode関数のオーバーライドをする機会があり、そのへんの勉強を改めてしていたのだが、compare関連ももっと勉強しないとなと感じた。
Kotlinアプリのリファクタリングポイント｜Naoto Nakazato
kotlinのより良い書き方を紹介するセッションだった。tips集という感じでそうだよね！という内容が多かったが、拡張関数をinterface内において、使えるスコープを限定した方がいいよねというのはすごく共感できた。拡張関数を言語機能として提供している場合、チームの各々が俺の考えた最強のextentionみたいなものが乱立してカオスになる。しかしコーディングルールで強制するには難しいし、かと言って放置しておくと、似たようなものや全体としては必要ないものまで「無用な汎用性」を持って作成されがちだと思う。なので、extentionsパッケージなどはトップディレクトリに作成せずに、機能ごとにパッケージ内で閉じていくスタイルが良いなと共感した。
他にも資料の115Pから始まる、状態管理の整理の仕方については勉強になったが、数理的に求めた組み合わせ最適解に名前をつけるのが一番大変なのだよな...と感じた。EitherやPairといったクラスを乱用するのはカオスエンジニアリングの始まりだ。資料にもあるように状態を数式で表せて、仮に
val state = Either<Pair<A, B?>, C>?
のようなものができたとしても、例えばUserの状態Aと画面の状態BをもつPairにどんな時も適切な名前がつけられるだろうか？プロダクトのコードが状態を表現する中間クラスで汚染され始めるのは避けたいとも思った。人の理解しやすさは文脈に影響するので、特定の状態を組み合わせる名前では表現の限界がありそうにも感じた。とはいえ、上記のように状態が整理されることは大切なので、整理をしたあとチームで議論をするしかないように思う。
Kotlin linter｜kgmyshin
これからlinterを導入するなら必読といって良い発表だった。俺自身、Abemaにきて最初にやったのがlinterの導入だったので、ほとんどの話は理解していたが、こういう場で発表する機会を持てるところがチャンスをつかめている人の違いなのだなと感じた。単純にアウトプットが足りないのだろうな...。知見は溜まりつつあるので、みんながまだ理解していないであろう部分や深掘りしていない部分を詳しく説明するような発表をしていきたい。
webやバックエンドの人は驚くかもしれないが、iOSやAndroidの開発ではまだlinterを積極的に導入しているところは少ないのが現実だと思う。それなりの規模のチームがあれば整っていると思うが、みんな迷わずに最初から導入しているという例の方が少ない。これはlintを整備するよりもさっさと実装して動かすほうが早いという意味でもあるように感じる。また、より少ない人数で開発されている現場が多いのだろうなとも感じた。少数でやっている限り、口伝すれば困らないことはざらかもしれない。とはいえ、エンジニアたる者そこに手を抜きたくはないのでちゃんとやるべきだろうというのが持論だし、そのために超えないといけない障壁はどんどん消していこうなというスタンスだ。
Kotlinに関していえば、Googleが提供するAndroidサポートライブラリでも採用しているlinterが存在し、発表を何度かしているがktlintがそれだ。俺がよく言っているのはlinterとformatterの役割はきちんと分けましょうねということだ。実際にはそれぞれ近い部分も存在するとは思うが、概念を超えた性能は不要なので、役割は明確に分けて、しっかり名前を変更するべきだと俺は思っている。という気持ちをプロポーザルにするのがいいのかもしれない。
これからももっと現場に浸透するように支援や発表を行なっていきたい。
Kotlin コルーチンを理解しよう｜sys1yagi
コルーチンについてまだまだ理解が足りていない部分が多かったが、それを一掃してくれる神資料と言うべきものだった...Qiitaとかで他の人の記事を見たりしているが、自分のプロダクトに導入できないと意味がないので、積極的にやっていく。Javaではどのように実装されるのか、Kotlinでそれをどのように実現しているのかという気になる部分を全て丁寧に一つずつ解説されているので、絶対に読まなければいけない資料だった。即刻プロダクト導入したいが、coroutineに置き換えるメリットがなんであるかをきちんと説明できるべきなので、プロジェクトに導入するには勢いかより深い理解が必要だなと感じた。coroutine自体は古くからあるプログラミング手法と言えるので、概念的にどういうものなのかという説明がされるとやはり理解が進む。JSやgoの文脈ではとにかくネストを解消するにはみたいな印象しか持っていなかったが、なぜ、どのように解決するのかというのがわかってきたので、Androidでは「特にこういう問題を解決したい」というシーンが見えてくれば導入待ったなしだと思う。
議論をしていて気になるのは、Rxプログラミングで解決したい問題を解決するためにcoroutineが適切かどうかはまだわからないということだった。Rxの概念や思想は素晴らしいが、coroutineで本当に問題なく置き換えられるかがわからない。これからの実務導入で見てみないとわからない部分が多そうだなと。システムで取り扱うデータとシステムの状態を独自の概念で表現していくという点で似ているが、出発点が違うのでお互いのカバーしあえない領域はでてきそうだなという小並感。
この辺の技術を勉強していると、どんどん数学やアルゴリズムとデータ構造についてもっとCSの理解しないとな...と反省するばかりである。
あとはLT会をみたけど、3分が短すぎてほとんど勢いしか伝わらなかった...2万行のJavaをconvertする勇気すげぇ...って気持ちが残った。
もう何度も考えているが、資料を即日公開、動画も配信となるイベントに足を運ぶ意味はなんなのだろうかということがわからなくなってきた。ネットワーキングや自分の発表、何かの協力チャンスを掴むなどの目的があれば良いとは思う。実際、今回は同期がやりたいと言っているイベントの話を聞いていて、それに近いことをしようとしていたmixiの人の小話が聞こえたのでそこを繋いだりできてよかった。会社でスカラシップをしたこともあり、学生と交流する目的もあったので参加してよかった。けれど、土日は人生においても貴重な時間であり、その1日を勉強のためだけにリアルタイムで時間を消費するよりは、集中して家で情報集めをする方が効率が良いとは思っている。「いつもいる人」ブランディングもあるかもしれないが、うまく時間を使える方法で付き合っていきたい。
終わった後はいつものメンバーでboard game会をしたりした。土曜日が消えた。
