Software Design 2025年8月号
Software Design 2025年8月号
https://gihyo.jp/magazine/SD/archive/2025/202508
第1特集 自信を持って決断したい そのリファクタリング、今やるか？見送るか？ 適切なタイミングとビジネス面の価値
よかった. リファクタリング手法そのものというよりリファクタリングの戦略的価値を中心とした話. 記事の中でも何度も出てくるが『Tidy First?』をかなり意識した内容と言っていい. 全体的に参考文献が多いので, 知識が開いているのも良い.
テスト駆動開発, クリーンアーキテクチャに続き, 三大誤解されている内容の一つなので毎回リファクタリングの定義から入るのがちょっと面白かった.
リファクタリングという言葉だけで説明しようとせずに具体的に何が問題か・どうすべきかを（ステークホルダーに）説明するべきだみたいな話をよく聞くけど, これも関係してくるかもしれない.
具体的なコードでどのようにリファクタリングすべきかみたいな話も書かれているが, 紙面が足りていないのでそういった内容に期待している場合は他の書籍を当たったほうがよいかも. まあリファクタリングしたいという状況は慎重かつ無自覚1な場合があって, コードの正しさが一義的に決まらないことの方が多い. だからソフトウェアコンストラクションの深いところまで踏み込まないと, リファクタリングという文脈において解説するのは難しいだろう.
第1章：なぜリファクタリングは議論になるのか？ 定義を再確認して考える
表1のようなリファクタリングのサイズを導入し、共通認識をそろえておくのがよいでしょう。
ここだけ引っかかった. 「統合テスト」みたいな曖昧な指標になっている気がする. あくまで例であるし, 組織内で合意できれば問題ないはずだが, もう少し機械的に決めたい. とはいえクラスサイズなら関数のインターフェースを変更しないとか, エンドポイントのサイズならリクエストとレスポンスを変更しないとか, そういうふうになるはずなので, 概ね同じことを言っている気がする.
第2章：リファクタリングの実施判断力を養う どんなコードに対し、いつ、どのように取り組むか
（他の章はビジネスや組織全体に関わってくるので）個々人で読んでためになるという意味ではこの章が一番よかったかも. WHENがわかればあとは手を動かすだけなので, そのタイミングを知り意識するということは重要だと思う.
今後修正予定のあるモジュール、頻繁に機能修正し続けているモジュール、そして今まさに機能追加等のために修正しようとしているモジュールこそリファクタリングしたほうがよい対象になります。
これ大変良い指標だと思っています.
第2特集 OSの基本のキ 今さら聞けないファイルシステム＆ストレージ 見落としがちなデータ管理のしくみを学び直そう
つ っこんだ内容でかなり好き. こういうのってどうやって勉強するんだろうね. 聞きかじりでも知っておくと全然違うことで活きたりするのでこういう基礎的な内容が重要だったりする. 関係ないけど『［試して理解］ Linuxのしくみ ―実験と図解で学ぶOS、仮想マシン、コンテナの基礎知識』という本も良いです.
2038年問題を考える
世界規模の技術的負債と言っていのかもしれない. ここまでの問題が自分から発生することはないだろうが他山の石として学んでおきたい. ちなみにESP32というマイコンのファームウェアでも対策しています.
ITエンジニア必須の用語解説 200回記念 時代に取り残されないキャッチアップ術
面白かった. 普段見ているサイトとかかなり具体的な内容も書かれていていい感じ.
つまみぐい関数型プログラミング 【3】関数型プログラミングの便利な道具①：パターンマッチ
match式と型の組み合わせが最高なんですね. オブジェクト指向のデザインパターンのようなものもほとんどこれで解消できるんですね. 個人的にはもう少し詳しく紙面を割いて紹介してほしいくらい.
Ruby×静的型付け戦略 【4】プロジェクトへの型導入戦略
「つまみぐい関数型プログラミング」と内容がシンクロする部分があって最高になっている.
乱数のひみつ 【6】認証付き暗号を支える乱数
なんか自分でも実装できそうな気がしてきますね?