ベタープログラマ ―優れたプログラマになるための38の考え方とテクニック

Book description

本書は、優れたコードを作りだし、人々と効率的に働く生産性の高いプログラマになるための考え方とテクニックを38のテーマで紹介します。個人的な活動として、継続的な学習方法と停滞を避けるための課題の見つけ方など、自らを成長させる方法も紹介。さらに組織の中で他の人とコミュニケーションを取りながら、効果的に働くための習慣を解説します。『Code Craft』の著者Pete Goodliffeが、自らの経験を元に「優れたプログラマ」になるための考え方と習慣をまとめた本書は、プログラミングを愛し、長く続けながら、優れたプログラマになりたいと思うすべての人に必携の一冊です。

Table of contents

  1.  大扉
  2.  原書大扉
  3.  クレジット
  4.  本書への推薦の言葉
  5.  献辞
  6.  はじめに
  7.   取り扱う内容
  8.   対象とする読者
  9.   この本の構成
  10.   メンターへの注意
  11.   お問い合わせ
  12.   謝辞
  13.  1章 コードを気にかける
  14. 第Ⅰ部 you.write(code)
  15.  2章 見かけのよい状態を維持する
  16.   表現は強力
  17.   それはコミュニケーションに関すること
  18.   レイアウト
  19.    きちんとした構造
  20.    一貫性
  21.   名前
  22.    冗長性を避ける
  23.    明瞭である
  24.    慣用的である
  25.    正確である
  26.   身なりを整える
  27.   結論
  28.  3章 少ないコードを書く
  29.   なぜ気にかけるのか
  30.   たるんだロジック
  31.   複製
  32.   死んでいるコード
  33.   コメント
  34.   くどさ
  35.   悪い設計
  36.   空白
  37.   では、何をしたらよいのか
  38.   結論
  39.  4章 取り除くことでコードを改善する
  40.   悪習の放置
  41.   悪いことではなく、避けられないこと
  42.   何が問題か
  43.   死者をよみがえらせる
  44.   外科的除去
  45.   結論
  46.  5章 コードベースの過去の幽霊
  47.   表現
  48.   技術の進歩
  49.   イデオム
  50.   設計の決定
  51.   バグ
  52.   結論
  53.  6章 航路を航行する
  54.   私の友人からの小さな助け
  55.   手がかりを探す
  56.   やってみて学ぶ
  57.    低い位置にぶら下がっている果実
  58.    コードを点検する
  59.    調査、そして行動
  60.    テストファースト
  61.    維持管理
  62.    分かったことを文書化する
  63.   結論
  64.  7章 汚物の中で転げ回る
  65.   前兆を嗅ぎ付ける
  66.   汚水槽に入って行く
  67.   調査は語る
  68.   砂掘り場で働く
  69.   汚い物をきれいにする
  70.   調整を行う
  71.   できの悪いコード? 下手なプログラマ?
  72.  8章 そのエラーを無視するな!
  73.   エラーの仕組み
  74.   エラー無視による事態
  75.   エラーへの言い訳
  76.   結論
  77.  9章 予期せぬことを予期する
  78.   エラー
  79.   スレッド化
  80.   シャットダウン
  81.   この話の教訓
  82.  10章 バグ狩り
  83.   経済的な視点
  84.   少しの予防薬
  85.   バグ狩り
  86.    罠を仕掛ける
  87.    バイナリチョップを学ぶ
  88.    ソフトウェア考古学を使う
  89.    テスト、テスト、テスト
  90.    切れ味のよいツールへの投資
  91.    原因分析に関係のないコードを取り除く
  92.    清潔さを保って伝染を防ぐ
  93.    間接的な方法
  94.    急がないこと
  95.   再現できないバグ
  96.   結論
  97.  11章 テストの時代
  98.   なぜテストをするのか
  99.    フィードバックループを短くする
  100.    コードをテストするコード
  101.    誰がテストを書くのか
  102.   テストの種類
  103.   テストはいつ書くのか
  104.   テストはいつ実行するのか
  105.   何をテストするのか
  106.   優れたテスト
  107.   テストはどうのように見えるのか
  108.    テスト名
  109.   テストの構造
  110.    テストを保守する
  111.    テストフレームワークを選ぶ
  112.   コードは孤島ではない
  113.   結論
  114.  12章 複雑さに対処する
  115.   ブロブ
  116.   ケーススタディ:ブロブの複雑さを減らす
  117.   線
  118.   そして最後に、人々
  119.   結論
  120.  13章 二つのシステムの物語
  121.   混乱したメトロポリス
  122.    理解不可能
  123.    凝集度の欠如
  124.    不必要な結合
  125.    コードの問題
  126.    コード外の問題
  127.    メトロポリスからの絵はがき
  128.   デザインタウン
  129.    機能の場所を見つける
  130.    首尾一貫性
  131.    アーキテクチャを成長させる
  132.    設計の決定を遅らせる
  133.    品質を維持する
  134.    技術的負債に対処する
  135.    テストが設計を形作る
  136.    設計のための時間
  137.    設計と共に活動する
  138.   次にどうする
  139. 第Ⅱ部 練習することで完璧になる
  140.  14章 ソフトウェア開発とは
  141.   ソフトウェアの作り方
  142.   ソフトウェア開発は芸術
  143.   ソフトウェア開発は科学
  144.   ソフトウェア開発はスポーツ
  145.   ソフトウェア開発は子供の遊び
  146.   ソフトウェア開発は退屈な仕事
  147.   比喩の過重荷
  148.  15章 規則に従って競技する
  149.   もっと多くの規則が必要
  150.   規則を決める
  151.  16章 単純に保つ
  152.   単純な設計
  153.    使うのが容易
  154.    誤用を防ぐ
  155.    大きさが重要
  156.    短いコードパス
  157.    安定性
  158.   単純なコード行
  159.   単純に保ち、愚かにならない
  160.   想定は単純さを減少させる
  161.   早まった最適化を避ける
  162.   十分に単純
  163.   単純な結論
  164.  17章 頭を使いなさい
  165.   愚かにならない
  166.   不注意を避ける
  167.   考えてよいのだ!
  168.  18章 変わらないものはない
  169.   何ものも恐れない変化
  170.   態度を変える
  171.   変更を行う
  172.    変更に備えて設計する
  173.    変更のためのツール
  174.    戦い方を選ぶ
  175.   多くの変更
  176.  19章 コードを再利用するケース
  177.   再利用のケース1:コピー&ペースト
  178.   再利用のケース2:再利用のための設計
  179.   再利用のケース3:ライブラリへの昇格とリファクタリング
  180.   再利用のケース4:購入、あるいは車輪の発明
  181.  20章 効果的なバージョンコントロール
  182.   使いなさい、さもなければ失われる
  183.   どれでもよいから一つを選ぶ
  184.   適切なものを保存する
  185.    解答1:すべてのものを保存する
  186.    解答2:不必要なものを保存しない
  187.    ソフトウェアのリリースを保存する
  188.    リポジトリのレイアウト
  189.   バージョンコントロールをうまく使う
  190.    アトミックなコミットを行う
  191.    正しいメッセージを書く
  192.    優れたコミットを作成する
  193.   ブランチ:木を見て森を見る
  194.   コードの我が家
  195.   結論
  196.  21章 ゴールポストを抜ける
  197.   ソフトウェア開発:堆肥をシャベルですくう
  198.   誤った対立
  199.   コードを修復するためにチームを修復する
  200.   QAへビルドをリリースする
  201.    成果物を最初にテストする
  202.    意図を持ったリリース
  203.    急がば回れ
  204.    自動化する
  205.    尊敬する
  206.   障害報告を受け取ったら
  207.   強くなるための特徴
  208.   パズルのピース
  209.  22章 凍結されたコードの数奇な人生
  210.   コード凍結を探求する
  211.   コード凍結に対する新たな秩序
  212.   凍結の形態
  213.   ブランチでうまくいく
  214.   しかし、実際には凍結されていない!
  215.   凍結期間の長さ
  216.   凍結を感じる
  217.   終わりは迫っている
  218.   凍結防止
  219.   結論
  220.  23章 プリーズ・リリース・ミー
  221.   プロセスの一部
  222.   歯車の歯
  223.    ステップ1:リリースに着手
  224.    ステップ2:リリースを準備
  225.    ステップ3:リリースをビルド
  226.    ステップ4:リリースをパッケージ化
  227.    ステップ5:リリースを配置
  228.   早めに頻繁にリリース
  229.   そして、さらに
  230. 第Ⅲ部 個人的なこと
  231.  24章 学びを愛して生きる
  232.   何を学ぶべきか
  233.   学ぶことを学ぶ
  234.   学習モデル
  235.    知識ポートフォリオ
  236.   学ぶために教える
  237.   学ぶために行う
  238.   これまでに学んできたこと
  239.  25章 試験に基づく開発者
  240.   要点を理解する
  241.   成功は自己満足を生み出す
  242.   試験
  243.   試験に基づく開発者
  244.   結論
  245.  26章 チャレンジを楽しむ
  246.   それは、モチベーション
  247.   何がチャレンジ?
  248.   やってはいけない
  249.   チャレンジしなさい
  250.   結論
  251.  27章 停滞を避ける
  252.   スキルは投資
  253.   読者への練習問題
  254.   雇用保障
  255.  28章 倫理的なプログラマ
  256.   コードに対する態度
  257.   法的問題
  258.   人への態度
  259.    チームメイト
  260.    マネージャ
  261.    雇用主
  262.    あなた自身
  263.   コードにおけるヒポクラテスの誓い
  264.   結論
  265.  29章 言語への愛
  266.   すべての言語を愛する
  267.   あなたの言語を愛する
  268.   言語との関係を育む
  269.   愛と尊敬
  270.    決意
  271.    会話
  272.    忍耐
  273.    共有された価値
  274.   完璧な比喩?
  275.   結論
  276.  30章 プログラマの姿勢
  277.   コンピュータに向かう基本的な姿勢
  278.    姿勢をデバッグする
  279.    ひどい状況のとき
  280.    徹夜
  281.    上司からの干渉
  282.    危機は去った
  283.    設計するとき
  284.   目の疲れ
  285.   結論
  286. 第Ⅳ部 成し遂げる
  287.  31章 一生懸命ではなく、賢く
  288.   戦い方を選ぶ
  289.   戦術
  290.    賢く再利用する
  291.    他人の問題にする
  292.    やらなければならないことだけを行う
  293.   一時的な解決策
  294.    優先順位をつける
  295.    何が求められているのか
  296.    一度に一つずつ
  297.    小さく(そして単純に)する
  298.    問題を先延ばしにして積み上げない
  299.    自動化
  300.    誤りを防ぐ
  301.    会話する
  302.    燃え尽きを避ける
  303.    強力なツール
  304.   結論
  305.  32章 完了したときが完了
  306.   まだ到着しないの?
  307.   逆方向に開発:分解
  308.   「完了」を定義する
  309.   あとはやるだけ
  310.  33章 今度こそ分かった……
  311.   無人島開発
  312.   山の麓に立っていた
  313. 第V部 人々の営み
  314.  34章 人々の力
  315.   何をすべきか
  316.   専門家を知る
  317.   振り返ると
  318.  35章 原因は思考
  319.   比喩を広げる
  320.   説明責任を持つことが重要
  321.   コード++
  322.   機能させる
  323.   標準を設定する
  324.   次のステップ
  325.   結論
  326.  36章 遠慮なく話す
  327.   コードはコミュニケーション
  328.    コンピュータとの会話
  329.    動物に話しかける
  330.    ツールとの会話
  331.   人と人とのコミュニケーション
  332.    会話の方法
  333.    言葉に注意する
  334.    身振り
  335.    並列な会話
  336.   チームの会話
  337.   顧客との会話
  338.   他のコミュニケーション
  339.   結論
  340.  37章 多くのマニフェスト
  341.   ソフトウェア開発のためのジェネリックマニフェスト
  342.   ごめんなさい
  343.   マニフェスト
  344.   しかし、本当なの?
  345.   落ち
  346.  38章 コードへの叙情歌
  347.   コーディングは、人の問題
  348.  結び
  349.   態度
  350.   前進、そしてコードを書く
  351.  訳者あとがき
  352.   謝辞
  353.  著者・訳者紹介
  354.  奥付

Product information

  • Title: ベタープログラマ ―優れたプログラマになるための38の考え方とテクニック
  • Author(s): Pete Goodliffe, 柴田 芳樹
  • Release date: December 2017
  • Publisher(s): O'Reilly Japan, Inc.
  • ISBN: 9784873118208

You might also like

book

レガシーコードからの脱却 ―ソフトウェアの寿命を延ばし価値を高める9つのプラクティス

by David Scott Bernstein, 吉羽 龍太郎, 永瀬 美穂, 原田 騎郎, 有野 雅士

レガシーコードとは、バグを多く含み、壊れやすく拡張が難しいコードを指します。このようなコードの保守と管理には多大な労力がつぎ込まれることになります。しかも一度作ってしまったレガシーコードの質を上げるには、初めから質の高いコードを作るよりも膨大なコストがかかります。 本書では、ソフトウェア開発において、初めからレガシーコードを作りださないためのプラクティスを9つ挙げて解説します。プロダクトオーナーは目的を語り、やり方は開発者に任せること、小さなバッチで開発を進めること、継続的に統合すること、チームメンバーで協力することなど、日々の開発に取り入れる考え方と具体的な実践について各章で分かりやすく解説します。 信頼性や拡張性が高いソフトウェアをリリースしたい開発者、運用管理者、マネージャに必携の一冊です。

book

プロダクトマネジメント ―ビルドトラップを避け顧客に価値を届ける

by Melissa Perri, 吉羽 龍太郎

本書は、顧客に価値を届けるプロダクトを作り出すプロダクトマネジメントについて学ぶ本です。プロダクトマネジメントを理解することで、企業がビジネス目標を達成しながら、顧客の課題を解決する方法を解説します。はじめにプロダクトマネージャーの役割と責任を定義し、優れた意思決定を促す戦略の立て方を紹介します。実験と最適化によって作るべきプロダクトを決めるプロセスを解説し、最後にプロダクト主導の組織を支えるための文化や方針を紹介します。ビルドトラップを避け、顧客の課題にフォーカスするプロダクトマネジメントの原則を解説する本書は、規模の大小を問わずすべてのプロダクトチーム、マネージャー、プログラマ、アーキテクト、デザイナ、マーケターに必携の一冊です。

book

進化的アーキテクチャ ―絶え間ない変化を支える

by Neal Ford, Rebecca Parsons, Patrick Kua, 島田 浩二

現代におけるエンタープライズアーキテクチャは、もはや静的な計画をあてにすることはできなくなっています。そしてソフトウェア開発エコシステムは、ツールやフレームワーク、技術イノベーションの流れと共に絶え間なく変化しています。こうした状況の中で、いったん構築したシステムを成長させていくには、さまざまな変化に適応しながら進化するアーキテクチャをシステムに組み込む必要があります。本書は、そうしたアーキテクチャを「進化的アーキテクチャ」と名付け、その構築に必要な考え方や技術、実践方法などについて解説するものです。

book

リーンエンタープライズ ―イノベーションを実現する創発的な組織づくり

by Jez Humble, Joanne Molesky, Barry O'Reilly, 角 征典, 笹井 崇司, Eric Ries

新規事業を生み出し、顧客にすばやく価値を届けるには、それを支援する体制が必要です。本書は、あらゆるムダを省き、継続的に仮説検証を繰り返しながら、プロダクトやサービスを構築する「リーンスタートアップ」の手法を既存の企業に適用するための方法を説明します。市場環境や顧客ニーズの変化に対応し、イノベーションを加速させ、組織文化、ガバナンス、財務管理を最適化し続けるハイパフォーマンス組織になるための原則とパターンを、さまざまな成功企業のケーススタディとともに詳述します。