「技術的負債」の版間の差分

出典: フリー百科事典『ウィキペディア(Wikipedia)』
削除された内容 追加された内容
Shingo.a (会話 | 投稿記録)
出典追加
編集の要約なし
15行目: 15行目:
==対応ツール==
==対応ツール==
[[SideCI]] - [[Ruby]](汎用プログラミング言語)に対応して'''技術的負債'''を可視化する「負債カンバン」を提供している。<ref>{{Cite web|url=http://jp.techcrunch.com/2016/08/31/sideci-introduces-technical-debt-kamban/|title=自動コードレビュー「SideCI」が、技術的負債を可視化する「負債カンバン」提供開始|last=Nishimura|first=Ken|website=TechCrunch Japan|access-date=2016-12-15}}</ref>
[[SideCI]] - [[Ruby]](汎用プログラミング言語)に対応して'''技術的負債'''を可視化する「負債カンバン」を提供している。<ref>{{Cite web|url=http://jp.techcrunch.com/2016/08/31/sideci-introduces-technical-debt-kamban/|title=自動コードレビュー「SideCI」が、技術的負債を可視化する「負債カンバン」提供開始|last=Nishimura|first=Ken|website=TechCrunch Japan|access-date=2016-12-15}}</ref>



==参考文献==
==参考文献==
22行目: 21行目:
==関連項目==
==関連項目==
* [[大きな泥だんご]]
* [[大きな泥だんご]]
* [[SQALE]]


==外部リンク==
==外部リンク==

2019年10月19日 (土) 18:04時点における版

技術的負債: Technical debt)とは、行き当たりばったりなソフトウェアアーキテクチャと、余裕のないソフトウェア開発が引き起こす結果のことを指す新しい比喩である[1]。「設計上の負債(design debt)」とも言う。

1992年ウォード・カニンガムが、技術的な複雑さと債務の比較を経験報告で初めて行った。

最初のコードを出荷することは、借金をしに行くのと同じである。小さな負債は、代価を得て即座に書き直す機会を得るまでの開発を加速する。危険なのは、借金が返済されなかった場合である。品質の良くないコードを使い続けることは、借金の利息としてとらえることができる。技術部門は、欠陥のある実装や、不完全なオブジェクト指向などによる借金を目の前にして、立ち尽くす羽目になる[2]

Joshua Kerievskyは、彼の影響ある著作の一つ『Refactoring to Patterns』において、彼が「設計上の借金」と呼ぶアーキテクチャの手抜きによるコストに関して類似した議論を示した[3]

開発の中で先送りされるのは、文書化テストコードの記述、ソースコード中の積み残し(TODO)項目の解決やコンパイラの警告、静的コード解析ツールの解析結果への対応などである。その他にも、技術的負債の例として、組織で共有されない知識や、複雑すぎて変更が難しいコードなどがある。

オープンソースソフトウェアでは、手元で変更したコードをプロジェクトに送らないことは技術的負債である。手元で必要なメンテナンスをすること、その結果プロジェクト全体での他のユーザーがメンテナンスしなくて済むことが、ここでは「利息の支払い」にあたる。進行中のプロジェクトは、将来借金を返すコストを増大させていると言える。

対応ツール

SideCI - Ruby(汎用プログラミング言語)に対応して技術的負債を可視化する「負債カンバン」を提供している。[4]

参考文献

  1. ^ s:プログラマが知るべき97のこと/分別のある行動
  2. ^ Ward Cunningham (1992年3月26日). “The WyCash Portfolio Management System”. 2008年9月26日閲覧。
  3. ^ Kerievsky, Joshua (2004). Refactoring to Patterns. ISBN 0321213351 
  4. ^ Nishimura, Ken. “自動コードレビュー「SideCI」が、技術的負債を可視化する「負債カンバン」提供開始”. TechCrunch Japan. 2016年12月15日閲覧。

関連項目

外部リンク