プログラミングテクニックの問題なのか?

まあ、だいたいあってると思う。こういう記事も書けるんだこの人。

以下の三つの「迷信」が挙げられている。

  1. 「変数のスコープは狭いほど良い」という迷信
  2. 「同じロジックのコードを2度以上書くな」という迷信
  3. プログラミング言語を極めるのが大切」という迷信

1 は「狭いほど良い」とまで思ってる人はあんまりいないと思うが。。。protected でも困らなさそうな場面でもとりあえず private みたいなのはよくある。でもこれって2で出てくる予見可能性に対する謙虚な態度の一貫としてやってることだったりするんだよね。問題が出た時点で担当者間のコミュニケーションで調整できるならそれでいいと思う。

でも public になってなくて困るというのはプログラミングテクニック以前に設計上問題あるんじゃないかなー。アクセス指定は「俺の実装はここまでしか想定してませんよ、想定外の状況に責任もてないから制限するよ」っていう宣言みたいなものだと思えばいい。プログラマの思い違いでもないなら想定すべき状況を想定していないのは設計が甘いということ。システムの輪郭がはっきりしてなくて、モジュールの担当者毎に違った輪郭が思い描かれているのでしょう。


2 は悩ましいところ。下手に纏めると修正時にデグレードの原因になるというのは本当にそうだけど、これは纏めないと修正漏れが出るというのと本質的に表裏一体。組み込み系で新機種対応とかでコードをメンテする時にいつも悩む。というか怖いときは新機種だけで実行されるようにコピペしたコードを修正するな。旧機種全部でリグレッションテスト徹底できるほど余裕ないし。でもそれはむしろ、余裕が欲しい、というのが本音。


3 が迷信というのは間違いじゃないけど微妙。言語固有の知識で、知ってると知らないじゃ生産性が何倍も違ってくるようなものはないわけじゃない。ただ、なんでもそうだけど、学習が進めば進むほど学習コストに見合うだけの効果が得られなくなるので、「極める」という行為は基本的に贅沢な行為だ。みんながやるべきこと、目指すべきことではない。プロジェクトに一人くらい「極めた」人がいて、みんなでその人を尊重する、くらいがいいんじゃないか。


全体に、外部要因との兼ね合いで原則を外さなきゃいけない場面で「プログラミング」の原則に固執することを諌める内容だと思う。そういう意味では三つの「迷信」はプログラミングテクニックとしてマズいわけではなくて、プログラミングはものづくりのプロセスの一部なんだという自覚が大事なんじゃないか。ただ、三歩引いた目で見るなら、プログラミングの原則を曲げなきゃいかんような事態が発生するのはプロセスそのものに問題があるんじゃないかと疑う必要はあるかもしれない。予見可能性に対する謙虚な態度という意味でも、原則を曲げることが禍根を残す可能性を恐れるべき。