Software Design の 2025 年 8 月号について、
- ざっくり内容紹介
- 個人的に気になった記事やポイント
をまとめている記事です。
サマリー記事の一覧はこちら。
特集①:リファクタリング 今やるか?見送るか?
- リファクタリングやレガシー改善はソフトウェア開発の中においてたぶん自分が一番関心がある領域のひとつなので、読んできた書籍の数や実際に仕事として投下した工数も圧倒的に多いのだけど、その状況でこの題材をこれくらいの分量のコラムとして読むのは初めてだったかもしれない
- 別に悪いとかはなかったが、読んでいてそれぞれの項目ひとつずつに対して自分の意見がほぼ明確にあるというのが自分で珍しく感じた
- この話はソフトウェア開発の分野としてだけではなく必ず「事業」や「人」という概念が入ってくると思っているので、ある一定量の切り口だけに絞ってこのようなコラムを書くのは著者ご本人としてもいろいろ難しいと思われているのでは、などと思った
Extra Feature:2038 年問題を考える
- あまり詳しい内容に踏み込んで調べたことない話だったのでちゃんと読んだ
- 面白かった
- 個人用ではない機器においてはまだ全然対策が進んでいない可能性が大いにあり、このままだと普通に問題が起こるものも多そうとのこと
- これをまだ 13 年あると見るかもう 13 年しかないと見るか
- UNIX および UNIX のための C などの標準化の過程で、time_t 型は定義されたものの実際にはこれは実装依存ということになってしまい、当時の暗黙の標準だった long 型、つまり符号付き 32bit になってしまった
- UNIX time を使う多くのコードがこれをベースに書かれてしまったため、単に time 関数の戻り値を 64bit にしたとて問題は単純には解決しなくなった
- C はオーバーフローが起きても例外が投げられないので、おかしなことが起きてもソフトウェアがそのまま進んでしまうのもやっかいな問題のひとつである
- いろいろ対策が考えられている
- なるほどと思ったのは epoch をずらしてしまえばいいというやつだが、ソフトウェアの改修の面では最も問題が起きないだろうが、要件から見たらどれくらい問題が起きるのか考えるだけで頭が痛くなりそうではある
- この筆者さんたちがつくった y2k38-checker という 2038 年問題検出 OSS があるらしい
Column
- ネコ、コード、ネコ
- 引き続きこれを読む
- 今回の話は Rui さんが書いた他の何かの文章で読んだことあったかもしれない(気のせいかも)
- Emacs を使っているのは知っていたけど、コード補完すら使っていないというのは驚いた。たいへんそう(小並感)
Software Design 2025 年 8 月号
この号の分のみ単品で読みたい方は、普通に Amazon で買うのがおすすめ。
紙 or 電子書籍で選べます。