もしかしたらコードメトリクスこそが、僕たちを救ってくれるかもしれない。 - Qiita
結論 コードメトリクスの一つ、保守容易性指数と、バグ発生率とに、相関の兆候を見つけた まだ下調べの段階だけど、大規模調査および統計的検定の結果、 保守容易性指数とバグ発生率との相関が認められたら、 保守容易性指数をKPIにすることで、数値的品質評価・管理ができるかもしれない バグをまき散らすけど手が早いエンジニアの影に隠れて、 丁寧にモノづくりをしているけどいまいち評価されていないエンジニアに、 日の目をあてられるかもしれない。 バグ対処コストと保守容易性とを掛け合わせることで、 技術的負債を金銭的評価ができる可能性がある 金銭的に評価できれば、返済に関して、ビジネスサイドと有意義な議論ができる可能性がある はじめに 僕ら(@gakuri、@ahera、@yukke7624)は、とあるSI会社で横断的にプロジェクト支援をしている。 マネジメント状況の監査、支援、テコ入れから、技術的アドバイ
メンバーに恨まれそうな3つのコードレビュー施策を徹底したら、逆にメンバーが爆速で成長した話 - Qiita
ある程度経験を積んだレビュワーがやりがちな失敗は、 指摘しやすいコーディング規約違反だけ指摘している というもの。 コードレビューで指摘するべき欠陥とは、必ずしも規約違反だけではなく、 仕様考慮もれや機能的なバグ、非機能的なセキュリティやパフォーマンス上の問題点も含まれる。 一つ関数に対して複数の視点でソースチェックをしないといけないが、 人間は同時に複数のことは考えられない。 そこでどうすればいいかと情報をあさっていたところ、 われらがIPAがセキュアプログラミング講座というWEBページで、 四回に分けてレビューすることを提唱していた。 １回目はどこに何があるか、 ２回目は可読性が確保されているか、規約にのっとっているか ３回目は機能性 ４回目はセキュリティ といった具合である。 IPAの講座では４回目はセキュリティに限定しているが、 担当していたプロダクトは、非機能面はセキュリティはも
P"r"aying Manager ～節子、それマネジメントちゃう。オカルトや～ - Qiita
はじめに 最近、社内外の多くのプロジェクトマネジメント実態を調べる機会に恵まれた。 その中で、面白いことに気がついた。 問題に直面して、原因を分析しなければ、対策も取ろうとしないマネージャ達。 彼らはマネジメントしていない。ただ祈ってるだけ。 つまり、P"r"aying Manager じゃね？と。 ※Pray ・・・ 祈る Praying Managerの生態 [ケース1] 進捗をPGが自力で回復してくれることを祈る あるプロジェクトでは、3ヶ月の工期のうち、1ヶ月が経過したが、進捗が半月分しか出なかった。 つまりプロジェクトとしては破綻状態であるわけだ。 このことについてマネージャは、 プロジェクトの最初は立ち上がりが悪く、進捗が出ないものなんです。 対策はいずれメンバのスピードが上がってくればという感じですね。 と回答し、なにも手を打たなかった。 （最終的には会社が介入して正常化を図
GMO社が被害を受けたStruts 2（CVE-2017-5638）問題で我々は何を学ぶべきか？ - Qiita
GMOペイメントゲートウェイ社（以下GMOPG）という、クレジット決済代行を取り扱う、 国内最大手の会社がクレジットカード番号を流出させたとして、 3/10以降大きく報道されました。 この事故から、我々エンジニアが学ぶべき事は何でしょうか？ 発生した事象について CVE-2017-5638とはなにか ファイルアップロードにおけるマルチーパートヘッダーの解釈部分に脆弱性があり、 リモートコード実行（RCE）が可能な状態であったらしい 本投稿の趣旨から外れるので、詳しくは調べていません。 経緯・経過 3/6 脆弱性情報が公開されたらしい (Cf. Apache Struts 2における脆弱性 (S2-045、CVE-2017-5638)の被害拡大について ) 3/8 IPAが情報を掲載 (Cf. Apache Struts2 の脆弱性対策について(CVE-2017-5638)(S2-045)
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
