Q&A
チーム開発が契機なんでしょうか… これまであんまりチームで開発することが無いのが僕がcomposerにメリットを感じない理由のように読めます。
>これは山本五十六が残した名言の一節です。
>「やってみせ 言って聞かせて させてみて ほめてやらねば 人は動かじ」
僕が新技術を覚えられるように、 miyabi-sunさん、僕をほめてやってくれませんか…？
回答していて思ったのですが、やはり、そろそろ覚えなきゃダメでしょうか？
namespaceにしろ、yieldにしろ、traitにしろ、どれも必ずしも必要ないといういうか、無いと困るケースのほうが少ないかと思っています。というか、普通のシステムでは必要な時の方が極稀かなと。
だからPHP5.4以降にやっと追加されてるのだと思います。
でも、いい加減わかってないと「PHP使えます」とは恥ずかしくて言えない雰囲気が…。というか、質問者の断片的な情報から問題解決するのは難しい時があると感じました。
今からPHPやりますって人は、そういう、あんまり重要でない技術が使われたコードを意味もわからず勉強しなきゃいけないからかわいそうだなと思います。
autoloadとかも便利だけど、それはわかってる人が使うと便利だという話で、わかってない人だと、パスが通っているディレクトリに該当ファイルが無いとか、ファイル名とクラス名の規約から外れてるせいで読み込まれず「どうしてコードがあるのにエラーが出るの！？」となることも多いかと。
requireから始めて「おまえ、２回呼んだぞ！」って怒られてrequire_once（ちょっと遅いけど）を覚えたけど、もういちいちrequire_onceするのいやだー
という段階を踏んだほうがいいのではないかと思います。
composerも嫌いで、WEBでzipをダウンロードしてきて解凍してサーバに置いてパス通したら動いちゃう、というお手軽さがPHPの良さだったのに、まず、composerをインストールしなきゃいけないという風潮はあんまり優しくないと感じています。Windowsはcomposerそのもののインストールがやたらめんどくさいです。Windowsはcomposerに限らず多くの開発ツールのインストールがやたらめんどくさいし、仕様が変わって古い情報がつかえなかったりしてハマったりするし。一回インストールすれば後は良いかとおもいきや、職場が変わったらまた同じ苦労が再現されます。
前まではTwigはzipで提供されていたのに、最近はcomposerでインストールしないとならない、みたいになってしまってつらいです。PHPUnitのSkeletonGeneratorもPEARではチャンネルが見つからないため入らず、composer経由でないとインストールできなくなっていますね。
本当に、めんどくさい環境になってしまったなと感じます。
複数のライブラリを使おうとしたら、えらく奇跡的に自前のクラスとクラス名がバッティングしていて意味不明のエラーが出た、いいかげんこんなことでリファクタリングするのめんどくさい…
要求が複雑すぎて、単一継承じゃ賄いきれん…
莫大なループしたらメモリたらんて… どうしよう…
みたなケースって、10年以上開発してますけど、１回もありませんでした。
クラス名はよくありそうな名前を避けてればまずバッティングすることはないからnamespaceの有り難みはほとんど感じられません。
yieldの解説を見ると円周率が～とかフィボナッチ数列が～とか、普通の人はまず実務ではありえないのではないでしょうか。
traitは、昔ゲームを作ってたことがあるので、ちょっと便利かなとは思いますが、やっぱりそれ以外の実務で必要なケースは殆ど無いかなと。（業務システムとかで、そんな複雑な要求っていう時点でなんか間違ってるというか、かなり危険です）
PHPもかなり熟成されてきたのでありがたいですが、この辺りの機能って、みなさん積極的に使ってらっしゃいますか？
質問しないといつまでたっても質問者系のバッジが増えていかないので、日曜ということもあり、駄文を投稿してみました。よろしくお願いします。
回答3件
0
ベストアンサー
そんなことに悩んでいる内に、PHP 7が出ちゃってますよ。どうします？ PHP 6※すらわかっていないのに、いきなりPHP 7なんて、一体どう書けばいいのやら・・・
※ ご心配無く。こんなこともあろうかと、PHP 6は歴史から抹消しておきましたぜ！
冗談はさておき、PHPについてだけの話をすると最終的にdisちゃいそうなので、一般的な各言語共通で私の意見を述べたいと思います。言語の機能の話でしていますが、パッケージ管理などのライブラリについても同様だと思っていただければと思います。
###新しい機能は積極的に採用すべきか？
開発が停止していない限り、プログラミング言語は常に進化しています。どんな言語であれ、人間が作る物ですから、最初から完璧な物はありません。もっとこんな機能が欲しい、こんなできると便利だ、こういうのがあればもっと簡素に書ける、と言う事を誰もが思い始めます。また、単なる機能の追加だけで無く、安全では無い機能は、より安全な機能に置き換え、将来的には古い機能を削除してしまおうと目論みます。これには終わりがありません。どこまで追求しても完璧などないからです。
こうして、新しいバージョンが出る度に、新しい機能が追加されます。問題はそれらを採用すべきかどうかです。私は採用にあたり、次の視点に立つべきだと思います。
- 環境が整っているか？
新しいバージョンが安定して動作しなければ意味がありません。ただ、この問題は時が必ず解決してくれます。これを言い訳にして新しいプロジェクトで採用しないのは、最初の数ヶ月〜数カ年(言語や環境による)だけです。
- 何のための追加か？
機能の追加の理由には大きく分けて二つあります。
- 単に書き易くなっただけ
- より安全なコードを書けるようになった※
※ ここでの「安全」とは、セキュリティ向上も含みますが、それ以外にもバグを発生させにくいといったこと含まれます。
最初の1.の理由だけであれば、積極的に採用する価値はあまりありません。ただし、新しい機能を使った書き方でコードがわかりやすくなり、保守性が上がる場合は、2.の意味も含まれる場合がありますので注意が必要です。一般的に「簡素に書ける」→「コードの意味がわかりやすい」→「保守がしやすくなる」→「バグが出るような間違った書き方をしにくくなる」傾向があります。
問題は2.です。これは今までの書き方では色々と問題が多かったために採用されています。セキュリティ向上やバグの防止のためにも積極的に採用すべきです。また、これによって古い書き方は将来的に廃止される可能性が高いです。廃止されてから急いで対応するのでは無く、積極的に採用し、事前に対応しておく方がいいと思います。
- その機能にメリット・デメリットは？
時々ですが、メリットがほとんどなく、逆にデメリットがあるような機能が追加されるときがあります。地雷のような機能ですので、もちろん使いません。デメリットが判明するのが追加されてからしばらく経ってからと言うのがありますが、環境の問題が解決される頃には、だいたい評価が見えてくるので、それほど大きな問題にはなりません。
以上を踏まえて、今から書くコードで採用するかどうかを決めます。基本的には最初の環境さえ問題なければ、デメリットが無い限り、積極的に採用する場合が多いです。ほとんどの場合において、書きやすい＝安全になる、と思われる機能が多く、採用しない理由があまりないからです。
###teratailでの回答の時はどうすべきか？
私がteratailの回答の時に一番気をつけているのは、安全なコードを書くことです。コードが安全になるのであれば、積極的に新しい機能でも採用します。初心者は最初に教えて貰った物をとりあえず使い続けます。例えそのコードが古い環境で動かなくても、危険なコードが動いてしまうよりはましだからです。
あとは、わかりやすいコードになるかどうかを重視します。新しい機能だから使わないという選択肢は、質問者がバージョンを指定しない限りすることはあまりありません。
色々書きましたが、単純に新しもの好きというのがあります。新しい機能というのは、例えなくても同じような動作を古い書き方でさせることは出来るでしょう。でも、それぞれそれなりに追加された理由があるはずです。今自分にとって必要ないから使わないというのはあまりお勧めできる判断基準ではありません。追加された理由をきちんと吟味してみることが大切かなと思います。
ただ、PHPは「他の言語がこうしているから、とりあえず足そう」って傾向が強いんですよね。機能ばっかり肥大化していって、言語としての整合性がとれているのかよくわからないものになっちゃっているような気がします。そんなんだから「PHPは初期のPerlが犯した過ちを、Perlよりゆるやかに進めているといえます。」とかいわれちゃうんかなと。おっと、やっぱりdisちゃった。
投稿2016/01/17 04:11
総合スコア21741
0
composerも嫌い
私もcomposerを初めて触った時に全く同じ事を思いました。
composerを見直したのは、npm(node.jsのパッケージ管理ツール)を使い始めてからです。
パッケージの依存関係をテキストファイルで持ってるというのはかなり強いメリットです。
毎回自分のプロジェクトのgitなりSubversionに入れてるとどんどん無駄なファイルで肥大化していきますしね・・・
今はVagrantやDocker、プロビジョンツールのAnsibleやChefなんか出てきてますが、
これらはサーバーのあるべき姿をテキストファイルで持てます。
究極git cloneでファイルをダウンロードした後に、
vagrant upコマンド叩いて待ってるだけで、ファイルを含めたローカル開発環境の構築が全て終わりということも十分可能です。
こういったスキルを前任者が持っているってのは後輩や後々ジョインするメンバーにとってとてもありがたい事なので、
自分自身で得してる気は全く無いのですが、リーダー的な役割を担う人間が勉強していくべき知識かなと思います。
namespaceにしろ、yieldにしろ、traitにしろ、どれも必ずしも必要ないといういうか
感覚としては共感です。
よほどの天才以外は「困った→調べる→へーこんなのあるんだ→すげー！」というプロセスを踏んで初めて覚えるものなので、
他人から「こうやれ」と押し付けられても覚えられないです。
teratailなんかでも良いコードでも新しい概念や難しい概念を使うと読み飛ばされるので、
あえて古い技術で書きなおしている箇所もあります。
ただし、プロジェクトで使うケースを考えると話が変わってくるかなと思います。
プロジェクトではどうすればいいのか？
これはまだまだ私も試行錯誤の段階ですが、
山本五十六が残した名言の一節です。
「やってみせ 言って聞かせて させてみて ほめてやらねば 人は動かじ」
「話し合い、耳を傾け、承認し、任せてやらねば、人は育たず」
結局自分も後輩も、やった分しか成長出来ません。
分かってない人の為だけに古い技術を使うという選択肢はバッドノウハウに繋がりますし、
いざ、その新しい技術を使うべき場面に遭遇しても、練習してないからやっぱり古い書き方で…となるのは目に見えてます。
後輩コードをレビューする時に、一番その後輩の成長の道を閉ざしてしまうのがそれだと思ってます。
自分の腕や感性も錆びついちゃいますしね…
新しい技術は一度は使ってみて、自分の感性で見極めた方が良いです。
次はよりかっこよく使えそうなら工夫してみるのも良いと思います。
投稿2016/01/17 04:54
編集2016/01/17 05:00
総合スコア21384
>毎回自分のプロジェクトのgitなりSubversionに入れてるとどんどん無駄なファイルで肥大化していきますしね・・・
必要なライブラリごとリポジトリに突っ込んでるっていうのはダメ運用なんですね…
>必要なライブラリごとリポジトリに突っ込んでるっていうのはダメ運用なんですね…
私は突っ込めるものは突っ込みたいです。
パッケージマネージャで外部のリポジトリから取ってくると、今日取ってこれたライブラリと同一のものを明日も取ってこれるという保証がなくて心配だからです。
git cloneした後に毎回パッケージマネージャのコマンドを打つのもなんかムダだなあと感じます。
>今日取ってこれたライブラリと同一のものを明日も取ってこれるという保証がなくて心配
その心配は共感します。
＞チーム開発が契機なんでしょうか
人は状況に応じた考え方をすると思うので、
必要なければ勉強しないでいいと思います。
＞必要なライブラリごとリポジトリに突っ込んでるっていうのはダメ運用なんですね…
バージョン上げるべきなのか、維持するべきなのか…他のプロジェクトでも同じの使ってるのか…様々な検討をした後に、
結果Gitのリポジトリに入れるのは選択肢としてはありだと思います。
ただ、後々ジョインしたり、保守する時、もしくは作業PCの引っ越しに備えて、
どの道使ってるライブラリのバージョンはどっかに記載しておく必要はあると思います。
composer.jsonに書きますか？
README.mdに書きますか？
はたまた毎回そのフォルダにアクセスしてバージョンを確認しますか？
リポジトリに混ぜる場合でも、composer.jsonでインストールした軌跡を残しておくと後々助かるケースがあります。
マイナーバージョンが上下すると使えるメソッドが増えたり減ったりするケースもありますしね…
> 今日取ってこれたライブラリと同一のものを明日も取ってこれるという保証がなくて心配
ComposerとPackagistは別物なので、自分で管理するComposerのサーバーを立てる等で工夫は出来ます。
因みにライブラリ関係でDL出来ない悲劇を経験した事はないです。
「本番環境が5.1で動いてるから、メソッド足りなくて動かん、ちゃんと検証しろ！」
…と怒鳴られてもPHP5.1なんてどうやって手に入れるの(in 2013年秋)…と途方にくれたことならありましたが…
結局エラー吐いてるメソッドはPHPマニュアル見ながら修正して、検証は5.3でゴリ押した経緯があります。
プロジェクトによって維持すべき項目ってのはありそうなので、
優先順位に応じてって感じになるんでしょうね…
＞僕をほめてやってくれませんか…？
褒めはしませんが、彼女ならあげます
https://paiza.jp/poh/ando
>どの道使ってるライブラリのバージョンはどっかに記載しておく必要はあると思います。
>composer.jsonに書きますか？
>README.mdに書きますか？
>はたまた毎回そのフォルダにアクセスしてバージョンを確認しますか？
/libraries/Twig_1.23.3/本体
ってします。すいません、殴ってもらって構いません。
>「本番環境が5.1で動いてるから、メソッド足りなくて動かん、ちゃんと検証しろ！」
>…と怒鳴られてもPHP5.1なんてどうやって手に入れるの(in 2013年秋)…と途方にくれたことならありましたが…
それが一番怖いので開発にあたってはまず、本番環境のPHPのバージョンを確認しています。
>褒めはしませんが、彼女ならあげます
ここの
http://next.rikunabi.com/tech_souken/entry/ct_s03600p002412
PHPちゃんの方がおっちょこちょいっぽくて、かわいいです…
Windowsのつらさって、
>…と怒鳴られてもPHP5.1なんてどうやって手に入れるの(in 2013年秋)…
みたいのもありますよね。
これがLinuxとかだとググりまくれば野良なソースが見つかって、コンパイルできたりするんですが…
話の趣旨はその通りと思いますが、
http://php.net/releases/
一応、PHP5.1はソースもWindowsのバイナリもダウンロードできるみたいです。
>一応、PHP5.1はソースもWindowsのバイナリもダウンロードできるみたいです。
いいね！ いや、逆によくないかも…
>話の趣旨はその通りと思いますが、
と、いうことは、http://next.rikunabi.com の PHPちゃんの方が可愛いということにもご賛同いただけるということですね？
0
これは個人の置かれている状況（チームメンバーの数、自分がアーキテクチャを決定できる立場にあるかなど）によるので、あくまで私の場合で回答させていただきます（新仕様をバリバリつかっている既存プロジェクトに入るときは当然覚えないといけませんよね）。
個人的には同感です。namespace、yield、traitどれも無くても私自身は困りません。
この辺は汎用性の高いライブラリをスマートに実装するときに欲しくなるものだと思います。
必要性を感じていないので、勉強もしていません。
「PHP得意」と言うのがためらわれるのもまったく同じように感じています。
しかしね、今フロントエンドやインフラの方で新技術登場のペースが早いし覚えなければいけないことは無数にある。新しいものを把握していないと焦りだしたらキリがないと割り切りました。
autoloadは便利で前使っていました。composerは確かにちょっと面倒臭さを感じますね。
namespaceは自分では使わなくても、ライブラリではきっちり使っていて欲しいです。
投稿2016/01/17 02:53
総合スコア196
ありがとうございます。
>namespaceは自分では使わなくても、ライブラリではきっちり使っていて欲しいです。
同感です。この機能はライブラリのような汎用コードを作る人が使う機能だと考えています。
あなたの回答
tips
プレビュー
バッドをするには、ログインかつ
こちらの条件を満たす必要があります。
退会済みユーザー
2016/01/17 04:21
2016/01/17 05:20
退会済みユーザー
2016/01/17 05:26
2016/01/17 05:33
退会済みユーザー
2016/01/17 05:41
退会済みユーザー
2016/01/17 05:55
退会済みユーザー
2016/01/17 06:13