プログラマが知るべき97のこと

著者 : 夏目大

制作 : Kevlin Henney 

• オライリージャパン (2010年12月18日発売)

感想・レビュー・書評

[amano225さんの感想 · 2011年12月4日]

半年以上かかってようやく読み終えた。
ページ順の目次以外に、カテゴリ別の目次があるのがいい。
その分野について困ったことがあればまた読み返したい。
自分も、そのうちプログラマとして本や雑誌に執筆できるぐらいになるようにがんばりたい。

[yujin283さんの感想 · 2011年10月23日]

知識だけではない、大切な話でとても有益。

[501さんの感想 · 2011年10月17日]

偉大な人たちの考え方を知るのは有益。
基本的に見開きの2ページで
小難しくなく、すんなり入ってくる内容ばかりで、
プログラミングに対し多角的視点を学ぶには良い本だと思う。

[takamin51さんの感想 · 2011年10月12日]

やはり皆、同じ所に苦しんだり、躓いていたり、失敗している事が良く分かった。
経験者が読めば、多くは「そうそう」と共感できるし、
新人や学生が読めば、「そういう事があるのか」
と心の用意ができるのではなかろうか。

ただし、掲載内容はあくまでも彼らの個人的意見であるため、すべての意見に対して共感できるこは限らない。が、価値観のバリエーションを垣間見ることができ、これも視野が広がる機会になりえる

[yumu19さんの感想 · 2011年9月25日]

素晴らしい本。
見開き２ページで１トピックなので、話が短くまとまっていて読みやすい。そして、そのため密度がものすごく濃い。
値段も安いし。皆読むべき。

--
プログラミングは、安定なコンピュータの世界と不安定な人間の世界を結婚させるようなもの。
問題を先送り：技術的負債
関数型プログラミング：参照透過性
ユーザが何をするかを観察する（あなたはユーザではない）
オープンソースのソースコードを見る。今すぐ。
ライブラリ化すると依存関係が出てくる
コードレビューを楽しいものにすること
１７　コードに書けないことのみをコメントにする　P３５
レベルの高い人がどうしても周囲にいないようなら転職を考える
もしこれが公になったら問題にならないか：セシウムさん。。。
３８　余分なコードは決して書かない　YAGNI（You Ain't Gonna Need It:それはたぶん必要ない）
　将来必要になるかと思った→今不要なら今書くべきではない
　実装してしまうほうが簡単だった
ムダな警告を排除する：クリーンな状態を維持
３人のプログラマの話（レンガの逆）
模索段階で書いたコードをレポジトリに入れてはいけない
語り得ぬものについては沈黙しなければならない　ー　ルートヴィヒ・ウィトゲンシュタイン
「見積もり」「ターゲット」「コミットメント」という言葉の意味を正しく認識しているか確認
XFD　おもちゃ
皆が常に同一のバイナリを使用するようにする
６０　「このコードはコメントがなければわかりにくい」と感じたのなら、コメントを書くよりも、リファクタリングを検討したほうがいいでしょう。　P１２０
MCO Mars Climate Orbiter
読みやすいコードを見つけたら、そこから多くを学び取る
「哲学探究」　思考や発想、画像がそのまま言語になって送られているわけではない
私達の世界観にはいまだにアリストテレスの影響が強く残っている
Pythonには逆アセンブラ
宝くじのリスク（優秀なプログラマが宝くじにあたってやめてしまうリスク）
WET原則（Write Every Time:必要なものをその都度書く）
８８　いつも「このコードは生涯、自分がサポートし続けなくてはならない」と思ってコードを書く。　P176
テストは「コードを見る人のため」に書く
理想のプログラマを演じてみる
ルーチンワークを一日の最初に。準備体操的な。
０７「不具合の修正時には必ず先に不具合を再現する自動テストを書いてから修正する」P214
ニッチな要求に「No」と言う
名前から入る




ーー
webサイト　ソフトウェア工学とは何か？
ペアプログラミング　エンジニアとしての指南書

[s2k1ta98さんの感想 · 2011年9月25日]

心して読んだ。グッと来るものが多々あった。現場で働いたことはないごテストとプログラマーの関係など書かれていることが多かったと思う。やはりプログラミングをするうえで原点を忘れてはいけないことを改めて実感した。

[あたしは、誰でしょうさんの感想 · 2011年9月22日]

借、2011.09.22-27

[yuji.developerさんの感想 · 2011年9月13日]

全てを実践出きるとは思わない採り入れられるもの採り入れていく。


この本は多くの仲間に読んでもらいたい。

[TOMOさんの感想 · 2011年9月6日]

・技術的負債を残すな。早めに返済せよ。
・ユーザーの身になってシステム構築をする。
・コーディング規約は自動化する。
・シンプルに。美しく。
・リファクタリングの重要性。
・機能の共有は慎重に。コンテキストを意識する。
・他人よりまず自分を疑う。
・ドメインの言葉を使ったコード（canView、isAdminなど）
・レビューは楽しく。辛辣な批判は絶対に避ける。
・コードに書けないことをコメントする。whatじゃなくwhy。
・常に自分よりレベルの高い人と仕事をする。
・技術的例外とビジネス例外を分ける。
・変更を恐れない。
・見られて恥ずかしいデータは使わない。
・DRY原則
・ハードワークは報われない。
・余分なコードは決して書かない。
・警告はエラーと同等にみなす。
・複数のプログラミング言語を学ぶ。
・自分の書いたコードに責任を持つ。
・他人のコードを読む。
・自動化できることは自動化する。
・ペアプログラミングのすすめ。
・他社へのおもいやりを考慮したコード。
・コードは生涯サポートするつもりで書く。
・プロジェクトにコードネームをつけよう。
・理想の人を演じきれ！仕事だろ！
・フロー状態を作る。
・コードを読むスキル。テストをするスキル。デバッグをするスキル。
・快適な環境を追求する。
・名前の重要性を意識する。

[nihimotoさんの感想 · 2011年8月23日]

９７もあるとピンとくる内容とそうじゃない内容があるけど、たぶん自分の経験値によってどれが響くのか違うんだと思う。
いつかすべての内容が理解できるようになりますように。

著者プロフィール

1966年、大阪府生まれ。同志社大学文学部卒業。翻訳家。訳書にゴドフリー゠スミス『タコの心身問題』（みすず書房）、グリック『タイムトラベル』（柏書房）、コステロ『エルヴィス・コステロ自伝』（亜紀書房）など多数。

「2023年 『シカゴ・ソウルはどう世界を変えたのか』 で使われていた紹介文から引用しています。」