正しくレビューをするということが難しいのはなぜだろうか

システム開発をしていると、大体において開発した物に対して識者からレビューという物が発生します。非常にわかりやすく言うと、できあがった物が適正かどうかを判断してもらうわけですね。ところがこのレビューという物、適切に行うのは非常に難しいのです。

• レビューする側が問題領域をきちんと理解してる必要があり。
• さらにそこに使われている技術等が適切かどうかの判断。
• データ量などが将来にわたってどうなるか等を判断

などをしなければいけません。物事の論理に従って理性的に、良い意味で機械的に正しくあるべき姿を提示できるのが理想的かなと思っています。現状自分がいるところはある意味適切という意味で希少な例のところにいるかなとはおもっていますが、ただ、大抵の場合そうはなりません。レビューという名の誰の益にもならない個人たたきになる場合が非常に多かった気がします。上記の3つをきちんと満たすことはもちろんのこと、適切じゃ無いレビューをすることがレビューをする人にも、受ける人にも、会社にも、誰の得にもならないと言うことを理解してなければならないと思います。その上で、将来のために、相手のために、自分自身のために行うことが必要じゃ無いかなとは思います。悪い例を挙げていくと、

• 重箱の隅つつき
• レビュー段階ならないと発覚し得ない情報がある（暗にこめたんですよねとか）
• レビュー者の気分で技術方針がコロコロ変わる
• レビュー者の趣味の押しつけ

などがあげられます。もちろん大抵の人間は神じゃないので完璧じゃ無いのでこれを毎回１００％満たすことは無理だと思います。こういうことが起きうる要因って何だろうかと考えたときに、以下のレビューアーが内包するメタデータに起因するのでは無いかと思っています。

• そもそもどうやってレビューするのか不明
• 本人の性格
• 技術レベル
• 体調の良し悪し
• 技術的指向性が開発者と同じ方向性をむいているか
• 交友関係の障害等
• 現在担当している仕事の量
• 開発者が好きか嫌いか
• 社内政治

本人の性格や技術レベル、社内政治や交友関係等は解消しづらい問題では無いかなとは思いますが、対人問題であれば双方にとって気持ちよく終わって問題を起こさないようにするぐらいしか指針が出せませんが（問題領域に詳しくおすすめの書籍等詳しい方は教えて頂きたいです）、こちらが根が深く根本的に解消しづらいところもあるので困難さの一員では無いかと思います。単純にレビューという技術であればぱっとアマゾンやググって見た感じ何件かでてきたので並べておきます。何かおすすめのサイトなり書籍があれば知りたいです。

ソフトウェア・レビュー技術―基礎から実践までのノウハウ

なぜ重大な問題を見逃すのか? 間違いだらけの設計レビュー

ピアレビュー

• http://www.src-j.com/books/pdf/228_pt.pdf
• http://monoist.atmarkit.co.jp/mn/articles/1011/11/news116.html

多岐にわたった知識を総動員し、それぞれに対してかなり詳しく使いこなしているする必要があり、そういった理由から難しい技術なんじゃ無いかなぁと言う気はしてます。関係する領域においてなるべく勉強はしておきたいです。（自戒の念を込めて）

openされたファイルとunlinkについて

tmpfileの挙動でオープンしたと同時にunlinkが発行されて後始末をしなくていいという話だったんですが具体的にどういう挙動なんだということが気になりまして調べてみたら、unlinkはファイルシステム上の名前の削除で、さらにどのプロセスもファイルをオープンしていなければファイルが削除されるという(see man 2 unlink)ことになっていて、tmpfileの挙動はこれを利用した物になっているようです。従って受け取ったファイルディスクリプタをcloseしてしまうとプロセスが起動中でもそのファイルは削除されてしまうようです。

参考

http://linuxjm.sourceforge.jp/html/LDP_man-pages/man2/unlink.2.html
http://pubs.opengroup.org/onlinepubs/009695399/functions/unlink.html

Linuxプログラミングインタフェース

tmpfileについて調べたこと

Linuxにおいて大体何かを組んでいると一時的に何かに保存したいとかメモリ食べたくないとか様々な理由で一時的なファイルを作成すると思います。一時的なファイルを作成すること自体はそこまで難しくなく/tmp/以下に好きな前をつけて扱えばいいと思うのですが、好きに/tmp以下にファイルを作るのは複数プロセスが立ち上がった場合に同一ファイルを意図せず見てしまう、他のプログラムが同一の名前を意図せず使用してしまう、セキュリティホールなどになってしまう(see man tempnam)などの危険性があります。頑張ればこれらの問題はファイルオープン時におけるオプションのO_EXCL(see man open)とファイル名生成の工夫で大体は解決つくはずですが、これを頑張らなくてやってくれる仕組みがtmpfileです。読み書き用で開いてO_EXCLで他のプロセスが同じ名前で開くことを防ぎます。おまけにオープン直後にunlink実行してて削除してくれるので後始末も安心です。(/tmp以下は大体の場合はtmpwatchというcronによって良きに削除されていくのでそこまで問題にはならないですが)各言語にもtmpfile相当のものが実装されていて似たような挙動をするはず。

例を取ってPerlだとFile::Tempというモジュールがありまして。

tempfileの実行テスト

use strict;
use warnings;
use File::Temp qw/ tempfile /;

my ($fh,$filename) = tempfile( UNLINK => 1);

print $filename . "\n";

実行結果

/tmp/T4Yk7WE06m

確認すると削除されています。

デフォルトの挙動でファイルが残るので
UNLINK => 1 をtempfileのオプションとして残すと削除されました。

同様な処理として一時的なディレクトリを作成する処理としてtempdirというものがあるのですが、LinuxProgrammingInterfaceにはこの用語出てこないです。代わりにmkdtempというCライブラリの話が出てくるのでこちらがあたるのでしょうね。

参照

Linuxプログラミングインタフェース

https://metacpan.org/pod/File::Temp
http://linuxjm.sourceforge.jp/html/LDP_man-pages/man2/open.2.html

なんていうか

会社とかで長く生き続けるメンテしづらくてパフォーマンスでないコードのことだと思うけど、くそコード連呼されるのをみてて思うのは、死ぬ気でその集団を守ってきた老兵にその集団で生かされてきた若造が唾はいているようなものにみえて、おまえがそこまで生きてこれたのその老兵のお陰なんよ。とか頭の中よぎってしまう。自分が頑張るんでもう良いんですよぐらいの気持ちでいたい。

３年たったのでかいてみる

正直、震災を忘れたい人もいるだろうからこの日のメディア震災一色はどうにかして欲しい気がする。被害地にいたわけでもないし間接的に関わっただけでも割としばらくの間は精神的にしんどかった。当事者の方々はどう思ってんのかは計り知れないし、どこに直接的な被害者がいるのかわからないからうかつに話題にはだせない。海外のＴＶドラマで９１１が深刻な話として直接間接いまでもふと話題に上がるのは似たような心情なんだろうなとおもう。震災の復興自体は今でも継続した話だし追悼などの話がいまでも上がるのは忘れっぽいこの国にしては、というよりはこの国だから忘れないようにしてるのか。悪いことでは無いが忘れたい人もいるんじゃ無いかとおもって時折考えてしまう。

ぎょっとしたこと

合気道の開祖である植芝先生はよく「教わったことは忘れろ」といったたぐいのことをよくおっしゃられていたようです。実はこれ分野違っても囲碁でも「定石は覚えて忘れろ」みたいな言葉があったりします。自分なりの解釈としては体に覚え込ませて意識しないレベルまで持って行きなさいという意味だと思っていたんですが、最近プログラマの為の数学勉強に出席させていただいていて、ここしばらく忙しかったこともあり見直しとかできてなかったので、そろそろ見直すかと思ってノートとスライドを振り返っていたらことがおこりました。自分自身すっかりメモしたこと自体忘れていたのですが、ここしばらく自分のなかやメモで連呼されている言葉が書かれていました。本当に自分にとって大事なことだと認識したら取り込まれて別の形で噴出していくものなのだなと実感すると同時にぎょっとしました。

Rubyの入門書でいいものを知りませんかね？という質問に対してどう答えるべきだったか？

Rubyの入門書でいいものが欲しいという話がちらっと流れてきて、親切な人たちが多い集まりなので、鉄板？であろう「プログラミング言語Ruby」からはじまり「メタプログラミングRuby」、そしてるびまの「Rubyの歩き方」はてはＲＨＧまででてきた。

プログラミング言語 Ruby

初めてのRuby

たのしいRuby 第4版

メタプログラミングRuby

Rubyソースコード完全解説

正直、このときるりまを示しつつもこの人に何を推薦すべきなのか悩んでいた。頭をすきっりして寝るためにここに書いておこうと思う。

入門書がほしい人とは？

入門書がほしいのですが？という質問に対してＡＰＩリファレンスのＵＲＬを渡すケースをよく見られるのだがそれに違和感をよく感じる。渡してる人はおそらく絶対的に間違っているわけではない。たぶん、仕事や論文を書く上で参考文献として載せる場合それはとても正しい行為だと思うが、おそらく質問者の意図をくむとそれは違っている気がする。ＡＰＩリファレンスの場所もわかっているしそれを必要に迫られている部分に関しては読んでいると思う。だが、途中で気づいているのだと思う。あまりにも自己流で非効率すぎるやり方を自分がしていると。高速道路がほしい。頂上に登って俯瞰した人の意見がほしい。故に入門書がほしいという話になるのだと思います。

入門者とは？

言語の入門者と一口に入門者といっても様々な人々がいます。本当に初心者で何も書いたことがない人。学校の授業で表面だけならった人。実はちょっと読めるんだけどつまみ食いで覚えたから基礎固めをしたい人。ほかの言語をそこそこ使っているが対象の言語を使ったことがない人などが考えられます。

レベル的に、

本当に初心者で何も書いたことがない人＜学校の授業で表面だけならった人＜実はちょっと読めるんだけどつまみ食いで覚えたから基礎固めをしたい人＜ほかの言語をそこそこ使っているが対象の言語を使ったことがない人

このように分けられると考えた場合、異論はあると思いますが最初の2つのケースはいわゆる本当のプログラムのイロハが書いてある入門書を読むかチュートリアルをこなすかするのが妥当だと思います。問題はそれ以降のレベルの人たちでおそらく言語を超えたパラダイムのものでまかなえる概念のものはすでに習得しているはずなんですね。言語固有の特性やメジャーなＯＳＳのプロダクトを読むために知識がほしい、もしくは作りたいといったレベルじゃないかなぁと思うんですよね。本質的にはここのレベルに到達した場合基礎力の差が諸にでてくるので安易な解決方法はすくなくとも言語入門書にはなくて全く別のレイヤーの別のものに入門しなければならないわけで正直時間が非常にかかります。そこまで追ってると時間がかかりすぎるよというのは本音でしょうから、いいソースコードや入門書がないですか。という質問に戻ってくると思います。あまり好きではないですが、背に腹は代えられないケースは当然あるのでショートカット案を考えます。要は未知のものがでてきてすごく時間をとられることが問題なので、その言語のどの機能をどうやって書くかが網羅されているものをとりあえずチェックする。固有の単語、概念などをつぶしておくなどが有効じゃないかなって気がします。（ただ、これはホントに言語を使いこなしているというレベルの人の前ではバレます。バレたからどうということは全くありませんが。）

今回の質問者にすすめたらよかったんじゃなかというもの

おそらく今回の質問者は後者の人なので割と簡単に読める逆引き系あたりが有効かなという気がするので「The Ruby Way」か最近のメジャーなプロダクトの解説も載ってる「パーフェクト Ruby」あたりが妥当だったじゃないのかなぁと思いました。

Ruby Way 第2版 (Professional Ruby Series)

パーフェクトRuby (PERFECT SERIES 6)

追記

自分にとってこの入門書がすばらしかった（２５６や初めてのRubyなど）や、rubyの為にmrubyやるとかあったりして様々な入門書への出会いやアプローチがあり、そして考え方があるんだなぁとコメントを眺めていて思わされました。内容や記事を読んでくださる方へ気になるコメントとしては、「The Ruby Way」は好きだけどちょっと昔で今では使用されてないものもあって現時点（201310）においておすすめではないなという話もあり、私もこの本、よくある逆引きの適当さが良い意味でなくてすごい好きなんでだしました。ただ、本の場合は常について回る問題なのですが、特にこういうRubyの様なLL言語の場合移り変わりが非常に激しいので出版年数によって言語のライブラリなどのはやり廃りの問題はあるのでそこは購入を検討される方は気になされた方がよいかもしれません。ただ、わかりやすいし個人的には僕は好きです。あと、他言語で特にJSやCなどは沢山の入門書などがでているのでどなたか詳しい人書いてほしいなぁというコメントもありまして。私も知りたいです。何方か詳しい方いらっしゃいましたら書いて欲しいなぁ