2022振り返り

投稿日: by yimajo

電子書籍リリース編

今年はEffective Swiftという技術書籍をリリースしてました。

BOOTHで買えます。
https://booth.pm/ja/items/3755447

これまでRxSwift研究読本やらCombine Framework Guidebookなどを書いてきたんですが、もう少し基礎寄りなことを書いておこうと思っていて、それをちゃんとまとめています。

また、本書のためにSwift自体のテストコードを読むとメモリライフサイクルについて調べていて、メモリ管理について絶対この本を読むまでしらないことが書いてあるはずです。

買ったもの

モバイルディスプレイ

安いサンワダイレクトの12.5インチくらいのを買いました。

手汗出るのでmacbookをあんまり使いたくない。

デザインとしてロゴでSANWAとか書いてると萎えるのでそういうロゴがない液晶をできるだけ選んでます。ただ、シルバーのとこが気にはなる。バッテリーがないので安い。

こういうサブディスプレイの基本的な用途として

  • DeepLアプリ
  • ターミナルアプリ
  • 画面共有時に見せるときの画面

として使っています。モバイルディスプレイだけどほぼ持ち運びはしません。たぶん450~500gくらいなので軽いけど。

iPadで代用できるとは思いますがiPadだとベゼルが太いのが気になる。

Amazonのリンクを貼っておきます。

https://amzn.to/3VEmx57

キーボード

keychron Q10を買いました。アリス配列という分割してるタイプ。普通のmacのキーボードと似てるのがいいです。そしてそれのパームレストも買いました。

ただパームレストは水平になっておらず、足が浮いてる状態で致命的で初期不良だったのでサポートに連絡して新しいものを送ってもらいました。

YouTubeで調べると他の購入者も同じように水平になってなくて、検品が機能していないことがわかります（というか他の購入者もサポートに連絡してもらって企業的に検品体制どうにかしてほしい）。

台

手元にキーボードとディスプレイがありつつ、macbookは台に置いて動かしています。

ロゴのBoYataというのがバランスが悪すぎるのが残念。それ以外は問題ないです。

https://amzn.to/3GqjjOu

ほしいけど悩ましいもの

5k2kディスプレイ

https://amzn.to/3GuI9Nl

ほしいけどこの製品の発表は2020年1月なんですよね。そこから1年と半年くらい遅れて発売されて今2022年末なのでもう2023年なんですよ。つまり2023年に2020年のもの買うのかは悩ましい。もう新型がいつ発表されてもおかしくない。

更にレビューを読むと（35inchの別商品だけど）

  • 起動時間がながい（おそらく、遅い）
  • 何もしてないのに画面が割れたが保証対象外

もうちょっと様子見かなと思っています。

仕事の上で気がついたこと編

もうだいぶ長いこと社会人をやってるわけですが、仕事をしていて気がついてきたことも多くありました。

  • 自分がコードを書き直すということは、なるべく本質的に問題を解決するため
    • 大胆に書き換えるための計画づくりを行う
    • 大胆に書き換えるために意味のあるテストコードを書く
  • 開発環境の向上のために大きな施策をする前に小さな施策を積み重ねないといけない
    • いきなり大きな問題を取り扱わない
    • 計測をしないといけない

自分がコードを書き直すということは、なるべく本質的に問題を解決するため

自分が他社のコードを書き直すことがあるわけですが、自分がやる意味って何なんだろ、というのを常に頭に置かないといけないと考えさせられました。

大胆に書き換えるための計画づくりを行う

これはあくまで例えばですが、機能をなにか置き換えるときに根本から修正変更したい。それをやらないとコードを読んで理解する時間が他の人にも降りかかる、根本的に修正したくなる。

そのために、必要な時間と内容を見積もってタスク化し、その計画を共有するということが自分の勝ちパターンだなということが意識できるようになってきました。この計画づくりも、もちろんやってみないと分からないことも出てくるけれど、計画をつくってそれがうまくいかないことで得られることもあります。

さらにミスってもミスを最小限にし学びがあるようにするっていうのが良いと思っていて、そのためにはなるべく影響範囲を小さくすることを考えたりします。

意味のあるテストコードを書く

大胆にコードの書き換えが必要なとき、基本的には既存のテストコードを壊さないで内部だけを一回書き換えた改善版をPull Request出してテストをパスさせてみる。そうやってその部分の解像度を上げておいて、新しく書き換えるものでは必要なテストを足したりします。意味のあるテストコードはすごく難しいし、どんなものが意味があるのかを具体的な例を挙げずに抽象的に書くのは難しいので別の機会にします。

開発環境の向上のために大きな施策をする前に小さな施策を積み重ねないといけない

iOSアプリ開発のプロジェクトでは、あまり決定的な作り方というのが確定していなくて、各社なんとなくの感じでバラバラなやり方で進めているのがまだ現状です。そうなると1つの例としてはビルド時にRn Scriptでいろいろやってしまって、ビルド時間を大幅に遅らせてしまうので圧倒的に生産性を落としてしまうわけです。

しかし、これにいきなり対応してしまおうとするのはあんまり筋が良くないなとわかってきました。いきなり取り組んでPull Requestを作ったとしてもおそらくマージされないでしょう。「論よりプルリク」なんてのは下地ができあがっているチームでの話というのが私の経験則です。

いきなり大きな問題を取り扱わない

こういう場合は経験的にどうするかというと、小さな改善の施策を合間にやっていくのが結局早いと感じています。あくまでたとえばですが、Xcodeで警告が200くらいあったら1つずつ解消する小さなPull Requestを合間に出していくなどする。大抵どうでもいい警告でも本質的に改善すべき重大なものもあるし、そもそも警告として扱わなくてもいい内容もあったりしますが、それを対応していく。雑に言うと文化的な雪かきをするしかないです。またはボール拾い。警告を圧倒的に少なくしておいて、増えたら気がつけるようにし、なるべく警告を増えないように意識づけてもらえるようにするなどが良いです。ただ、これも目的と手段が難しい場面はあって、警告を必ず0にしなければいけないと思い込まれると、無理に警告を発生させないような方法を考えさせてしまうことがデメリットだとは思います。

これも例えば工場で「事故を0にしよう」というスローガンがあったとして、そのために小さな事故を事故とみなさなかったり、そういう本来の目的を失ってしまうことになってしまうこともあります。そういう「おもしろ」も起こることはありますが、それは目的が何かを説明すれば良いとして、とにかく最初は自分の手を汚すしかないです。警告だけじゃなく不安定なテストコードをガンガン直していくのでもいい。

なんだかそういう自分の手を汚して小さな改善することや、目的と手段のカオス化って小さい頃に見たお仕事系テレビドラマの話みたいで「あるある」なのでめちゃくちゃおもしろいんで、好奇心がくすぐられっぱなしなんですが、あんまりそういう事象を「おもしれー」と表現するのも良くないね、事象を面白いといってるのかそれの元コードを書いた人を面白いと言ってるのか、その違いが他人にはわからないというのも何度も考えさせられてきました。

念の為、なんで工場の話を書いたかというと、社会人になった最初は半導体関連の会社に就職してめちゃくちゃ古い体質の会社だったのもあって、最初の一年は工場にいくことがめちゃくちゃ多かったからです。ものを作る仕事では工場だろうが家でリモートワークだろうがあんまり違いはないと思います。

計測をしないといけない

閑話休題。小さなプルリクエストを重ねていって、徐々に大きな改善をするときは計測をやるということを怠らないように考えています。数字で出る改善点は出せるなら出す、もし数字を出すことが無理ならそう書いておけば、なにか案を教えてくれることもあるでしょう。警告数の対応はデクリメントされるのでわかりやすいですが、そうでないことの場合は他の数字で出していくことが重要です。ビルド時間だったりアプリの起動時間だったり、OSSへの依存数を減らしたり、Objective-Cのコード数の減少だったり。

そうやって小さなことからやっていって、他のメンバーが理解しやすい数字を出して納得してもらえるようになって、やっと大きな改善ができるのだと思います。ちゃんと数字で改善の長所と短所を語れるようになって下地ができているなと思います。

来年のこと

  • 不安定なテストコードを改善する指針を公開したい
  • 自分のWebサービスやアプリをつくる時間を確保したい

不安定なテストコードを改善する指針

CIでテストコードがたまに失敗するみたいなこともよくあると思います。今年と去年はそういうのもかなり改善することをやっていて、そのパターンをどこかに公開したいと思っています。ただ、そこに誰も困ってないかもしれない、「不思議だねえ」って感じで放置されてるかもしれないんであんまり優先度は高くはないです。

たいてい、下記3つが絡み合って実行順序も関係してテストが不安定になっているはずです

  • 言語仕様（特にバリアブルなオブジェクトに対する変更を複数のテストで共有してしまうこと、参照の破棄）
  • リアクティブプログラミングフレームワークの挙動
  • テスト用のフレームワークの内部実装
  • CIサーバがローカルマシンより低スペックなこと

自分のWebサービスやアプリを作る時間を確保したい

つくりたいものいっぱいあるんでできれば優先したいです