日本のコンピュータ情報 : 富士通富士通は、事業活動に伴う温室効果ガスの排出量（Scope1,2）をグループ全体で2030年度までに100%削減するほか、2040年度までにバリューチェーン全体のScope3をネットゼロにすることを目標としています。 COP28 ジャパン・パビリオンのパネルディスカッションにおいて、富士通 青柳一郎が、気候変動に対する考え方や富士通が行っている施策を報告しました。
複雑度と単体テストケース数の相関関係 - プログラマの思索
garyoさんから、ソースの複雑度と単体テストケース数について有益なアドバイスを示唆してもらったので、メモしておく。 ◆SourceMonitor Version 2.4 SourceMonitorはフリーで、以下の言語のソースのソフトウェア複雑度（McCabeのサイクロマチック数）を測定できる。 例：C++, C, C#, VB.NET, Java, Delphi, Visual Basic (VB6) or HTML ◆McCabe's cyclomatic complexity SourceMonitorで求められる複雑度（McCabeのサイクロマチック数）は、モジュール内の分岐の数（＋ループの数）で計算される。 複雑度の数値は、下記の意味を持つらしい。 10 以下であればよい構造 30 を越える場合，構造に疑問 50 を越える場合，テストが不可能 75 を越える場合，いかなる変更も
どうやってソフトウェアのまずさを数値化するかを調べてみる
開発エンジニアのsugimotoです。 弊社サービスのMARKETING PLATFORMの開発を担当してます。 近頃はソースコードのまずさによりメンテナンスコストの増加やメンテナンスによる新たなバグの発生で悩むことが多かったので、今回はこのまずさをどう数値化したものかを調べてブログに書いてみます。 ○技術的負債 ソースコードのまずさを負債と捉えて数値化できるのではと考え技術的負債について調べてみました。技術的負債のちゃんとした内容はWikipediaとかInfoQとかの記事を見てもらうのが良いので、ここでは理解した内容を簡単にまとめてみます。 ・負債 まず負債って何？ということなんですが、お金と同様に借金です。ソフトウェアの場合、借金に当たるのが良い設計(あるべき姿)に対してどれだけ妥協した設計で作ったかを表します。式で表すと 負債 ＝ 良い設計で作ったもののコスト － 妥協した設計で作
数値で測るコード品質 - give IT a try
プロフィールのところにも書いてあるのですが、おいらの目標は「美しく無駄のないシステムアーキテクチャを設計、構築すること」です。 なぜならシステムの保守性や拡張性って、アーキテクチャやコードの品質によって雲泥の差が出ることを、幾度となく痛感してきているからです。 しかし、どんなアーキテクチャやソースコードがキレイなのか、拡張性や保守性が高いのか、っていうのはなかなか客観的に判断しにくいのもたしか。 「俺のコードはあんたのより分かりやすい」 「そうですか？？」 「絶対そうやろ！？なんでわからんのや？？？」 みたいな議論が始まったらたぶん平行線になっちゃいますよね。 そこでツールを使って、コードの品質を定量的に測ってみることにしました。 今回使ったツール 今回使ったツールはこちらです。 SourceMonitor V3.5 http://sourceforge.net/projects/dupl
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
