第６章 手法 ～プログラマの道具箱～
6.1 曳光弾
最終形にも残る「骨格コード」
- 全体の流れを早めに通して、狙いを確認する…ということでしょうか。
- …普段からやってますが、全く意識してなかったです💦
暗闇の中で道筋を照らす
- これは日々実感してます！
最初に動作する土台を作る
- アジャイル開発で、常にリリースできる状態を保つ、のもこの考え方に近い？
プロトタイプとの違い
- 違いは…目的と使用後かしら…。
プロトタイプは試供品と試作品
- 破棄が前提、だとしたら、あんまりプロトタイプは作ったことがないかもしれません。
その他
- 読み終わってから、普段動作ってるのか考えてたんですが…
- ざっくり主題を作る（曳光弾）から、テストを書きながら細かいケアをしてく、TDD的な感じかも。
6.2 契約による設計
「呼び出し側」と「呼び出される側」の取り決め
- これ、あんまり意識してなかったです。
- どこにチェック機構を設けるか、について指針になっていいですね。
- 呼ばれた関数は引数が契約に従っているかチェック
- 呼んだ側は出力が契約に従っているかチェック
- …これって、チームで共有してたほうがいい知識ですよね。
「思い違い」の早期発見
- 早期発見…握りつぶしの反対ですよね。
コメントとアサーションで契約
- 引数で渡された値を加工しない……今どきは普通にやってますね。
- 関数のアサーションをそのままユーザの入力チェックに使うな…はそのとおりですね。
- 入力を厳格にする…はテストをちゃんと書くことにしてると、自然にやりますね。だって書くの大変だもんw
クラス不変表明
- 「クラスのオブジェクトは常にこういう状態でなければならない」という保証のこと…。
- あんまり使ったことはないです。
アサーション（表明）
- Rubyでは言語の機能としては持ってなくて、自作するんだそうです。
トラッシュよりクラッシュ
- 同意。ダメなときは無理なリカバリをしない。
6.3 防御的プログラミング
「かもしれない」プログラミング
- ifがあったらelseを常に気にかけるようにしてて、想定外を事前になるべく想定するようにしてます。
開発と運用の安全運転
バリケード戦略
- わかるようなわからないような…
- Railsでフォームなどから受け取ったユーザ入力にdirtyフラグがつけられてるようなもの？
アサーション（表明）とエラー処理の区分け
エラー処理におけるバリエーション
- 確かにこのあたりの手を使いますね…。
エラー処理における「正当性」と「堅牢性」
6.4 ドッグフーディング
ソフトウェアの「味見」
- 「味見」だとユーザっぷりが足りないような…。
- 「自ら使う」だけだとちょっと足りないような…。
- 「日常的に」とか入れたらしっくりくるかも。
ユーザーの視点を手に入れる
- ユーザとしてちゃんと利用しようとすると、なぜか突然不具合や不便なところを見つけたりする経験がありますね…。
- 社内システムの場合、業務内容の他に、社内行事などを通じてなんとなく人となりなどを知っておくと…ユーザになりきって使うことができるような気がしてます。
- でも、デカい現場だと難しそう…。（昔を思い出して。）
自分でユーザーのように使う
- そりゃそうですねえ…。
- 自社サービスを使って、ユーザから資金を集めたこともありましたが、これもドッグフーディングですよね。
- 一方で、サービス運営者・作成者との視点も混ざって持っているので、純粋なユーザではないのはちゃんと気をつけてたほうがよさそう。
6.5 ラバーダッキング
「説明する」というデバッグ
- 誰かに説明すると解決する、というのを人を使わずにもできるってものですね。
自己解決を促す
- プルリクエストのセルフレビューのときに、将来何か必要になったときに読まれることを想定して、コメントを残していくときに、ある意味デバッグになってると思ってて…やり始めてから結構コードがよくなった気がしてます。
無機質に説明
- 同僚はたしかに一番いいけど、いないときもありますもんね。
- 自分はChatGPTを相手にしてることが多いかも💦
その他
6.6 コンテキスト
「文脈会話」「文脈思考」
- モジュール名とかクラス名はコンテキストといっていいんじゃないかしら…？
- だから変な名前をつけるとおかしくなっちゃうというか。
会話や思考を迷子にしない
- 達人はパターンを知ってるだけじゃなくて、その活用場所を決められるから、というのはそのとおりだと思う…。
コンテキストを示す
- コンテキストを示す、というのは、モジュール名、クラス名、メソッド名を決めてから書く、みたいな？
コンテキストと作業依頼
- これ、じゃあどうしたら…。
- 初心者には事細かに指示し、熟練者には目的を指示するのはわかったけど…中間は？
コンテキストの伝導能力
- この実験、おもしろいですね。ノンセクションめっちゃ時間かかりました💦
チームはハイコンテキスト志向で
- そうですね。
コード共通化はコンテキスト志向で
- まぁ…コンテキストの違うものは似てても違うものですよね。
プログラマのコンテキストスイッチ
- 最近は擬似的な別人になるために、考え事をしているときにわざと中断して、コンテキストスイッチを起こしてます。少し冷静になれる気がしてます。
「システム・シンキング」とドメイン駆動設計
- めちゃ長い…。
「フロネシス」と全体最適化
「関係主義」と障害対応
- 境目に不具合が起きやすい、みたいな感じですかね？
