プログラミング格言集

ビル・ゲイツの言葉

ビル・ゲイツ(Bill Gates)は、ポール・アレンとともにマイクロソフトを創業した人です。

Measuring programming progress by lines of code is like measuring aircraft building progress by weight.

（訳）行数でプログラムの進行状況を知る事は、重さで飛行機の出来上がり具合を知るようなものだ。

ソースコードは無駄に長ければ、メンテナンスが難しく、発見しにくいバグを混入してしまいます。

にもかかわらず、大量のソースコードを作成することを評価されることがレベルの低い開発現場では発生しがちです。

プロジェクトの管理者（評価者）は、短く洗練されたソースコードこそ価値があることを知るべきです。

プログラミングで最も難しい点は、アルゴリズムをどうするか決めること。そして、それをできるだけ単純化すること。 

グレース・ホッパーの名言

グレース・ホッパーはCOBOLの開発者です。

もしそれがよい考えなら、思い切ってそれをしなさい。
許可をもらうよりも、謝るほうが簡単だから。

先進的で挑戦的であれということですね。

ポール・グレアムの名言

ポール・グレアムはイングランド出身アメリカ在住のプログラマーで、「ANSI Common Lisp」や「ハッカーと画家」の著者として有名です。

単に問題の解き方を変えるということではなく、解いている問題自体を変えるのだ。

物事の見方を変えて、発想を転換していくことが大事です。

マーティン・ファウラーの名言

マーティン・ファウラーは、アジャイルソフトウェア開発宣言の起草を支援するなど、特にオブジェクト指向分析やオブジェクト指向設計において、ソフトウェア開発業界に多くの影響を与えている人物です。

どんなプログラマーでもコンピュータに理解できるコードは書ける。 しかし人間に理解できるコードは、優秀なプログラマーにしか書けない

著書の「リファクタリング」は、ソフトウェア業界に大きな影響を与えています。

出典不明

最悪のPDCAサイクル

実際の業務では「Plan-Do-Check-Action」サイクルを上手く回せていないことが多々あります。
プロジェクト開始当初は、進んで目標・計画は立てて資料を作成するが、行動はしない（モノを作れない）。
確認や原因分析をして見栄えの良い資料を作成するが、実際の改善行動は起こさない。
個人的な偏見ですが、文系の人たちの特徴だと思います。

Plan（計画）→Delay（遅れる）→Cancel(中止する)→Apologize（謝る）

Plan（計画）→Delay（遅れる）→Change(仕様変更)→Apologize（謝る）

Plan（計画）→Disaster（破綻）→Chaos（混沌）→Action（とにかく何とかする）

Plan（計画）→Doomsday （最後の審判）→Catastrophe （大惨事）→Apocalypse （黙示録）

いろいろなパターンが生まれているようです。
なお、PDCAがうまくいかない原因のうち、最も多いのがPlanの段階での問題とされているようです。
次世代版としてOODA（Observe（観察）→Orient（判断）→Decide（決定）→Act（実行））ループとか提唱されてきているようです。

開発現場において

やっつけ仕事は評価が高い

洗練された成果物でないにもかかわらず、急ぎの件が間に合ったと好評価されることがあります。

一時しのぎで作成したプログラムは、ソースコードの量も無駄に多く、将来の保守性を一切検討していない場合が多々あります。

にもかかわらず、開発経験が乏しいプロジェクト管理者はこのような対応を評価してしまいがちです。

対偶は「丁寧にした仕事は評価されない」になります。

楽ができて得をしたのは引き継いだ人だったりします。

無理な仕事を頑張るのはプロではなく、無理な仕事を事前に無理と判断できるのがプロであることを知るべきです。

プログラマーについて

真のプログラマは、楽をするためにはどんな苦労も厭わない。

バグについて

次の日ぱっと見ると一瞬で原因がわかる。

原因不明のバグに対して解決する手がかりすらが見つからない場合には、潔く諦めることが最良の対応となることがあります。

ダック・タイピング（duck typing）について

"If it walks like a duck and quacks like a duck, it must be a duck"
（もしもそれがアヒルのように歩き、アヒルのように鳴くのなら、それはアヒルである）

Rubyコミュニティでデーブ・トーマスがこの言葉を使ったと考えられています。

オブジェクトを特徴付けるのは種類(クラス)ではなく振る舞い(メソッド)であるという意味です。

同じ操作を行えるならば実際は違うものであっても、その違いは気にせずに共通化することができるという考えです。

Rubyなどの動的型付けオブジェクト指向プログラミング言語に特徴的な型付けの作法です。