もうおまえらPHPerは正規表現をブログにうpするんじゃねえ!
と言われても仕方がないと、404の人が書いてらっしゃいます。
実を言うと、私も正規表現は苦手です。正直言って、いろんな勘違いをそのまま公開している口なので、もうそこは「ごめんなさい」としか言えません。*1
個人差のある問題なのに、PHPerはと言われてしまうとき、うーん、当たってると思ってしまいます。
正規表現の学習にはダメ出しが役に立つ
本質的にはメッシーな正規表現を素で書ければいいのですが、難しいです。多くの才能ある人でも、大概は多様な学習の成果として経験を積んでいるように思います。正規表現はある典型的なパターンを書くのは簡単でも、書き手の想定から漏れが生じて問題を引き起こすので、どんなケースで問題が生じるのかという嗅覚のようなものが必要になると思います。そんなわけで、おざなりに学ぶのは簡単でも、正確な正規表現を書ける実力を付けていくには、互いにダメ出しして問題点を抽出するという習慣が有効な気がします。
個人的な問題なはずなのに、PHPerはというひとくくりにされても抗えない理由がPHPer周りの環境にはあるかもしれません。
PHPerはダメ出ししない傾向が
ライブラリやCMS等製品として公開されているようなものでも、いいかげんな正規表現をみかけます。それがわかっていても、PHPer(あえて言えば"日本のPHPer")はあんまりダメ出しをしないのかもしれません。運用上困った時だけバグレポートを上げるというケースが圧倒的なような気がします。モヒカン族なんていう造語http://ja.wikipedia.org/wiki/%E3%83%A2%E3%83%92%E3%82%AB%E3%83%B3%E6%97%8F_(%E3%83%8D%E3%83%83%E3%83%88%E7%94%A8%E8%AA%9E) がありますが、この点ではモヒカン族の掟の方が技術向上には一役買えると思います。コミュニティの技術力を底上げするには、メンバーのダメ出し力、そしてダメ受け力の向上が必要なんじゃないかと思います。
なぜダメ出しが必要か。
人は学習するときに何らかのリソースを参考にします。
古い技術者は限られたリソースから学習するために、古書や試行錯誤をするしかなかったわけですが、そんな折、最も成長できたのは、チーム内の切磋琢磨、お互いに間違いを指摘しあって問題を討議するという雰囲気だったような気がします。
正規表現は上で書きましたが、自分で検証しても不十分で別な視点からの指摘を受けると、新しい見識が開けるようなところがあります。なので古い技術者からすれば他人の指摘は、本当に心から「ありがとう」という気持ちでいっぱいになる話だったわけです。
ところがPHPerは多くをネット上の記事から学びます。互いに指摘という精神的にメンドクサイ習慣よりもてっとり早く初歩的な事象を学ぶことができます。まぁ、その分バッドノウハウが流れやすいわけですが・・・*2そのため、相対的にですが、他人の指摘は快く受け取られないような気がします。
OSSの現状
OSSプロジェクトだと間違いを指摘するぐらいだったら、さっさと直してコミットすればいいじゃん、な話が出ることがあります。確かに目先のソースは修正されるかもしれませんが、技術力を高めあうことができません。修正してコミットする義務なんてないのに、指摘する側にはそれを求めるという反訴的行動がとられることがよくあります。そういう雰囲気に対して、指摘力のある人は去ってしまうのではないかと思います。
正規表現に限らず、技術力をつけていくためのきっかけを失ってしまいます。
PHPerの構成
PHPerの特徴として純粋な技術者層が薄い割に、非常にカジュアルな動機で書いている層が相当あるように思います。
そういった層では技術的向上に対するウエイトが低く問題の指摘の相対的価値が理解できず、技術的な指摘と個人的な中傷とを混同してしまう確率が一定量あるようなのです。指摘と中傷を識別できる人たちであっても、識別できないメンバーがコミュニティにあれば、コミュニティの雰囲気を悪くする可能性があるなら、その原因を排除しようという動きに対して抗えないという特徴がありそうです。
そのため、技術者だけがコードを書いていた、（もしくは書いている）言語と比べると、PHPerのコミュニティの方向性は非技術指向になりがちです。最近でこそ、JavaやC++などからの流入組が結構いるようなので情勢は少しずつ変わってきているような気もしますが。
PHPは廃れるのか
それでは、PHPerの技術力は向上しないのか？それはNOで。ここまで書いてきたことと逆行してしまうのですが、モヒカン族的やり方が技術力向上という一側面でだけはベターな選択だとしても、そこに人が棲むことができなければコミュニティは育たないということだと思います。モヒカン禁止なコミュニティであっても、構成因子のそれぞれの力や成長力が弱くても、他の要因によって総体としてゆるやかに成長することは可能だからです。また、雰囲気を壊さずに技術的指摘を行える「才能」の持ち主がけん引しうるからです。
コミュニティの運営は
Drupalの日本公式のフォーラムを見ていると、かつてのいじめっ子を今度は逆にいじめ返すという、まぁよくあるパターンになっていっているような気がします。正義の履き違えによって生じる宗教論争のような・・・どちらが正しいとは一概には言えないと思うのですが、片方に属するとそういう目は失いがちです。
OSSプロジェクトを成功させていくために、もしくは中途で大きな混乱を招かないためには、創立して間もない時期からそういったことも想定した雰囲気作りをして、なんらかの意思表示をしておく必要があるような気がします。セキュリティ上の問題点の指摘の仕方、ソースコード上の問題点やバグの指摘、アーキテクチャ上のよりよい構想について話をするときの方法論、そういうものを早期にまとめておくとよいのかもしれません。
ここで言うゼロトレランスとは、そんな振る舞いを決して見過ごさないということです。 たとえば、技術的なコメントといっしょに プロジェクトの他の開発者に対する個人攻撃 (ad hominem) を含むコメントが投稿されたとしましょう。そんな場合は、まず その個人攻撃に対する指摘をしたうえで、技術的な内容についてはそれとは分けて返答するようにしましょう。
http://producingoss.com/ja/setting-tone.html#prevent-rudeness
オープンソースソフトウエアの作り方
とても参考になります。
