PHPコーディング規約だって

忙しくなってきたので現実逃避気味。

株式会社 社会式株 PHPコーディング規約

ネタ的だけど、ちょっと思うことを書いてみる。

小規模限定 PHPは1人月程度以下の規模でしか使用しない。より大きな規模のシステムでは、Ruby On Railsを使用する。これにより、PHPの利点を最大限に引き出す事が可能となる。

やや同意。
せいぜい2~3人月か。
RoRではなくて、Java + Servletという選択肢もあるだろう。
ただ、2~3人月規模の案件は結構あるのでこれはこれでいいと思う。

ツールはなるべく使用しないという事


せめて、SmartyPEAR::MDB2 ぐらいは使おうよ。
ただ、このへんの習得に時間がかかるのであれば、そもそもプログラマ向いてない気がするが。

そんな時間があるなら、もっと他に学んで欲しい事は山のようにある。RoR、構造化HTML、CSSJavaScriptAJAXLinux、ネットワーク、セキュリティなどなどなど

向いてない人が色々覚えても意味がない。
一点突破するしかなくね?

自動テスト

ああああ、気になったところしかやってない。。。

PEAR

自分でコードを書くぐらいなら、まず探せ、と。

オブジェクト指向禁止 もし君がオブジェクト指向プログラマであれば、PHPのオブジェクトシステムは「いけてない」という事に同意してくれると思う。PHP4とPHP5では大きく変わるし、所詮後からとってつけた機能だし。

おそらく、さくらインターネットがPHP5対応になった時点でPHP4の出番は今後激減してくると思われる。
ただ、Javaと異なり、クラス構造やオブジェクトをメモリプールできるわけでなし、動的型付けな為、エディタの補完機能を頼れる訳でなし、過剰なデザインパターンに走っても仕方ないのがPHP

ライブラリ禁止

前段にも絡むが、「自作ライブラリではなくPEARなどを積極的に利用する」のであれば同意。
自作ライブラリであれば、その使用方法の伝達に作成者のコストがさかれるが、一般化されているライブラリであれば、使用方法もネットに転がっていたりするので、「ドキュメント探して調べろ」の一言で済む。

HTMLとPHPコード(ビジネスロジック)の分離

Smarty使っとけ。
DB部分を MDB2 のラッパーで対応し、クラス化しておけば、必然的に MVC 構造になる。
ただ、機能がせいぜい1つとかであれば、オール PHP ファイルでエイヤでやってしまっていいと思う。

ファイル構造は単純に

個人的には config.inc みたいな設定用PHPを一つ作っている。
ディレクトリ等の設定はサーバ毎に変えている。
あと、必要な共通機能はほとんどクラス化しているので、ちょっとした関数はそこに書いてしまっている。

曖昧模糊としていること。

色んなことを幅広く覚えて、他の仕組みのよいところを取り入れる必要がある反面、
会社としては得意な開発手法や領域を絞るべき。
(中小企業に限定されるかもしれないが)
PHP(でもJavaでもRoRでも)ばかりやってきた企業とPHPJavaRoRも.NETもやっている企業のどちらが安心できるかと言えば、集中による技術の高さが期待できるので前者かな、という気がする。
「なんでもできる」ということは技術が再利用しにくい感じで偏在しているこということである。
「この間の仕組みをそのまま再利用」ということが可能になれば、開発の生産性は飛躍的に増大する。
全ての初期開発が実際には「改修作業」となるから。
「言語間の生産性の高さ」など「熟練度による生産性の高さ」に比較するとちっぽけなものだ。
「なんでも自社内でできます」というのはジリ貧に陥る可能性が高い。
というか、「熟練度による生産性の高さ」を有した企業とコスト競争をしているということを自覚するべき。