【2022年】リファクタリング・コーディング技術の本「人気・おすすめの10冊」

コーディング界隈でよく名前の挙がる名著ですが、非常に読みやすく、短期間で読了できました。 初学者からベテランまで活用できる内容となっております。 (参考：YahooShopping)

組織における情報の透明性、
開発における見積りの不確実性を解決しようとしたときに、
どういうことを考えていけばいいのか、
最初の一歩の踏み出し方を教えてくれる本な気がしました。
どの章でも、どの問題でも、
まずは何がわかっていて、何がわかっていないのか、
無知の知ではないが、わかっていないことを知ることを基礎としている気がします。
組織のマネージメントを考えたときに、
この本を読むことで知識の整理、行動の促進、自身の立ち位置の把握と、
振り返りを生むことが多い本だと思いました。
（以下抜粋。○：完全抜粋、●：簡略抜粋）
●「エンジニアリング」とは一体何でしょうか。
（中略）
私たちは、自分たちが日々行っている「エンジニアリング」とは一体何なのかをよく知らないということです。
（中略）
エンジニアリングとは、つまるところ、「実現」していくための科学分野だといえるでしょう。（P.10-11）
●不確実性コーン。プロジェクト初期においての見積もりは、見積もりに対して4倍から1/4の範囲で誤差があります。後半になればなるほどその誤差は減ります。つまり「実現」するエンジニアリングで重要なのは「どうしたら効率よく不確実性を減らしていけるのか」という考え方なのです。（P.12）
●シャノンは、不確実性の量をエントロピーと呼びました。例として天気として、明日は晴れか雨だけだとします。明日は晴れが50%（雨が50%）の場合1bit、晴れが80％（雨が20%）の場合0.72bit、晴れが100%（雨が0%）の場合0bit。（本にはエントロピーの式がある）発生する確率が偏っているほど、不確実性の量は減っていくことがわかります。（P.15）
○全体論とシステム志向は、「人は、問題を個人の責任にしたり、全体像を見失った局所的最適な思考をしてしまう」ので、それが全体像ではないかもしれない、問題は関係性にあるのではないあかという視点と問題解決のための目を提供し、行動を促すものでした。（P.67）
○「情報の非対称性」と「限定的理性」、この2つが、組織における人間の不完全さを加速させ、組織に忍んでいる理不尽の増幅装置となってしまうのです。（P.69）
○「情報の透明性」とは、意思決定と意思決定に関わる情報が、組織内に正しく整合性をもって伝達されるように継続して努力し、何かわからない決定があったとしても、それを隠そうとしたわけではなく、抜けてしまったのか、自分が聞き逃したのだから、直接聞いてみようという関係性をつくることです。情報公開が情報の透明性を作るわけではありません。（P.72）
●メンターとメンティの関係性の条件。
・謙虚：お互いに弱さを見せられる
・敬意：お互いに敬意を持っている
・信頼：お互いにメンティの成長期待をもっている（P.81）
●「悩む」と「考える」の違い
（中略）
「悩んでいる」というのは、頭の中に様々なことが去来し、ぐるぐると思考がめぐり続け、もやもやが取れない状態だと考えています。
（中略）
この状態になったときには、サポートが必要dふぇ、共���考えるための戦略を立てていく必要があります。（P.87）
○メンターは、メンティの問題を直接解くことはできません。メンターができることは、問題を「簡単な問題に変換する」ことだけです。（P.96-97）
●認知フレームを発見する「キーワード」（P.101）
（それぞれの系で抜粋。相手の裏側を考えるのに非常に有効に思える）
こちら系　：この会社　：同じ側にいるように思えるが、実は一体感を持っていない。
あちら系　：あの部署は：同じくくりにいるはずなのに、向こう側と線引きしている。
極端系　　：いつも　　：ゼロ一で、グラデーションなしの物事判断
すべき系　：～すべき　：「～すべき」という枠組みの中で限定的に考えている
決めつけ系：どうせ　：感情的に決めていて、事実確認なしで推論している
●承認（アクノレッジメント）の3つの段階（P.112）
存在承認：挨拶を始め、相手がここにいることに対するメッセージ。
行動承認：行動に対して言葉で出して伝える。例えばほめること。
結果承認：できあがったものに対して主観を込めて伝える。ほめるより広い範囲への承認。
○マネジメントとは、対象となる○○の資源・資産・リスクを管理し、効果を最大化する手法（P.136）
○「アジャイル」状態とは、具体的にどのような状態でしょうか。それは以下のような状態のいのことを意味しています。
・情報の非対称性が小さい
・認知の歪みが少ない
・チームより小さい限定合理性が働かない
・対人リスクを取れていて心理的安全性が高い
・課題・不安に向き合い不確実性の削減が効率よくできている
・チーム全体のゴール認識レベルが高い（P.141）
●SECIモデル（P.151）
共同化・表出化・連結化・内面化という各フェーズを繰り返していくことで、知識というものが発展的に組織的に蓄積されます。
・共同化：組織において共通の経験を積み重ねることで、暗黙的な経験的な知識が共有されているフェーズ。共同化を促すためには、経験や思い、信念などをストーリーテリングする場が必要になる。
（異なる人が独自に実施）
・表出化：体感的で明文化されていない経験的知識の共通点や抽象的な構造・類似点を見つけモデル化していく工程。これはメンタリング的な対話によって引き出されていく。
（構造化、類似点の抽出によりモデリング、文章化）
・連結化：複数の形式的な知識を積み重ねて、1つの知識体系を作るフェーズ。そのためには、形式知を共有・編集・結合させるような場が必要で、Wikiなどのシステムはそのようなことを目的としている。
（Wikiなどによる凝縮して他の人ができるようにする）
・内面化：形式知として生まれた知識体系を知識として覚えている状態から、実践や行動を通じて、体感的・身体的に「理解できた」という状態に変えるフェーズ
（文書化された知識を実践や行動に移すが、ゆっくりと見ながらでもよい練習している状態）
○「見積り」について考えてみましょう。ソフトウェア開発は同じことを二度と繰り返す必要が基本的にないので、毎回どこかしら初めての作業になります。そのため、作業見積もりというのはいい加減なもので、正解とは限りません。ですが、作業実績であればどうでしょうか。これは過去の実例なので正確な数値です。これをもとに将来を見通すほうが、より正確になるはずです。（P.177）
（アジャイルに限らず予測と実績を取得しておくことで、初めて改善できる。やるやらを考える時にも、なんのためにやるのか、測定できる何が改善されるのかを考えないといけないということ。）
○プロジェクト型チームはレスポンスタイムを最適化する。
プロダクト型チームはスループットを最適化する。（P.179）
●見積りは、あくまで予測です。しかし、この予測を「ノルマ」として扱ってしまった場合、それが達成できないときに能力や評価の問題にされる可能性が出てしまいます。
（中略）
予測を「ノルマ」にした途端、それを達成するための過負荷な労働が生まれ、クオリティは下がってしまいます。あるいは、スケジュールの予測精度はどんどんと下がってしまいます。このようなことを避けるために、エンジニアは次からは防衛的で悲観的なケースで見積りを行うとします。（P.190）
●2点見積り、3点見積り（P.193）
●エピック→テーマ→ストーリー→タスク（P.208）
○すでに成功しているビジネスであれば、公開されている情報からでもリーンキャンバスを再現することはできるでしょう。成功しているビジネス10個程度ピックアップして、そこからリーンキャンバスを想像するという練習を繰り返すと、プロダクトのもつ本質が見えてくるようになります。
　仮説検証における仮説は、十分な情報があるところとから導かれる正解ではありません。わずかな痕跡からでもよいのではっきりとした具体的なイメージをもつことで、はじめて仮説と現実の違いを認識することができます。（P.220）
○技術的負債は「見ることができない」（P.256）
●技術的負債というと抽象度が高く見ることができないが、解決方法を調査検討することで何が問題が見えてきます。見えてこればそれはただのタスクでしかありません。（P.264）
●システム外注における取引コスト
・探索のコスト：クオリティの高い外注先を探す、関係を構築するコスト
・交渉のコスト：契約条件をまとめるコスト
・監督のコスト：品質の監視、維持、検収をするコスト（P.276） (参考：honto)

レガシーコードをいかにHackしてテストケースの作成やリファクタリングを行うかの本。
JavaやC++はともかくCでリンカを変えて本番コードからテスト用のモックを参照するというのは目から鱗でした。
既に存在するレガシーコードに対してのアプローチを前提に書かれているため大抵の現場で役に立つと思われますｗ（サンプルコードはJava/C++/Cが中心だけど別言語でもたぶん置き換えは可能）
リファクタリングに伴う影響の調査
　　↓
本番コードをテストコードで保護＆本番コードに依存性を注入しテストしやすくする
　　↓
本番コードを修正
といった石橋を叩きすぎて渡るというポリシーが素敵。プロなら品質を担保するためにこれくらいやるべきですよねｗ
ただし内容は非常に難しいので、最低でも「リファクタリング　プログラムの体質改善テクニック」や「クリーンコード」を読んでいることが前提かと。
http://booklog.jp/users/sue445/archives/4894712288
http://booklog.jp/users/sue445/archives/4048676881
読み終わった本の中で仕事中にもすぐ手にとりたい物は机の上に立てているのですが、この本は表紙の「テストがないコードはレガシーコードだ！」が非常にショッキングなため机の上にみんなに表紙が見えるように置いていますｗ (参考：honto)

リファクタリングを実装に合わせて行うのは同感。
実行速度のチューニングはリファクタリングと相反していると考えがちだが、実は違う点はハッとした。基本に忠実にしっかり計測したい。
カタログは全体を通してざっくり読んだので、必要に応じて読み返したい。
データベースリファクタリングも少し気になった。 (参考：honto)

「この本で初めてデザインパターンが理解できた」「UMLとイラストを交えた解説がとてもわかりやすい」と、多くの読者から絶賛された大ロングセラーの増補改訂版。原典『デザインパターン』で紹介された全23のパターンを、Javaによる実装を含めて解説。
2001年6月の初版刊行以来、多くの読者から圧倒的に支持されてきた前著の増補改訂版です。改訂にあたっては、前著の内容を全面的に見直して、文章や表記をより適切な表現に改めています。
また、デザインパターンについて、読者が誤解しやすい点、間違いやすい点を、巻末に「Q＆A」として追加しています。
デザインパターンについて学び、実践で使用したいプログラマはもちろん、オブジェクト指向の本質を理解したい人に最適の1冊です。 (参考：honto)

詳細 -- Robert Nystrom「Game Programming Patterns」インプレス - みんなで正誤表

public-errata.appspot.com

(参考：honto)

リファクタリングを実装に合わせて行うのは同感。
実行速度のチューニングはリファクタリングと相反していると考えがちだが、実は違う点はハッとした。基本に忠実にしっかり計測したい。
カタログは全体を通してざっくり読んだので、必要に応じて読み返したい。
データベースリファクタリングも少し気になった。 (参考：honto)

コーディング界隈でよく名前の挙がる名著ですが、非常に読みやすく、短期間で読了できました。 初学者からベテランまで活用できる内容となっております。 (参考：YahooShopping)

既に知ってたことも体系的にまとめられているので、非常に良い本だと思います。ざっと斜め読みしてどこに何が書いてあるか把握しておき、必要な時にその都度活用するのが良いと思います。 (参考：YahooShopping)

レガシーコードをいかにHackしてテストケースの作成やリファクタリングを行うかの本。
JavaやC++はともかくCでリンカを変えて本番コードからテスト用のモックを参照するというのは目から鱗でした。
既に存在するレガシーコードに対してのアプローチを前提に書かれているため大抵の現場で役に立つと思われますｗ（サンプルコードはJava/C++/Cが中心だけど別言語でもたぶん置き換えは可能）
リファクタリングに伴う影響の調査
　　↓
本番コードをテストコードで保護＆本番コードに依存性を注入しテストしやすくする
　　↓
本番コードを修正
といった石橋を叩きすぎて渡るというポリシーが素敵。プロなら品質を担保するためにこれくらいやるべきですよねｗ
ただし内容は非常に難しいので、最低でも「リファクタリング　プログラムの体質改善テクニック」や「クリーンコード」を読んでいることが前提かと。
http://booklog.jp/users/sue445/archives/4894712288
http://booklog.jp/users/sue445/archives/4048676881
読み終わった本の中で仕事中にもすぐ手にとりたい物は机の上に立てているのですが、この本は表紙の「テストがないコードはレガシーコードだ！」が非常にショッキングなため机の上にみんなに表紙が見えるように置いていますｗ (参考：honto)