きっかけ
いま、IoTといっていいものか分からない製品を作っている。
※ちょっとバズ狙いでIot入れてみました。
製品上にwebサーバーを立てて、そいつを使ってアプリを開発している。
要は、スマホみたいなものを作っていると思えば、創造がつくだろうか？
そこで得たシステム開発の考え方をまとめる。
気をつけること
不確実性との付き合い方
頭の中で確実だと思っていることでも、別のバグでちょっとしたものが巡り巡って影響することがある。
特に、初期化や起動中、状態遷移中が不確実性と衝突しやすい。
完璧だと思っても、影響範囲をデカく作ってしまったために、他の影響を受けることが考えられる。
対処としては、公開範囲を狭くするしか無い。
つまり、スパゲッティコードを作らないように心がける必要がある。
特に、適切なデザインパターンを適用することが大事。
シンプルかつ、小さく作ることを心がけないと、あとで何が原因でバグったのか分からなくなる。
不確実性と正面からメンチ切る場合、スパゲッティで勝負してては勝てない。
シンプルなこんぼうやナイフで十分。
IoT開発にとどまらないが、不確実性が出やすいので、公開範囲には最新の注意を払う。
あと、依存関係は注視したほうがいい。
依存関係がスッキリしてない＝スパゲッティで、いざ問題が起こった時、どこが原因だったのか、わかりづらくなる。
誤用をさけるためにも、依存関係図をかけるなら早いうちにかいたほうがいい。
そのほうが、チームの共通認識を作りやすいし、レビュー指摘の意図が伝わりやすくなるはず。
ログ出力
注意すべきは、どこで何をしたか。
これが出てないと、何も追えない。
また、過度にログを出しすぎるのもＮＧ。
それはそれで追いかけづらくなる。
大事なのは、システム影響がある変更をログに出すこと。
ログは、システムの状態を見るためのものなので、システム影響がある変更は、必ず出力する。
障害対応で得たこと
コメントは適度に書く
適切に命名したからと言って、必ずしも分かりやすいとは限らない。
ソース上に書けない因果関係などは、必ずかかないと、障害に対応しづらくなる。
たまに、適切に命名したから大丈夫みたいなやつがいるが、必ずしも意図が伝わるとは限らない。
書きすぎるのも良くないが、書かなすぎもよくない。
ソース作ってて不安だと思う箇所が必ず出るはず。
そういう時は、周囲の暇そうな人間か、命令を聞く人間を捕まえて、軽く相談することが重要。
他人に伝わらなければ、コメント書くか、そもそも設計を見直した方がいい。
ログには決まった文言を
障害調査でログをgrepすることはよくあるはず。
そう言ったときに、ワードが複数並ぶのは、かなり面倒くさい。
なるべく文言は統一したほうがいい。
ここらへんの考え方は、エリック・エヴァンスのドメイン駆動設計が参考になりそう。
※前、読んだけど、分からなすぎて挫折した。。。
今なら読める気がする。
ログ設計にも応用できるかもしれない。
あとがき
結構長いことブログに吐き出してなかったので、コメント程度だが吐き出す。
