Boolean値の管理は結構難しいんじゃないかみたいな話

技術書典8にサークル参加することになり、ずっと「何について書こうか」を考えている。技術同人誌は自分の学習や技術に対する理解を深めるために書いているという側面が強いので、普段興味があるものでないとモチベーションは上がらない。それに後から読み返して「あーそーだよね」とか（自分が）したい。

一方、特定技術についてはもう先駆者がいて、サークル参加数も増えてどんどん埋もれていっている。積んでいるゲームもあるし、ハマっているジャンルの同人誌も読みたいし、気になる映画も多いし、今年はプライベートでも色々あるので（まあ一つ前のエントリで察しはつくだろうが）自分の時間を原稿で潰したくないな、とも思っている。そういう影響を受けて、最近自分のモチベーションが下がってしまっている。

じゃあどうする？という話で色々考えていた。今はVue + TypeScript（サーバーサイドはRails）でできたWebアプリケーションのエンハンス開発をしている。途中参加でエンハンス開発をしており、こんな感じの状況である。

  • Jestを動かす環境はあるが、コンポーネントへのUnitTest実装はほぼ無いに等しい
    • 途中参加したときはJestが通らなかった。最近「とにかくオールグリーンにする」ことはできた
    • 一緒に開発している人と頑張って書こうとしている -「画面の動きとデザインカンプが仕様」状態となっている
    • 毎回動作がデグレしていないか、masterブランチの動作と比較している
  • サービスリリースしたときの開発メンバーはほぼ抜けてしまっている
    • GitHubのissueベース開発だったのでメンバーがいないことで困っているとかはない。ツールはなんでもいいけど変更・実装作業がチケット単位になっているのすごく大事。

機能追加や改修、バグFIX時に既存の機能が「正しい動作」をしているか、何が正しいのかを判断するのに時間がかかる。特に時間がかかるのがBoolean値の判定で挙動が変わる部分である。true/falseの2種類しかないはずなのに、なんでこの解読に時間がかかるのか？どういう類の実装をされるとエンハンス開発しづらくなるのだろう？と思うようになった。というわけで、これについて考えた本を作ろうと思っている。

ぼんやり考えていることをつらつらとあげてみる。考えてたこと、今関わっている開発とは別の開発現場でも見ている。ちなみにVueでフロントエンド開発している現場、ここ1年ちょっとで3つくらい行ったけどコンポーネントのテストは後回しになっているところばかりだった。コンポーネントのテストが書けているだけで色々と強い環境なんじゃないかと思っている。

Vueで条件がtrueのときは特定の要素・コンポーネントを表示する、みたいなとき、

# AもBもCも別の条件
v-if=A || B || C

みたいな実装をされているとつらい。A・B・Cがメソッドになっていて、return値を追いかけないといけない場合、とてもつらい。とにかくDebugツールとにらめっこしないと無理。コメントがないと「動作 is 仕様」状態になってしまいがち。

このパターン、さらにつらくなるのはこういうとき↓

# Bのreturn値はfalse
v-if=A || !B || C

Bのreturn値がfalseでそれを反転してtrueになるのでコンポーネント表示…いやすぐ分かるわけあるかい！みたいな気持ちになる。後から継ぎ足しで実装されてたりするとなりがち。

コンテキストが別のtrue / falseをORまたはANDで繋がれてしまうパターンもつらい。ある特定要素を無効化状態にするみたいなとき、

# Aはバリデーションエラーがあるか判定するメソッド、Bはフォームの値が更新されたか判定するメソッド
disabled= A() || B()

とかなっているとつらい。パイプが2つくらいならまだ、まあ何とかわかる。3つや4つとか繋がれていると…。

同じパラメータ名なのに、条件が異なっていたりすると「動作 is 仕様」になってしまう。たとえば↓みたいなとき

# trueならdisabled
disabled=A

# falseならdisabled
disabled=B

このパターンはテストやドキュメントがないと解読や改修に時間がかかる。コンポーネントごとに実装者が違っているとおこりがち。同じ名前を使うなら、条件は全体で合わせておいて欲しい。

これと似ているが、変数名とtrue / falseの意味が逆になっていたりするとえっ？となってしまう。

# trueだと要素が無効化されるパラメータ名
isXXEnable=true

Enableなんだから有効化でしょうが！と思ってしまう。結構ある。スケジュールがギリギリとかだとこういうところは置いてきぼりになる。でも後から改修入れられないのが1番つらいのでうまくやっておきたい。まあ大前提はテスト書いてくれっていうのはある。

Boolean値以外にも「解読がしんどい」ものはある。2020年は同人イベント参加回数をかなり絞る予定なので、直近はブログに書こうと思っている。予定やお金に都合がつけば11月の技術書典か12月のコミケどちらかは申し込みたいもんですね。