達人プログラマー
原著は1999年、日本語では2000年に出版。
2016年に、現代向けに表現を改訂した新装版が出ている。
アンドリュー・ハント／デビット・トーマス 著
技術者として駆け出しの頃以来、久しぶりに読んでみた。
自分の記憶定着及び、若手エンジニアの方への参考として、導入部分の読書メモを残す。
まえがき
誰が本書をよむべきなのか？
- より効率的、そして、より生産定期なプログラマーになりたいと願う方々
- このアプローチに従えば、飛躍的に経験を積むことができ、生産性を高め、開発プロセス全体のより良い理解が得られる
達人プログラマーの性格
- 新し物好き
- 研究好き
- 批判的
- 現実的
- 何でも屋
達人プログラマーになるためには？
自らの技術に関心を持つこと
-> 自分の技術に関心を持たない限り、ソフトウェア開発には何の意味もなくなるあなたの仕事について考えること！
-> 絶え間なく考え続け、リアルタイムで自身の作業を批判する達人と大規模チーム
-> 個人の貢献がプロジェクトを支えている継続は力なり
-> 持っているスキルを日々磨き、新たなツールのレパートリーを増やしていく
読書メモ
導入部分の第１、２章について印象に残った内容をメモに残す。
- 第１章 達人の哲学
- 第２章 達人のアプローチ
- 第３章 基本的なツール
- 第４章 妄想の達人
- 第５章 曲げるか壊すか
- 第６章 コーディング段階
- 第７章 プロジェクトを始める前に
- 第８章 達人のプロジェクト
第１章 達人の哲学
常人と達人プログラマーとの違いは、問題に対するアプローチとその開発手段についての考え方、スタイル、哲学である
１ 猫がソースコードを食べちゃった
- 問題に対してプロとして可能な限りの対処を行う努力をすること
- 無知は誤りと同じであると考え、自分の欠点について正直になること
- いい加減な言い訳よりも対策を用意すること
２ ソフトウェアのエントロピー
- エントロピーは増大していく（無秩序な度合いは増していく）
- 割れた窓を放置しておかないこと（問題のあるコードや課題を放置しない）
３ 石のスープと蛙の煮物
変化の触媒たれ
-> 道理にかなった要求を考え出し、その要求を引き出せるようそれなりのものを作り上げる。（最低限のβ版やMVP）大きな構想を忘れないようにすること
->ゆで蛙にならない
４ 十分によいソフトウェア
- 関係者にとって十分に良い(good enough)ソフトウェアを書く
- 品質要求を明確にすること
５ あなたの知識ポートフォリオ
知識ポートフォリオの管理は金融フォリオの管理とよく似ている
-
常に知識ポートフォリオに投資する
- 定期的に投資を行う
- 多角化
- リスク管理
- 安く買い、高く売る（クローズアップされる技術を一般的になる前に学んでおく）
- 見直しと再配分
見聞きしたことを批判的な目で分析すること
-
チャレンジ
- 新たな言語の学習を始めよう
- 新たな書籍を読み始めよう（コーディングを行ってるならば、設計やアーキテクチャの書籍）
- 外に出てプロジェクト以外や社外の人間と技術的な話をしよう
６ 伝達しよう！
伝える事柄と、伝える方法は車の両輪だと考えること
- 言いたいことを知る（伝達のうちでいもっとも難しい）
- 聞き手のことを知る（ニーズ、興味、能力）
- タイミングを選ぶ
- スタイルを選ぶ
- 見栄えを良くする
- 聞き手を巻き込む
- 良い聞き手になる
- 聞き手の立場になる
第２章 達人のアプローチ
ソフトウェア開発で適用可能なヒントや小技、公理となっている自明なアイディア、普遍的なプロセス
７ 二重化の過ち
- DRY - Don't Repeat Yourself
- 二重化のカテゴリー
- やむを得ない二重化（環境が二重化を要求するような場合）
- 不慮の二重化（情報の二重化に開発者が気がつかない場合）
- 手抜きによる二重化（手を抜き、簡単な方法を選ぶことにより二重化が起きる場合）
- 開発者間の二重化（チーム内の別の担当者が情報を二重化してしまう場合）
８ 直交性
直交性原則の適用によりシステムの品質はすぐさま向上していく
-
直交性とは
- ２つ以上のものごとで、片方を変更しても、片方に影響を与えないことを直行していると呼ぶ
-
直行することの利点
- 生産性向上
- リスク削減
９ 可逆性
-
最終決定などというものは存在しない
- DRY原則、結合度の最小化、メタデータの使用を貫き通すことによって、後戻りが許されない多くの重大な決定から開放される
- すべての決定が変更されないものと仮定して、不慮の出来事が発生した際の準備を怠ることに誤ちがある
-
柔軟なアーキテクチャー
- どのようなメカニズムを使用するにしても可逆性を持たせる
このあたりのことは、書籍「Clean Architecture」に詳しく解説されている。
１０ 曳光弾
-
目標を見つけるには曳光弾
- 早いうちからユーザーにものを見せることができる
- 開発者の活躍できる舞台を創造することができる
- 統合プラットフォームを手に入れることができる（デバッグやテストがより早く、より正確になる）
- デモ可能なものがある（いつでもデモできる）
- 進捗が明確になる
-
曳光弾は常に目標を捉えるとは限らない
- 狙ったものを明確にするが常にただし目標であるとは限らない
- 何度でもねらいを修正しなければならない
-
曳光弾とプロトタイピング
- プロトタイピングとはシステムの最終形態についての理解を検証するためのもの
- プロトタイピングは使い捨て
- 曳光弾は最小限度だが完全なものでありシステム最終形態の骨格の一部をなすもの
１３ 見積もり
見積方法を学習し、直感的に物事を判断できるスキルを開発することによって、実現正の判断という魔法が使えるようになる。
-
見積もり精度
- 依頼された場合、どういった文脈における見積もりであるかを知る（正確な答えが必要か、大雑把な答えで良いか）
- 期間によって使う単位を変えること勧める。使用する単位によって精度が違って感じられる（約6ヶ月よりも「130日」の方が精度が高いと感じられる）
-
見積方法
- システムのモデル化を行う
- モデルをコンポーネントに分割する
- 各コンポーネントに影響を与えるパラメータに値を入れてみる
- 答えを計算する
-
見積もりの改善
- 見積もりがまずいものであった場合、推測がなぜ違ったのか見つけ出し、解明する
- 次回よりうまく見積もれるようになる
-
プロジェクトのスケジュールを見積もる
- プロジェクトのタイムテーブルを確定する唯一の方法は、そのプロジェクト自身を実際に経験してみることが一番
- インクリメンタル開発の回を重ねる毎に正確なものとなっていき、スケジュールに対する確信も大きくなっていく
３章以降
- 第１章 達人の哲学**
- 第２章 達人のアプローチ
- 第３章 基本的なツール
- 第４章 妄想の達人
- 第５章 曲げるか壊すか
- 第６章 コーディング段階
- 第７章 プロジェクトを始める前に
- 第８章 達人のプロジェクト
読み進むためのポイント
文字数も多く、考えながら読むタイプの本のため、個人差はありますが、短時間で読了できる本ではないと思います。
技術的に古い内容もあり、とっつきずらい部分があるので、途中で挫折してしまうかもしれません。
頭から読んでみるのが難しいと思う場合は、読みやすい方法で読んで見るのが良いと思います。
第１，２章を読む
第１，２章は達人の考え方とその実践をどう進めるか。という内容のため、目を通しておいた方が良い部分です。
この２章をざっと読みましょう。
巻末のヒントとチェックリストから気になるものを拾い読む
-
ヒント
- 1.自らの技術に関心を持つこと
- 2.あなたの仕事について考えること！
・・・ - 11.DRY-Don't Repeat Yourself
-
チェックリスト
- 学ぶべき言語
- 合言葉WISDOM
- 直交性
・・・
最後に
達人プログラマーは、取り上げられている技術内容は古いため、読みにくい部分もあり、現在であればより詳細に洗練された表現をしている本も多くあると思います。
ただし、プログラマーにとって、普遍的な内容をここまで網羅している本はなかなかなく、何度も手にとって読み返すに値する本です。
一度、手にとって読んでみることをお勧めします！