Continuous tax

http://beust.com/weblog/archives/000463.html

While it looks innocuous, the loss of typing actually has dire consequences on the maintainability and readability of your code by not giving you any hint on what type an object passed to a method really is and, worse, by making it impossible to apply even the simplest automatic refactorings such as renaming public functions (see this post for more details).

To make matter worse, changing a type in my dynamic code forces me to update my tests manually

上記のcontinuous taxの話は、とてもよくわかる。

動的言語で開発する場合、メソッドのパラメータの型がわからないので、分かりやすい命名と一貫性のある命名規則がなければ、コードを読むのが大変になる。だから、動的な言語で開発する場合には、静的な言語より、多数のテストを書く、コーディングスタイルの統一、多くのレビューが重要になってくると思う。そうしなかった場合に、Continuous taxというのはより重くのしかかってくることになると思う。保守コストがかなり高くなっていくとは思う。

その上、リファクタリング時には、ソースとテストの二重の修正をしなければいけなくなってくるので、動的言語では規模が大きくなってくるとリファクタリングが大変になり、保守のコストも高くつくことになる。こういう問題は、実際に製品開発とかである一定の規模のアプリを作ってみると痛切に感じることになる。自分も趣味でアプリを作っているときには、身にしみて感じることはなかった。

ただ、友達と話していて思うのは、ある程度以上の規模のアプリを作るといったときに、Rubyとかでそんな規模のものは書かないよねっていうこと。実際のところは、フロントエンドはそんなに規模が大きくならないから、Continuous taxそのものが小さいという可能性もあるというのは最近思うことがある。

さらに、実際のところは、CPANがあるからPerl使というのがPerlを使う殆どの理由だったりするということもあるわけで、シンプルな規模の議論だけをすると不毛な議論に陥ってしまう気もする。使えるライブラリの量が変わらず、ある一定規模以上になった場合には、静的言語で開発したほうがContinuous Taxというのは低い（or 殆どなし）というのはその通りなのだと思うのだけれど。

こういったContinuous Taxのような負債は、規模が大きくなればなるほどじわりじわりと効いてくるわけで、ライブラリ量などの前提条件も含めて、考えていくというのは組織で開発するという場合には、重要なことなんじゃないかと思う。