今週も読み物を読みながら妄想を膨らませてます。
- 作者: 和田卓人,Kevlin Henney,夏目大
- 出版社/メーカー: オライリージャパン
- 発売日: 2010/12/18
- メディア: 単行本（ソフトカバー）
- 購入: 58人 クリック: 2,107回
- この商品を含むブログ (350件) を見る
何が書かれているか
「監修者まえがき」からの引用です。
この本には73人のプログラマによる97本のエッセイと、日本人プログラマ8人による書き下ろしの10本、合計81人による107本のエッセイが収録されています。
（中略）
エッセイの内容は多岐に渡り、例えば以下のようなテーマで、各寄稿者の個性に満ちた語り口で綴られています。
- プログラマとしての勉強法について
- バージョン管理、テスト、自動化について
- コーディング規約やスタイル、レイアウトなどについて
- エディタとコマンドラインを使うか、IDEを使うかという話題（いわゆる宗教戦争）について
- 他のメンバーと協業することについて
- お客様、実際にシステムを使う利用者の方と話し、フィードバックを得ることについて
（中略）
コンピュータシステム、ソフトウェア工学の世界における改革は、しばしば個を無視した全体最適の視点で語られがちです。昔から「このツールを導入すれば」「このプロセスを導入すれば」、誰でも、どんなレベルの人を集めても成功できる -- 銀の弾丸を探し、そして失望する -- 何度となく繰り返してきました。
ソフトウェア開発には銀の弾丸はありません。良いソフトウェアを作るには、良いプログラマが必要です。
（中略）
「でも私にはプログラマとしての才能がない」そう考える人もいるでしょう。私はプログラミング能力は「才能」と「スキル」に関係があると考えています。「才能」が生得されるものとすれば、「スキル」は後天的な修練によって得られるものです。そして、良いプログラマの質を支えるものは「スキル」の方なのです。
量は質に転化します。多くの良い本を読み、様々な考えに触れ、たくさんのコードを書くことで、スキルは上達します。
この本は、様々な考えに触れてプログラマとして上達するためのきっかけ、「とびら」となる本だと考えています。様々なバックグラウンド、様々な視点から書かれた107本のエッセイが、あなたのプログラマとしての人生に影響を与え、技術者として上達することの一助となることを心から願います。
印象に残ったエッセイ
印象に残ったエッセイとその中からの引用です。
プログラマが知るべき97のこと
- 18. 学び続ける姿勢 (Clint Shank)
やはり会社は当てにせず、自らの力で学んでいくのだ、と思っていた方が確かでしょう。学び続ける姿勢を保つための手段をあげておきましょう。
- 22. 1万時間の訓練 (Jon Jagger)
専門家のパフォーマンスを研究している人たちの間では、もって生まれた才能あるレベルを超えると大きな意味を持たなくと意見の一致をみている。プロスポーツ選手になろうと思った場合、確かに最低限の才能は必要だ。だがその後、勝ち抜いていくのは、最も厳しい練習に耐えた人たちだ。
- 25. 見られて恥ずかしいデータは使わないこと (Rod Begbie)
「好事門を出ず、悪事千里を走る」
- 26. 言語だけでなく文化も学ぶ (Anders Noras)
新しい言語から新たな発想を得て、同じ問題に対して違った解決策を見つけられるようになることが大事なのです。新たな言語を学べば、従来から使っていた言語でも、より美しいコードが書けるようになることが多いのです。
- 33. オープンソースプロジェクトで夢を実現する (Richard Monson-Haefel)
本当はGoogleやApple、Microsoftなどで働いてみたいという希望を持ちながら、今は大手の保険会社から発注されたシステムを作っている、そんな人もいるはずです。
- 35. 超人の神話 (Ryan Brush)
XYZ という例外が発生したんですが、何が問題なんでしょうか？
こういう質問をする人が、スタックトレースやエラーログを提示してくれたり、問題の起きた状況について、詳しく説明してくれたりすることはまずありません。
- 40. プロセス間通信とアプリケーションの応答時間の関係 (Randy Stafford)
個々のデータベース呼び出しの所要時間が10ミリ秒だとしても、1,000回の呼び出しが必要になれば（そのくらいは珍しくありません）、全体の応答時間は10秒を超えてしまう計算になります。
- 45. 限界を知る (Greg Colvin)
特にソフトウェア技術者の場合、自分の使うシステムの、データ構造、アルゴリズム、アーキテクチャ、性能などの特性の「空間と時間の複雑性（Time and Space Complexity）」を知ることが重要になります。
- 46. すべきことは常に明確に (Dan Bergh Johnsson)
大事なのは、常に自分が何をすべきかを明確にするということです。完了する期限も必ず決めます。
- 53. 正しい使い方を簡単に、誤った使い方を困難に (Scott Meyers)
何より重要なのは、インターフェースが存在するのはユーザの利便のためであり、開発側の利便のためではないということです。
- 64. プロのプログラマとは？ (Robert C. Martin)
プロフェッショナルなプログラマの最大の特徴は「自分が責任を取る」という態度、責任感です。
- 66. いったんコンピュータから離れてみる (Robert C. Martin)
ある問題について十分に考えたら、あとは音楽を聴くなり、散歩をするなりして、脳の創造を司る部分をはたらかせてみてください。じっとコンピュータの前に座って考え込んでいるより、その方が良いアイデアを思いつくものです。
- 69. 車輪の再発明の効用 (Jason P. Sage)
- 74. 「イエス」から始める (Alex Miller)
「イエス」から始めれば、人との対立は生まれず、協力関係が生まれるのです。
- 78. テストは夜間と週末に (Rajith Attapattu)
夜間や週末にはテストサーバを動かしていないところも多いと思います。テストには是非、夜間や週末を利用すべきです。
- 79. テストのないソフトウェア開発はあり得ない (Neal Ford)
1992年にJack ReevesがC++ Journal誌に寄稿した"What is Software Design（ソフトウェアデザインとは何か）?"という記事がよく知られています。もう20年近くも前に書かれた記事ですが、今でも驚くほど真実を言い当てていると思います。
- 80. 1人より2人 (Adrian Wible)
ある調査によれば、ペアプログラミングには、生産性、作業速度を40%向上させる効果があるという結果が得られています。
- 81. エラーがエラーを相殺してしまう (Allan Kelly)
アポロ11号の月着陸のソフトウェア設計を指揮したAllan Klumppは、あるインタビューで、エンジンを制御するソフトウェアにバグがあったことを明かしています。そのバグのせいで、着陸船の動きが不安定になる恐れがあったという
のです。しかし、結果的にバグは別のバグによって相殺されたため、発見も修正もされず、アポロ11号、12号の月着陸は無事成功しました。
- 82. 他者への思いやりを意識したコーディング (Aslam Khan)
そのUbuntu の理念は"Umuntu ngumuntu ngabantu"です。これもズールー語で、翻訳すると「人間は、他の人間がいるお陰で、人間になっている」というような意味です"
- 84. 正しいアルゴリズムとデータ構造を選ぶ (Jan Christiaan "JC" Van Winkel)
for (i=0; i<strlen(s); i++) { if (... s[i] ...) }
- 88. コードは生涯サポートするつもりで書く (Yuriy Zubarev)
いつも「このコードは生涯、自分がサポートし続けなくてはならない」と思ってコードを書く。
- 89. 関数の「サイズ」を小さくする (Keith Braithwaite)
この「サイズ」は、関数を実装しているコードの量という意味ではありません（もちろん、それも重要なのですが）。そのコードが表現している数学関数のサイズという意味です。
- 91. 良いプログラマになるには (Pete Goodliffe)
両者の最大の違いは「取り組む姿勢」にあります。
- 92. 顧客の言葉はそのまま受け取らない (Nate Jackson)
その答えは実に簡単です。顧客との関わりを密にすることです。
- 93. エラーを無視するな (Pete Goodliffe)
警告を無視続けて進むと、自体が余計に面倒になってしまうのです。
- 94. リンカは魔法のプログラムではない (Walter Bright)
オブジェクトファイルのコードセクション、データセクションを連結し、定義されているシンボルと参照を接続し、ライブラリから未解決シンボルを抽出し、実行ファイルを書き出す、それだけです。
日本人プログラマによる知っておくべきこと
- 02. ロールプレイングゲーム (関将俊)
「理想のプログラマ」を演じるわけです。
- 07. 不具合にテストを書いて立ち向かう (和田 卓人)
「不具合の修正時には必ず先に不具合を再現する自動テストを書いてから修正する」
- 10. 名前重要 (まつもと ゆきひろ)
適切な名前をつけられると言うことは、その機能が正しく理解されて、設計されているということで、逆にふさわしい名前がつけられないということは、その機能が果たすべき役割を設計者自身も十分理解できていないということなのではないでしょうか。
