開発する時に心がけているもの

はじめに

この記事は闇の 魔術に対する防衛術 Advent Calendar 2018 の 12/9 の記事です。 qiita.com 遅れてすみません。皆Qiitaに書いてるのに別のところに書いてしまいすみません。

※これは個人的に心に留めているメモです。 時と場合によって最適解ではないし、最適解を見つけていくほうが良いと思う。

いきさつ

開発を行っているとよく魔法のせいなのか虚無になる事がある。
手を動かしてコードを書いてるが 頭が動いていない、未来が見えない、虚無、虚無、虚無等々……、吸魂鬼でもいるのかな?アズカバンかな?

そういう時に以下の事を心に留めて設計をすると吸魂鬼が寄り付かず
心が守られた開発ができるかもしれない……(しらんけど)

たいてい柴田さんと話している中で出てきたものなので柴田さんに感謝です。

yshibata.blog.so-net.ne.jp

吸魂鬼とは

地上を歩く(実際には滑っているが、便宜上このように表現)生物の中で最も忌まわしきものの1つと言われており、人間の心から発せられる幸福・歓喜などの感情を感知し、それを吸い取って自身の糧とする。その影響力は凄まじく、吸魂鬼が周囲にいるだけで人間は活力を失ってしまう。特に、ハリー・ポッターのように過去に悲惨な記憶を持つ者ほど、吸魂鬼の影響を受けやすい。 ただし、吸い取れるのは前述の感情のみで、それ以外の感情(妄執など)は吸い取れない。人間ほど感情が複雑でないためか動物の感情も吸い取れないうえに目が見えないため(眼窩は存在するが目玉がない)、動物もどきが動物に変身してしまうと感情を吸い取れなくなる。 映画では吸魂鬼が姿を見せると周囲の気温が下がり、ガラスについた水滴や池などが凍りつき草花は枯れてしまう。 吸魂鬼に向かって「守護霊の呪文(パトローナス・チャーム)」を使用すると、吸魂鬼を追い払える。また、ルーピン曰く、鬱になったときはチョコレートを食べると気分が良くなる。

wikipediaより引用

つまり近くにいるだけで心が壊れ、虚無になるやつ。絶対自分の周りにいる。

Expecto Patronum!

Interfaceを考えるときは以下の質問を自分にする

  • そのAPI誰が使うの?
  • そのAPI、設計者都合じゃない?(使ってるライブラリが**を必要としているから等)
  • そのAPI使う人はなぜ使うの?(他のAPIがこうあればそのAPIいらなくない?)
  • そのAPI使うときの引数は正しい?(その引数はClient持ってなくない?)

脳死Create を生やしたから Delete を生やすなんてするとたまにそこに吸魂鬼が住み着く。 少なくとも存在理由を答えられないInterfaceは極力控えよう。Interfaceが増えるとその分 正しい振る舞いをする事を保証する物が増えるのでテストが増える。ドキュメントも増える。
テスト/ドキュメントを書かないと数日後に吸魂鬼が住み着くぞ

テストは書く

それはそうなんだが守護霊(テスト)がいる環境での開発の感想が書きたい
テストが有るとね、Methodが、安心感?絶対に問題ないとわかっていると感じて光って見える。 マジExpecto Patronum。想定内の挙動しかしないのでレゴブロックを積み上げる気持ちで開発できる。
守護霊に守られてる感じがする。安らぎ
なにか変更があったときもE2Eテストが通ったら安心してDeployできる、マジExpecto Patronum。
もう変更なんて怖くない、だって僕には守護霊(テスト)があるから……

本当にテストが書かれているシステムのコードは開発がレゴブロックを組むみたいに安らかにかけて良かった。

エラーが見つかったときはエラーを確認する

エラーを再現するTestを書く(必ず落ちる) -> 修正する -> Testが通ることを確認する 先にProductionのコードを修正するとエラーが本当に修正されたかわからない。
落ちるテスト -> 通るテスト の流れがあるとバグ部分のテストができてるので安心。
エラーを直した、と思ったら通らない の繰り返しになってる -> 吸魂鬼が住み着いてる

E2Eはなるべく早く取り掛かる。優先度を高くする

消耗しつつUnitテスト書いても最終的にE2Eが通らないと意味がないのでなるべく早く取り掛かったほうが良い
E2E -> Unit -> E2E -> Unit
E2Eが全て通ればProductionとしてはある程度問題ないと思うので、E2Eでカバレッジを取りつつ、 どうしてもE2Eでカバーできないケースに対してUnitテストを書くと良いと思う。
CodeCovの犬 となりホワイトボックステストを消耗しつつ書いている -> 吸魂鬼が住み着いてる

CodeCovに振り回されてはいけない、時には勇気を持って赤くする

赤を恐れるあまり、絶対発生しないテストケースを書いていないか?書いていたら 吸魂鬼が住みつき始める
他の層でValidationしていて、こちらの層では絶対発生しないケース(ドキュメントにも書いてある)をテストしようと 複雑な条件整備とテストケースを作りつつ、CodeCovの赤を緑にしようとしてると無意味なテストが量産される。
虚無になり書いたコードが意味がなかった時はとてもつらい。

名前有るもの理由を考える

この世には様々なものが妬み嫌われていたりする。 しかし、大抵の嫌われている物には名前があり、作者は価値を感じて作ったと思う。 なので、一概に否定せず、何故その結果になったかを考えると世界に優しくなれる。 世界に優しくなろう。 吸魂鬼が寄り付かない

まとめ

コレは私の心の中のPatronumなので自分のPatronumを見つけていこう。 プロダクトに吸魂鬼が住み着いていなくても、上のレイヤーに吸魂鬼が住み着いていて全てが崩壊する場合もあるよ。
本当はFinTech界隈の吸魂鬼事情についてかk