[アウトライン] ベタープログラマ
謝辞
- 訳者である @yoshiki_shibata さんに内容に問題がないことを確認頂いたことを感謝します
- 8章あたりまでなので、内容に過剰に触れていると判断された場合は速やかに削除します
- アウトラインは書きますが、直接的な内容は書かないことをご了承ください
- 本当によい本なので買いだと思いますよ！
- 正確な内容を避けるため、本稿ではh2よりも深い複雑さを避ける様にしています
- 各項目自体が非常に読みやすく、ためになるので2,3章読みたいという意味でも手にとって読むことを推奨します
概要
- まずは大枠を読んでみてそれぞれの章で自分に必要な考え方を学ぶ
- 読んでもらいたい良著なのでまとめています
- これを読めばいいやってならずに、書籍を読んでむしろフィードバックください
- あなたや、あなたの同僚がよいエンジニアであり、いつか一緒に働けることを幸せだと思えるなら本望です
1章 コードを気にかける
- なぜ、この本を手にとったか、そしてこの本が伝えるであろうことを示す
2章 見かけのよい状態を維持する
- レイアウトや命名に関してのよくある話
- このあたりはコードを書く前に決定して本質的な問題に目を向けるためのもの
- 読む相手を意識しよう
- あなたのコードを読む読者は二人いる、それはコンパイラと人間のプログラマだ
- あと、チャンク化して意味を持たそうぜ
- 個人的にはPBPの内容を思い起こした
3章 少ないコードを書く
- 簡潔に書け
- かつてのソフトウェア業界にはびこったステップ数みたいのはクレイジー
- コピペすんな共通化しろ、DRY原則守れ
- 使われないコード、見ればわかるコメントは不要
- 冗長な表現はよくない
- プログラマが知るべき97のことでもボーイスカウト精神に触れていましたね
4章 取り除くことでコードを改善する
- 本当にコードを書くことが必要かを見極める
- YAGNI守ろう
- 不要なコードは消そう
- VCS使おう、使っているなら復元は容易だ
- ここ で書かれている内容を想起させますね
5章 コードベースの過去の亡霊
- 過去の自分を探索しよう
- 平均的なプログラマはソフトウェアを一生メンテすることはない
- 正しいものは常に遷移する。TPOをわきまえてコードを書こう
- かつての自分との対面は自身のバグによるもの
- 時代の変遷によりよいコードの定義は変わっていく。受け入れよう
- 時代の変化を感じないのであれば学んでいないことの兆候
6章 航路を航行する
- コードをどこから見ていくかという課題
- 同僚、もしくは健全なOSSを使っているのであれば助けてくれる人はいる
- 環境に依存する様なハードコードするな死ぬぞ
- 優れたテストはそのプロジェクトであるかを測る材料だ
- ディレクトリ構成もコードと同じく品質の一つである
- 結果的にアーキテクチャ大事
- 疑わしいコードを書いた過去のメンバーを知ることも必要
- エラーレベルを引き上げよう
- 小さく始めよう
- テストを書こう
- 使いやすくしよう
- 形式知大事
- 伊藤直也さんも言ってましたね
7章 汚物の中で転げ回る
- 呪われたコードの存在を示す章
- 書いた人間が誰であれ、不快なコードはある(自分のコードも同様である)
- 汚いものをキレイにするために必要な心構え
- キレイにするためのコストを考えよう、他に出来ることがあるかも知れない
- ボーイスカウト精神を持とう
- 1度に行うべき変更は１つにしよう
- 「できの悪い」コードをとがめる必要はありません
- 整理する機会を楽しもう
- かつての競合なんだけどこの記事とても好きです
8章 そのエラーを無視するな！
- 失敗の重大性を認識することは大事(些細なことでも重大だったりする)
- エラーを注視しよう
- エラーを無視するな！伝えたいことはこれだけだ！！
9章 予期せぬことを予期する
- いかにエラーを捕捉するか、そしてユーザに伝えるか
10章 バグ狩り
- デバッグに費やされる時間は年間3,120億ドルと試算されている！！
- 少しの予防策は何百倍もの治療薬に匹敵する
- 最初にバグを出さないことを目指そう
- コードレビュー、ペアプログラミング、テスト戦略
- デバッグは最初にコードを書くよりも2倍難しい
- 再現手順大事！
- ログ大事！
- 切り分け大事！
- 古の技術を知ることも時には大事
- テストしよう
- よいツールを使おう
- バグを保持しない
- 影響範囲を考慮しよう
- 再現できないバグはその隠れ家を知るための罠を仕掛けよう
11章 テストの時代
- なぜ、テストをするのか？
- テストを書くべき人間はコードを書いた人間
- テストの種類やスコープ
- テストにも名前は大事！
- テストフレームワークの重要性、テストもメンテするべき対象である
12章 複雑さに対処する
- 役割と責務を腹落ちさせ、適度な粒度に分解せよ
- コードは複雑に絡み合い、孤島の様に振る舞うことは稀である
- 人間が意図して複雑さを生み出すわけではない
- 複雑でない状態を保つために必要なことはコードを書く人間が責任を持って努めること
13章 二つのシステムの物語
- ソフトウェアと建築は意味的な設計は似ている
- 幸運なソフトウェアはアーキテクトによって綿密に設計されている
- 経験は優れた教師
- よろしくないソフトウェアは狂った様に突進しながら投入されていく
- こういったプロダクトはひどい設計の上に成り立ち、さらにひどい実装が行われていた
- 理由はレイヤや、粒度といったことへの無関心
- チームの人間関係の健全さはソフトウェア設計に直接影響を与える
- 複雑なシステムはテストを書くことが困難である
- 問題は更なる問題を生み出す
- 複製と車輪の再発明が悪循環を生み出す
- I/F大事
- でも必要ならそのI/Fを変更することを恐れずやろう！
- 最悪な行為は、理解できないものを設計すること
- 現実的な選択とずさんな選択は異なるコードは単体テストされるべき
14章 ソフトウェア設計とは
- 今日のソフトウェアの多くは誤った方法で書かれたコードである
- 誠実な開発者は正しい方法で開発することを熱望すべき
この先を読み進めることを避けたほうがいい貴方へ
- プログラマとして向上したいですか？
- 正しい方法で正しいものを 実際に作ってみたいですか？
- あなたの答えがNoであれば、ここから先へ進むことはヤメましょう
- 個人的にはこの3月のライオンの零くんの叫びを思い出しました
- ソフトウェア開発のプロセスは下記の要素からなる芸術的なものである
- 創造的
- 美的
- 職人的
- チームが主体
- ソフトウェア開発を科学であるとすれば下記を意味すべき
- 厳密さ
- 体系的
- 洞察に満ちている
- スポーツと同様にソフトウェア開発には以下のことが伴う
- チームワーク
- 規律
- 規則
- ソフトウェア開発は子供の遊びを通して成長することに似ている
- 学習
- 単純さ
- 楽しむ
- ソフトウェア開発は下記の様な退屈な仕事を伴うこともある
- きれいに掃除
- 裏方で働く
- 保守
15章 規則に従って競技する
- 規則に従おう
- 規則があるおかげでスポーツは公平である
- 規則があるおかげで旅は安全になる
- 規則があるおかげで開発を他の誰かと行うことができる
- 3つの重要な原則
- 単純に保つ
- 頭を使う
- 変わらないものはない
- 規則を決め、時間の経過とともに(チームの成長に合わせて)メンテする
16章 単純に保つ
- KISS(Keep, it simle, stupid)であれ
- 単純さは優れた目的
- 自分のコードに単純さを求めて努力すべき
- 開発者の世界の２つの単純さがある
- 誤った単純さ
- できるだけ容易な方法でコードを書く
- 手抜きをし、厄介で複雑なものをすべて無視する
- 間抜けなプログラミングである
- これらを満たすコードは何かしらの複雑さを持っている
- 頭を使わないやり方は単純なコードではなく極度に単純化されたコード
- 極度に単純化されたコードは正しくないコード
- このようなコードはのたいていは主要な処理だけを行うだけだったりする
- 単純さは、正しいコードの言い訳にはならない
- 正しい単純さ
- 単純な設計
- 使うのが容易
- 誤用を防ぐ
- 大きさが重要(ここでいう大きさはコンポーネント単位の大きさ)
- 短いコードパス
- 安定性
- 単純なコード行
- ただし、コードが単純に見えるかは好みや慣れによる部分も多い
- 単純に保ち愚かにならない
- 絆創膏を貼ることで工数を短くすることはできる
- だが、これは新たな問題を生み出しただけに過ぎないことが多い
- 修正を受け入れ、単純さを維持するためにコードを書き直す
- バグ修正のための正しいつなぎ目を作るためにロジックをリファクタリングせよ
- これを行うことで長期的な利益がもたらされるだろう
- 想定は単純さを減少させる
- 暗黙の想定を避ける
- 早まった最適化を避ける
- 最適化は単純さとは正反対
- 時期尚早の最適化はプログラミングにおけるすべての悪の根源
- 最初に書くべきは明瞭なコード
- 標準的なことを行いスピードが必要であればまずは測定する
- 単純さは下記の点において十分さに結びつく
- 主要なロジックだけを行う単純さを求めず、十分な単純さを求める
- 使われないコードを書かずに十分なだけの量のコードを書く
- 解決方法を過剰に複雑にせず、当面の課題だけを解決してください
- 単純な結論
- 絆創膏による修正やコードレビューの省略、時間のなさはとっちらかったコードを生み出す
- 上記が行われた後には健全性を回復するのが困難となる
- YAGNIは機能の十分さについて述べている
- DRYはコードの大きさについて述べている
17章 頭を使いなさい
- 愚かにならない
- リリースを急ぐとプレッシャーのあまり愚かなコードを生み出す
- うっかりして設計を過剰に複雑にしない
- 誰でも間違いはありうる
- 終始一貫して完璧なコードを書ける人間なんていない
- 間違った時は素直に間違いを認めて作ったものを取りやめよう
- 機能不全なコードにすがって顔をつぶすよりも勇気を持って優れた行動をとろう
- 不注意を避ける
- 全体像を考慮する
- 周りのコードが正しいかを確認する
- 差し迫った問題だけを解決しようとすれば深みにはまることは容易
- これらを怠ると愚かなコードが生み出される
- 不注意にコードを書かない
- これらの罠を避けるために下記を行うことが考えられる
- 設計レビュー
- ペアプログラミング
- コードレビュー
- 考えてよいのだ！
- 「頭を使いなさい」は、何よりも、力を与えてくれる規則
- プログラマによってはコードモンキーの様な働き方をする人間もいる
- コードに対する際に、その形と構造に関して意識的な決断を行おう
- 既存のパターンが怪しければ変更を検討しよう
- 応急処置のために複雑化したコードに同じ様な応急処置を行わない
- 意見を持ち、それを声に出すためには、勇気が必要
- 頭を使う勇気を持ち、コードを批判し、改善するために決断を下す力を持っていると感じてください
18章 変わらないものはない
- コードの神聖化は以下の様なプログラマの恐れによって生まれる
- 間違ってしまう恐れ
- 壊してしまう恐れ
- 余分な作業に対する恐れ
- 変更のコストのための恐れ
- 神聖化によって変更を許されなくなったソフトウェアは死後硬直
- 死後硬直を起こすのは下記の様なことが要因である
- 作った人間がいなくなる
- 製品がリリースされ多くの人たちが利用している
- 何ものも恐れない変化
- 優れた変更方法を学ぶ
- 変更を容易にする方法を学ぶ
- コードに順応性をもたせ、その品質に妥協しない
- 優れたコードを生み出す健全な態度を受け入れる
- 究極的には大胆不敵に変更をおこなうだけ
- 試みることは恥じることではなく、失敗から学びを得ることができる
- 製品化される前に十分なテストとインスペクションを行おう
- ソフトウェアの改善に対して、自分ができる役割を理解する
- 態度を変える
- 健全なコードの変更を可能にするために、チームは正しい態度をとる必要がある
- 「優れたコード」は他人の責任ではなく自分の責任
- あなたは変更を行う力と改善を成し遂げる力を持っています
- 誤った、危険な、ひどい、複製された、あるいは不愉快なコードは実在する
- これらを変更するのは気晴らしでも脱線でも、貴重な時間の浪費でもない
- これらの変更を積極的に推奨すべき
- もろい部分を長く腐らせない様にする
- 恐ろしくて変更できないコードを見つけたらそのコードを変更すべき
- リファクタリングが良い手段であり、チームは時間がかかることを理解してくれる
- コードは誰にも所有されていない、誰でも変更可能である
- コードを所有するという態度は避ける
- 間違いを犯すことや間違ったコードを書くことは犯罪ではない
- コードを互いに修正し合うのは当然、学んで成長するべき
- 誰かの意見が最も重要ということはない
- 誤った尊敬を与えてしまうと他のメンバーの寄与を低く見てしまう
- 優れたプログラマは変更を予期している
- 説明責任を重視しよう
- 変更を行う
- コードへのルートを走行する方法を学ぶことが重要
- 地図を作り、最適な順番で変更を行う
- 変更に備えて設計する
- 副作用を避ける
- 一つのことをうまくやる様に変更する
- 変更のためのツール
- 自動化されたテストは、コードの変更に確信を得るための重要な安全装置
- 戦い方を学ぶ
- 修正が困難な巨大なものも存在する
- ロードマップを描き、プロジェクト計画に盛り込むべき
19章 コードを再利用するケース
- コピー&ペースト
- コードの複製は悪魔の様なものであり、海賊行為に等しい
- DRYを思い出し、繰り返しを避けよう
- 大量に複製されたコードにバグがあることに気づいた時はすでに致命的
- 再利用のための設計
- 複数のプロジェクトで使うためのライブラリを作る
- ライブラリを使うことは再利用でなく利用
- 小さく始める
- ライブラリは全てを行うのではなく現時点の要件を満たす単純樹なコードを書く
- ライブラリへの昇格とリファクタリング
- 小さくモジュール化されたコードを書く
- コードを一箇所以上で使うことがわかったらそのコードを移動しライブラリとする
- その際はできる限り小さくAPIを拡張する
- 購入、あるういは車輪の再発明
- 他人のコード(OSSや販売されているソフトウェア)を避けない
20章 効果的なバージョンコントロール
- 開発者にとってバージョントントロールは食事したり呼吸したりする様なもの
- エディタやコンパイラと同様に開発の基本的なもの
- バージョンコントロールは下記の恩恵を与えるだろう
- 開発者の共同作業のハブ
- 成果の状態を定義し公開する
- コードの履歴を残す
- 過去の変更を閲覧することを可能にし、ソフトウェア考古学に貢献する
- 成果物の重要なバックアップとなる
- ソフトウェアに問題があった場合に変更をなかったことにできる
- 作業のリズムを提供する、それはコードを書く、テストする、レビューするコミットするという一連の流れである
- 使いなさい、さもなければ失われるもの
- バージョンコントロールは全てのプロジェクトで使われるべきもの
- VCSを使わないという選択はありえない
- ソフトウェアは本質的に安全ではない
- どれでもよいから一つを選ぶ
- rsc, CVS, SVN, Git, Mercurial等様々なVCSがある
- 今の主流はGitである
- 適切なものを保存する
- 不必要なものを保存しない
- ソフトウェアのリリースを保存する
- リポジトリのレイアウト
- ディレクトリ構造が明瞭であり、コードの構成を表現する様にしよう
- 重複は無条件に避ける
- サードパーティのコードは別管理とする
- アトミックなコミットを行う
- 変更を小さく、そして頻繁にコミットする
- まとめてコミットをしない
- なぜなら、変更点が明白でなくなるから
- 競合が発生しやすくなる
- 1つ以上の変更をコミットしない
- 正しいメッセージを書く
- コミットしたコードに正しいメッセージを書く
- 優れたコードと同様に明瞭で簡潔なメッセージを書く
- 簡潔であるとは、例えば変更したファイルの一覧はVCSが提供するので不要であるということ
- 優れたコミットを作成する
- 勤勉なプログラマは思慮深く、適切なコミットを行う
- コミットメッセージと同様にコミットの内容にも注意を払う
- ビルドが失敗する様なコミットを行わない
- 常に最新のmasterをマージして検証する
- 確信がない限りファイルの削除を行ったりしないこと
- エディタに行末を変更させない
- ブランチ: 木を見て森を見る
- 機能開発のカプセル化
- 実験的な開発を行うために複数ブランチを切って、最もよいものを採用する
- 重大な変更がある場合に他の開発者の手を止めないためにブランチを切る
- 安定リリースから開発を分離する
- コードの我が家
- リポジトリを介護施設や死体安置所にしない
- コードの成長に伴い、VCSがいかに助力となるかを実感する
- ソースコードはプロジェクトが大きくなればなるほどVCSに依存する
21章 ゴールポストを抜ける
- 愛こそはすべて
- チームでは少し多めの愛が優れたコードを生み出す
- 開発者にとって不安定な関係はQAチーム
- QAチームのあるべき姿は品質を製品に作りこむことである
- QAチームの仕事
- ソフトウェアの仕様書に関与すること
- テストを可能にするため、設計と開発に貢献すること
- テストフェーズには深く関与する
- 最終的にテストされたものがリリースされることを注視する
- よくある開発プロセスは下記の様なもの
- 誰かが要件を流し込む
- 要件がアーキテクト、設計者へと流れる
- プログラマが設計を実行可能なコードへ返還する
- QAチームに渡ったときに不思議なことに実行可能でないためにこの流れが詰まってしまう
- 誤った対立
- 開発者とQAチームの関係は多くの場合に良好とは言えない
- その様な環境ではテスターと開発者の縄張り争いが繰り広げられる
- 開発とQAは異なる活動である
- テスターたちは品質を作りこむために存在する
- ソフトウェア開発は戦闘でなく、等しく全員が同じ立場である
- コードを修復するためにチームを修復する
- 不健全なチームは不健全なコードを生み出す
- QAチームとの協業を大事にしよう
- 急がば回れ
- どんな事情があっても変更を急がない
- 手順を省いたり、すべてを十分にテストしないとQAチームの負荷を増大させる
- 夏休みの宿題を明日までに終わらせないといけない小学生のような必死さはなにかを間違えている
- 自動化する
- 人による誤りを除去する
- 不要なリリースを避けることを可能とする
- 尊敬する
- QAに仕事を放り投げるのでなく、安全なリリースを可能としてもらうという意識
- 障害報告を受け取ったら
- テスターが障害を見つけたらそれはあなたの障害です
- 障害報告は個人攻撃ではない
- プロ意識を持った対応は「ありがとう、調べてみます」
- 顧客によって障害が見つかったのでないことを感謝しよう
- 障害報告が多く、対処できないのであればそれは何かが間違っている
- QAはあなたが作ったバグを報告するに過ぎない
- 強くなるための特徴
- 効果的な協業関係は、開発者の正しい態度から生まれる
- QAエンジニアと協業するために次のことに注意しよう
- テスターは開発者と違う領域のプロフェッショナルであり敬意を払うべき
- テスターはコンパイラでなく、ユーザとして振る舞う
- QAチームに健全な敬意を払おう
- パズルのピース
- テストは最後の活動ではない
- 90%の開発を終え、テストを通過するには別の90%の努力が必要である
22章 凍結されたコードの数奇な人生
- コード凍結はおそらく善意を持って広まった言葉である
- リリースの定義は簡単
- リリース日を決めることは適切に役立つか？
- 凍結の前提となる条件は明らかにすべての機能が実装され顕著なバグがない状態
- この段階(コードの凍結)は意図的な減速
- 凍結の期間の長さ
- ナルニアの冬の様な不必要に長い凍結期間は望まれない
- しかし、短すぎてもいけない
- これらを決定すべき要素はリグレッションテストである
- 一般的な凍結期間は2週間
- 凍結期間中に技術的負債をまとめる
- 凍結期間はそのための期間
- 凍結防止のための手段
- 継続的デリバリー
- テストの自動化
- Cucumber等の優れた成否判定ツールを用いる
- テスト期間を短縮する
- 人力でないデプロイを用意する
23章 プリーズ・リリース・ミー
- リリースは開発の大切なプロセスである
- そのためには、規律と計画が必要である
- 失敗をもたらす様々な要因を引き起こす原因の多くはだらしない習慣
- コミットされていなかったローカルコードの混入
- 最新に反映されていなかったコードベース
- CVSを使わないプロジェクトのリリース
- 歯車の歯(優れたリリースの方法)
- リリースの種類と名前、同意を得ること
- リリースするものが正確であること
- クリーンなブランチを用意すること
- 最終成果物をテストする
24章 学びを愛して生きる
- プログラマは継続的に学び、スキルを向上させることを求められる
- 常に新しいものを学ぶ様にしよう
- 学ぶことが生まれつきうまい人たちは情報を吸収することに優れている
- そして、短い期間で精通できる
- そうでない人も努力次第でその様にはなれる
- 学習を楽しむ人間であれ
- 何を学ぶべきか
- 知の知、知の不知、不知の知、不知の不知を知ること
- 知らないことに取り組もう
- 学ぶためには時間を要するので賢く投資しよう
- 新たな技術を学ぶ際にスペシャリストになる必要はないがHello World以上のことは学ぼう
- ソフトウェアの設計方法を学ぶ
- コードを書くことが退屈であるならば、ソフトウェアのチームリーダーになる方法を学ぶ
- 広く学び、別の視点を持とう
- 学び方を学ぶ
- 世界観を広げよう
- 学ぶことを学ぶ
- 学ぶことは、人間の基本的なスキル
- 視野を広く持とう
- 性格は学習スタイルに影響を与える
- 内向的であれば独習、外交的であればワークショップなど
- 自分が学ぶために最適なメディアを選ぼう
- 交差感覚を刺激するために他の音楽を聴く等の別の刺激を受けることは大事かも知れない
- 興味を持てるものを学ぼう
- スキル獲得のドレイファスモデル
- 初心者は問題に関する知識を持たない
- 初級者は全体を見ていないが経験があるが、行き詰まることもある
- 中級者は問題を正しく理解しており、全体を見ることが出来る
- 上級者は全体像に深く理解しており、正しい単純さを求めることが出来る
- 専門家は問題が何かを発見出来、規則性を持たずとも説明を可能とする
- 知識ポートフォリオ
- 知識の棚卸しを行い、自分に必要なものを残す
- 学ぶことの投資領域を認識する
- 学ぶために教える
- 何かを学ぶために最も効果的な方法の一つは、それを教えること
- 誰かにその話題を説明することはそれを深く理解し、整理することに役立つ
- ブログ等のアウトプットはその助力となりえます
- 学ぶために行う
- 基本的な学習方法は下記の様に行って学ぶこと
- 書籍や記事を読むこと
- オンラインチュートリアルを見ること
- カンファレンスへ参加すること
- ただし、実際に使うまでは具象化されないことに注意
- 何かを生み出し、その知識を具象化しよう
- 間違おう、そこから何がうまくいかなかったかを学ぼう
25章 試験に基づく開発者
- 経験を積んだプログラマは、深く考えることなく驚くほど効率的に働く
- 自覚のない有能の状態に達するには多くの活動がある
- 運転はプログラミングと興味深い類似がある
- 要点を理解する
- 運転にはエチケットや規則、自動車の仕組みを学ぶ必要がある
- 経験を積めば、これらの多くが自然な行動となる
- 残る問題は道路や、常に求められる判断である
- 生まれつき注意深い人間もいれば、そうでない人間もいる
- 成功は自己満足を生み出す
- 自覚のない有能な状態は、注意してないと自己満足になってしまう
- 個人的にこれは極力避けたいと思っているので、避けるために案件移動している
- 優れた運転手となるためには、この自己満足の状態を克服することが重要
- そうでなければ、あなたは危険人物となります
- 有能な状態になった際に自己満足とならない様に注意しよう
- 試験
- 自動車運転免許には試験の通貨が義務付けられる
- それは優れた判断ができることを証明するため
- 試験は善意に基づいた優れた運転手になるためのもの
- 試験に基づく開発者
- プログラミングの世界においては法律的な免許はない
- 収入を得るために必要なスキルを示す必要を忘れてはならない
- 尊敬する人間がいますか？それは妥当ですか？
- プログラマのスキルの多くは仕事を通した経験で成り立つ
- ただし、その経験は時間だけでは測れない
26章 チャレンジを楽しむ
- プログラマは知識を武器とする職業である
- 知識を使うことは喜びであり、プログラマはそのために生きている
- プログラマはチャレンジを好み、楽しむ生き物である
- 熱心で積極的なプログラマは常に新しく刺激的なチャレンジを求める
- それは、モチベーション
- 刺激的なもの、挑戦的なもの、楽しんで習得できるものがモチベーションを維持する
- 大量生産するだけの人間は関心を持たなくなる
- これは優れたプログラマになることを止めることである
- 能力を問われる問題には勇気付けられ、興奮し、学びの向上に役立つ
- 腐ったプログラマを好きな人はいません
- 何がチャレンジ？
- 何が自分が興味を持つ対象であるかを定義しよう
- 言語？プラットフォーム？アルゴリズム？ライブラリ？
- 日々のプロジェクトと改善プロジェクトを分けよう
- やってはいけない
- 退屈な仕事を他人に任せない
- ビジネス価値を提供しないコードを下手に修正すること
- 本質的な仕事を見失う仕事をすること
- プログラミングの仕事が退屈であることを忘れること
- 余暇をプログラミングに費やすこと
- 車輪の再発明
- チャレンジしなさい
- やりたいことを計画し、実行しよう
- code kataを行い、捨てよう、これは価値ある意図的な練習を提供する
- 楽しいと思える練習問題を解こう
- 個人的なプロジェクトを持とう、そこから、新たなことを学ぼう
- 広く興味を持とう
- 言語やパラダイムに固執せずに挑戦して自分を最適化しよう
- 今の職場がチャレンジングでないなら他の職場に移ろう
- やる気のあるプログラマと一緒にいよう(仕事でもカンファレンスでもいい)
- 何を得たかを可視化しよう
- 休憩はちゃんととろう(打ちのめされることを厭わない様に)
- 車輪の再発明を恐れない、既存の実装と実現したいことは違うかもしれない
27章 停滞を避ける
- 自分が誇れる最後の学びはいつですか？
- これが曖昧で昔のことであれば、あなたは学んでいません
- 安全地帯に入り、そこは楽な生活と短い仕事と先が読める場所です
- その安全地帯は有害な場所であり、罠です
- 安易な生活は学ぶことも、進歩することも、良くなることもないということ
- スキルは投資
- スキルの道具箱を維持することは大変な努力が必要
- 恥ずかしい思いをすることもある
- スキルへの投資は意識して決意しなければならない
- 優れたプログラマで優れた人になるための投資を高く評価すべき
- 雇用保障
- 十分なスキルを持ち、継続的に学び続ければ雇用保障は増大する
- しかし、適切な仕事に就いているか自問をしよう
- 楽しく仕事ができないなら違う仕事を選ぶことを考えよう
- チャレンジできない環境は危険
- 優れたプログラマはコードと自分のキャリアに対する取り組み方の双方で勇敢である
28章 倫理的なプログラマ
- コーダーの品質は技術的な技量でなく、態度に依存する
- 故意に読むのが困難であったり、誰も理解できないコードを書いてはならない
- それは「雇用確保のための作戦」として扱うということはあってはならない
- バグを隠す様な下手な修正を行わない
- そういった問題の対応を正しく行うことが専門化の仕事
- 倫理的なプログラマは絆創膏を貼ることがあっても、問題をリスト化し技術的負債を返済するためのロードマップを描く
- 倫理的なプログラマはできる限り、最善のコードを書くことを目標とする
- どんな時でも力を尽くし、最善の結果を生み出すツールと技法を使用する
- それは品質を保障する自動化されたテストや、間違いを見つけたり設計をよくするためのレビューである
- 法的問題
- ライセンスを守ろう、かつての会社で保有していたライセンスはあなたのものではない
- 著作権を守らないことは窃盗である
- 倫理的なプログラマは作者の明示を適切に行うことに注意を払う
- ソフトウェアを盗んだり、海賊版の開発ツールを使わない
- 人への態度
- コードには他者に対する「倫理的な態度」が求められる
- ダークサイドに落ちず、優れた能力を正しい方向に用いる
- 他人の人生を悪くするコードを書かない
- 社会的に問題のあることのためにコードを書かない
- チームメイト
- 倫理的なプログラマはできる限り最善の結果を達成することに注意を払う
- ゴシップや陰口を言わず、すべての人を褒める
- 誰もが貢献できる価値を持っていることを常に信じる
- 誰もが耳を傾ける意見を持ち、拒絶されることなく意見を述べられるべき
- 誠実で信頼される人間であれ
- 相手が間違っていると信じているときに、同意しているふりをしない
- 建設的な意見と創意と筋の通った議論は優れたコード設計の決定を導く
- 各メンバーが対応できる「ディベート」のレベルを理解しよう
- 倫理的なプログラマは侮辱したり、怒ったりせずに最も生産的な議論の結果が得られることを望む
- 外的な要因で差別をしない
- 倫理的なプログラマは「難しい人」を公平に扱うことに細心の注意を払い、不必要な衝突を避ける
- マネージャ
- マネージャとの間で合意している多くの事柄は他のメンバーとの倫理的な契約事項
- 自身の成果でないものを自分のものとしない
- 元が誰かのアイデアであれば、その人の成果としよう
- 厄介な問題に取り組んでいるふりをしながら、個人的なことに時間を使って多くの時間を見積もらない
- プロジェクトをスムーズに進める問題の兆候に気づいたらすぐに報告する
- 心配したくない、誰かを傷つけたくない、悲観的だと思われたくないなどと考えない
- 対処が計画され、対処されるのが早いほど、プロジェクトがスムーズに進む
- バグを発見したら、障害報告に起票する
- 持ち合わせないスキルや技術知識を持っているふりをしない
- 能力不足のままに完了できない仕事を引き受けてプロジェクトを危険にさらさない
- 雇用主
- 雇用主に対しては尊敬をもって接する
- 機密情報を適切に扱う
- 特別な許可がない限り、他者に自身の成果を売却しない
- あなた自身
- 倫理的なプログラマは優れたプログラミングの実践を学び続ける
- 倫理的なプログラマは非現実的な期待に応えようとして自身が燃え尽きることを嫌う
- コードにおけるヒポクラテスとの誓い
- コードやビジネスに対して害を及ぼさないこと
- 自身の進歩と技能の向上を追求すること
- 最善の能力で割り当てられた仕事を行い、チームと強調して働くこと
- 誠意を持って他人に接し、プロジェクトとチームが最大限の効果を生み出すために働くこと
29章 言語への愛
- 似ている仕事に出会ったなら、単に学んだことのあるスキルを再利用して簡単に実現出来る
- 継続的に新たなことに挑戦し、学び、新たな問題を解決し、新たな技術を使わなければならない
- それが優れたプログラマとなる方法である
- すべての言語を愛する
- 成長する方法は2つ以上の言語で開発すること
- 1つの言語しか知らないというキャリアは機会損失
- スクリプト言語もコンパイル言語も同様に学ぼう
- 膨大なライブラリを持つ言語を学ぼう
- 異なるイディオム、パラダイムを学ぶことが大切である
- アセンブリを理解する、隠れた翻訳言語があることを意識する
- あなたの言語を愛する
- 言語との関係は結婚に似ており、見返りが得られるが努力を必要とする
- 関係を満たすためにはコストをかけて何かに投資しなければならない
- 言語はあなたを学ばないが、言語の開発者はユーザを学ぶ努力を行う
- 言語との関係を育む
- 愛している言語と付き合おう
- 愛と尊敬は時間の経過とともに育まれる
- 時には犠牲を払わなければならないこともある
- 会話は出来る出来ないでなく、学ぶべきスタイル
- プログラミングという行為は会話そのもの
- 会話をうまく行うためには膨大な努力と継続的に注意を払うことが必要
- 言語を理解するというのは一朝一夕では出来ない
プログラマの姿勢
- 労働環境を正しくしないと多くの医療費を払うことになる
- 目がスクリーンの上部となる様にする
- 膝がお尻よりも下になる様にする
- モニタを快適な距離(45cmから60cm)とする
- お尻の角度は90度かすこし大きいか
- 足裏は床にできる限り平らにする
- 腰を支える様に椅子を調整する
31章 一生懸命ではなく、賢く
- 一つのツール、あるいは一つの方法を常に頼りにするのは危険
- 戦い方を学ぶ
- 生産的なプログラマは一生懸命でなく、賢く働くことを学ぶ必要がある
- 経験を積んだプログラマの特徴の一つは技術的な判断力だけでなく、問題の解き方と戦い方
- 優れたプログラマたちは物事を台無しにせず、賢く問題を素早く終わらせる
- これは問題をうまく解決する方法を知っているからである
- 戦術
- 車輪の再発明をしない
- 誰かが問題の解決法を知っているなら移譲する
- リファクタリングや単体テストを行うべきか思慮し、必要なことだけを行う
- 複数の解決策の中で長時間悩むなら、最も時間がかからず容易に引き返せるものを選ぶ
- 優先順位をつけ、最も重要なことを最初に行う
- 顧客が真に求めるものを把握する
- 一つのことをうまくやる
- 小さく、そして単純にする
- 問題を先延ばしにして積み上げない
- 自動化にかかる時間が膨大でないなら自動化を検討する
- 早く、小さくフィードバックを受けられる様にする
- 明確に質問するために正しい質問の仕方を学ぶ
- 自身の能力を大きく超える仕事に対したなら、素直に相談する
- 作業を円滑に進めるためのツールを探し、導入する
32章 完了した時が完了
- 完了とは何か？
- 完了状態を言語化することの意味
- 計画を熟考していれば避けられる問題であり、下記の様な問題を引き起こす
- いつ止めてよいかわからず不必要な仕事をしてしまう
- 終わったと思う仕事が実は完了していない
- 想定外の箇所の修正に伴い、正しいゴールが見えていない
- 一生懸命に働きすぎて、正しい働き方をできていない
- 逆方向に開発: 分解
- 「完了」と定義するための最初のステップは何に取り組んでいるかを正しく知ること
- 小さくきちんと理解された問題がどれだけ解決されているかを知ることは容易
- 巨大なタスクを与えられたら、取り掛かる前に小さく理解可能な部品に分解する
- 「完了」を定義する
- 取り組んでいるタスクが何であっても、いつ止めるかを理解する
- 官僚を定義しないと、止める必要があるにもかかわらず働き続けることになる
- 何を持って成功とするかを知るまではコーディングを始めてはならない
- 完了が定義されるまでは作業を始めてはならない
- 成功基準は曖昧でなく具体的でなければならない
- 成功基準は重要なひとたちに周知しなければならない
- 達成不可能な完了の定義は役立たない
33章 今度こそわかった
- 開発者は孤島ではない
- 問題の一部を見ることで、問題全体を見ていなかったり効率的に取り組むことができない危険性に注意
- 他のプログラマに対して説明責任を持ち、彼や彼女と協業しよう
- 助けを求めないといったプライドは捨てる
- 山の麓に立っていた
- 登山に向かう際に個々に山の麓に向かうのは誤った取り組み
- チームで共に麓、もしくは正しいスタート地点を定めて向かうこと
- 問題に対する最初のルートが最善とは限らない
- 問題に直面した時は常に2つ以上の解決方法を検討する
34章 人々の力
- プログラミングは単なる技術的な挑戦ではない
- 一緒に働く人間が自信を形成する
- 意図を持って、優れたプログラマと一緒に働こう
- 優れたプログラマになりたいのであれば、優れたプログラマと働かなければならない
- プログラマは環境の産物
- 意気消沈した人といれば意気消沈するし、疲れ切った人といれば意気消沈する
- だらしない同僚と一緒にいればだらしない人間となる
- 優れたコードに対して情熱的で、優れたソフトウェアを作り出す努力をする人と働くことで得られるのは下記のこと
- 熱意(伝わりやすい)
- モチベーション(気持ちを高めてくれる)
- 責任感(伝わりやすい)
- この様な人達を見つけて、彼らの会社で働こう
- 優れたコードとそれをうまく書くことを気にかける人々を意識して探し求めよう
- 優れた人間を働くことで下記の様な得られる
- 優れたプログラマの習慣と態度
- 不得意な領域の改善
- 優秀なプログラマから学ぶべきこと
- 難問をどの様に理解してい解いているのか
- 問題解決への道筋をどのように立てているのか
- 物事が困難になったときに、どのような態度をとるのか
- どのようにして問題に取り組み続けるのか。いつ休憩をとるのか、いつ別の方法を試すのか
- 自身がまだ理解していない、彼らのコーディングすスキルや技法
- 専門家を知る
- すべての時間を使ってコードに取り組む様な働きすぎな人間とは付き合わない
- 上記の様な人々は間違いなく優秀なプログラマではない
- 専門家はあたかも容易に行っているかの様に思わせ、時間通りに完了させる
35章 原因は思考
- 説明責任を持つことがコードの品質に直接的に関連していると考える
- 職場で実践できていないとすれば、登壇者の話には何の価値もない
- 不格好で急いだ修正を行いたいという誘惑を避けること
- よく考えていない設計やいい加減で安易な解決方法、中途半端な対処を避ける
- これらをどうすれば達成できるか
- 説明責任を持つことが重要
- 自身をよいプログラマにするのは他のプログラマ
- 成果物の品質に対して説明責任を持つことでコーディング品質は劇的に向上する
- コード++
- 優れたコードを生み出すにはあらゆる段階でそれを検査する人々を必要とする
- 最善の能力を発揮し、取り組んでいるプロジェクトの品質を確認する人々がそうである
- 高品質の成果物を生み出し、怠慢にならない様にその気にさせる人がいるか確認しよう
- 機能させる
- 誰かがコードを読んで批評することがわかれば、優れたコードを書くことだろう
- 標準を設定する
- 成果を受け手が誰である(もしくは誰であるべきか)かを正しく認識しよう
- 成果の判断を行う人間が誰である(もしくは誰であるべきか)かを正しく認識しよう
- 成果のどの側面が説明責任に基づくべきかを熟考しよう
36章 遠慮なく話す
- プログラマの仕事は全てがコミュニケーション
- コミュニケーションの質によって成功したり、失敗したりするといっても過言ではない
- コードはコミュニケーション
- コードはコンピュータとの会話
- 自身が書いたコードを読まなければならない人々との会話
- そして、将来の自分自身との会話
- 優れたプログラマは意図を明確に伝えるコードを書く様に努める
- アルゴリズムを明確に示す
- ロジックを不明瞭としない
- 他の人たちが容易に変更できる様にする
- コードは変更を余儀なくされる、その際に気をかけるべきこと
- 理解できないコードは変更の妨げになる
- 簡潔だからといって読みやすく優れたコードとは限らない
- だが、少なくとも優れたコードは長すぎたりコメントだらけではない
- コメントは適切な長さで、かつ、メンテされるべき
- 優れたコードは保守する人間が頭を抱える様な先進的なものであるべきではない
- この状況は保守するプログラマに依存する
- チームの会話
- コミュニケーションはチームの潤滑油
- 他の人たちと会話せずに一緒に働くことはできない
- 優れたコミュニケーションは優れたコードの構造に反映される
- 健全なコミュニケーションは仲間意識を生み出し、職場を快適にする
- 不健全なコミュニケーションは信頼関係を急速に壊し、チームワークを妨げる
- これを避けるためには尊敬、信頼、友情、気遣いを持って隠れた動機や敵意を持たないこと
- 顧客との会話
- 最も重要な会話の一つが顧客との会話
- 何を欲しがっているかを理解しよう
- そのためのヒアリングを重視しよう
- (デモなどを使って)顧客の言葉で話そう
37章 多くのマニフェスト
- 主要なマニフェストを知り、それを理解し自身の意見を持とう
- 優れたプログラマは自分の成果に情熱を持っている
- 彼らは行っていることに投資し、継続的な向上を図っている
- 彼らはそれを他人と協業する際に必要なマニフェストとして言語化する
- 彼らはこの神聖な「一つの道」に従わない人々を嫌う
- だが、それは有益な態度とは程遠いものである
- マニフェストに盲目的に従ったり、マニフェストを教条的に扱ってはならない
- マニフェストは原則の大まかな概要に過ぎない
- 例えばアジャイルのエバンジェリストたちが実現方法が複数あると明確に述べている様に
- 優れたプログラマになるためにはマニフェストに対して実用的な取り組みを行うこと
- マニフェストから学ぶ
- マニフェストが支持している開発に対する視点を理解する
- 役立つものを使う
- 自身を最新に保つ
- 新たな流行や方法論を学び、よい点を理解する
- 盲目的に従わない、偏見を持たずに評価する
- 本書における優れたプログラマのマニフェストは下記である
- コードを気にかける
- チームの自立を促す
- 単純に保つ
- 頭を使う
- 変わらないものはない
- 継続的に学ぶ
- 継続的に向上を求める(あなた自身、チーム、コード)
- 長期的視点に立って、いつも価値を提供する
38章 コードへの叙情歌
- コーディングは人の問題
- 適切に開発していないと思うメンバーにどの様に対するべきか
- リーダーが気づかない、もしくはリーダーが問題の一部である場合もある
- コードに対する責任を持つ様に(非難せずに)促し、最も効果的な働き方ができる方法の導入を検討する
- その方法はペアプロ、メンター、設計レビューといったものである
- 優れた基準を自身で設定し、よろしくない人間に迎合しない
- 周りがそうであったからといって、悪いやり方に自分を染めない様に注意しよう
- 文化の変革は容易ではなく、時間を要する問題
- しかし、成し遂げられないことではない
最後に
- 結びに関しては書きません
- 本書を手に取った人間が思ったことはこうであったろうということが書かれていると思います
- 訳者あとがきはこちらから
- そして、最後に @yoshiki_shibata さんに素晴らしい本の翻訳をしてくださったことに心からの感謝を