はじめに
既存のコードから思想を読み取り、自分が実現したい機能に落とし込んでいくことが、自分にできていなかった。
そんな時、会社の先輩エンジニアにこの本を進めてもらったため、読みました。
開発以外の重要なこともたくさん記載があったので、自分が重要だと思った箇所を感想を含めて、まとめています。
引用文献
各章の解説
まえがき
まえがきで、「達人プログラマーになるためには？」という見出しで、どのような性格が多いか、いくつか記載されていました。その中で、自分が特に必要だと思ったのは、以下になります。
- 批判的
- 事実がはっきりするまで、額面通りに受け取らない
- 現実的
- 各問題に潜んでいる本質を理解しようとする
- ものごとがいかに難しいか、どれだけ時間がかかるのか、感覚を養っている
周りの先輩エンジニアも見ていて、自分にできていなくて、特に感じた点になります。
ここは自分も早く成長したいところ、、、
1章 達人の哲学
ここでは、達人プログラマーになるためには？の考え方がまとまっています。
その中で、自分が大切だと思った考え方は、以下になります。
Tip 3 あなたには現状を打破する力がある
Tip 5 割れた窓を放置しておかないこと
あなたには現状を打破する力がある
簡潔にまとめると、不満を感じていたら、自分の足で改善へと努力しようという話です。
不満を少なからず、誰しもが抱えると思います。
そんな中でも、ただ抱えるだけではなく、自分で行動して環境を改善していこう。その力があなたにはあると記載されています。
これはつい先日に先輩エンジニアに指摘されたところなので、自分でも気をつけていきたいところです。
割れた窓を放置しておかないこと
「割れ窓理論」というがあります。（※ ここでは詳細を省きます）
悪い設計や質の低いコードがあれば、その後に作られるコードも悪い設計のままですし、改善されないままネガティブな方向に進んでしまいます。
そうならないためにも、見つけ次第、改善するような行動をしないといけないですし、自分自身も良いコードを書くよう言い聞かせるようにします。
2章 達人のアプローチ
ここでは、開発のあらゆる局面で適用できるアイデアやプロセスがまとまっています。
その中で、自分が大切だと思った考え方は、以下になります。
Tip 14 よい設計は悪い設計よりも変更しやすい
Tip 15 DRY - Don't Repeat Yourself（繰り返しを避けること）
Tip 23 後でびっくりしないために、見積もりを行うこと
よい設計は悪い設計よりも変更しやすい
ETC原則（Easier To Change）というのがあります。
変更しやすい設計にしようということです。
ETC原則はルールではなく、実装する際の考えに役立つものです。常に実装の際に、将来的に変更しやすいかどうかを問いながら、実装するよう心がけようと思いました。
DRY - Don't Repeat Yourself（繰り返しを避けること）
本書には、以下のように記載がありました。
「すべての知識はシステム内において、単一、かつ明確な、そして信頼できる表現になっていなければならない」
単一でなければ、片方を修正しても、もう片方も変更する必要があります。
また、コードだけとは限らないと本書では記載されています。
ドキュメント、内外部API、開発者間、、、etc
既にあるものに関しては管理をして、同じものを何度も作成しないような環境を構築したいです。
後でびっくりしないために、見積もりを行うこと
タスクが振られたら、必ず見積もりは聞かれると思います。
まずタスクで尋ねられている内容を理解して、各フェーズに細分化します。
しっかり自分の能力を見誤らずに、見積もりたいところです。
あと、個人的に面白かったのが、本書で以下の記載がありました。
コーヒーの自動販売機の前で行った見積もりは、（コーヒーのシミのように）相手の脳裏から消し去られることがないのです。
、、、気をつけよう。
3章 基本的なツール
ここでは、より生産的になるために、ツールについての大切さがまとまっています。
その中で、自分が大切だと思った考え方は、以下になります。
Tip 26 コマンドシェルの力を使うこと
Tip 27 エディターに熟達すること
コマンドシェルの力を使うこと
先輩エンジニアのターミナルを見てみると、カスタマイズされていることがほとんどです。
おそらく自分が使いやすいように設定していると思います。
本所では、以下の設定を試してみては？と提案があります。
- カラーテーマの設定
- プロンプトの設定
- エイリアスとシェル関数
- コマンドの補完
自分の中で優先度は低いですが、必ず試してみようと思います。
エディターに熟達すること
私たちの多くは、VSCodeを使用していると思います。
自分はまだショートカットを使わずに、自力で修正するところも結構あります、、、
そこで本書は、熟達の目標として以下の記載がありました。（※ 一部抜粋）
- テキストを編集する際、文字や単語、行、段落で移動や選択が行える。
- 特定の行番号に移動する。
- 選択した範囲の行を並び替える。
また、マウス / トラックパッドを使用せず、キーボードのみで編集できるように心がけることも記載されています。
まだまだ自分にはできないですが、VSCodeで拡張機能を入れつつ、キーボードだけで編集できるようになっていきたいです。
4章 妄想の達人
ここでは、自分を含めた誰もが完璧なコーディングを行うことができないという事実を知り、その防衛手段がまとまっています。
その中で、自分が大切だと思った考え方は、以下になります。
Tip 38 早めにクラッシュさせること
Tip 42 少しずつ進めること - 常に
早めにクラッシュさせること
実装したコードの中で、すべての例外を補足して、再スローするやり方もありますが、コードの結合度を下げてしまいます。
できるだけ早期に問題を検出すれば、早めに停止することができます。本書では、停止せずに放っておくのは、衣類を洗濯機で20回ほど連続してかけるのと同じだと記載しています。
障害によって、中途半端に動作をしてしまうより、問題があったときにすぐ停止できるよう実装を心がけます。
少しずつ進めること - 常に
実装を進めて、レビューを出したときに、そもそもの設計がおかしくて出戻りが発生したことはありますでしょうか？
自分はあるので、このTipは結構刺さりました、、、。
遠くを見ようとせず、近いところから。
フィードバックを得た上で、先に進む前に軌道修正を加えて進みましょう。
、、、気をつけます。
5章 柳に雪折れ無し
ここでは、コードに柔軟性を持たせるための考え方がまとまっています。
その中で、自分が大切だと思った考え方は、以下になります。
Tip 44 分離されたコードは変更しやすい
Tip 49 プログラミングとはコードについての話であるが、プログラムはデータについての話である
Tip 51 インヘリタンス（相続）税を払わないこと
分離されたコードは変更しやすい
分離をうまくしないと、変更すべき箇所を全て洗い出したり、一部を修正したら動作しなかったりする可能性があります。
結合度を上げずに、変更しやすいコードを実装していきたいです。
プログラミングとはコードについての話であるが、プログラムはデータについての話である
本書では以下のように記載があります。
find . -type f | xargs wc -l | sort -n | tail -6 | head -5
ディレクトリ名
→ ファイルのリスト
→ 行数と名前のリスト
→ ソートされたリスト
→ 上位5ファイル + 合計行
→ 上位5ファイル
コードで直接考えてもいいですが、このようにデータとして考えるのもわかりやすいなと思いました。
相手に説明する際にも、有効な手段かと思います。
インヘリタンス（相続）税を払わないこと
本書では、継承によって結合度が上がったり、多重継承になる可能性があるので、おすすめをしていません。
ただ、以下3つの方法のいずれかを使えば、問題ないと記載されています。
- インターフェースとプロトコル
- 委譲
- mixin と trait
オブジェクト指向言語には、必ず起きる問題かと思います。
上記のテクニックを意識して、気をつけようと思いました。
6章 並行性
ここでは、並行処理と並列処理の考察がまとまっています。
その中で、自分が大切だと思った考え方は、以下になります。
Tip 56 並行性を向上させるためにワークフローを分析する
Tip 58 無秩序なエラーはしばしば並行処理によって引き起こされる
並行性を向上させるためにワークフローを分析する
アクティビティー図を用いて、ワークフローを分析するように本書では記載されています。
ただ、並行化できる箇所を見つけることはできますが、並行処理を行うべきかはわからないため、自分で効率よく見つけられるようになりたいです。
無秩序なエラーはしばしば並行処理によって引き起こされる
並行処理では、コードが変更可能であれば、どこででも発生する可能性があると、本書では記載がありました。
念頭にしっかり置いて、エラーがあった際はありとあらゆる可能性を模索してみようと思いました。
7章 コーディング段階
ここでは、コーディング段階における重要な考え方がまとまっています。
その中で、自分が大切だと思った考え方は、以下になります。
Tip 65 早めにリファクタリングすること、そしてこまめにリファクタリングすること
Tip 70 ソフトウェアをテストすること、さもなければユーザーにテストを強いることになる
Tip 74 適切な名前を付け、必要に応じてリネームすること
早めにリファクタリングすること、そしてこまめにリファクタリングすること
問題が小さいうちに容易に修正できるので、肥大化する前にしっかりスケジュールを組んで対応しようと本書に記載がありました。
事業の状況にもよりますが、改善できる箇所を見つけ次第、提案していこうと思います。
ソフトウェアをテストすること、さもなければユーザーにテストを強いることになる
テストはプログラミングの一部であると、本書には記載があります。
テスト駆動開発（TDD）でのメリットの記載もあり、テストの重要性がたくさん記載されています。
リリース後のテストも含めて、設計をしつつ、実装をしていきたいです。
適切な名前を付け、必要に応じてリネームすること
本書では、名前の変更は難しいため、リネームしやすい状態を作るよう記載があります。
それも大切だと思いますが、個人的には、その名前を見て、何をしているか明確になっている必要があると思います。ドキュメントや説明がなくても、名前で判断できるようにしたいです。
8章 プロジェクトを始める前に
ここでは、成功に向けるために、プロジェクトを立ち上げる「前」に重要な解決する課題がまとまっています。
その中で、自分が大切だと思った考え方は、以下になります。
Tip 78 ユーザーとともに働き、ユーザーのように考える
Tip 81 枠にとらわれずに考えるのではなく、枠を見つけ出すこと
ユーザーとともに働き、ユーザーのように考える
実際に上司に、「ユーザーがどのようにシステムを使用しているのか、実際に横で見てみると良いよ」と言われた事があります。
本書にも、仕事を横で一週間みるように記載があります。
相手の信頼を勝ち取り、良い相談者になるために、良い行動だと思いました。
枠にとらわれずに考えるのではなく、枠を見つけ出すこと
開発を進めていく段階で、手に負えなさそうな問題に直面する場合があると思います。
そこで先入観をなくす必要があると、本書では記載があります。
一旦全て解決策を列挙して考えてみたり、どうしても詰まった時は他のことをしてみると良いとあります。
自分もよく詰まるポイントではあるので、詰まったら他のことに時間を使い、頭をリセットしてから再度検討しようと思います。
9章 達人のプロジェクト
最後の章で、プロジェクトの成否を分けるいくつかの重要な領域がまとまっています。
その中で、自分が大切だと思った考え方は、以下になります。
Tip 96 単にコードを調達するのではなく、ユーザーを喜ばせる
Tip 97 あなたの作品に署名すること
単にコードを調達するのではなく、ユーザーを喜ばせる
エンジニアは「問題の解決者」であるべきと本書では記載があります。
システムを利用するユーザーと信頼関係を築いて、問題を解決していきます。
あなたの作品に署名すること
責任逃れをしないこと。
自分が実装した設計やコードに自信を持って、仕事に誇りを持ちます。
最後に
読んでみた感想ですが、初心者にとっても刺さると思いますが、ある程度開発経験をこなしたエンジニアの方にすごく刺さる本だなと思いました。
一度に全てを覚えることはできないので、必要な時にまたこの本に戻って、復習しようと思います。
ご覧いただき、ありがとうございました。