Clean Coder読んだ

読み終わり申した。

Clean Coder プロフェッショナルプログラマへの道

 　ボブおじさんことロバートマーチンによるソフトウェア開発のプロとはなんぞや、について書かれている本。正直読むまでそんなに期待していなかったのだが、プログラマ歴４０年超は伊達ではなかった。プロ意識の塊のような人だ。ソフトウェア開発を仕事としている人は総じて読むべき本だと思う。

　全部で１４章まであるのだが、おそらく著者の言いたことの大部分は１章から３章までにほぼ集約されている。

• 第一章　プロ意識
• 第二章　「ノー」と言う
• 第三章　「イエス」と言う

　第一章ではプロとしての意識とはどういうものかと書かれている。

プロ意識というのは、自分で責任を取ることに他ならない。 

 　労働倫理や自己研鑚、専門性や謙虚さなどにも言及しているが、一番大事なのは責任をとることだと言っている。第二章、第三章で語られている内容は、責任を取る場合と取らない場合についての内容だ。例えば、よくありがちな、対立を避けるために（うまくいくとは限りませんが、）やってみます、という言葉についてだ。

試しにやってみるというのは、力を温存していたと認めることだ。試しにやってみるというのは、温存しておいた力を使えば目標が達成できると認めることだ。さらに言えば、温存していた力を使って目標を達成すると約束することだ。つまり、試しにやってみるというのは、成功を約束するということなのだ。「試しに」やってみて、望ましい成果につながらなかったときは、失敗したということになる。 

 上記のように全力でやってなかったことを表明するだけでなく、意識せずともコミットメントしていることになる。本人はうまくいくとは思っていない。つまり嘘をついているのと同じだ。「ノー」と言わせない空気があっても、「ノー」というべきときは言わなければならない。

　第三章の「イエス」と言うは、その反対でコミットメントするべき場合を述べている。何に対して責任を追うべきなのか。

プロは頼まれたことすべてに「イエス」と言う必要はない。しかし、「イエス」と言える創造的な方法を懸命に探さなければいけない。プロが「イエス」という時には、確実に約束したとわかるような約束の言葉を使っている。 

 　責任を負うのはプレッシャーがかかる。難しいことだが、やっていかなければならない。

　この本を読んでいると、理想からあまりにかけ離れた自分の行動を省みて後ろめたい気持ちになることもある。とは言え、理想のプログラマとはどうあるべきかを知り、そこへ到達しようとするのは極めて重要だ。まずは到達すべき地点を知ることから始まる。

　ということで、職業上ソフトウェア開発者をやっている人には是非読んでいただきたい。特に、新社会人には進むべき方向を知るため、そしてこの業界に入って数年経過し、中途半端にスレた対応をしがちになっている中堅のプログラマは喝を入れてもらうために読むべき本だと思う。

リーダブルコード読んだ

 さっくり読み終わった。

リーダブルコード ―より良いコードを書くためのシンプルで実践的なテクニック (Theory in practice)

 　タイトルの通り「読みやすいコード書こうぜ！」って本。読みやすさを題材にしてるので、著者も訳者も本書の読みやすさをかなり大事にして書いたようだ。おかげでかなり読みやすかった。

　「読みやすさ」を本書では次のように定義している。

コードは他の人が最短時間で理解できるように書かなれければいけない。 

 　これは最もな話で、プログラムをするとき、コードを書く時間よりコードを読む時間が圧倒的に長い。であればコードを読む時間を短縮するのが開発効率を上げる近道になる。この定義にそって、命名規則やリファクタリングの話を展開している。

　リファクタリングについてはマーチン・ファウラーの本が有名だけど、あっちの本はリファクタリングをパターンとして定義している本で、リーダブルコードと扱っているジャンルは一緒だ。でも、読みやすさという点で、まずはリーダブルコード、その後でマーチン・ファウラーのリファクタリング本を読むのが良さそうだ。

リファクタリング―プログラムの体質改善テクニック (Object Technology Series)

 　コーディングの表現には２つの面があると思う。ひとつはモデリング等のロジカルな面。もう一つは人にやさしい、読みやすいコードの表現かどうかということだ。理想的なコーディングはこの両面を意識することでできるものだと考えている。

　コードの読みやすさというものは、結局のところ人が感じることであり、どうしたらより分かりやすくなるか、誤解を招かない表現になるかというように、より良い表現を探すなかで確立されるものだと思う。コードリーディングのありがたいところは、そういう試行錯誤の過程を描いてくれている点だ。どう考えてどう解決するべきかを示してくれている。手法よりもその裏にある考え方を本書ほど具体的に提示してくれている本はそんなに無いと思う。

　読みやすさという点で、一つ思い出した。言葉の危うさについてだ。2/10 - はきだめで書いているが、人はそれぞれの個人言語を持っている。少し引用してみる。（「外山滋比古の文による」という例題から引用）

　われわれは、ものを読むときには、テクストの文字、文章を、あるがままに見、読んでいると考えている。

　実際は、しかし、決してそうではない。いかなる読者にも必ずなにがしかの先入主がある。知識、思想、習慣、信念など比較的恒常的なものもあれば、一時的気分、好悪といったものもあろう。一人一人違う個性は、ことばをかえれば、先入主の塊のようなものであるから、先入主の全くない人は人間ではなくなる。読者にはそういう広義の先入主の編みが幾重にもはりめぐらされていて、それぞれ掩蔽を起こす。だから、人がものを読めば、決してあるがままに読めないし、また、読めもしない。

　この先入主というのを言い換えたのが個人言語だ。人はその人特有の言語体系を持っている。それは引用にあるように文章を読むときにも、自分の考えを文にするときにもフィルターのように関わって、作用してくるわけだ。

　これはコーディングでも同じだと思う。書くときに個人言語を通して表現され、それが他人の個人言語によって理解される。だからこそ、より明確に、より読みやすくなるよう、クラスやメソッド等を命名しなければならない。

　話が少し変な方向に行ってしまった。閑話休題。

　リーダブルコードで扱っている話題は、プログラマなら必ず身に付けるべき内容だと思う。ある程度コーディングしてきている人であればみんな納得する内容だし、新規性もあまりないと思う。でも、この内容を自分で人に説明して共有できるかというと、中々難しい。一緒にコードを読みつつ、少しずつコードに対する考え方をすりあわせて行くしか無い。そういう場合にこの本を渡して読ませることで考え方を共有できるというのはありがたい。

3/5

リーダブルコード

コードのスピードバンプを作らない

— たが (@yuuto) 2014, 3月 5

スピードバンプって道路でスピードを出させないようにするための段差のことらしい。コードを読む速度を落とすようなものを仕込まないようにしようってことみたい。なるほどね。

　リーダブルコードを読んでると英語が疎かだと分かりにくい部分が少し出てきた。やはりコーディングするだけでも英語は必要だと再認識した。ただ、英語圏の人には感覚的にAの表現がしっくりくるけど、日本での英語レベルだともっと平易なA'の表現の方が伝わりやすいといった場合がある。本来はAの表現にするべきなんだろうけど、コードを読む可能性のあるメンバーの英語レベルに合わせて変えていった方がいいんだろう。多分、つい最近盛り上がっていたラムダ式の是非と同じ問題じゃなかろうか。

やったこと

• forest１～７章再読
• forest問題集7章分終了
• リーダブルコード120p