2011-06-08
いっしょに仕事をしたいプログラマ 5つの特徴
ちょっとこんなことを考えるきっかけがあったので、ざっと書き出してみた。Webに公開されている情報からあるプログラマについて見てみたとき、どういう人ならいっしょに働いてもいいかについて。
ここに書く内容はソースコードの品質以前の問題についてのみにしてある。だからこの特徴を満たしていればどうということに直接なるわけではない。ただ、欠けているところがあれば、少なくとも自分はその人といっしょに仕事をしたいとは思わないだろう。
なお自分は現勤務先の採用活動にはかかわっておらず、このエントリの内容は勤務先の採用基準とは全く無関係です。
学生さんなどの場合にはまた話が違うと思います。
あと割と自分のことは棚に上げてます。「お前これできてねえじゃん」という部分については都度ご指摘をいただけますと大変ありがたく思います……。
1. その人が書いたソースコードが公開されている
日本語で何を言われてもぶっちゃけよくわかんない。口だけが異様にうまいんだけどコード見てみたらうへえ、どころか本当に全く書けなかったりする人もいるし…… 。
もちろん公開できないような場所で公開できないようなコードをずっと書いてきてすごい技術の持ち主というのも世の中にはいっぱいいるに決まっていて、そういう人をうまく見付けてこられればいいんだろうけど、自分には無理です。だから見えるところにその人の書いたソースコードが何かしらある、というのが最低条件。
ぶっちゃけ、blogエントリのコード片でもいいと思うんだよね。ただ、いつも読んでるblogならともかく、ある人について調べるときにblogを全部読み返すのはちょっときついから、判断のしやすさで言えば、適当なサイズのライブラリ/プロジェクトがどこかのサイトで公開されているというのが簡単かな。
2. バージョン管理システムを適切に使っている
ソースコードがzipで固めてどこかに置かれているだけ、というのは判断が難しい。バージョン管理システムを使えない人とはいっしょに仕事はできない。
github(git)/bitbucket(Mercurial)/Google Code(Subversion/Mercurial) などに置いてあってほしい。どういうcommitが行われているかの履歴がちゃんと見えると嬉しいな。
ちなみに最悪なのはzipだけで置かれてるコードを見てみたら中身にコメントで「ここは〜(その人の名前)が修正 何月何日」みたいに書いてあるとか、そういう感じのやつ。業界によってはかなりの割合でいるのがおそろしい。
3. 複数の言語のコードが公開されている
公開されているコードがすべてひとつの言語で書かれていると、見てみてもいまいち判断がつきかねる。個人的にいちばん判断がつきかねるのはすべてJavaのコードの場合、およびすべてPHPの場合。
2つ以上の言語のコードがあればそれぞれについてどう考えているのかを想像することもできなくないし、少なくとも「言語について何らかの価値観、選択肢と判断基準をもっている」ことはわかる。これがないとちょっといっしょに仕事するのはきついよね。
ちなみにPerlばっかり書く人が本当にPerlだけしか書けないというのはほとんど見たことがない。*1
4. その言語のコーディング規約や慣習に従う
言語によって、クラス/関数/変数/定数名をどういう命名にするかなどはもちろん異なっている。文法で縛られている場合もあるが全てではなく、自由なんだけどコーディング規約的にはこうしてね、とか、決まりではないんだけどいろいろな人のコードを見ると普通こうしてるよね、とかいう割合は多い。
で、それに反したコードを平気で書いてしまう人というのはちょっとアレな感じだ。他の人のコードを読まないのかなーとか、自分のコードのメンテするのがきつくないのかなーやらないのかなーとか思う。具体的に言うと、そんなコードを自分はメンテナンスしたくない。
またコードの字面だけじゃなくて、ソースコードツリーにおけるファイル配置がどんな感じなの、とか、ドキュメントファイルの書き方とか、そういうあたりもこの項目に近いものがあるかな。
使用する環境やライブラリの特殊事情が絡む場合もあるし、そもそも自分がよく知らない言語の場合にはよく分かんない場合も多そうだけどね。
5. 人のコードにパッチを送る
これは実際やっててもぱっとは見えない場合が多そうだけど、いちおう。
誰かが公開しているライブラリ/ミドルウェアに自分には都合が悪い部分を見付けた場合、それにどう対処するかはいっしょに仕事をする上で大事な点だと思う。バグは直せば(そしてパッチを送れば)いいけど、機能的な違い/要望の場合はなかなか難しい。そこに対処して元のコード/動作/APIと折り合いをつけつつ問題を解決するようなパッチを書ければ、それはすばらしいことだ。ぜひいっしょに仕事したい。
アレなパターンは「まるっとコピーした上で元の動作やAPIを破壊しまくった変更を加えて、元のプロジェクトとは完全に別個に置く」ようなやつ。なんというか、つらい。元のプロジェクトが進化したらマージはどうすんのとか、API変えられたら相互に差し替えもできないじゃんとか、本当に変更後の方がいいと思うなら元プロジェクトにフィードバックした方がいいに決まってるのになんでしないのとか、いろいろと考えさせられる。仕事で書くコードにそんなことされたらたまらん。
結論
結論なんてもちろん無い。ここに書いた内容は人によっては「こんなの守ってる、少なくともできるだけ守ろうとする、のは当然だろ」とそれこそ当たり前のように思う人もいるだろう。そういう人は履歴書と職務経歴書を今後もいっしょにやっていこうぜ。
でも現実問題として特定の会社に閉じて生きてきた人とかだと、どれひとつとして満たしていない人もいる。いっぱいいる。そういう人たちにこのエントリが届くことは残念ながらほとんど無い気はするけど、でもまあ、もしかして届くことがあるといいな、それで少しでも意識が変わることがあるといいな、と思ってる。
Permalink | コメント(36) | トラックバック(7) | 12:01 
*1：掲示板作ってみましたレベルの人の話はいまはしていない。
- 912 http://b.hatena.ne.jp/hotentry
- 849 http://twitter.com/
- 795 http://members.jcom.home.ne.jp/sarasiru/
- 628 http://b.hatena.ne.jp/hotentry/it
- 510 http://reader.livedoor.com/reader/
- 452 http://www.ig.gmodules.com/gadgets/ifr?exp_rpc_js=1&exp_track_js=1&url=http://www.hatena.ne.jp/tools/gadget/bookmark/bookmark_gadget.xml&container=ig&view=default&lang=ja&country=JP&sanitize=0&v=298d279074e4cc94&parent=http://www.google.co.j
- 350 http://alfalfalfa.com/archives/3508023.html
- 329 http://www.mew5.com/
- 301 http://homepage1.nifty.com/maname/
- 208 http://members.jcom.home.ne.jp/sarasiru/nikki.html
