Software Design 2025年5月号

Software Design 2025年5月号

https://gihyo.jp/magazine/SD/archive/2025/202505

第1特集 オブザーバビリティの最前線 可観測性の基本とOpenTelemetry入門

オブザーバビリティに関する基礎的な内容から実際の手法, また現場での課題感などがきれいにまとめられていてとてもよかった. 「第4章:オブザーバビリティの組織への導入と目指すゴール 成熟度モデルによる現状把握と改善で徐々にレベルアップ」では特にペインポイントが挙げられていて個人的にはかなり面白かった. オブザーバビリティは効果測定も難しく目的や要件の策定も難しいので, やはり導入のハードルは高いが, きちんと理解しておくべきだと感じた.

逆に問題が起きていないのにアラートが頻発している状況では「アラート疲れ」が生じ、本当に重要な問題に適切に対応できなくなる可能性があります。

ほんとうにこれで, ただいろんな指標を可視化しているだけではだめで, 事業ドメインに関する理解やオブザーバビリティに関する知識が必要なところが難しい点だと思う.

第2特集 クラス設計の鉄則 堅牢で変更に強いコードを作り上げる技術

最近では明示的に「クラス」というものを扱わない場合もあるが, 書かれている基本的な概念はクラスのような言語に依存したものでなくても同様だろう. 非常に重要な内容なので繰り返しいろんな形で学ぶことが重要だと思う. ただ内容に一部断定的なものがあり, 設計というものの観点をきちんと伝えられていないように感じる. 想定読者がジュニアだからといってシンプルに答えを与えてあげることが正しいと私は思わない. 現実世界をソフトウェアとして切り出すことによって生じる曖昧さやそのときどきの状況に依存した観点があり, 常に正しい設計やアプローチは存在しないはずだ. 設計にはそういった難しさがあるということをきちんと伝えることこそ誠実さだと思う. この特集で挙げられていた『Tidy First?』でもそういった難しさについて語られていたはずだ. 『Tidy First?』が扱っていた主題はそこにあったはずで, そういった設計に対する態度や考え方が元の書籍から引用した結果抜け落ちてしまっているのはとても悲しい.

細かな点で言うと長いメソッドや大きなクラスが悪いということは一概には言えない. これは『A Philosophy of Software Design』で語られていたことで, Deep Module のほうが良いという場合もある. これらの問題は問題はおもに認知負荷に関する問題で, その複雑さが課題内在性負荷から生じるものか課題外在性負荷から生じるものかという観点で考えたほうがよっぽど明確に判断できるだろう.

よく知られたアプリケーションアーキテクチャとしては、多層アーキテクチャ、ポートとアダプター(ヘキサゴナルアーキテクチャ)、オニオンアーキテクチャ、クリーンアーキテクチャなどがあります。

クリーンアーキテクチャというアーキテクチャは存在しない.

https://yyyank.blogspot.com/2021/06/there-is-no-clean-architecture.html

プログラミング×AIの最前線 【2】プログラミング分野における大規模言語モデルの最新動向

o4-mini とGemini 2.5 が出たので, もうすでに各モデルに関する説明が古くなってしまっていて可哀想だ... というか媒体として扱うべき内容ではないだろう.

実践データベースリファクタリング 【16】終わらないリファクタリングプロジェクト

現実に新規開発を止めて期限を決めてリファクタリングで成果を出すのって難しいんだよな...

魅惑の自作シェルの世界 【30】パス名展開(後編)

ちなみに今までClippyを使っていなかったのは単なる怠慢です。すみません。

笑った. 新しめの言語だとコンパイラや linter がすごく賢くて便利で助かる. いや, clang-tidy も便利だけども.

(もし書籍化されるとしたらこういうライブ感は無くなってしまうのかなと思った. こういうのを味わえる(?)のも雑誌の醍醐味かも)