Closed1

複雑性

wrenchwrench
スクラップに書く目的

1.自身のアウトプット
場所として、Zennのスクラップは個人のメモとして活用できるので、丁度良いと考えて選びました。

2.何か交流のきっかけにならないかなという思い
同じ本を読んでいる方がいれば、ぜひ交流できれば嬉しいと思い、発信してみることにしました

これは何か?

A PHILOSOPHY OF SOFTWARE DESIGN』を読んでおり、自身のまとめになります。

複雑さ(Complexity)

複雑とは?

複雑さとは、ソフトウェアシステムの構造に関するもので、システムの理解や変更を困難にする要因。

複雑性の症状

変化増幅 (Change amplification)

例えば、2ページのウェブサイトがあり、各ページにCSSファイルが存在し、背景色が定義されているとする。

両ページの色を変更する場合、2箇所の定義を変更する必要があります。
このウェブサイトが100ページに及ぶ場合、変更箇所は100にも上り、変更数が増大します。

しかし、全ページの背景色を1箇所で管理していれば、ページ数に関わらず変更は1箇所で済む。

「変更が多くのコードの変更を求めない」設計は、良いデザインの一つの目標。

認知負荷 (Cognitive load)

認知負荷とは、開発者がタスクを完遂するために知っておく必要がある情報量を意味する。

認知負荷が高い状態では、開発者が必要な情報を学ぶために多くの時間を費やしたり、重要な点を見落としてバグを引き起こすリスクが高まる。

システム設計者は、コードの行数を複雑性の指標として誤解することがありますが、短いコードが必ずしも単純とは限らない。

認知負荷の要素:

  • 課題内在性負荷: コードの本質的な複雑さ
  • 課題外在性負荷: コードの表現方法や構造による余分な複雑さ
  • 学習関連負荷: 新しい概念や技術を学ぶための負荷

わずか数行でアプリケーションを書けるフレームワークもある。
しかし、その内容を理解するのが非常に難しい場合もある。

多くの行数を必要とするアプローチの方が、認知負荷を軽減できる為、実際には単純なこともある。

未知の未知 (Unknown unknowns)

タスク完了に必要なコードの修正箇所や、開発者が持つべき情報が明確でない状態。

これは3つの中で最も深刻な問題で、対処方法や適切さが全く不明である。

確実な方法はシステム内の全コードを読むことですが、これは現実的ではない。

このスクラップは2025/02/16にクローズされました