アカウント名:
パスワード:
5.4の新機能の為に移りましょうよ
traitがとても便利似非多重継承ができるのでオブジェクト指向言語としてなんとか許せるレベルになった感じ?(フレームの元?)trait型とかは使えないけど、まあ、PHPだしabstractメソッドとかは持てるし色々なクラスで使うメソッドをメンバで持たなくていいので記述がすっきり嬉しすぎてデバッグ系のメソッドまとめたtraitとか、メソッド結果キャッシュするtraitとか、DB結果編集によく使うメソッドまとめたtraitとかTool系のクラスを沢山traitに移植したprivateフィールド名が被るとエラるのでtraitのprivateフィールドにベタな名前つけない点だけ注意(useで
> 動かなくても殆どのケースでちょっと修正程度の事が殆どこの「ちょっと修正」をしたくないからみんな移らないんだよね。
しかもPHPの場合は「ちょっと修正」しなければならない場所を検出するのが、超めんどくさい。そこが最大の障害と言ってもいいくらいに。
まず「コンパイル」がないから、コンパイル時のエラーでは変更点やバグを検出できないし、実行時エラーも一度実行しただけでは出るとは限らず、全パスの全ての組み合わせを網羅的に実行してようやくエラーが出る有様。
さらに酷い時は関数や演算子の動作が変更されていて、実行したら結果は変われど、実行時エラーが出ずにすんなり動いてしまうことも。
その結果、変更する部分が仮に本当に少しだけだったとしても、新バージョンへの移植とデバッグにかかるコストが膨大になる。
PHP界隈には自動テストの習慣ってないんでしょうか?それとも、最先端のWeb開発ではテストを自動化するという流れはもう廃れてしまったのでしょうか?
ないわけではないけれど、日本だと、「人月単価が安いから ≒ 低スキル技術者を使えるから」がPHPを採用する最大の理由だから。ユニットテストだなんて、そんな『高度なスキル』を駆使できる会社の方が珍しいかも。#そういう意味ではPHPは「最先端のWeb開発」じゃなくて、「時代遅れのWeb開発」なのです。
そういう職場ではMVCフレームワークどころか、共通モジュールの切り分けさえせずに、ガチガチに結合した単一のPHPファイルで書く人も多い。結果としてテスト不可能なコードが量産されるので、ユニットテストどころの騒ぎでは無い。
かといってPHPではフレームワークを使うと、今度はそのフレームワークが「フレームワーク Ver1はPHP5.0から5.2.xまでしか動きません。PHP5.3移行ではフレームワークVer.2を使って下さい。ただし、Ver1とVer2は互換性がありません。」みたいなこともしばしば。
ちょっと方向性は違うけど参考までに。「テスト不能な PHP コードをリファクタリングするための戦略」http://www.ibm.com/developerworks/jp/opensource/library/os-refactoringphp/ [ibm.com]#こんなのはマシな方です。もう疲れたよパトラッシュ。 orz
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
一つのことを行い、またそれをうまくやるプログラムを書け -- Malcolm Douglas McIlroy
さっさと移行するのがお勧めです(オフとぴ) (スコア:3, 参考になる)
5.4の新機能の為に移りましょうよ
traitがとても便利
似非多重継承ができるのでオブジェクト指向言語としてなんとか許せるレベルになった感じ?(フレームの元?)
trait型とかは使えないけど、まあ、PHPだし
abstractメソッドとかは持てるし
色々なクラスで使うメソッドをメンバで持たなくていいので記述がすっきり
嬉しすぎてデバッグ系のメソッドまとめたtraitとか、メソッド結果キャッシュするtraitとか、
DB結果編集によく使うメソッドまとめたtraitとかTool系のクラスを沢山traitに移植した
privateフィールド名が被るとエラるのでtraitのprivateフィールドにベタな名前つけない点だけ注意
(useで
Re: (スコア:1)
> 動かなくても殆どのケースでちょっと修正程度の事が殆ど
この「ちょっと修正」をしたくないからみんな移らないんだよね。
Re: (スコア:0)
しかもPHPの場合は「ちょっと修正」しなければならない場所を検出するのが、
超めんどくさい。そこが最大の障害と言ってもいいくらいに。
まず「コンパイル」がないから、コンパイル時のエラーでは変更点やバグを検出できないし、
実行時エラーも一度実行しただけでは出るとは限らず、全パスの全ての組み合わせを
網羅的に実行してようやくエラーが出る有様。
さらに酷い時は関数や演算子の動作が変更されていて、実行したら結果は
変われど、実行時エラーが出ずにすんなり動いてしまうことも。
その結果、変更する部分が仮に本当に少しだけだったとしても、新バージョンへの
移植とデバッグにかかるコストが膨大になる。
Re: (スコア:0)
PHP界隈には自動テストの習慣ってないんでしょうか?
それとも、最先端のWeb開発ではテストを自動化するという流れはもう廃れてしまったのでしょうか?
Re:さっさと移行するのがお勧めです(オフとぴ) (スコア:0)
ないわけではないけれど、日本だと、
「人月単価が安いから ≒ 低スキル技術者を使えるから」
がPHPを採用する最大の理由だから。
ユニットテストだなんて、そんな『高度なスキル』を駆使できる会社の方が珍しいかも。
#そういう意味ではPHPは「最先端のWeb開発」じゃなくて、「時代遅れのWeb開発」なのです。
そういう職場ではMVCフレームワークどころか、共通モジュールの切り分けさえ
せずに、ガチガチに結合した単一のPHPファイルで書く人も多い。結果として
テスト不可能なコードが量産されるので、ユニットテストどころの騒ぎでは無い。
かといってPHPではフレームワークを使うと、今度はそのフレームワークが
「フレームワーク Ver1はPHP5.0から5.2.xまでしか動きません。
PHP5.3移行ではフレームワークVer.2を使って下さい。
ただし、Ver1とVer2は互換性がありません。」
みたいなこともしばしば。
ちょっと方向性は違うけど参考までに。
「テスト不能な PHP コードをリファクタリングするための戦略」
http://www.ibm.com/developerworks/jp/opensource/library/os-refactoringphp/ [ibm.com]
#こんなのはマシな方です。もう疲れたよパトラッシュ。 orz