[書籍]SEのホンネ話―会社じゃ言えない

結婚式の招待状が出来上がってきた。けっこう重たいなあ。

==

本屋さんで目当ての本がなくて、ちょいとマンガチックな本を買ってきた。

SEという人たちはこんな生態ですよ～、みたいなエッセイ。SEと一口に言ってもいろいろな人や業種や会社があるので、当たらずとも遠からず、といった印象だったけれど、休日に読むにはちょうどいいかな。アットマークアイティの4コママンガもけっこう暇つぶしに読んでますが、それに似た感じ。

p17　プログラマは芸術家？

聞いたことあるかも。これって中学や高校の数学の問題を解くのとおんなじで、コードを書く人は例外もあるだろうけど、たいていはエレガントな解法を欲してしまう特性があるんだろうね。テストを専門にしている方々ももしかしたら同じようなことがいえるのかな。どれだけ少ない負荷・労力で、どれだけ高品質・網羅されたテストを設計・実施・管理するか。みたいな。

p105　コーディングスタイルを決めるモノ

コーディングの癖は誰にでもあって、同じ人でも時期によってブームがある（と、僕は思っている。僕がそうだ）。たいていC言語で実装しているので、例えば変数名だとか、関数名だとか、ソースファイル名だとか、よくある癖だったり、設計に絡んだ癖もある。復帰値の型の癖。構造体の名前の癖。コメントの癖。バージョン管理システムへのcommitタイミングの癖。etc

今の自分のブームは、やっぱりテスト（動的テスト）がしやすいように実装すること。かな。本の中でも言及されているが、

その会社では、設計がアバウトで許されていたこともあったけれど、試験などはさらに輪を掛けたアバウトさであった。正直なところ、「試験」というよりも「動作確認」と言った方が実状に沿っていたのだ。

（中略）

実際のところ、本当にめんどくさい試験というのは、ソースコードレベルまでを精査するホワイトボックス試験なのだ。

（中略）

そうすると、じゃあせめて楽になるようにと、ひとつひとつの関数をコンパクトにしたり、各分岐条件をシンプルで読みやすいものにしたりするようになった。いつしか、「試験することを前提としたコードの書き方」に変容していったわけである。

「ホワイトボックス試験」もそうだし、「試験することを前提とした～」もそうだし、知識としては本を読んだり、ネットを調べたり、先輩に聞いたりするとわかることだが、実際に自分が必要になったときに得られる知識であれば、なおさら血になり肉になりやすいのかな。はやりの「リファクタリング」ってのはこれとは少し違うものなのかな。