« 最近はいろいろと高い・・・という感覚 | Main | Amazonのマクラーレン・ホンダのドキュメンタリー »

良いコードとは何かを伝える

ずっとインフラ系のSEとして活動してきたので、システム開発プロジェクトでコードを書く用になったのは、ここ5年ぐらいのことです。私がやるからには、テストを書かないなんてあり得ません。というか、別に私がどうのこうのというような話じゃなくて、テストは書くよね、普通。

とはいうものの、「プログラム開発経験あり」という触れ込みの開発者をパートナーから集めても、実際にテストを書いたことがあるという人は極々、まれ。となると、教えねばなりません。教える方法としては、コードレビューしかありません。もちろん、ガイドとかそういうものも書くんですけど、しょせんはあるモデルケースに過ぎません。実際のところは書いてきたコードを、「こういう時はこうするのだ」と添削して返さないと本当の意味では伝わりません。

いやね、じゃあ私はそういう教育を受けたのかっていうと、そうじゃないんだけども。単に好きだから雑誌やら書籍やらWebサイトやらで得た知識が、渾然一体となったものなわけで。でも、それをみんなに求めるわけにはいかんからね。

で、そんな活動を今のプロジェクトで半年ぐらいにわたって続けてきたわけです。「一度はタンバリンにコードを突き返された奴しかコミット権限をやらないからな」と言って(笑)。その結果、年末の評価で言われたのが、「レビューを明確な基準がなく、主観的にやっている」という指摘です。ちゃんと基準を明確にして仕事せいと。お前の好き・嫌いで決めてるんちゃうんかと。

わからんでもないけども、どうにも納得がいかん。コードレビューと聞くと、あたかも私が合否の判定をしてるみたいに受け取られているみたいなんですが、目的は教育なんですよ。実際にやってみてもらって、そして、自分もやってみせて、ほら違うでしょ。こっちがいいでしょ、とやらないと伝わらないからやっているだけで。そーゆーことじゃねーんだよなー、理解されてねーなー・・・と上司からの評価を得られずにふてくされる日々。

そんなとき、ajitofmというポットキャストの第17回を聞いていて、ほぼ日でやっていた濱口秀司さんの対談について触れられているのを聞いて、腑に落ちました。

この対談、私も読んでいたんですけど、中で出てくる図が本当に秀逸なんです。

どういう図なのかは、是非対談を読んで欲しいんですが、教育ではこの4象限のそれぞれを全て伝えなければならないと。で、どのプロジェクトでもTODOリストやチェックリストなどの「文書化できるWHAT」と実装ガイドや操作手順書のような「文書化できるHOW」については準備するし、作って展開することについて一生懸命考えるんだけど、スキルとカルチャーについてはもの凄く手薄か、あるいはまったく考えてないことが非常に多いのです。

その理由の大きい部分は、プロジェクトメンバーが基本的には一期一会で、時間のかかる教育はコストパフォーマンスが悪いということがあるんですが、それでも半年とか、1年とかの期間があるのならば上の図の右半分をどうメンバーに伝えていくかを考えなくちゃいけない。そして、それをやる方法の1つがコードレビューだということです。

システム開発の現場におけるスキルやカルチャーの重要性は、わかっている人はすごくわかっているんですが、取り上げられることがあまりないトピックではあります。わかっている人はわかっているので、例えばアジャイル開発宣言では「自己組織的なチーム」という言葉でそれを取り上げてますし、スクラムマスターはチームのカルチャーを醸成することに非常に腐心することになります。

となると、「コードレビューを明確な基準の下で行え」という指摘は、私のやろうとしていることとまったく相容れないことだってことです。だって、明確に文書化できないものを伝えることが目的なんだもん。やっていることは「良いコードとは何か」ということを、「私の価値基準」で伝えていることだからです。そりゃどんなコードが良いコードかってことを文書で書くことはできる(出来るから、その文書を通じて私が学べたわけだし)けれども、やったところでそれはもうあるし。要するに「リーダブルコード」ぐらい読んでからプロを名乗れよってことなんですけどね。

例えば、ある条件A(cond_a)とB(cond_b)があって、その組み合わせによって違う処理をするというコードを、チームメンバーがこう書いてきたりするわけです。

if(cond_a) {
    if(cond_b) {
        // AかつBのときの処理
    }else{
        //AだけどBじゃないときの処理
    }
} else if(cond_b) {
    // AじゃないけどBのときの処理
} else {
    // AでもBでもないときの処理
}

コードを書き慣れている人なら、気持ち悪いですよね。

if(cond_a) {
    if(cond_b) {
        // AかつBのときの処理
    }else{
        //AだけどBじゃないときの処理
    }
} else {
     if(cond_b) {
         // AじゃないけどBのときの処理
    } else {
        // AでもBでもないときの処理
    }
}

こうなっていて欲しい。ただ、条件Aや条件Bの性質によっては上のコードが自然な場合もなくはない。たぶん。これを「同じ条件はおなじインデントの位置で調べろ」とかいうルールにすることはおそらく間違っていて、もっとメタな視点からの指摘じゃないとダメなわけです。しかしまあ、上みたいなコードを書いてくる人に読みやすいコードを書くように指導することは、正直、どうやったらいいのかわからないんですけどね。読みづらいって思ってないかもしれないし。となると、「良いコード」を浴びせまくるしかないのかなと思うわけで、レビューしかないぞと。

どうやって、プログラマのスキルやカルチャーを育成するかはホント難しい話なんですが、これがないとどうにもならんので、評価はされないけどこういう活動を続けていくしかないと信じてます。

でも、評価されてないと続けらんないんだけどね。うむー。

|
|

« 最近はいろいろと高い・・・という感覚 | Main | Amazonのマクラーレン・ホンダのドキュメンタリー »

日記・コラム・つぶやき」カテゴリの記事

Comments

Post a comment



(Not displayed with comment.)


Comments are moderated, and will not appear on this weblog until the author has approved them.



TrackBack

TrackBack URL for this entry:
http://app.cocolog-nifty.com/t/trackback/47905/66338086

Listed below are links to weblogs that reference 良いコードとは何かを伝える:

« 最近はいろいろと高い・・・という感覚 | Main | Amazonのマクラーレン・ホンダのドキュメンタリー »