プログラマが知るべきこと

More than 3 years have passed since last update.


引用

プログラマが知るべき97のこと

http://amzn.to/1fjzZ36

http://bit.ly/1k7KAaP


対人関係/心理


[03] ユーザが何をするかを観察する(あなたはユーザではない)

http://bit.ly/1Cujdh0


私達はどうしても、誰もが自分と同じようなものの見方や考え方をするはずと思っていしまいがちです。しかし実際には、ものの見方や考え方はひとによって大きく違っています。こういう誤った思い込みのことを心理学では「偽の合意効果」とよびます。自分と考え方や行動が違っている人を見た時、私たちは(多くの場合は無意識に)、そういう人たちを、なにか問題のある人、というふうに評価してしまいがちです。



[28] 「魔法」に頼りすぎてはいけない

http://bit.ly/1k7OAI9


自分が積極的に関わらない仕事に関しては、無意識のうちに簡単だと思ってしまうし、まるで「魔法」のように自動的にできるような錯覚に陥ってしまうのが人間の常です。



[74] 「イエス」から始める

http://bit.ly/1ZgXpPZ


たとえば、誰かが「このアプリケーションのウィンドウを全部、円形で半透明にしてくれたら嬉しいんだけど」と言ってきたとします。こういう要望は、「バカバカしい」と即座に拒否することもできます。そうはせずに「どうしてですか」と尋ねるようにすると、その方が良い結果になることが多いのです。尋ねてみると、円形で半透明のウィンドウが欲しいと思う、何か切実な理由が本当にあるかもしれません。



[91] 良いプログラマになるには

http://bit.ly/1OdBnpj


ソフトウェア会社で長年働いた経験から、1つわかったことがあります。それは、良いプログラマとそうでないプログラマの違いです。両者の最大の違いは「取り組む姿勢」にあります。良いプログラマの姿勢は、プロフェッショナルという言葉にふさわしいものです。常に、最大限の力を尽くして良いコードを書こうとします。リソースの制約のある中、早く作業を終わらせろと会社が圧力をかけてくる中、それでもできる限り良いコードを書こうと努力をするのです。



働き方


[36] ハードワークは報われない

http://bit.ly/22flfxU


脳外科医が週60時間も執刀していたとして、そんな医者にかかりたいと思うでしょうか? かかりたい人はいないはずです。プロには、備えるための時間、知識と技術を高める時間がどうしても必要なのです。

仕事には長い時間を書けず、集中して短い時間で終わらせるように心がける。より効率的な問題解決方法を探す努力を常にする。プロジェクトに貢献するというのはそういうことです。



[46] すべきことは常に明確に

http://bit.ly/22flfxU


大事なのは、常に自分が何をすべきかを明確にするということです。完了する期限も必ず決めます。もし、期限内に予定の作業が終わらないようであれば、その間に書いたコード、コードに加えた変更はすべて破棄します。再度、小目標を立て直して作業内容を検討し、はじめからやり直すのです。次に何をすればいいかがすぐにわからない時は、やはりあれこれと模索するのですが、大事なのは「いつの間にか手探り状態になっていた」ということを絶対に避けるということです。模索段階で、書いたコードを決してレポジトリに入れてはいけません。



[80] 1人より2人

http://bit.ly/1IZXfIy


ペアプログラミングのパートナーから、今まで知らなかったキーボードショートカットを教わったとして、それによって得られる長期的な利益はどのくらいでしょうかペアを組むことによって、ソフトウェアの品質は全体としてどのくらい向上するでしょうか。それを評価する方法はあるでしょうか。難しい問題に直面した時も、2人であれば行き詰まらずに解決できることが多いですが、その効果が具体的にどのくらいか知ることはできるでしょうか。ある調査によれば、ペアプログラミングには、生産性、作業速度を40%向上させる効果があるという結果が得られています。ただし、効果を定量的に評価することは難しいようです。



原則


[22] 1万時間の訓練

http://bit.ly/1Pcjla7


専門的な技術や知識は、ゆっくりと徐々に身につくものです。1万時間が経過した途端、急に身につく、というわけではありません。それでも、ともかく1万時間やる、ということが大切なのです。ただ1万時間と言ってもそれは膨大な時間です。週に20時間なら10年かかることになります。「1万時間努力したはいいけれど、結果、自分にはエキスパートになる素質がないとわかるだけかもしれない」そう心配する人はいるでしょう。そんな心配はいりません。エキスパートには必ずなれます。

ただ反復訓練をすればいいというのではなく、自分の現在の能力を少し越える課題に取り組むことが重要である。それで自分の限界を引き上げるのだ。困難な課題に挑戦し、その結果をよく分析し、なにか失敗すれば修正する、その繰り返しである。



[29] DRY原則

http://bit.ly/1NYFVEh


DRY(Don't Repeat Your Self:繰り返しを避けること)原則

ソフトウェア開発に関わる作業の多くは「同じことの繰り返し」です。つまり作業が何度も重複します。この重複は、自動化によって容易に解消できます。

ソフトウェア開発に関する原則には、他にもDRY原則に関連するものがいくつかあります。OAOO(Once and Only Once:1度、ただ1度)原則はその1つです。これは、コードの機能、ふるまいについてのみ適用される原則で、DRY原則を特殊化したものと考えることもできます。OCP(Open/Closed Principle:開放/閉鎖原則)というのもあります。これは、クラスなどのプログラム単位は、拡張にに対して「開いて(open)」いなくてはならず、反対に、修正に対しては「閉じて(close)」いなくてはならない、という原則です。この原則は、DRY原則が守られている場合にのみ有効です。他には、SRP(Single Responsibility Principle:単一責任原則) という有名な還俗もあります。これは、「クラスに変更を加える理由は2つ以上存在してはならない(1つの変更の理由は常に1つでなければならない)」という原則で、やはりDRY原則が守られている場合のみに有効です。



[34] API設計の黄金律

http://bit.ly/1T7yRVH


APIを提供するときは、API自身のテストだけでなく、必ずそのAPIを利用するコードのユニットテストも書く」APIの設計者は、これを黄金律にして欲しいと思います。



[73] 単一責任原則

http://bit.ly/1ZgXpzk


良いシステムデザインとは、システムのコンポーネントがそれぞれ独立してデプロイできるようになっているデザインのことです。独立してデプロイできるというのは、あるコンポーネントに変更を加えたからといって、別のコンポーネントの再デプロイは不要であるという意味です。



[107] 名前重要

http://bit.ly/1BJYV5u


適切な名前をつけられると言うことは、その機能が正しく理解されて、設計されているということで、逆にふさわしい名前がつけられないということは、その機能が果たすべき役割を設計者自身も十分理解できていないということなのではないでしょうか。