リファクタリング・ウェットウェア読んだ

リファクタリング・ウェットウェア ―達人プログラマーの思考法と学習法

 読み終わった。

脳みそのリファクタリングしようぜっていうオライリーらしくない本だったけど、そこそこ面白かった。脳みそがどう働いてるのか、どういう風に学習するのか、読み込みや書き込みはどうなってるのかとか、そういう内容に言及してる本。読む人を選ぶ本だなー。

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

だいたいこんな感じ。生涯学習続けていく職なので、そもそも学習ってどういうものなのか、どういうプロセスを経ているのかとかは結構興味がある。努力論もこの理由から読んだ。

努力論 (岩波文庫)

リファクタリング・ウェットウェアはエッセンスを羅列している感じで、特にまとまった内容ではないのだが、全体として脳の働きや、それに伴う行動についての分析でおもしろいものがあった。いくつか気になったポイントを羅列してみよう。

ドレイファスモデル

 1970年台にドレイファス兄弟によって考案された技術習得の過程を表すモデルらしい。詳しくは↓のサイトとかで。

エンジニアの技能レベル〜ドレイファスモデル〜

この本では達人レベルで重視される直感の働きに注目している。

無限後退

何かしらをルール化する際に問題となる無限後退。いくら詳しく説明しようとしても、言葉は全ての具象を正確に表すことはできない。言葉と具象の分かれ目を意識できるかどうかが大きなポイントだ。

比喩

あるもののとある側面、特徴を強調したいために使うのが比喩。抽象的なものを考えるのが得意な人はあまりいない。自分が認識している以上に多くの比喩に頼って考え事をしている。しかし、比喩の扱い方を間違えると、間違った認識につながる。それが次の命名の誤りにリンクする。

シンボル化による縮小の誤り、命名の誤り

シンボル化は一種の比喩だが、ある特徴を強調する代わりにその他の特徴を見えにくくする。その失われた特徴、ニュアンスによって、事実までもが失われる場合もある。命名の誤りもまた同じで、ものに名前をつけるとそれで説明できたと思い込んでしまい、思考が止まってしまう。名前を付けただけでは役に立つ理解が得られるとは限らない。

　これはコードを書くときだけの話ではなく、ものを認知する行為全体に言える。

プラトンの襞（ひだ）とブラック・スワン-不確実性とリスクの本質

ブラック・スワン[上]―不確実性とリスクの本質

具象と抽象、不確実性に対する人の認識がどれほど適当なものなのかについて書かれているらしい。

トカゲの論理(dinosaur brains)

人は進化してきた。つまり、脳も少しずつ「建て増し」されてきている。この「建て増し」された脳の、古い部分は原始的な生存本能を司っているのだが、これが現代社会における行動とマッチしないことがある。これをトカゲの論理と呼ぶらしい。具体的なトカゲの論理の反応はこんな感じ。

• 戦うか、逃げるか、怯える
• ただちに行動する
• 支配する
• 縄張りを守る
• 傷つけられたら怒りの声を上げる
• 自分と同じ＝善、自分と違う＝悪

こういう行動を起こしそうになったら、ひとまず深呼吸して落ち着くべし。

ヴィパッサナー瞑想

集中力を持続するということは、余計な雑念に悩まされないということ。これは訓練することができる。その一つが瞑想。何も考えない状態を維持するというのは思った以上に難しく、すぐにいろんな考えや思いが浮かんでくる。これらに惑わされないようにできれば、集中力が増すだろう。

というわけで

気になった所だけ挙げてみたわけだけども、一番良かったのは瞑想について。結構コーディングしているとき、設計しているときに雑念に惑わされる事が多くて困っていたところだったので惹かれた。少し瞑想試してみたが、確かに何も考えないようにするのは難しい。これも習慣にできるかどうかが鍵だと思うので、少しずつやっていきたい。

Clean Coder読んだ

読み終わり申した。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

リーダブルコード読んだ

 さっくり読み終わった。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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