メンテナンスとは
ソフトウェアを開発するにあたって、最も大切なことは「保守性」です。
リリースして終わりではなく、リリースしてからは、新しい機能を追加していくことや、ユーザからの反応にあわせて機能を改修していくことなど、ソフトウェアをずっと直していくことになります。そのソフトウェアの「直しやすさ」が「保守性」と呼ばれます。
どうすれば小さなチームでも大きな成果を出せるのか 〜 少人数のチーム、低コストで開発を続けていくためのプロセスを学ぶ | Social Change!
テストを書くことは、検収や納品をパスするためのものではなく、「直しやすさ」を保証するためのものです。メンテナンス性に気をつけて開発しましょう。
ソフトウェアは成長させる
ソフトウェアが失敗する唯一最大の兆候は規模です。よく考えれば、最初から大規模なシステムを設計することにほとんどメリットはありません。にもかかわらず、アーキテクトは誰しも最初から大きなシステムを設計したくなるものです。最初から大規模なシステムを設計すると、付随的な複雑さや惰性の仕事を招きやすいばかりでなく、プロジェクトが大規模になります。しかし、大きなプロジェクトは失敗しやすく、テストできなくなる危険も高く、もろくなりやすく、不要で使われない部品が作り込まれやすく、高くつきやすく、政治的に不都合なものになりやすいのです。
優れたソフトウェアは構築されるのではなく、成長する - ソフトウェアアーキテクトが知るべき97のこと
できる限り小規模なシステムを設計し、その実現を助け、大きいビジョンに向かってシステムを成長させましょう。
Twitterの初期
ハッシュタグも、リツイートもユーザー発信の機能
Twitterは昔「twttr」だった?!2006年頃のTwitterを振り返る - 聴く耳を持たない(片方しか)
ソフトウェアは育てないといけない
- 人間と同じ、生きている限りメンテナンスが必要
- ソフトウェアは小さく始めないと危ない
- 段階設計(フェーズ設計)をして、螺旋的に成長させる
ソフトウェアはナマモノ
- コードをメンテナンスしないと動かなくなる
- ソフトウェアは相互依存によって成り立っている
- 依存するソフトウェアが変化するのでこちらも変化する必要がある
- 世の中の変化とともにソフトウェアの要件自体も変化する
着地のイメージがない
- 企画立案者(ソフトウェアの発注者)も、完成形のイメージがない
- 多くの場合、作っている途中で完成系のイメージが変わる
- 変わるたびに大騒ぎし、一生完成しない = 仕様変更問題
- また、同じ情熱を持った開発チームだったとしても、完成形のイメージが違う
- 人の思考は、基本的にはシンクロしない
要件定義・機能定義は難しい
- ここにないものの要件や機能を定義することは難しい
- だからこそ、1周して形にする必要がある
- 形にする前に議論したり、要件を変えても無駄
- 要件は基本的にフェーズの最初に決め打ち
- 開発中に変更させることはご法度
- 変更させるなら次のフェーズ
- 螺旋的に成長させる過程で捨てる予定のコードが使われることはよくある
コードを書き直す
最近のコード書きでオススメしているのは、一回実装が終わったら、プロダクトコードを一回消せなのだけれど、実は、最初のプロダクトコードは、問題を理解するためのコードなんだな。
問題を理解するためのコード->問題を形式化するためのコード->実際のプロダクトコードの順で書く。問題を形式化するためのコード(TDD/BDDのテスト)が書けたら、最初の理解のためのコードを消して、プロダクトコードに書き直す。最初のコードを、プロダクトコードに流用しないのが大事。
過剰品質 vs ハインリッヒの法則
過剰品質は意味がない。
ただし、ハインリッヒの法則が現実になるのは困る。
ハインリッヒの法則
1つの重大事故の背後には29の軽微な事故があり、その背景には300の異常が存在する
これは、例えるならば、1つの重大なシステム障害の背後には、29のエラーログが出力されており、その背景には300のインデントミスやスペルミス、命名規約ミス、不適切なコメント、重複したコード
誰のための品質なのか? ユーザーのためか? 発注者のためか? 発注者のための品質に消耗する必要はあるのか
検収と正常の定義
ソフトウェアの複雑性 > 人間の認知能力
その複雑なシステムを検収するには、天才的な頭脳が必要かもしれない。
認知できるサイズのソフトウェアにしよう!