パスワードを忘れた? アカウント作成
この議論は賞味期限が切れたので、アーカイブ化されています。 新たにコメントを付けることはできません。

PHP、5.3 系のサポート終了が迫るも移行進まず」記事へのコメント

  • by Anonymous Coward on 2013年03月26日 15時11分 (#2350446)

    5.4の新機能の為に移りましょうよ

    traitがとても便利
    似非多重継承ができるのでオブジェクト指向言語としてなんとか許せるレベルになった感じ?(フレームの元?)
    trait型とかは使えないけど、まあ、PHPだし
    abstractメソッドとかは持てるし
    色々なクラスで使うメソッドをメンバで持たなくていいので記述がすっきり
    嬉しすぎてデバッグ系のメソッドまとめたtraitとか、メソッド結果キャッシュするtraitとか、
    DB結果編集によく使うメソッドまとめたtraitとかTool系のクラスを沢山traitに移植した
    privateフィールド名が被るとエラるのでtraitのprivateフィールドにベタな名前つけない点だけ注意
    (useで変更もできるけど面倒なので)

    後Arrayの砂糖さんが地味に便利
     Array() ⇒ []
     function (Array $arg = []){…}とか、
     private $m_option = [];とか

    パフォーマンスも上がってる
    処理にもよるけど10%~20%とか
    APCを使ってる環境だと何故かもっと上がるっぽい
    測っていないけど客からパフォーマンスチューニングしてくれた?とか聞かれる位、目に見えて速度上がった
    パフォーマンスチューニングで10%~20%とかあげるのは(元がダメダメなコードとかでなければ)どれだけ大変かと

    確かに変更点は多いけど、普通に5.3用に書かれたコードなら大体何もしなくても動く
    動かなくても殆どのケースでちょっと修正程度の事が殆ど
    古いライブラリで警告やエラーが出る事があるので、そこだけチェックして問題なさそうならさっさと5.4にするのがお勧め

    • by Anonymous Coward on 2013年03月26日 15時31分 (#2350455)

      > 動かなくても殆どのケースでちょっと修正程度の事が殆ど
      この「ちょっと修正」をしたくないからみんな移らないんだよね。

      親コメント
      • by Anonymous Coward

        新機能やSyntax Sugerとかを使うから、次のバージョンアップの際にさっそく仕様変更されて、また書き直す羽目になるんですよね。。
        そういう思いを何度もすると人は学習して、段々とガチガチのコア機能しか使わなくなってくるという

      • by Anonymous Coward

        しかもPHPの場合は「ちょっと修正」しなければならない場所を検出するのが、
        超めんどくさい。そこが最大の障害と言ってもいいくらいに。

        まず「コンパイル」がないから、コンパイル時のエラーでは変更点やバグを検出できないし、
        実行時エラーも一度実行しただけでは出るとは限らず、全パスの全ての組み合わせを
        網羅的に実行してようやくエラーが出る有様。

        さらに酷い時は関数や演算子の動作が変更されていて、実行したら結果は
        変われど、実行時エラーが出ずにすんなり動いてしまうことも。

        その結果、変更する部分が仮に本当に少しだけだったとしても、新バージョンへの
        移植とデバッグにかかるコストが膨大になる。

        • by Anonymous Coward

          PHP界隈には自動テストの習慣ってないんでしょうか?
          それとも、最先端のWeb開発ではテストを自動化するという流れはもう廃れてしまったのでしょうか?

          • by Anonymous Coward

            ないわけではないけれど、日本だと、
            「人月単価が安いから ≒ 低スキル技術者を使えるから」
            がPHPを採用する最大の理由だから。
            ユニットテストだなんて、そんな『高度なスキル』を駆使できる会社の方が珍しいかも。
            #そういう意味ではPHPは「最先端のWeb開発」じゃなくて、「時代遅れのWeb開発」なのです。

            そういう職場ではMVCフレームワークどころか、共通モジュールの切り分けさえ
            せずに、ガチガチに結合した単一のPHPファイルで書く人も多い。結果として
            テスト不可能なコードが量産されるので、ユニットテストどころの騒ぎでは無い。

            かといってPHPではフレームワークを使うと、今度はそのフレームワークが
            「フレームワーク Ver1はPHP5.0から5.2.xまでしか動きません。

          • by Anonymous Coward

            自分が作ったコード部分ならまだしも、他者が作ったライブラリやフレームワークについては、
            ユニットテストがあろうとなかろうと、変更する部分を検出することは困難。

            かりに判明しても、ライブラリがPHPの新しいバージョン用には提供されてなくて、差し替えようにも
            代替となるライブラリが存在しなくて、移行は断念せざるをえなかったり。運良く代替ライブラリが
            見つかっても、互換ではないために差し替えのコストがかなり高く付いたり。

            • by Anonymous Coward

              ライブラリやフレームワークについては、それぞれの開発者が検証をするのでは?
              言語のバージョンアップから検証が終わるまでのタイムラグはあるかもしれませんが、だからと言って利用されている現場それぞれで個別に検証するのはさすがに無駄過ぎるでしょう。

              • by Anonymous Coward

                >ライブラリやフレームワークについては、それぞれの開発者が検証をするのでは?
                理想としてはそうだと思う。
                でもPHP界隈における現実は違う。

                開発/サポートが打ち切られてPHP新バージョン用には提供されてなかったり、
                新しいバージョンで動くライブラリはあるけど互換性がありませんだったりは珍しくない。
                ライブラリの開発者だって、次々と互換性のない変更の入るPHP言語にウンザリしてるんでしょう。

                結果として結局は互換性の無いライブラリ間の移植作業や、
                ライブラリの独自カスタマイズが必要になる。

                >利用されている現場それぞれで個別に検証するのはさすがに無駄過ぎるでしょう。
                まったくその通りだと思います。

                それがPHPのバージョン間の移行コストが激しく高くなる原因の一つですね。
                #だからPHPなんて糞言語を採用するなとあれほど……。 orz

    • by Anonymous Coward

      > 古いライブラリで警告やエラーが出る事があるので、そこだけチェックして問題なさそうならさっさと5.4にするのがお勧め

      趣味でPHP使ってるならこんないい加減な判断でも何も問題ありませんが,
      業務だと有り得ない話ですね.

      • by Anonymous Coward on 2013年03月26日 15時54分 (#2350467)

        うん、おっしゃるとおり。
        でもサポートが終了した処理系を使うのも業務ではありえない
        ・・・と思うんだが、往々にしてありえるのが困るんだよな。

        親コメント
        • PHP は民間企業が延長サポートサービスしてたりするよ。

          アプリの工数100万なんて真面目にプロジェクト管理すると何もしないのと同じようなもんだから、
          その程度の金でセキュリティ対応できるなら安いという判断はありかもね。

          まぁ根本対応はPHPのライフサイクルか、互換性のどちらかをまともにする必要があるわけですが。

          --
          [Q][W][E][R][T][Y]
          親コメント
          • by Anonymous Coward

            PHPが使われてるような業界では、100万円ははした金とは言えないと思う。

            まともなプログラマを採用する気もない会社が採用する技術だもの。

        • by Anonymous Coward

          なんで有り得るんだろう?
          困ったらどうする?
          その辺を語らなきゃ、抽象的で無意味なグチですな。

          # 俺の周辺では無いのは救いだ

          • あり得るのは、移行コストが高すぎるから。特にPHP。

            困るのは、たとえば処理系のバグや脆弱性が見つかった時に、コミュニティに頼ることが
            できず自分で修正するしか無いこと。それを修正できる保証も無いし、仮にできたとしても
            時間も金もかかる。

            実際には移行するだけの人も金もないから使ってるんだし、おそらく修正は無理。
            綱渡り状態だよ。

            それを上司や経営者が理解してないのが最大の問題だな。

            親コメント
          • by Anonymous Coward

            別ACだけど、
            言語に対するサポートなんて飾りじゃないの?
            PHP本体がどれだけバグってようが、要は自分とこのユースケースでがっちり試験して
            その範囲だけでの動作保証を自ら行いさえすれば、言語のバージョンなんて上げなくてよくね?

            OSとかなら話は別だけど、PHPは実行環境そのものを不特定ユーザに開放してるわけじゃないじゃん。
            サポート切れてバグが放置されてたとしても、そういうバグがあると知ってさえいりゃあ
            ある意味バグも仕様なわけで。自分らで回避して作りこめばそれまでだよね。

            • by Anonymous Coward

              > OSとかなら話は別だけど、PHPは実行環境そのものを不特定ユーザに開放してるわけじゃないじゃん。
              ん?PHPは不特定ユーザからの入力を受けますよ?
              その中には、不具合を誘発する入力があるかもしれません。

              > サポート切れてバグが放置されてたとしても、そういうバグがあると知ってさえいりゃあ
              サポート切れたソフトに対してバグ探しをしてくれる人がいればいいですけどね。

      • by Anonymous Coward
        業務でPHPを使ってるなら、網羅的なテストスィートがあるはずだから、チェックも楽ちんのはずだよね。
    • by Anonymous Coward

      逆です。
      PHP終了のお知らせと解釈した方がいいでしょう。
      これまで使っていたところが、バージョンアップに反応していないんだから。

      • by Anonymous Coward

        バージョンアップに反応してないのは、作るだけ作ったけどメンテナンス体制が整えられてないサイトが多数存在するのではないでしょうか。PHPで作られているCMSも多いので、CMSを使ったコンテンツ作成はできるけどPHPはよくわからんっていう人は多い気がします。

    • by Anonymous Coward

      いや、もうPHPから別の環境に移行すれば?

      • by Anonymous Coward

        中小向けのWeb制作が触るサーバだと、Perlなんて5.8系がデフォです。

        いろいろ触れるところなら、Perlbrewなり何なりで自力で何とかなるんですが。

あつくて寝られない時はhackしろ! 386BSD(98)はそうやってつくられましたよ? -- あるハッカー

処理中...