考え方
新規作成 2021-6-26
「結果・結論」は大事だが、それに至った「経緯・理由」の理解は大切
その場で「aがbだからcになり、だから結論はd」な感じで、結論dまでに至った過程が自分で納得するため
逆算
仮説
「はやくできるようになろう」より「ゆっくりでも理解しようとする」心がけ
強い目的意識
コードも例外ではない。
例えば、Aという機能(処理)があってBという機能(処理)を実現したいときに、AがBも実現するとしたとき、AはたまたまBが出来るだけで、意図したことではない。そのため、もしAを削除すると本来必要だったBが実現できなくなる、ということが考えられる。
その機能(処理)がある目的とはなにかを意識すること
「機能」を「役割」に読み変えても通じそう。
差分
関係性
dag
結果整合
消去法
知識が古くなっていないか
問題へのアプローチの仕方
それが妥当か
原因がどこか切り分ける
期限
mece
tree
やらないことを決める
何かをやる理由
振り返る
なぜうまくいったか
なぜ失敗したか
再発防止策
根本の原因まで深堀ること
費用対効果
どこまで先を見通しているか
一貫性
implements/handler
頭出しして意見をもらう
その後のタスク(資料作りとか)で修正時間が大幅に減る(可能性が高そう)
仕組みの理解
全体構成の把握
広くみてみる
デファクト・トレンド
抽象度別の理解
設計 > インタフェース(関数) > 実装の詳細 な感じで、各々説明ができるレベル
動作確認(テスト)に時間をかけるか、リカバリ案考えてはやくリリースするか
前任者の書いたコードの設計理解
PRのレビュー依頼
セルフレビューとコメント書くこと忘れないこと
特に、イシューやタイトル、descriptionに関係ない修正は必ずコメントすること
そのコードである意図や経緯があとから追える事も大事
依存・関係する他のPRがあればそのリンクも記載すること
何らかの問題がある・発生したとき
対応案をいくつか出す
対応方針を定める
ミーティング開いて話し合って、方針固める
障害発生時
復旧優先
状況の周知徹底。障害対応中は何するか・してるかを逐次共有
dbの更新するなら、戻せるようctasで更新するテーブルのコピーをとっておく
mtg主催する側
そのmtg自体の目的をハッキリさせてまず伝えること
e.g. 相談か?共有か?など
作業ログをどこか一ヶ所に残す
なにをやるか/なぜやるかもセット
新しい技術を利用するとき
アドホックにググってブログを参照して利用始める、はよろしくない
そのブログが正確であるか?とかわかってないない自分が判断するから非常に良くない
その技術を一番知っている対象を参照する
公式ドキュメント
公式のチュートリアルを進めて理解する