![[PukiWiki]](image/wadanyan.png "[PukiWiki]")
#author("2019-01-04T22:09:15+09:00","","") #author("2019-01-07T13:57:53+09:00","","") [[岡坂]] * レビュー論文 [#hb323ab0] -&attachref(Investigating Code Review Quality- Do People and Participation Matter?.pdf); -&attachref(The Impact of Code Review Coverage and Code Review Participation on Software Quality_1.pdf); -&attachref(An Empirical Study of the Impact of Modern Code Review Practices .pdf); * 卒論進捗 [#hb323ab0] ** 第１章 [#icd3bc3b] -1.1 -1.2 ◯ **第２章 [#gc10caee] -2.1 ◯ -2.2 ◯ **第３章 [#g22b6112] -3.1 ◯ -3.2 ◯ -3.3 ◯ **第４章 [#i56f9deb] -4.1 ◯ -4.2 ◯ -4.3 -4.4 -4.5 **第５章 [#w3a75a4e] -5.1 -5.2 **第６章 [#sc7a9e05] -6.1 -6.2 * 活動報告 [#hb323ab0] **1/7 [#g28a1ac6] ***DONE [#z67b38a3] -不具合の分類目視から進めていく **12/24 [#g28a1ac6] ***DONE [#z67b38a3] -卒論の2章（関連研究），4章（対象プロジェクト・Mozillaコードレビュー）記述 **11/28 [#g28a1ac6] ***DONE [#z67b38a3] -スペルミスによる不具合 --700行以上の変更を一人でレビュー，しかも機能面で指摘する箇所が大量&br; → ９回にわたるレビューでようやく終了，負担が大きすぎる？ --誤字・脱字のみをチェックするレビュワーがいてもいいかも？&br; → 数行だけの変更なら必要なさそうなので，閾値決めたい -知識不足による不具合 --機能性向上のための変更の中で，内部で自動的に設定される値を手動で設定していた&br; (変更は数行だったのでレビューは"コメントつけといたほうがいいよ！"ぐらい)&br; → 不具合が報告されてすぐに気付いていた人がいたのでわかる人が見たらレビュー段階で気付けそう --ちょっとした変更でも機能性向上のための変更であれば，複数人のレビュワーが必要 **7/9 [#g28a1ac6] ***DONE [#z67b38a3] -目視の方法を少し変更 --inducing の方から見た方が理解しやすいが，機能性・可読性の向上のための変更の場合無駄になる&br; → fixed から確認して機能性・可読性の向上のための変更であれば次のコミットを見ることにした --reviewboardのリンクを確認 ***TODO [#z67b38a3] **7/2 [#g28a1ac6] ***DONE [#z67b38a3] -目視継続中 --エラー処理不足 ---条件文忘れ --リファクタリング（？）ミス&br; → より適切な変更をお願いしたところ、不具合が発生 ***TODO [#z67b38a3] -対策を考えることも頭に入れつつ目視を続ける **6/25 [#g28a1ac6] ***DONE [#z67b38a3] -目視継続中 --新機能が追加されたが，その機能が特定の場合に使用できないことを知らずに使っていたことによる不具合があった&br; （不具合が出てから判明した？） --２つの不具合があり、異なる修正方法をとるべきところを同じ修正をしていた&br; → １つの不具合にのみ議論は多くされていた --新規ファイルが作成されたときに不具合が出ることがやはり多い **6/19 [#g28a1ac6] ***DONE[#p12c6a2d] -15 件目視 --コミットが見当たらないものがある --ファイルが別の名前あるいは無くなっている, 統合されているものがある &br; → 時間はかかるけど見つけられるかも -輪講用の論文を読んだ -見逃しバグ数：510 件, 期間 2015/10/01~2016/09/30 では 465 件 &br; （FixedBugIdの数だけでいうとまだ少なくなる） ***TODO [#z67b38a3] -40 件まで目視 --先週できなかった分も今週やるつもりで40 -コードから判断したのかBugzillaのコメントから判断したのかで目視結果を分ける **6/11 [#g28a1ac6] ***DONE[#p12c6a2d] -10 件目視&br; ※ 目視件数を変更ファイル数から見逃しバグ数に変更（2500 → 400） -研究報告（研究発表会で使用した資料）：&attachref(研究発表_0611.pdf); ***TODO [#z67b38a3] -25 件まで目視 -Investigating Code Review Quality: Do People and Participation Matter?の論文をもう一度読んで，SZZアルゴリズムの使い方を理解する -コード内の変数の意味を見つけてみる -見逃しバグ数の確認 -目視結果を事実と推測に分ける **6/9 [#g28a1ac6] ***DONE[#p12c6a2d] -５０件目視 --可読性や機能性向上のための変更もあったが，例外処理忘れのようなバグ原因が見られた． ***TODO [#z67b38a3] **5/28 [#g28a1ac6] ***DONE[#p12c6a2d] -FixedCommitId[4649ee47134c9985a626e2354a43d201e043e9cc]とInducingCommitId[5cb1b77a4e889d8c73902915906238ccbfbefb9b]の変更内容を確認し、どのような修正をしていたか実際に確認（変更箇所はエクセルファイルに記載されていた） -FixedBugId[1303054]のコメント欄からどのような議論からその変更に至ったか確認 -InducingBugのコメント欄はまだ読めていないのでなぜバグが混入したことを見つけられなかったのかは不明 ***TODO [#z67b38a3] -２０件目視 **5/22 [#g28a1ac6] ***DONE[#p12c6a2d] -An Empirical Study of the Impact of Modern Code Review Practices on Software Quality --The Impact of Code Review Coverage and Code Review Participation on Software Qualityの拡張版 --レビュワーの専門知識がソフトウェアの品質と関係があるかどうかの調査が追加されていた --相も変わらず分析手法が理解しにくい(重回帰分析に結び目を追加して、より精度の高い曲線を描く？) -柏さんに目視対象のMozillaデータを送ってもらった ***TODO [#z67b38a3] -目視用エクセルファイルの意味を理解する --まずはFixedCommitId[4649ee47134c9985a626e2354a43d201e043e9cc]から紐解いてみる **5/15 [#g28a1ac6] ***DONE[#p12c6a2d] -読んだ - The Impact of Code Review Coverage and Code Review Participation on Software Quality ***TODO [#z67b38a3] -柏さんからMozillaのデータの場所を聞く **5/8 [#g28a1ac6] ***DONE[#p12c6a2d] -読んだ - Investigating Code Review Practices in Defective Files- An Empirical Study of the Qt System -途中 - The Impact of Code Review Coverage and Code Review Participation on Software Quality ***TODO [#z67b38a3] -読む - The Impact of Code Review Coverage and Code Review Participation on Software Quality -まとめる - Investigating Code Review Practices in Defective Files- An Empirical Study of the Qt System **4/23 [#g28a1ac6] ***DONE [#z67b38a3] - 読み終えた：“Investigating Code Review Quality: Do People and Participation Matter? （&attachref(icsme15-OleksiiOlgaLatifa.pdf);） --まとめ資料：（&attachref(Investigating Code Review Quality - Do People and Participation Matter?.pdf);） -メモ --ccリストに追加されている開発者数がレビューの質に与える影響のことには触れていたが, レビュー自体に参加している開発者数の影響は？（そもそもレビューは複数人でするものなのかどうか） --個人的要因のメトリクスと参加のメトリクスを使って重回帰分析をしても意味はないのか. --多重共線性があったメトリクスは片方が除去されていたが, どちらを除去してもいいのか. --szzアルゴリズムの論文（&attachref(szz_algo.pdf);）にも一応目を通してみようと思う. --これ気になる（まだ読んでないけど）（&attachref(深層学習＿バグ混入コミット予測.pdf);） --亀井先生・Shane McIntosh先生の論文:（&attachref(McIntosh_EMSE2015.pdf);） ***TODO [#z67b38a3] - これ読む（&attachref(Investigating Code Review Practices in Defective Files- An Empirical Study of the Qt System.pdf);)&br; （&attachref(The Impact of Code Review Coverage and Code Review Participation on Software Quality_0.pdf);） -亀井先生・Shane McIntosh先生の論文:（&attachref(McIntosh_EMSE2015.pdf);） **4/16 [#g28a1ac6] ***DONE [#z67b38a3] - 途中まで読んだ：“Investigating Code Review Quality: Do People and Participation Matter? ***TODO [#z67b38a3] - 論文まとめる **4/9 [#g28a1ac6] ***TODO [#z67b38a3] - Oleksii Kononenko, Olga Baysal, Latifa Guerrouj, Yaxin Cao and Michael W. Godfrey,“Investigating Code Review Quality: Do People and Participation Matter?,”Software Maintenance and Evolution (ICSME), pp.111-120, 2015を読む（時間があれば資料としてまとめる） -研究室Wikiにあるコードレビュー関係の資料に目を通す． ***メモ [#p6b8c498] -SZZアルゴリズムとは？ --バグ混入コミットを特定するアルゴリズム
