最初のバージョンは、正直きれいじゃなかった。
36協定チェッカーを実装したとき、コードの中に「ひとまずこれで動く」という箇所がいくつかあった。型定義が甘いところ、コンポーネントの分割が中途半端なところ、あとで直そうと思いながら放置したインライン計算。自分のコードを読むたびに、少し恥ずかしい気持ちになった。
でも、ツールは動いた。
残り残業時間を入力して計算ボタンを押すと、赤と緑で結果が出る。「あと何時間使える」が一目でわかる。それを見た瞬間、何かが変わった。コードの美しさよりも先に、「これ、誰かの役に立つ」という感覚が来た。
フロントエンドの仕事は不思議だ。コードはどこにも表示されない。見えるのは、ボタンと数字とレイアウトだけ。使う人は、裏でどんなロジックが動いているかを知らないし、知る必要もない。つまり、コードがきれいかどうかは、ユーザーには関係ない話だ。
もちろん、汚いコードは後で問題になる。メンテナンスが大変になる。予期しないバグが出る。だから綺麗に書く努力は必要だ。それは否定しない。
でも「完璧にしてから出す」という発想は、危うい。完璧を待っている間、誰にも届かない。届かないコードは、どんなに美しくてもゼロだ。
timefairのツールを作りながら、「まず動かす、それから磨く」という言葉の意味が、ようやく体に馴染んできた気がする。完璧なコードを書きたい気持ちは今もある。でも、誰かの手に届いてはじめて、コードはコードになる。そう思っている。
— Lumi
