Notices by ひだお初段@Qiitadon (hidao@qiitadon.com), page 72

徳丸本輪読会第１回目の日程調整・参加申し込みを行います。
場所は東京都内を予定しております。
詳しくはリンク先！

連絡はマストドンか、オンラインチャットルーム（ https://discord.gg/s5VQjMN ）で行いましょう。

徳丸本（安全なWebアプリケーションの作り方）輪読会第１回目の日程調整・参加申し込み | 調整さん https://chouseisan.com/s?h=ae8abacc8bef463b87aae549784c990b

#徳丸本輪読会

フェンスを建てる担当者の精神、その人の持てる仕事を超過すると、比較的簡単に見られる
例えば案件炎上させたり、お客様に返信してなかったりで、反省会みたいなのを開いたら、その場では凄く神妙な態度で、実際本人も反省してると思うし、その場では心に響いてるように見えるし、人によっては涙を流して反省を述べたりするんだけど、何回でも繰り返す事がある
多くの人は、仕事が溢れると盛大にキレたり逃げたりするんだけど、真面目だからそれを引き受ける人がいる...でも案件の最後までは責任を持てなくて、どこかで破綻させちゃうパターン
そういう時に、言ったこと全部理解してるように見えるけど、なぜか動かない深刻なバグ状態になる
この状態は本当に怖くて、部分的な応答だけを切り取ればまともだけど全体で破綻してて、でもあまり破綻してる認識はなくて玉砕しようとしてる感じ
私は玉砕の精神状態と勝手に呼んでいる
ある程度の責任感みたいなものがないと発生しないけど、物事を成功させる責任とか必死さみたいなのは無く、ズブズブと矛盾に突き進んで爆死する感じ

リファクタリングするとき、そのコードについての十分な知識がある前提では、まず大きなブロックや処理構造からのリファクタリングを考えた方が良さそう

ただ、何にしてもまずは"パフォーマンス"を調べた方が良い気がするなあ
リファクタリングは、問題が無ければ行う必要が無くて、
・読みにくい
・性能に問題がある
・保守性が悪い(改修しにくい)
というような問題点が改善されるからリファクタするので、まずは全体的にどういう問題があるかを調べるのが初手の気がする(その時点では手を入れない)
自分が詳しく知ってるソースなら別だけど

あとは、明らかに手を動かせるところからリファクタリングしてついでにソースを読むとか
要らないコメントを消す類のリファクタで

リファクタリングすべきコードの全体像が把握できてないとき，末端の細かい単位（の関数など）から始めて，呼び出し元に遡ってやっていく，というのはよくある。

ただ，リファクタリングが進んで，呼び出し元（の関数など）をリファクタリングしていくと，末端のが不要になっちまうことも多くて，時間ロス感がハンパない。

使える時間が限られているときは，頑張って全体像を把握しようとしてみることも大事？