第8回 Perlによる大規模システム開発・設計のツボ（3） | gihyo.jp

技術的負債の「見える化」 どのようなソフトウェアにも設計上のミスはあります。設計時点ではサービスの発展性や日々変わりゆく要件を完全に予測することはできないからです。ある時点で正しい設計も、その次のサービスリリースでは設計上の修正を必要とするかもしれません。これらの変更への粘着性や複雑性のある状態を、「⁠技術的負債」と言います。 mixiでは技術的負債は長らく、コードレビューや技術力の高いエンジニアによる新機能リリース時の修正などで対応を行ってきました。しかし、これまでに紹介した「わかりやすいコードの指針」や「アーキテクチャパターン」をレビューや教育だけで維持することは、ソフトウェアが巨大になり、開発者数が増加するにつれて難しくなります。そのため現在では、ソフトウェアの設計品質評価を自動化するツール群を開発し、それらを用いて技術的負債を見える化し、計画的に解消していく試みを行っています。 コ

[halfrack]

"SRP"

[arikui]

[]

[vcc]

ソフトウェアの設計品質評価、メトリクス方法

[kiyo_hiko]

どうでもいい話：俄Java屋やってたときにMetrics結果を会社に提出してベターなコードへの取り組みをと叫んだら、うやむやにされたことがあったが、Perlでも多分そうなる。でもまあこういう情報は押さえておきたいしブクマ

[somat]

循環的複雑度や、モジュール間の依存関係、手を入れてる開発者の数などから、プログラムの負債の程度をポイント付け

[labunix]

Perl Hackers Hub：第8回　Perlによる大規模システム開発・設計のツボ（3） #gihyojp

[okinaka]

ある程度規模が大きくなるとメトリクスの計測も必要