『実装パターン』の自分の感想ツイートまとめ

鏡双司 | Skeb Open @SO_C

『実装パターン』を読み始めた。まえがきに「パターン本ではない」なんて書いてあって、面食らう。「他の人が読んで理解できるコードの作成方法」とのこと。

鏡双司 | Skeb Open @SO_C

『実装パターン』に書かれているのは、「一般的なプログラマであれば、1日に何度も行うような小さな決定」。

鏡双司 | Skeb Open @SO_C

『実装パターン』は、割と穏当というか、OOPへのこだわりみたいなものは薄いなぁ。

鏡双司 | Skeb Open @SO_C

『実装パターン』、反転メッセージと説明メッセージがよく似ている。

鏡双司 | Skeb Open @SO_C

カバレッジ100%にしろ、というのはメリットよりデメリットの方が目立つなぁ。関数を増やす方向のリファクタリングへのモチベーション奪うし、トリッキーなテストコードになりがちだし。

鏡双司 | Skeb Open @SO_C

『実装パターン』が強調している「対称性」の原則が面白い。下位の問題の抽出はするようにしていたけれど、中小度を揃えるのはあまり意識していなかった。たしかにロジカルライティングでも章・節の抽象度そろえるな。

鏡双司 | Skeb Open @SO_C

「推測ではなく事実に基づいて，メソッドは組み立てよう．コードを動作させてから，どのような構造であるべきかを決定しよう．事前にコードの構造化にたくさん時間を費やしても，実装の途中で何かを学習するたびに，今までの作業を元に戻したり，やり直したりする羽目になるだけだ．」『実装パターン』

鏡双司 | Skeb Open @SO_C

動作するメソッドの構造の改善ってつまり、リファクタリング。そうしようと思ったら、テストが必要。

鏡双司 | Skeb Open @SO_C

しかし、そう考えると、事前に詳細設計しようとするのは、筋が悪いよなあ。

鏡双司 | Skeb Open @SO_C

動作確認コストが高かったら、事前に詳細設計して机上レビューした方が効率的なんだろうけれど、今UTを簡単に繰り返しまとめて実行できるからなあ。

鏡双司 | Skeb Open @SO_C

そういう意味では、アジャイルサムライにあった実装する人が実装できるレベルまで設計を詳細化すればいい、というのは効果的そう。設計書は納品しない前提だけれど。

鏡双司 | Skeb Open @SO_C

『実装パターン』、メソッドの可視性、普段考えていることに近い。こうして、言語化された状態で改めてインプットすると、考えが整理されて人に伝えやすくなるなぁ。

鏡双司 | Skeb Open @SO_C

『実装パターン』、コレクション用アクセッサメソッド使わないとなぁ。しょっちゅう横着している……。

鏡双司 | Skeb Open @SO_C

設計を守るのが目的ではない。「目の前の証拠を信じ，それに従って行動すると，設計は一般に改善する．その結果，事前に描いた設計図をかたくなに守るよりも，コードは読みやすくなり，これまで以上に汎用的に役立つようになる．」『実装パターン』

鏡双司 | Skeb Open @SO_C

『実装パターン』、パブリックなgetter/setterは基本ツール専用。getterは、アルゴリズムが別のオブジェクトにあるときは問題ない。アルゴリズムを委譲で切り替えたりするときかな？

鏡双司 | Skeb Open @SO_C

『実装パターン』9章コレクション、これもこうやってまとまってると、スッキリするなぁ。

鏡双司 | Skeb Open @SO_C

『実装パターン』10章 フレームワークへの拡張。クライアントコードでは、コードの理解とメンテナンスが最大のコストだったのが、フレームワークではクライアントコードのアップグレード対応が最大のコストになる。優先順位が変わる。

鏡双司 | Skeb Open @SO_C

『実装パターン』の最大の教訓は「プログラマの仕事は，他のプログラマとの間でコミュニケーションを取ることである．マシンとではない」。よく言われることだけれど、他のプログラマには、未来の自分も含まれる。