A Day In The Boy's Life -22ページ目

A Day In The Boy's Life

とあるエンジニアのとある1日のつぶやき。

composerには、composerでインストールしたパッケージを呼び出すためのオートローダー機能を備えています。

これは何もcomposerでだけ使えるというわけではなく、自分たちで作成したライブラリなんかもこのオートローダーを使って自動で呼び出せたりす るので便利です。


もちろん、クラスファイルのオートローダーを実装する で書いたように、自前のオートロー ダーを作成することもできますが、ライブラリのパスが固定になったりPSRなどのコーディング規約に沿ったファイルパスを使いたいといった場合 に作りこむのが手間だったりもします(そういうサンプルは公開されてたりもしますけど)。



PSR-0に準拠したクラスファイルをオートロードする


ってことで、composerのオートローダーを使って自前のライブラリを呼び出すための手順です。

マニュアル に書いているように、オートロードする には幾つかの方法が存在します。

まずは、PSR-0に準拠したライブラリパスで呼び出す方法です(ComposerはPSR-4にも対応しています)。

composer.jsonに下記のように名前空間とクラスファイルが置かれたパスを指定します。


{
  "autoload": {
    "psr-0": {
        "Foo\\Bar\\": "/path/to/lib/"
    }
  }
}

PSR-0の規則に沿うと上記の場合は「/path/to/lib/Foo/Bar/」内にあるディレクトリがオートロードされます。

パスは相対パスでも記述できますが、その場合はcomposerのルートディレクトリ(composer.jsonやvendorディレクトリが存在するディレクトリ) から見たパスとなります。

また、パスは間違っていたとしてもcomposer updateで再構成した際にエラーなどは出ないので注意が必要です。


{
  "autoload": {
    "psr-0": {
        "Foo\\Bar\\": "../../lib/"
    }
  }
}

composer updateを実行するとオートロード用のファイルが更新されます。

具体的には、vendor/composer/autoload_namespaces.phpに先ほどの名前空間とそれに対応するパスが配列に追加されます。


<?php

// autoload_namespaces.php @generated by Composer

$vendorDir = dirname(dirname(__FILE__));
$baseDir = dirname($vendorDir);

return array(
    'phpDocumentor' => array($vendorDir . '/phpdocumentor/reflection-docblock/src'),
    'Foo\\Bar\\' => array('/path/to/lib/'),
    'Symfony\\Component\\Yaml\\' => array($vendorDir . '/symfony/yaml'),
    'Log' => array($vendorDir . '/pear/log'),
);

自前のオートローダーをどうしても作りたい場合は、上記のファイルからごにょごにょしてもよいかもしれません。

余談ですけど、オートロードのファイルだけを更新したい場合は


$ composer dump-autoload

とするだけでもいけます。



独自のクラスファイルをオートロードする


続いて、PSRに準拠していないクラスファイルを読み込みたいという場合ですが、Classmapという仕組みを使うことができます。


{
  "autoload": {
    "psr-0": {
        "Foo\\Bar\\": "/path/to/lib/"
    },
    "classmap": [
      "/path/to/another/lib/",
      "Foo.class.php"
    ]
  }
}

Classmapは単純に読み込みたいディレクトリを指定するだけです。

Foo.class.phpのようにダイレクトにファイル名を指定することも可能です。

Classmapの場合は、composer updateまたはdump-autoloadを実行するとvendor/composer/autoload_classmap.phpに情報が出力されます。


一応、特定のファイルを読み込みたいという場合はfilesという項目も存在します。


{
  "autoload": {
    "psr-0": {
        "Foo\\Bar\\": "/path/to/lib/"
    },
    "classmap": [
      "/path/to/another/lib/",
      "Foo.class.php"
    ],
    "files": [
      "Bar.class.php",
      "Hoge.php"
    ]
  }
}

こちらは特定のファイルを読み込むように書くだけですが、classmapでも対応できるので正直なんであるのかよくわかりません。

オートロードが完了したら、composerのautoloader.phpを読み込んであげれば自由に使えるようになります。


<?php

require_once 'vendor/autoload.php';

$obj = new Hoge();
$obj->bar();

自前で用意するよりも柔軟に管理ができたりもしますので、オートロードは全部composerにお任せというのもありかもしれません。





入社したての頃はそれまでと比べて社会人としてのルールやスタイルなどの違いや、仕事のやり方などに様々な疑問や不明点というものが出てきます。

ただ、そういったことは社会人の経験を重ねるとともに忘れていったり、そもそも疑問にすら感じなくなってきます。

理由は、要領を掴むことで応用が利くようになったり、慣れによって感覚が麻痺してしまうからでしょう。

 

それはある意味成長なのかもしれませんが、同時に視野が固まったり考え方が偏っていることでもあります。

 

要は一般的な社会の一員に染まってしまうということです。

 

 

疑問を残す

 

 

 

自分の部署では新入社員が入ると、仕事において疑問に感じたことをメモしてもらうことをしています。

 

まぁ、一般的なことではあるんですけど自分のノートにまとめるんじゃなくてデータで残すというようなことをしてます。

 

それは、例えばわからない技術的な専門用語であったり、仕事でよく使うような略語であったり、仕事のルールであったりと様々なのですが、そうしている理由は入社したての右も左もわからない状態からあとで見直してみるとそんなこともわからなかったのかという成長の軌跡を実感してもらうためであったりするのですが、それは表向きのものであって実際の効果というのはそんなに高いようには感じていません。

 

何故なら途中で実務が多くなるにつれてメモをする余裕がなくなってきたり、詰め込みの教育の現場からすぐに答えが出されて自分で調べるという時間が与えられなかったり、過去の記録を見返すという行為自体をしなかったりするからです。

 

本当の狙いとしては、わからない人の視点というのはどういったものかを実感して欲しかったり、過去の自分も含めて視野レベルが違う人がいるという認識を持ってもらうことにあったりします。

 

それは、仕事において人と話すときに相手の知りたいポイントを探ったり相手のその分野においてのレベル感を量るときに役立ったりします。

また、実際にわからない人の視点というのは結構貴重だったりもするわけです。

わかる人になってしまったときに、わからない人の何が困っているのかがわからなくなります

そして、多くの製品やサービスというものは困っている人やわからない人に届ける物が多かったり、最初に触れるものへの抵抗感を限りなく低くすることというのは重要だったりもするのですが、過去のわからない頃の自分の中にそのヒントが埋もれているかもしれません。

 

だからこそ、わかる人になってしまう前にわからない頃の自分の考えや思いの断片を残しておくというのは大切なんじゃないかと思うわけです(まぁ、あとから見直したら結構恥ずかしかったりもするんですが)。

 

 

 

ギャップを知る

 

 

 

過去の自分を見つめなおす機会は今の自分とのギャップの確認でもあります。

 

それは、過去の時点で想像していた未来の自分と現時点の自分とのギャップでもあります。

こういったギャップを確認するというのは仕事においてもよくあることで、特に失敗しそうな(した)時にAsIsとToBeとのギャップを分析することは大事だったりもします。

 

ギャップを知るにははっきりとした基準が必要で、今の自分というのはいつでもはっきりしていますが、過去の自分というのは記憶から薄れていくとどんどんとぼんやりしていったりします

 

特に社会に出てしまうと、次々に頭に詰め込まれたり、タスクを割り振られたりで過去の自分がどんどん流されてしまったりして、夢ややりたい事というのも薄れていったりします。

ですから、過去の自分とのギャップを知りたくてもぼんやりとした記録の中で確認していかなくてはなりませんから何らかの記録の断片があったほうが分析しやすくなるわけです。

頭の記録に頼ると「あー俺、この時はこんなこと考えてたっけ」ぐらいな記憶しかなかったりもするのですが、それがあるだけましという場合もあって、実際のところ考えが大きく変わっていることにさえ気が付かないことはよくあったりします。

 

TwitterやFacebookなどへの投稿でさえ日々の自分の新しい発言に過去の自分の発言は流され薄められていきます。

 

こんなにデジタル化が進みなんでもかんでも記録し記録される時代であっても過去の自分というものを見直したり発見するのはとても難しいことです。

皮肉にもビッグデータとか言う自動的に記録されていく動向分析の中の自分(のデータ)のほうが、自分自身よりはっきりとした情報を持っているかもしれません。

 

まぁ、過去の自分とかそんなことを気にせずに前に進めということかもしれませんけど、闇雲に進めばいいというものでもないでしょう。

 

きちんと何処にいて何処に進めばいいのかというものさしが必要です。

なので、何かにその時の自分をメモしておくというのは大事だって思ったりするわけです。

メモする方法は色々あるわけですが、個人的にはみんなブログ書こうぜとか思いつつ、このエントリをまとめたいと思います。

 

 

 

 

 

 

その人が優秀なプログラマかどうかって話は、結構そのチームで求められる役割に大きく左右されたりして、コミュニケーションをとるのがうまいとか、コーディングのスピードが速いとか、フルスタック的にインフラからアプリケーションレイヤまで幅広く話が通じるとか、様々あったりするのですけど純粋にプログラマとしての役割だけを見た場合、何か一歩足りないというか突き抜けていない感が出ている場合があったりします。

 

それは、実際にコードレビューとかをしてみると、仕事は早いんだけど単に動くだけのコードであったり、コーディング規約がばらばらで見づらいものであったり、プログラムへのこだわりが感じられなかったりと、要はシステムとして見ればなんら影響は無い(少なくとも表面上は)のだけど、蓋を開けてみれば色々と問題があるなと感じたりする時です。

 

 

プログラマとしてののこだわり

 

例えば、(記事としては古いのですが)最近話題になってた記事で


新人プログラマーに読ませて欲しいネーミングの大切さ

 

というようなものがありますけど、これも要は動くからどうでもいいと思ってしまうのか、俺がちゃんと書かないと後々面倒になると思うか(というよりそれが自然にできる)が分かれ道になってくると思うのです。

 

それは、過去に苦い経験をしたことからくる心理からかもしれませんし、世の中に出ているハウツーを見たときに得た共感によるものかもしれませんが、こういうことってプログラミングの世界で何が大事なのか、つまりはプログラマとして何が大事なのかってことが頭の中にあるかどうかによってくるんじゃないかと思ったりします。

 

それは細かいことかもしれませんけど、そういったこだわりを持つことでコードの質もだいぶ違ってくるでしょうし、プログラマにとって何が大事かを考えるってことは、それに反した状況に陥ったときに「じゃあどうすればいいのか」という探求の反復にもつながります。

 

技術レベルで言うと特定の技術であっても、技術同士が連動するため深く掘り下げていくことはかなり困難なわけですけど、そういったこだわりを持っている人はその辺を気にしなかったりします。

プログラムのレイヤーを離れてミドルウェアやカーネルのレベルまでソースを確認したり、そうするために必要な知識を身につけることを苦に思っていなかったり。

 

こだわりというのはもちろん自分の好き嫌いというものではなく、プログラムとして何が正しいのかということを知っているということです。

 

何が正しいのかを知るためには、正しい方法を知る必要があります。

つまりは正しい方法を知るための模索が必要で、それにはかなりの努力を要します(そして本人的にはあまり努力しているという感じを見せませんし実際にそうは思ってないんだと思います)。

この探究心がある限り、その人はプログラマとしての成長が望めますし、コードの善悪がわかることでシステム全体の質を上げることに貢献してくれます。

 

単に動くコードを書くというのではなく、その場に適した正しいコードがかけるというのはプログラマの能力として大きな違いがあると思うわけです。

 

 

何故正しいコードを書く必要があるのか

 

それは、開発の生産性があがるとか、保守性が向上するとか、教育コストが抑えられるとか様々なことが言われたりしていますが、そういったことを改めていいたいのではなく、肝心なのはコードはコピーされるという事実です。

 

新人プログラマが学習するために書くコードは、ネットで調べたものや参考書の中のコードを書き写したものが多いと思います。

 

実際に現場でコーディングをすることになってもサンプルとして参考にするプログラムを教えられたりしますので、正しくないコードは正しくないコードとして学習されてしまいます。

 

正しくないコードでも正しく動くのは事実だったりしますが、パフォーマンスに問題があるかもしれませんし、セキュリティ的なリスクが内在しているかもしれませんし、レガシーの枠を超えることができずにプログラマの知識向上が行えないかもしれませんし、そんなコードを何時までも保守することでモチベーションが下がるかもしれません。

 

ですので、例えそれが動くコードであったとしても「このコードはテストをパスするかもしれないけど、そんなコードはクソコードだ!」ってはっきり言える人が必要なんだと思います。

(もちろんそんなにはっきり言うプログラマは扱いに難しい側面もあるわけですが)

 

そうしないと正しくないコードがどんどん生産され、それがコピーして量産されていきます。

 

その結果は先ほど書いたとおりのことが起きるかもしれないわけで、優秀なプログラマを育てたいというのと正反対の環境が生まれます。

何がプログラマとして正しいのかということを知っている人がいれば、コードが是正されていくわけでそこで正しいコードというものが作られていくきっかけとなります。

 

正しいコードこそが、プログラマとして何が正しいのかという知識を深め、優秀なプログラマを育てるための環境を作ってくれると思うわけです。