2011-03-21
■[開発]より良いPHPerのプロマネになるための20Tips
あなたが幸運にもPHPプロジェクトのマネージャに選ばれたときに気にして欲しいTipsを書いてみました。
基本
PHPのエンジニアは同じ単価でもスキルの差がある。マネージャはそれを埋めるために最悪自分で動かねばなりません。以下はその最悪に近いケースの話です。
逆に、運良く良いエンジニアを集められて場合はマネージャの仕事は本来の顧客に向いたものとなるでしょう。以下Tipsです。
人事労務管理編
1.メンバーの経歴はあてにしない
PHPerの関わる仕事はJava等の言語の仕事に比べて小型なものがおおいため細分化されていなく、1プロジェクトで1人プロマネで全行程1人でやる事も少なくありません。もちろん人には得意不得意がありますから全行程を卒なくこなせる人は稀です。履歴書や業務経歴書の内容は話し半分以下に聴いておいて、あなたのプロジェクトでの実績を重要視しましょう。
2.メンバーは定時に出社させ定時に退社させる
一部のIT企業ではフレックスタイムが流行っていますがこれを諦め、全員が出社しやすい時間を出社時間と定め、それから無理なく8時間(+1時間休憩)で退社させましょう。10時〜19時が良いと思います。
セットアップ編
プロジェクトの始めにメンバーにおねがいをしましょう。
3.Subversion利用を徹底させる
作業はかならずSubversionのワークディレクトリの下で行い、帰宅する前にはかならずコミットして帰ることを約束させましょう。コミットログは役に立たない事が多いので気軽に愚痴でも書いてもらう程度で良いかと思います（顧客に見せないように!)。
注意: 流行っているからと言ってgitやMarcurial等の分散レポジトリを使わせてはいけません。これらは扱いが複雑な上コミットしたがpushを忘れて帰られるという自体が頻発します。
4.PHP5.3専用のフレームワークは使わない
PHPは5.3になって複雑な文法が導入されました。PHP5.2で動くフレームワークやライブラリならこれら複雑な文法が使われていなので大丈夫ですが、PHP5.3専用フレームワークと謳っているものはこれら複雑な文法を駆使して作られているため危険です。
5.テキストエディタの設定を確認する
できれば、メンバーに同じPCを支給し、同じエディタを使わせる。設定で、改行コード(LF)・文字コード(UTF-8)・インデント(4SPACES)あたりを統一しましょう。
コーディング編
6.難しいコードを書かせない
エレガントなコードを書いて喜んでいる開発者には「もう少し丁寧に・・・」といって基本的な文法で書いてもらうようにしましょう。特にcall_user_func()・SPL・リフレクションあたりは危険なのでなるべく使わせないようにしましょう。
7.浮動小数を使わせない
どの言語でもそうですがfloatの扱いは本来難しいのでなるべく使わせないようにしましょう。
8.switchを使わせない
break忘れるのでなるべく使わせないようにしましょう。
9.正規表現を書かせない
正規表現のチェックは非常に難しいため、面倒でもifを利用して仕様通りに分かりやすく一つ一つ書いてもらいましょう。
10.SQLを書かせない
できればORマッパーを利用しましょう。無理ならJoinや副問い合わせなどの難しいことはさせず、関数で括り出してPHP側でforeachを駆使して何とかしてもらいましょう。無理にSQLを書かせるとかえって何やっているか解らなくなります。（この関数は恐らくあなたがごっそり書き換えることになるでしょう。）
11.一行でもブロックの{}を省略させない
PHPはブロックの中身が一行なら{}を省略して以下のように書けます。
if ($condition)
echo "hello!";
しかし、これは継続行を追加したときにトラブルの元なので{}を省略させないようにしましょう。
12.無理にコメントを要求しない
phpdoc形式などの形式的なコメントは役に立たない事が多いのでやめましょう。
13.関数名を日本語にしたがる人に優しく辞書を渡す
function Syokika() { ...
たまにいるので英語で書いてもらうようにお願いしましょう。
チェック＆レビュー編
メンバーが帰宅した後が本当のあなたの仕事です。ファイト！
14.ブランチのマージ
メンバーには極力trunkへのコミットを避け、開発者毎に一日分もしくはトピック毎にブランチを作りそこで作業をしてもらいましょう。ブランチをチェックしてマージは管理者がメンバーが帰った後に行いましょう。
注意: メンバーにマージを任せてはいけません。コンフリクトしたコードをそのままコミットして帰るメンバーのせいでtrunkが壊れると他のメンバの開発が滞るからです。
翌日の朝会ではメンバー毎にtrunkから新しいブランチを作成しそこから開発を再開するようにお願いしましょう。
15.コードレビュー環境を用意する
管理者は、メンバーが帰った後に大量のコードを読まなくてはいけませんので、快適に読める環境を用意しましょう。PHPの文法で色がついて、Subversionのdiffやblameをわかりやくす表示できるtracやRedmineを使いましょう。
- var_dumpをgrepする
コミットされていたらチェックして外しましょう。(Javascriptを利用しているならconsole.logなども要チェックです)
16.深夜にCIを動かして朝一番にチェックする
できるならJenkinsやphpUnderControl継続的テスト環境を用意しましょう。夜中にCIを実行し、翌朝チェックするサイクルを作りましょう。これだけで随分楽になります。
17.テストは管理者が書く
CIツールが実行するテストはコードカバレッジ50%を目指してあなたが書きましょう。クラスの初期化処理を書くだけでも基本的なミスは発見できます。
18.バグはBTSに
バグを発見したらtracやRedmineなどのBTS（バグ追跡ツール)を使って管理しましょう。BTSへの起票はマネージャが行い、開発者にはそれを指示書として明日の朝会で修正をお願いしましょう。
コミュニケーション編
19.他の言語の話をしない
PHPerはPHPに深い愛着がありますので、他の言語の話をするとしらけます。絶対にやめましょう。
20.開発環境の話をしない
どんなに効率的な開発環境でもメンバー全員が同じものをつかっていることが重要です。効率的な開発環境はあなたがメンバーの書いたコードを修正するために自分で利用し、メンバーに薦めるのはやめましょう。
----
と、ざっと20Tips書いてみました。マネージャとしていろいろやらなくてならないことにびっくりされたかもしれません。マネージャの日々の仕事の流れは例えば以下のようになります(メンバーを10時出社として)
9:30 出社 CIツールの結果確認 10:00 〜 10:30 メンバーの出社＆朝会 10:30 〜 13:30 午前の作業 13:30 〜 14:30 遅めのランチ 14:00 〜 19:00 午後の作業 19:00 メンバー帰宅(コミットのチェックをお忘れなく) 19:00 〜 コードレビューと修正、明日の分の指示書作成
私の経験では、コードレビューと修正、明日の分の指示書作成については、1メンバーあたり1時間程度見ておけば十分だと思います。（たとえば5人分なら19:00から5時間なので終電に間に合いますね！）
マネージャであるあなたの頑張りが顧客の信頼獲得と会社の発展につながります、頑張ってくださいｗｗ
Thanks:
Permalink | コメント(0) | トラックバック(0) | 07:46