complexity

ソフトウェアの複雑さ、みたいなふわっとした話

subtitle : 2/19 オプト社内勉強会

allotted-time : 30m

自己紹介

渋谷　充宏 @m4buya

• サーバーサイドプログラマ
• Ruby / Scala
• https://github.com/mshibuya
• RailsAdmin committer

ソフトウェアかわいいよソフトウェア

アジェンダ

• ソフトウェア、複雑すぎ
• 複雑だと何が困るのか
• なぜ複雑になるのか
• 複雑にしないために何ができるのか
• まとめ

ソフトウェア、複雑すぎ

{:relative_height='100'}

複雑でないソフトウェアはあんまりない

• 単純なソフトウェアには競争力がない！
  • 誰でも作れるから。。

複雑だと何が困るのか

• バグが発生しやすい
• 変更が困難

プロダクトとして破綻する

バグを直す速度 < バグが生まれる速度

複雑すぎることはリプレースの動機になる

• 不具合の多発・メンテナンス性の低下
• →ソフトウェアとしての寿命を早める

潜在的な市場を失う可能性

• 変更が困難
• →ビジネス上の要請に適時に応えることができない
• →ビジネスそのものの寿命を早める

なぜ複雑になるのか

• 現実世界が複雑だから…
• 大規模なソフトウェアだから

ケーススタディ

• 前職ではキャバクラ情報サイトを作ってました
• いろんなお店のいろんなキャバ嬢のプロフィール情報が掲載されている

誕生日

{:relative_height='100'}

動機

• 誕生日はお客さんを呼べる口実になるので、高らかにアピールしたい

ひな(24)

誕生日　1991年10月11日

ただし

• 年齢をごまかしているので、生年は出したくない人がいる

ひな

誕生日　10月11日

ただし

• 誕生日は知られたくないけど、若さはアピールしたい人がいる

ひな(24)

ただし

• 個人情報だから誕生日なんて登録したくない人もいる

ひな

制約1

• 18歳未満になるような誕生日は入力させられない

制約2

• 20歳未満になるような誕生日の場合は、「お酒」の欄を出せない

ひな(24)

誕生日　1991年10月11日

お酒　普通

現実世界が複雑だから

• 現実世界にはいろんな方面からのいろんな要請があり、どれももっともらしい理由を伴っている
• 要請を無視する選択もあり得るが、その場合はビジネス上の価値とのトレードオフ

大規模なソフトウェアだから

• 複雑さは組み合わせ爆発する

m通りの内部状態を持つコンポーネントとn通りの内部状態を持つコンポーネントをかけ合わせるとmn通りの内部状態を取りうる

• 大規模であればあるほど爆発的に複雑さが増す

複雑にしないために何ができるのか

• ソフトウェアを書かない
• 要件を削る
• 正しいアーキテクチャを選ぶ
• 複雑さを小さな単位に閉じ込める

ソフトウェアを書かない

• 我々の仕事は「問題を解決すること」であって、「ソフトウェアを書くこと」ではない
• 新たなソフトウェアを書く(=新たな複雑さを生む)ことなく問題解決できる可能性を探るべき

要件を削る

• ビジネス上の価値を諦めることになるので、トレードオフ

正しいアーキテクチャを選ぶ

• 問題領域にふさわしいアーキテクチャを選択しないことにより、複雑さが増すことがある

複雑さを小さな単位に閉じ込める

• 考慮すべき内部状態がmn通りではなく(m+n)通りになるように
• 疎結合
• プログラミング上の技法の少なからぬ部分がこれを目的としている
  • e.g. 構造化プログラミング, オブジェクト指向プログラミング

まとめ

• 複雑なソフトウェアは死ぬ
• 現実、複雑すぎ
• ソフトウェアも複雑になりがち
• 複雑さを抑えるためには、あらゆる手を尽くす必要がある

参考文献

• スティーブ マコネル『CODE COMPLETE 第2版 (上/下)』 日経BP社

ご静聴ありがとうございました

{:relative_height='80'}