技術的な判断をするときの考え方を文字にしてみる

会社に新卒が入ってきて、判断をするときにこういうこと考えるといいよねーってことを伝えられるように、いつも考えてることを文字に起こしてみる。

作る必要ある？

何かしらを作ると作っただけ複雑になる。なにもないのが一番単純。作らないのが一番楽だよね〜。
だから作らずに目的達成できるならそっちのほうがいいし、もしかしたらそもそもいらないかも。何もしなくて良いなら絶対そっちがいい！
働かなくて良い道を選びたい。

これは取り返しがつく選択？

なにか技術的な選択を迫られたとき、取り返しがつくかどうかを考える。
あとからもう片方の選択肢に切り替えられるなら、まぁどちらでもいいかなー。メリット・デメリットの天秤にはかけるけど、取り返しつくし。
AとBの選択肢があって、A→Bの切り替えはできるけどB→Aにするのは難しいといった場合は、Aを選ぶことが多いかも。もちろん天秤にかけたあとで。判断がどうしてもできない場合は取り返しが付きやすい方を選んでおいたほうが失敗したときにリカバリーしやすい。
どちらに転んでもリスクが小さい場合（たとえばlintを入れるか入れないかとか）は「どっちでもいいし、強いモチベーションがない」とかを明言しつつ試しにやってみて微妙ならやめよう！みたいな感じで良さそう。

運用するとき困らない？

人間が頑張って運用でカバー！は最後の選択肢。人間はミスるし、そういう面倒な作業は精神的にしんどい。楽しくない。
あと積み重なると気づいたときにはタスクに押しつぶされてたりする。運用も一緒に考える。

あとから変更するときこまらない？

区分を増やすとか処理をふやすとか、ある程度想定のつくものを増やそうとしたときどこを編集すればいいか考えておく。
「こことこことここを変えないといけない！（すごい散らばった場所に対して」とか変更漏れ発生しそうだなーと思ったら考え直す。

普通を好む

フレームワークの普通とかRFCに書いてある普通とかそういったものを好む。こういったものを作っている人は大体は自分たちより経験値を持っていてすごいエンジニア。できる限りこれにそって作ったほうが良い。オレオレの何かをやると大体のケースでバグったりセキュリティホール作ったりする。
フレームワーク文脈でいえばリフレクションとかで「privateなメソッド呼んでやったぜ！」とかドヤ顔してしまうとほぼ確実に痛い目を見る。普通に使わない人は互換性のサポート対象外だ。