■

「プログラマが知るべき97のこと」を読む。

面白かった。タイトル通り、世界的に著名なプログラマがプログラミングの心構えを２，３ページのコラムとして書いたもの。日本からはRUBYの開発者でもあるまつもとゆきひろ氏等が参加。特に響いた言葉を備忘録としてまとめておこう。

・エドワード・ガーソン　「関数型プログラミングは参照透過性を高める」

・フィリップ・ヴァン・ラーネン　「コーディング規約を自動化する　→自分の書いたコードを私物化出来ないようにするため」

・ヨルン・オルムハイム　「美しいコードとは、突き詰めればシンプルなコードのこと」

・ジョヴァンニ・アスケプローニ　「コンポーネント、ライブラリ、フレームワークを組み合わせて作る。」

　・「インフラコードよりもビジネスドメインに注力する。」　

　・「広く使われているコンポーネントやフレームワークの方がバグが少ない。」

　・「特定のツールに依存するとベンドロックインしてしまうので、保守性、パフォーマンス、拡張性などを考慮して適切に使う。」

　→要するに、最低限のツール導入から始める。という戦略。

　・「見積もりとターゲットとコミットメントの違いを明白にすること。」

　→いつまでに何をする、とコミットメント(約束)するのと、何をするために何日かかる、という見積もりを取り違えてはならない。

・スティーブ・Ｐ・バーチャック　「すばやくデプロイ、こまめにデプロイ」

　→コストを抑えるため。

・スコット・マイヤーズ　「正しい使い方を簡単に、誤った使い方を困難に」

　→誤った使い方がそもそもできないような設計を心がける。

・カーク・ペパーディーン　「ポリモーフィズムの利用機会を逃さない。」　→if then else箇所はポリモーフィズムで代理できないか考える

。

・マイケル・フェザーズ　「APIを提供するときは、API自身のテストだけでなく、必ずそのAPIを利用するコードのユニットテストも書く。」

・ヨハンネス・ブロドワル　「無駄な警告を排除する。」→コスト削減のため。必要なログが埋もれてしまうリスク。

ニール・フォード「橋のように形あるものをテストするのは容易なことではありません。(略)一方ソフトウェアの場合、とりあえず作る、ということにかかるコストは橋などに比べると圧倒的に安くなります」

ウォルター・ブライト「リンカは魔法のプログラムではない」

ニクラス・ニルソン「ステートに注目する」何か操作しようとすれば、まず現在どのステートにいるのかを確認する必要があります。その時々のステートによってできる操作とできない操作があるからです。

和田卓人「不具合にテストを書いて立ち向かう」

(テスト駆動開発について)不具合の修正時には必ず先に不具合を再現する自動テストを書いてから修正する。