[3] [[プロトコル]]の[DFN[拡張性]]とは、 新機能の追加の余地です。 [4] [[拡張性]]は柔軟性と発展性のために重要ですが、 [[相互運用性]]や[[セキュリティー]]の穴となることが多い危険要素でもあります。 [FIG(short list)[ [1] [[拡張性]]の概念 - [[Must-Understand]]/[[Must-Ignore]] - [[critical]]/[[non-critical]] - [[機能テスト]] - [[能力の記述]] - [[バージョニング]] - [[分散拡張性]] - [[登録簿]] - [[イカの耳]] - [[将来の標準化のために保留]] - [[先方互換性]] ]FIG] [FIG(short list)[ [5] [[拡張性]]の実現 - [[前方互換構文解析規則]] - [[RFC 2774]] [CODE[Man:]]/[CODE[Opt:]] - [[Markup Compatibility and Extensibility]] - [CODE[crit]] - [[外来マーク付け]] - [[TLS拡張]] - [[XML名前空間]] - [[カスタム要素]] - [CODE[mustUnderstand]] - [CODE[Require:]] - [CODE[extensions][extensions (GPX)]] - [CODE[annotation][annotation (SBML)]] - [CODE[definitionURL]] - [[ctext]] の拡張性 - [[OpenType]] の版番号 - [[HTTPの版]] - [[プラグイン]] - [CODE[object][]] - [[コメントの中身が意味を持ってしまう]] ]FIG] [2] [CITE@en[RFC 6709 - Design Considerations for Protocol Extensions]] ([TIME[2018-04-05 17:00:08 +09:00]]) [6] なお稀に「拡張性」は[[スケーラビリティー]]の訳語にも使います。 意味は似ていないこともないですが、 [[情報工学]]的には明確に違う概念です。 - [11] [CITE@ja[YAGNI - Wikipedia]], [TIME[2023-07-09T13:55:41.000Z]], [TIME[2023-07-24T12:28:22.274Z]] - [10] [CITE[YAGNI と premature complication #4]], [TIME[2021-05-15T13:33:48.000Z]], [TIME[2023-07-24T12:27:56.273Z]] - [8] [CITE@ja[くまぎさんはTwitterを使っています: 「@kfujieda プラガブルになったことで簡単になる機能実装はプラガブル設計をしたときにすでに織り込んでいた機能に限られるんですよこれが。そして更に別方向の機能追加をさらなるDIで取り込み続けるうちに絡まるんです…。」 / Twitter]], [TIME[午前10:00 · 2023年6月27日][2023-06-27T01:00:05.000Z]], [TIME[2023-07-24T12:16:13.000Z]] - [7] [CITE@ja[Shirouzu Hiroaki(白水啓章)さんはTwitterを使っています: 「そういえば昔、Namazuの高林哲さんが「将来性を考えた実装(抽象層を噛ませてメタ化しておく等)は、大半は想定した未来が来ないので無駄」と書いていたっけ…。 https://t.co/szYqfK71PD あたりにあったと思うのだが、見つけられない。」 / Twitter]], [TIME[午後10:53 · 2023年6月27日][2023-06-27T13:53:40.000Z]], [TIME[2023-07-24T12:16:13.000Z]] - [9] [CITE@ja[AoiMoe a.k.aしお兄PさんはTwitterを使っています: 「プログラマの病気として KISS の法則を忘れがちというのはあって、将来発生するかも分からないような機能拡張を見込んで拡張性豊かに書いたけど実際には使われず、結果としてその複雑さがメンテの足を引っ張るとか良くある。そういうのは「作りすぎ」なんだろう。」 / Twitter]], [TIME[午前2:28 · 2023年7月24日][2023-07-23T17:28:21.000Z]], [TIME[2023-07-24T12:16:13.000Z]]