最近やっぱり大事だよなと思った事を雑にまとめる。
変化に対応する事
今作ってるアプリやプロダクトは将来的にどう変わるか、どう変えていきたいか。について正確に予想しながら作り上げていく事は難しい。
もちろん何も考えずに作っていくわけではなくて、ある程度先を考えながら作るんだけど、作ってる途中で方針が変わったり、作って運用した結果、仕様を変えないといけないなど、臨機応変に対応する事が求められる。
どうすれば変化に対応する事が出来るのか？ その機能をそれ単体で動いてかつ、なるべく他に依存せずに独立して作る事だと思う。
考え方の１つの指針とては、この機能をライブラリ化した時に、どう言う形で公開するのか？というのを考えながら作る（実際に公開するわけではない）
こうやって考えると別の機能とかクラスに依存してるとやりずらいので、自然とそれ単体で動くような機能になっていく。
ただし、この辺はバランス感覚が必要で完璧を目指しすぎるとそれ相応の時間がかかる。
今必要なものを作る
その機能を実現するために必要な事だけやる。
将来的にこういう事がありそうだな。こういう使われ方もされそうだからこの機能も作っておこう。 という考えで実際に作る事はしない。 結局その機能が使われる事がなかったり、使われるとしても必要な機能を満たしておらず、結局修正が必要になったりする事が多い。
もちろん、実際には作らないけど、考えておく事は重要で、将来の事を考えて変化に対応しやすい形で作っておく事は問題ないと思う。
問題を解決する時に大きな問題から目を背けてないか？と考える
今ある機能が微妙に動いてないという事に気がついた時、ちゃんと動くようにコツコツ直すことをするんだけど、そもそも設計がその機能を動かせるように出来てないからうまく動かない。という事もあるんじゃなかろうか。
機能がちゃんと動いてない時はなおさないといけないけど、そもそもどうあるべきか？その方向にもっていかないといけないんじゃないか？という事を考えてやる必要がある。
他にも細かいインデントのズレとか、enumにした方がよさそう！という部分を見つけて直したい衝動にかられる。もちろんコードを良くしていく行為自体はいいと思うんだけど、それを直す時は何かのその周辺を触る時についでに直したらよくて、もっと大きな問題の解決に頭と時間を使った方がいいのではないか？と思ったりする。
圧倒的当事者意識
基本的にレビュー→マージのプロセスを経ている以上、どこのコードでも自分が書いたコードとして考えていきたい。 治安の悪いコードを書いてしまったり、見つけてしまった場合でも、何が問題なのか。どういう方向性で解決していけばいいのか。 について考えて解決までもっていけるようになりたい。
ただし、解決するかどうかも含めて、「問題を解決する時に大きな問題から目を背けてないか？」この視点を持ちつつやっていく必要がある。こういった事が起きる事も含めて、「LGTM」という行為には一定の重みを感じるようになってきた。
ハードウェアと何かする時
ハードウェアとやりとりして何かするアプリというものは、毎回接続して開発していくとかなり効率が悪い。なるべくテストを書いて、少なくとも正常系は一通りテストを書いてから実機で確認。 が出来るとめっちゃいい。
ハードウェアとのやりとりを上手く抽象化していい感じにテストが書けるようになりたい。 もちろん、テスト書きやすい部分は書いてる。
所感
雑に考えをまとめる。というのはなかなかいいことかもしれない。
