概要

達人プログラマー 第2版 の読書メモ

要約ではなく、個人的に刺さった箇所を雑にメモしているだけです。

第1章 達人の哲学

• 常人と達人プログラマーの違いは、 「問題に対するアプローチとその解決手段についての考え方、スタイル、哲学」 にあり、目の前の問題だけでなく、常にその問題をより大きなコンテキストで捉え、物事を大局的に見据える用途すことだ

• 達人プログラマーが行うこと全てに責任を負うことで、怠慢によるプロジェクトの崩壊を防げるようになる

• 「分からない」という言葉が口について出てきたときには、 「...でも答えを見つけ出すぞ」 と口に出すようにしよう！

• 割れた窓をそのままにしてはいけない。 発見と同時にすべて修復 しなさい

• 何らかの危機が訪れているからといって、巻き添え被害を引き起こしてはならない。1枚の割れた窓だけで多くの事態が引き起こされる

• 自分自身に向かって 「割れ窓は作らない」 と言い聞かせる

• 茹で蛙にならないように、常に大きな視点でモノを見る。個人で行っていることだけを注意するのでなく、常に周囲で何が起こっているかも注意すること

• 知識への投資は常に最高の利息がついてくる (ベンジャミン・フランクリン)

• 学んで身に着けた能力は多くの場合有効期限があるが、 新しい物事を学習するという能力は、最も重要な戦略的資産 である

• 毎年少なくとも言語を一つ学習しような

• 月に1冊のペースで技術書を読もうな

• 技術書以外の本も読もうな

• 現在のプロジェクトが扱っているものとは異なるテクノロジーに関するニュースやオンライン投稿に目を向けよう

• 学んだことを現在のプロジェクトにも適用してみよう。直接適用できなくても、なんらかのアイディアを借用できるはず

第2章 達人のアプローチ

達人プログラマが日々行っているアプローチの一部を要約

• 世の中の設計手法は多かれ少なかれ、 ETC(Easier To Change) の原則に基づいているという認識の元、コードを改善するたびに、「この変更で、システムは変更が容易になったか？」を自問自答する
• リリース後にメンテナンスフェーズが始まるのではなく、プログラマーは常にメンテナンスモードにあり、メンテナンスとは独立したアクティビティではなく、開発工程を通じて行う日常教務 であると意識する
• DRY 原則は、ソースコードの重複を排除するだけでなく、 「知識」「意図」 の二重定義を避けることにあると意識する
• 生産性の向上、リスクの低減、テストの容易さをもたらす直行性の高いシステム設計を行う
• プロトタイピングをする場合、コードは全て使い捨てるという前提を関係者全員が理解できるよう状態にする
• ユーザーは、実現してほしいことについてぼんやりとした考えしか有しておらず、詳細など知らず、気にもかけたくないと考えているため、彼らから本当の要求を引き出すために、実際に使ってみることのできるプログラムを提供する
• 誰かに見積もりを依頼された場合は、それがどういった文脈における見積もりなのかを確認する

第3章 基本的なツール

• エディタに熟達して、頭の中の思考をエディタのバッファ上に表示するまでの隔たりを限りなくゼロにしよう
• 自らが編集している姿を観察し、何らかの繰り返し作業を行っていると気づくたびに、「もっと良い方法があるはずだ」と考えるクセをつけよう
• 新たな機能、仕組みを無意識に使えるようにするには、繰り返し実行するしかない。意識的にそれを使う機会をみつけ、1日になんども使ってみれば、1週間で無意識に使えるようになるだろう
• プロジェクトメンバーが一人しかいなくても、使い捨てのコードだとしても、バージョン管理システムを使おう
• バグの原因があなたのミスなのか、他人のミスなのかは関係ない。いずれにしても「あなた」の問題なのだ
• バグの修正を始めるにあたって最初にやるべきことは、そのバグを再現することだ
• 驚くようなバグに遭遇したら、それをただ修正するだけではなく、なぜこういったミスが初期の段階で発覚しなかったのか理由を考えよう
• テキスト操作言語(awk,sed) はとにかく使い倒せ

第4章 妄想の達人

• 完璧なソフトウェアなんて未だかつて作られたことはないし、あなたが史上初の人間になることもまずないことを受け入れよう
• 自分自身が完璧なソフトウェアを作れないことを理解して、自分自身を含めて信頼得ずに、防衛的なコーディングを行う
• DbC を用いて、不正なデータ入力を最速で検知することで、後続のプログラムでクラッシュしてデバッグが困難になることを避けよう

第5章 柳に雪折れ無し

WIP

第6章 並行性

WIP

第7章 コーディング段階

• やるべきだと分かってはいるものの、恐怖心や困難さを感じて先送りにしているものごとを、1,2時間という枠を設けてやってみよう
• 我々開発者は、地雷原で働いているようなもので、毎日我々を陥れようとする罠が潜んでいる。いきあたりばったりの成功に頼るような偶発的プログラミングを避け、慎重なプログラミングを選ぼう
• テストコードは偶発的になりやすい(テストが通ってるからこのテストコードでOK的な)
• リファクタリングは、ガーデニングにおける雑草抜きや落ち葉をかき集めるような、リスクの低い、ちょっとした作業を日々実施するアクティビティーだ
• 1年前よりも、あるいは機能よりも、さらには10分前よりも良い考えが浮かんだとき、つまり何かを学んだときがリファクタリングのときです
• 「こんな重要性の低いコードに攻撃しようとする人など誰も居ない。サーバーがあることすら誰も知らない」と考えて外敵から身を守るのをやめない
• 人間の脳は、何かを近くする際、単語を最優先で処理するため、命名は非常に重要である
• 適切な名前付けが出来ない場合は、やろうとしていたことが無意味であることがよくある

積ん読化してしまったので一旦クローズ。