ちなみに

火曜日の空は僕を押しつぶした。

ソフトウェアのプロとしての態度

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

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

Clean Coder を読みました。

日本語版は2012年発売で、去年2014年の誕生日に頂いたものだったのですが、やっとこさ読み終わりました。 貰ってすぐに前半を読んでいたのですが、途中で止まってしまっていて、今期の目標を技術書を読むことに設定したのを機に、通勤時間に少しずつ読み進めて2ヶ月くらいで読みました。 さらに読み終わってから1ヶ月ほど経過していて、とにかく怠惰。

ボブおじさんことRobert C Martinの著書で、ソフトウェアのプロとしての考え方や振る舞いについて、豊富な実体験を元に解説されている。

終始厳しいことが書かれていて、胸にグサグサくる。いかに甘えた考え方をしていることを思い知らされるのだが、つまりはこの本を読むべき対象であったということだ。

しかしながらボブおじさんも最初から優れたソフトウェアエンジニアだった訳ではない。 駈け出しのころの失敗にも触れられていて、いかにして失敗から学びプロとしての振る舞いを身につけたかということまで赤裸々に書かれている。 自分とボブおじさんは元の出来が違うんだと悲観している場合ではない。

内容についてはいろんな方がブログに書けれているので、個人的にグサッときたところを引用しておく。

ふりかえって考えてみると、ルーティンをテストせずに出荷したのは無責任だったと思う。テストを怠ったのは納期に間に合わせるためだった。自分のメンツを保つためだった。顧客のことを考えていなかった。雇用主のことも考えていなかった。自分の批判だけを考えていた。

p.35

先述のボブおじさんの失敗について書かれた一文だけれど、僕の働き方を後ろから覗かれているのかと思った。いつもいつもこれで失敗している。学びがない。毎日ここを読んで脳に刻みつける必要がある。

もし力を温存していないのなら、もし新しい計画がないのであれば、もし振る舞いを買えないのであれば、もし最初の見積もりに自信があるのであれば、試しにやってみると約束するのは不誠実である。ウソをついているのと同じだ。恐らくは自分のメンツを保ち、対立を避けるためにやっているのだろう

p.55

試しにやってみるということについての厳しく書かれている。最初の見積もり以上のことを頼まれたときに、試しにやってみて出来るのだったら最初からやれたはずだし、力を温存していたことになる。温存していないのなら出来なら試しにやってみても出来るわけがない。何か他の策が見つかったり、理解が深まって最初の見積もりより簡単に出来ることが分かっているのなら、ハッキリと出来ますと言うべきなのだ。「試しにやってみる」は言う方は無理だと思っているのに、受け手は「出来る」と取ることが多いのでまずいことになる。イエス、ノーをはっきり言おう。そのための方法は本書に書かれている。

最低でも1人の人間に対して責任を負うのだ。それは、鏡やコンピュータ画面の前でやることではない。生身の人間の前に立って、自分でやると言うのだ。

p.68

責任を持とうというコンテキスとで出てくる一文。「〜しなければならない」「〜したい」「やりましょう」。一見約束をしているように見えて、実は自分がやるとは言っていない。逃げ道を作っているのだ。 人に面と向かって「私が…までに…をやります」というのは本当に怖い。怖いのは漠然と考えているからで、なぜ怖いのかを考えて、実行出来る行動に落とし込もう。そして約束するのだ。

長時間働いていると気分が爽快だったのを覚えている。なんだか打ち込んでいる感じがした。午前3時に働くのは、熱心なプロがやることだと考えていた。だが、全部間違っていた!

p.77

去年まではこの考えてかただったし、気を抜くといまだに無限に働こうとしてしまう。疲れているとき、気になることがあるとき、そういう時に書いたコードはめちゃくちゃになる。おもしろいのはゾーンに入ったときも作業をやめようと書かれていることで、なぜかというと、フロー状態というのは軽いめまいを起こしている状態で、たいていは大局を見失っているからだという。たしかにすごい書ける時に書いたコードはあとから見たらめちゃくちゃなことが多い。あと音楽も脳のリソースを持っていくからよくないということだった。これは何か別の本でも読んだ気がする。

期待はプロジェクトの殺し屋だ。

p.86

なんとかなりそうという期待をしてはいけないし、させてはいけない。出来ないものは出来ないのだという強い意思を持ってそのことを伝えなくてはならない。

それでもやはり、QAが何か見つけたならば、開発チームは申し訳無さそうに対応しなければいけない。

p.124

QAひいてはレビューアーに不具合や問題点を見つけてもらおうという甘い考えは捨てなくてはならない。 絶対に見つけさせないという見つけられるのは恥ずかしいことだという自覚をもって、責任を持って自分の仕事を次の人に渡さなくてはいけない。 ここ最近もレビューで指摘してもらおうという気持ちで働いているという自覚があってとても反省しているところだった。プロ失格である。

プログラミングは、長時間の集中力と意識を必要とする知的行為である。集中力は何らかのリソースを消費するのだが、それはマナに似ていると思う。集中力のマナを使い果たしたら、他の活動を一時間ほど行って、回復しなければならない。

p.136

これはよく勘違いして、ぜんぜん進んでないからもっとやろうとと根を詰めすぎてしまう。実はマナが尽きているのでそういうときは思い切って別のことをする必要がある。同僚はみんなマナの回復がうまい気がする。 働き続けているとまたコードが書けるようになるときがあるのだけれど、きっとこれは書けなさすぎて思考停止することでマナが回復しているだけなのではないか。それだったら他のことをして時間を有益に使いつつマナを回復した方がよい。

先に進むのが難しいと思ったら規律を信頼しよう。自分の持つ規律は、プレッシャーのかかった状況ではガイドになる。

p.157

プレッシャーがかかるとテストを書かなくなったり、とにかく素早く書くことを注力しがちだけれど、結果めちゃくちゃになったり失敗することがよくある。自分でじっくり選んだ規律を信じて、プレッシャーがかかったときこそ例えばテストをたくさん書いて着実に前に進む方が実は目的への近道なんだということが書かれている。プレッシャーがかかっても信じられる規律を熟考して選んでおく必要がある。自分で選んだ規律だからこそ最後まで信じられる。


自分の無力さ、自分の甘え、ここ最近また強く感じている。漠然と落ち込むのではなくて、行動出来る単位に分割してしっかり約束をしていこう。責任を持つのだー。

Webエンジニアのための データベース技術[実践]入門 (Software Design plus)

Webエンジニアのための データベース技術[実践]入門 (Software Design plus)

これをいま読んでるので、読み終わり次第ブログを書く。