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

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

by Pete Goodliffe, 柴田 芳樹
Released December 2017
Publisher(s): O'Reilly Japan, Inc.
ISBN: 9784873118208

Read it now on the O’Reilly learning platform with a 10-day free trial.

O’Reilly members get unlimited access to books, live events, courses curated by job role, and more from O’Reilly and nearly 200 top publishers.

Start your free trial

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. 第Ｖ部　人々の営み
  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

初めてのGraphQL ―Webサービスを作って学ぶ新世代API

by Eve Porcello, Alex Banks, 尾崎 沙耶, あんどうやすし

今日では多くのWebサービスがRESTアーキテクチャスタイルで実装されています。RESTは2000年にフィールディングの論文で提唱された後に爆発的に普及し洗練されてきました。一方で、本書で紹介するGraphQLは2015年にFacebookによって公開されたRESTとは異なるアプローチのアーキテクチャです。GraphQLの最大の特徴はクエリ言語を用いてデータを操作する点です。クエリ言語の表現力の高さによりクライアントは本当に必要なリクエストを送ることができます。本書ではGraphQLの概要とGraphQLを用いたWebサービスの開発方法を実装例に沿って紹介します。認証やファイルアップロードといった実践的なトピックまで踏み込んだGraphQLの実用的な入門書です。

book

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

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

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

book

スクラム実践者が知るべき97のこと

by Gunther Verheyen, 吉羽 龍太郎, 原田 騎郎, 永瀬 美穂

アジャイル開発手法のなかで最もよく使われる手法の1つがスクラムです。スクラムは、複雑な問題に取り組むためのシンプルなフレームワークであり、シンプルであるがゆえに実践には要所を押さえるスキルが必要になります。本書は、世界中で活躍するスクラム専門家が自らの経験と知見に基づいて執筆したエッセイ集です。スクラム適用の戦略、スクラムで進める上での戦術やパターン、さまざまな職種のコラボレーション、組織への影響などについて幅広い視点で紹介します。日本語版では、及部 敬雄、小林 恭平（kyon_mm）、高橋 一貴、長沢 智治、平鍋 健児、安井 力（やっとむ）、和田 卓人、永瀬 美穂、原田 騎郎、吉羽 龍太郎による10本の書下ろしを収録。

book

大規模データ管理 ―エンタープライズアーキテクチャのベストプラクティス

by Piethein Strengholt, 村上 列

データ管理と統合が急速に進化する中、複雑で緊密に結合したアーキテクチャから、現代のビジネスに対応できる、より柔軟なデータアーキテクチャへの移行が求められます。 本書は、変化が激しい時代でも長期的に持続可能な方法で大規模なデータ管理を行い、さまざまなユースケースに対応できる統合アーキテクチャを紹介します。この統合アーキテクチャを構成する、膨大なデータ利用に向けた「読み出し専用データストアアーキテクチャ」、リアルタイムなアプリケーションのための「APIアーキテクチャ」、大容量のスループットを実現する「ストリーミングアーキテクチャ」を詳述します。また技術開発、法規制、プライバシーに関する懸念など、データ管理全体を説明し、データガバナンスとセキュリティ、マスターデータ管理、セルフサービスとデータマーケットプレイス、メタデータの重要性について解説します。 企業のデータ戦略にかかわる本書は、アーキテクトはもちろん、経営者、ガバナンスチーム、データ分析・エンジニアリングチーム必携の一冊です。