ルール以下のようなガイドラインを設け、これを守るように書き換えた。メソッドの部分だけ特別にインデントする具体例こういう形の、素朴なルーティングがひたすらに羅列されていくコードになる。実際のコードでは数百行以上に及ぶ。基本的に1行に1つのルーティングが定義される。比較的素朴なメソッドを利用してルーティングを実現しようという話である。使わないことで、近しい概念から発生するルーティング同士の関係性をコード上で表現することはできなくなり、どういったリソースの関係性の元にそのルーティングが成り立っているかということはもはや表現されなくなり、ルーティング間には一部に重複した部分が存在するようになってしまう。利用しているとは到底言い難く、徒にコードを理解するための学習コストを高めるばかりという状況だったため、今回の変更を加えた。「パスの辞書順に定義する」というのは、誰が書いても同じコードになるようにするためのルール。「誰が書いても同じコードになるようにする」という部分について、決まりに縛り付けられて息苦しく感じたり、独創性を発揮する余地がなくなってしまったりという、ネガティブな雰囲気が感じられるかもしれない。コードを書くときの意思決定に必要な思考リソースを省くことができ、何も考えなくても書くべきコードが決定される、というようなポジティブな気持ちで捉えてほしいと思っている。こんなところで無駄に独創性を発揮してしまうよりは、思考リソースを温存しておいて、もっと他のところで発揮した方が良い。実際に変更を加える際には、変更前と変更後で挙動に違いが出ないことを保証する仕組みを用意するべき。出力結果に差分が生じないことを確かめながら変更を加えた。入っていたのを知らなかったみたいな理由でアプリケーションが壊れがちで、当たり前のことでも十分に気を付けるべき。経験者である、みたいな状況でもない限り、幾らかの利益を我慢してでも、素朴で読みやすいコードに留めておく方がメリットが大きいと思う。ところでルーティング定義が十分に単純化したことで、クライアントサイドとルーティング定義を共通化するような案も出てきたので、一度試してみたいと思っている。アプリからルーティング定義を生成してクライアントサイドの実装に利用するのではなくて、ルーティング定義からサーバサイドとクライアントサイドのルーティング定義をそれぞれ生成するということも出来そうな気がしている。