毎週１冊技術書を読んでブログでアウトプットすることを目標にしており、今回は第12弾です。
今回は、 達人プログラマー を読んでまとめました。
より良いプログラマーになるための実践的なアドバイスが多く含まれている名著なので、ご存知の方も多いと思います。
400ページ弱と割とボリュームはありますが、やはり名著であり学ぶことが多かったので定期的に読み返そうと思える技術書でした。
できる限りエッセンスはまとめたつもりなので、本書の内容にご興味ある方はこの記事を読めば概要は掴めると思います。
まえがき
-
達人プログラマーになるためには、日々の意思決定、あるいは各開発における全ての意思決定に対して継続的かつ批判的な評価をする必要がある。絶え間なく考え続け、リアルタイムで自らの作業を批判的に見るべき
第1章 達人の哲学
-
「壊れた窓」（つまり悪い設計、間違った意思決定、質の悪いコード）をそのままにしてはいけない。発見と同時に全てを修復するべきである。もし正しく修復するだけの十分な時間がないのであれば、その旨をわかりやすいところに明記しておく。チームやプロジェクトのコードが清潔で美しいものである場合、それを汚さないよう細心の注意を払うはずであり、それを維持することが重要
-
毎年少なくとも一つの言語を学習する。言語が異なると、同じ問題でも違った解決方法が採用される。つまり、いくつかの異なったアプローチを学習することにより、幅広い思考が可能になる
-
仕事における伝達のうちで最も難しいことは、自分の言いたいことを明確にすること。何が言いたのかを練り、次に概略を書く。そして、自分自身に対して「これで言いたいことの意味が伝わるだろうか？」と問いかける。その後、満足するまで磨きをかけていく
第2章 達人のアプローチ
-
直交性とは、2つ以上のものの独立性、分離性を表している。片方を変更しても他方に影響を与えない場合、それらは直交しているという。コンポーネントが互いに独立していると、他の部分を気にせずに変更することができる
-
見積もりを尋ねられた場合、まずそれがどういった文脈における見積もりなのかを知る必要がある。正確な答えが必要なのか、もしくは大雑把な答えで構わないのかを理解する
第3章 基本的なツール
-
シェルに慣れ親しむことによって、生産性は向上する
-
バグについて、最初に与えられた情報よりも多くの情報を集めるには、バグを報告してきたユーザーにインタビューするのが早い場合もある
-
問題の原因を探し出すための非常に簡単で効果的なテクニックとして、「誰かに説明する」という手法がある。他人に問題を説明するには、まずコードを精読し、その中に存在する暗黙の仮定を明確にしていかなければならない。いくつかの仮定を言葉で表していくことで、問題に対する新たな見識が突如としてひらめくことがある
第4章 妄想の達人
-
トラッシュ（メチャクチャ）にするのではなく、クラッシュ（停止）させる。通常の場合、障害を抱えて中途半端に動いているプログラムよりも死んだ（停止した）プログラムの方がダメージは少ない
第5章 柳に雪折れ無し
-
コードに柳の枝のような柔軟性を持たせることができれば、雪の重みという外界の変化に負けないようになる。柔軟性を保つ良い方法はコード量を減らすこと
-
機能に対するデメテルの法則の目的は、任意のプログラムにおけるモジュール間の結合度を最小化しようというもの。これを実現するためには、直接関係のないメソッドへのアクセスを出来るだけ避けるようにすれば良い。エラー発生率はメソッドから直接起動されている機能の数に比例するという結果もある
-
モデルからビューを分離すると、同じデータモデルを使って複数のビューをサポートできるようになり、柔軟性の高い設計となる
第6章 コーディング段階
-
常に何をやっているのかを意識する
-
完全に理解していないアプリケーションを作成しようとしたり、なじみのない技法を使おうとしない
-
信頼の置けるものだけを前提とする。偶然や仮定に依存してはいけない
-
仮定をドキュメント化する
-
過去のしがらみにとらわれない。既存のコードによって未来のコードが影響されないようにする。陳腐化したコードがあれば、それが全部であっても書き換える
-
理由の分からないものが動いているように見える場合、それが単なる偶然なのかどうかを確認する
-
リファクタリングと機能の追加を同時に行ってはいけない
-
リファクタリングを始める前に、しっかりしたテストが用意されていることを確認する。そして出来る限り頻繁にテストを行う
第7章 プロジェクトを始める前に
-
要求ドキュメントを生成する際に最も注意しなければいけないことは、過度の記述をしてしまわないようにすること。良いドキュメントは、ビジネスにおける必要性を正確に反映していて、かつ簡素な記述である
-
多くのプロジェクトの失敗原因として、スコープの増大がある。増加していく要求を管理するための鍵は、プロジェクトのスポンサーに対して、各新機能がスケジュールに与える影響を指摘していくこと
-
プロジェクトの用語集、つまりプロジェクト内で使用するすべての特殊な用語と語彙を1箇所にまとめて定義したものを作って、それを管理すべき。プロジェクトの参加者は、エンドユーザーからサポートスタッフに至るまで全て、この用語集を使うことによって整合性を保証できる
-
問題が思っていたよりも難解であることに気がついた場合は、以下を自問する
-
-
もっと簡単な手段は存在するのか？
-
-
-
本当の問題を解決しようとしているのか、それとも末端の問題にとらわれているのか？
-
なぜそれが問題なのか？
-
解決を難しくしている真の原因は何なのか？
-
この手段でやり遂げなければならないのか？
-
そもそも解決しなければならない問題なのか？
-
第8章 達人のプロジェクト
-
ブランドを確立するという手法でチームを一体化させることもできる。プロジェクトの立ち上げ時に、皆でそのプロジェクトに対して突飛な名前を付ける。これによってチームにアイデンティティーを与えるとともに、一丸となって仕事を行うための世界観も醸成できる。
-
優れたプロジェクトでは成果物のコードよりも多くのテストコードが存在する。長期的な観点に立った場合、テストコードの生成に時間をかけたとしても、最終的にコストは低く抑えられるうえ、欠陥がほとんどない製品を生み出せる可能性も上がる
-
プロジェクトのテストは、何をテストするか、どのようにテストするか、いつテストするかという3つの観点で実施方法を考える必要がある
-
変数名には、意味のある名前をつけなければならない。コードを書くのは数回で済むが、コードを読むのは何百回にもなるためである
-
プロジェクトの成功というものは、ユーザーの期待にどの程度答えたかによって現実的に判断される。ユーザーの期待を下回ったプロジェクトは、どんなに素晴らしい成果物を構築したとしても失敗したと見なされる
-
ユーザーが言葉で表現しきれていない期待を、ユーザーと共に作業することによって、開発プロセスや最終成果物に関する理解として共有する必要がある
おわりに
ここまで読んでいただきありがとうございます。
「毎年少なくとも１つの言語を学習する」というアドバイスはとても有名ですよね。
さらに僕は、勤めている会社で面白いプロジェクト名をつけている理由が分かりました 笑
PJに面白い名前を付けてる理由はコレか！！
— ゆうすけ@Railsエンジニア (@ysk_pro) 2018年10月21日
> プロジェクトの立ち上げ時に、皆でそのプロジェクトに対して突飛な名前を付ける。これによってチームにアイデンティティーを与えるとともに、一丸となって仕事を行うための世界観も醸成できる。
達人プログラマー(https://t.co/oPixwlWb9S)からの抜粋
以前読んでまとめた、「プリンシプル オブ プログラミング」 にも、より良いプログラマーになるための示唆が多く含まれていたので、↓の記事も合わせて読むのがオススメです。
次は、UNIXという考え方 を読む予定です。
こちらもかなり有名な技術書なので読むのが楽しみです。
来週も頑張ります！
