がるの健忘録

エンジニアでゲーマーで講師で占い師なおいちゃんのブログです。

性懲りもなく「PHPについて語っているBlog」に興味を持ってみる

元ネタ
http://d.hatena.ne.jp/tumf/20110321/1300661187


一部「ネタ」とか書かれているハテブもあるようですが、社長さんですし社名を正面に出して書いているようなBlogですんで、正面から受け取ってみたいと思います。

PHPのエンジニアは同じ単価でもスキルの差がある。マネージャはそれを埋めるために最悪自分で動かねばなりません。以下はその最悪に近いケースの話です。

別に、他の言語でも「同じ単価でスキルの差異」はふつ〜にあると思う。
なので「PHPのエンジニアは」って部分には違和感あり。でもまぁそれ以外はそんなもんだと思う。
「マネージャはそれを埋めるために最悪自分で動かねばなりません」は、おいちゃん的には理想到達点(っつかまぁやってるけど)。ただ、それを「すべてのマネージャに要求してよいのか?」って部分で疑問。…要求したいんだけど(苦笑

逆に、運良く良いエンジニアを集められて場合はマネージャの仕事は本来の顧客に向いたものとなるでしょう。

ん…なんか引っかかる。
よいエンジニアであろうとも、マネージャの向きは常に「顧客とチームの両方」を向いている必要があるんじゃないかなぁ?

1.メンバーの経歴はあてにしない

言語に拠らず、ごく当然。

2.メンバーは定時に出社させ定時に退社させる

ど〜なんだろ?
「週40時間労働」は、諸手を挙げて賛成。…ってなるとまぁ、定時出社、定時退社、になるのか。

3.Subversion利用を徹底させる

うんまぁ特に違和感もなく。

4.PHP5.3専用のフレームワークは使わない

状況次第、ではあるかなぁ。ただ「ど〜しても5.3系が必須」って状況もレアだと思うので、業務ベースで考えると、もうちょっと静観してもよいような…名前空間は欲しいような…でも¥はキライw

5.テキストエディタの設定を確認する

文字コードと改行コードはたしかに。
インデントは、個人的には2spaces派w
まぁ「統一ルール」があればよろしいのではないか、と。

6.難しいコードを書かせない

いつもながらに難しいところ。おいちゃん的には「必要なら書く、必要ないなら書かない」。

call_user_func()・SPL・リフレクション

call_user_funcは、基本つかわない。
SPLは…うんやっぱり使わないなぁ。
リフレクションは、使わないってよりもうちょっと踏み込んで「可能な限り忌避する」かなぁ。
なんだおぢちゃんのコード、難しくないぢゃんw

7.浮動小数を使わせない

至極当然。

8.switchを使わせない

break忘れってのはどうかと思いますが(苦笑
switchを「小器用に多用する」のは、大抵「ろくでもないコードの臭い」がするので、慎んだほうがよろしいのではなかろうか、と。
「どんなswitchがまずいのか」って部分の議論を、ちゃんとメンバー内でしておくとよいのだと思う。

9.正規表現を書かせない

単純に「重い」からおいちゃんキライ。抜けも多いしね。

10.SQLを書かせない

びみょ〜〜〜。「できればORマッパーを利用しましょう」は元々否定派だし。
SQLは「複雑なSQLが書ける」スキルを持ちつつ「基本、シンプルであることを旨とする」のがよいと思っているので。

11.一行でもブロックの{}を省略させない

これも、言語よらず一緒。

12.無理にコメントを要求しない

やだw
コメントは「何があろうとも潤沢に」書いてもらうのがおいちゃん流。

13.関数名を日本語にしたがる人に優しく辞書を渡す

あぁ…うん…(遠い目
おいちゃんは、Web系の辞書と翻訳サイトを多用(苦笑

14.ブランチのマージ

ん…これは「やだ」なぁ。
ちゃんと話をした上で、メンバーを信頼したい。

15.コードレビュー環境を用意する

「管理者は、メンバーが帰った後に大量のコードを読まなくてはいけませんので」いやまぁ居る間に読みますがw
自分の手に合ったお道具ってのは、大切ですね。

16.深夜にCIを動かして朝一番にチェックする

引き続き思案中。

17.テストは管理者が書く

テストって「指示書」の代わりにもなるので、ひとつあり。
おいちゃんは「テストを書いてもらって、それをレビューする」ことで、設計のお勉強を兼ねていただくことが多いです。

18.バグはBTS

よろしいのではないか、と。

19.他の言語の話をしない

そなの?
そこまで深い愛着をPHPに対してもつ人が周囲にはいないっていうかそもそも平気で「PHPってだめぢゃん」とかBlogに書いているおいちゃんがなに言ったって説得力ないよねぇw

20.開発環境の話をしない

んむり…ここもそんなに気にしないかなぁ。っつかまぁ、おいちゃんのIDEは「vi」基本だしw

私の経験では、コードレビューと修正、明日の分の指示書作成については、1メンバーあたり1時間程度見ておけば十分だと思います。(たとえば5人分なら19:00から5時間なので終電に間に合いますね!)

ここは断固として否定。
「週40時間」は、あらゆる人に適用されるべきだと思っているので。


全体として…「マネジメント」というか「現場指揮官」という感じの印象値。
あとは…端々に、びみょ〜に「現場を信用していない感」が漂うのが、なんとなく気になるのかなぁ。


気になったので、memo。