PHPのプロジェクトで気をつけてる(たい)事 - どうにもならない日々@mkkn

プロジェクトが一発終わりそうなんで。反省も込めて。

あとでちゃんと整理してまとめよう

　とりあえずこれがないと話にならん。名前空間使うかどうかは別にしてもだ。アンスコのディレクトリ分けも必須。

　PQPとかね。大事よ。常にデバッグ可能な形で。TDDとかまだまだ現場に浸透してないからこういう工夫は地味にきいてくる

　デバッガログを吐くかどうかにもよるけど、この辺さっさと決めといて…ってのも結構重要だったり。あとなんでもかんでも1メソドでやらない。ログの種類ごとに別メソドで。仕様変更で死ぬ。

　ConfigとかLangとかはどこから参照してるか曖昧になるから危険。これらは直接アクセスできないようにしてしまうべきだわ。んで別途アクセサを準備。この流れは必須。

　env_is_development関数マジで便利。こういうのは大事にしときたい。

　あとはこうなんかセッションとかでこっそり環境変数変更できる仕組みとかほしいよね。ステージング中のバグ解析とか面倒だし。もちろん,本番では動かないような仕組みで。

　定数値はしっかりConstしましょう。欲を言えばConst系クラスとしてクラス定数で宣言。もっと言えば静的private変数で宣言してgetterのみ提供。getterっていうか、is_xxx()系メソドね。毎回比較演算子使うのはナンセンス。

　つーかBeansの概念の偉大さが今になって理解できるようになってきた。

　コントローラは許容500行。1メソド許容10行。これはもう絶対だわ。まぁコントローラにかぎらず、なんだけどさ。

　このへんも大事よ。fuelのCrudみたいに一緒になってる時は継承とかトレイトとかで分離する。selectとかupdateとかみたいな抽象度の高いメソドをpublicに出さない。DBアクセスの外部公開には必ずデータ取得/操作の目的を明示的に付与する。

　極力外部化。仕様変更はDRY信仰の心を悉く挫いて行くけど、それでもめげない、諦めない。しっかり外部化は続ける。大事なのはコードの分離と構造化。仕様変更でごちゃごちゃになるのはそのへんが出来てないのが原因。客のせいじゃない

　クロージャのが色々と融通聞く気がする。特にスコープ周り。関数のメリットがわかんない。あ、メソドと関数は別、だからね。

　もうtry catchしましょう。そのほうが楽だ。

　これはほんとにね。色んな所で助けてくれる。ステージングのギリギリまで有効にしとけば,環境系エラーの追跡にも役立つ。

　SetEnv でproduction設定するなら,FW外にデプロイテスト用のスクリプトも用意しとくといいかも。ステージングデプロイ時にエラーで何がなんだかわかんない、なんて事になった時用にtest.phpが上手く作用してくれることを期待しての措置。

　docRootに直置きしてもいいし,FWのbootstrapファイルからrequireしてもいい。

とりあえずこんなトコロかなぁって。