Upload
others
View
0
Download
0
Embed Size (px)
Citation preview
© DebugEng Debug Engineering InstituteETWest2017 Booth presentation
IoT時代におけるコードの品性~ 人力レビューと機械レビュー ~
松尾谷 徹デバッグ工学研究所代表[email protected]
© DebugEng Debug Engineering InstituteET/IoT West2017Booth presentation
解説の概要
何の解説か? レビューのお話し
概要
1. 工学における一般的な手法としてのレビュー
2. ソフトウェア工学とレビュー:概観
3. 黎明期:エドガー・ダイクストラの構造化プログラミング
4. 発展期:ペヤプロなどアジャイル開発
5. 転換期:MIRSA-Cとコードの安全性(型安全)
6. IoT時代:これからの課題と対策
大筋は
SWの複雑化,肥大化のため従来技法では対応できなくなった
人力レビューを支援,代替する技術へのシフト
伝えたいこと
乗り遅れて置き去りにされないように!!+基本を忘れないように
2
© DebugEng Debug Engineering InstituteETWest2017 Booth presentation
1.リニューアル概要
知的な活動を評価する唯一の手法
1. レビューとは
3
<IoT時代におけるコードの品性>
© DebugEng Debug Engineering InstituteET/IoT West2017Booth presentation
レビューの構造
例:専門家(博士など)の認定 (ジャーナル論文の数)
分野を問わず論文は,第三者の査読による判定
長い歴史(3百年?)がある.他の手段が無い
査読者複数(3)
当該分野の専門家
表記法Syntax
意味Semantic
博士の修行者
論文 成果をまとめる結果は1.採録2.条件付き3.不採録
4
© DebugEng Debug Engineering InstituteET/IoT West2017Booth presentation
産業界では 設計の良否を判定するための設計査閲として定着
機械系
Syntax :3面図など製図の規則,現在はCADシステム
Semantic: 強度や加工の容易性など
電気系
Syntax :回路図の規則,現在はCADシステム
Semantic: キルヒホッフの法則,過渡応答,電磁輻射など
建築デザイン系
Syntax :スケッチ,意匠設計
Semantic: 感性による判断?
製品企画
??
企業の場合,人材育成の側面がある5
© DebugEng Debug Engineering InstituteET/IoT West2017Booth presentation
(一般的な)レビューとは
知的な成果物に対する,客観的な評価手法
レビューを可能にするには(前提条件)
1. 当該分野の専門家が共有するSyntaxに従った表現
レビュー結果の良否
1. レビューを行う専門家のスキルに依存
2. 客観性を高めるため複数の査読者(目の数を増やす)
レビューの費用効果
レビューにはコストがかかる
良否の判別と並行して,コメントによるフィードバック育成へ6
© DebugEng Debug Engineering InstituteETWest2017 Booth presentation
1.リニューアル概要
ソフトウェア工学におけるレビューを概観する
2. ソフトウェア工学とレビュー
7
<IoT時代におけるコードの品性>
© DebugEng Debug Engineering InstituteET/IoT West2017Booth presentation
ソフトウェア工学とレビュー
専門家の育成と認定
SEの博士認定システムは,他の分野と同じ査読(レビュー)システム
産業界におけるレビューの変化
黎明期:個人依存のため体系的なレビュー未完成 ~1970代
構造化プログラミング:エドガー・ダイクストラの提案
発展期:チーフプログラマ制,アジャイルを経て現代のOSSへ
転換期:MIRSA-Cとコードの安全性
混乱期:セキュリティ問題
IoT時代:これからの課題と対策
日本では,ちょっと違ったレビュー道もあった
外部品質保証とエビデンスのレビュー プロセス系のレビュー
– 今回は対象外
8
© DebugEng Debug Engineering InstituteET/IoT West2017Booth presentation
エビデンスのレビュー 技術分野とは別の分野:会計監査など
SWの世界では,システム監査など
基本構造
対象はプロセス
前提はプロセスに対して守るべき標準ありき
Syntax:標準で定義されたエビデンス書式
Semantic:標準で定義された活動が行われたか?
客観性を保つため,内部監査と外部監査
時代背景
国内のSW産業が受託型であり,プロダクトの品質保証ができない
よって,受託するプロセスの品質保証として流行った
その費用効果は??9
© DebugEng Debug Engineering InstituteETWest2017 Booth presentation
1.リニューアル概要
ソフトウェア工学はレビューから始まった
3. 黎明期のレビュー
10
<IoT時代におけるコードの品性>
© DebugEng Debug Engineering InstituteET/IoT West2017Booth presentation
黎明期??
書物によると
1946年のENIAC コンピュータの出現
1964年 IBM360の発表 OS360(すでに巨大 5Mlines)
1960年代:軍事システムや社会システムなど巨大システム開発
– ソフトウェア危機が発生 1968年 NATO主催の会議ソフト工学
1960年代における変化
個人技,職人技でSW開発は進んだが,大規模化で破綻!!
1970年代の発展期へ流れを変えたのはエドガー・ダイクストラの構造化プログラミング
11
© DebugEng Debug Engineering InstituteET/IoT West2017Booth presentation
構造化プログラミングとは? 師匠から聞いた話(1983年頃)
師匠は,エドガー・ダイクストラからその発見や原理について直接話を聞き,深く内容を理解していた.
師匠は,我々に次のような話をした.
1. 学者であるエドガー・ダイクストラが発見できた訳?
バローズ社のコンサルとして統計分析とヒアリングの結果
高生産性チームの事例分析
2. 「制御構造の抽象化」はsyntax側面
追従実験:おれおれコードとgoto-lessコード,どっちのQCDが良いか?
個人の生産性とチームの生産性
3. 2つの側面
1. リーダがレビューしやすい構造産業界:チーフプログラマ制度
2. 構造上の誤りが入りにくい構造その後も研究者のテーマ
– 最終的には抽象構文木(AST)として完成しコンパイラーで対応(現代)12
© DebugEng Debug Engineering InstituteET/IoT West2017Booth presentation
個人からチームへ 当時は
書物などから得られる知識はほとんど無かった.
コンピュータは高価であり個人では経験知識を得られなかった.
有能な棟梁に弟子入りするチームの起源 1960年代,IBMやバローズではチームが自然発生
ところがチームの生産性には大きなばらつきがあった
– 1981年バリー・ベームの著書 Software Engineering Economics
高生産性チームの分析
エドガー・ダイクストラの分析:構造化プログラミング
レビューを容易にする制御構造(レビューのSyntaxとして)の導入
メンバーの成長が速い
チーフプログラマー制の定着
IBMを始め多くの企業が取り入れ,現代に至る
日本は違った解釈をした・・・権威型チーフプログラマ制?
13
© DebugEng Debug Engineering InstituteETWest2017 Booth presentation
1.リニューアル概要
SW需要の拡大に翻弄される
4. 発展期のレビュー
14
<IoT時代におけるコードの品性>
© DebugEng Debug Engineering InstituteET/IoT West2017Booth presentation
発展期
1970年代 構造化プログラミングからSW工学技術開花
DFD,ER図,ミニスペックなどの手法が広まった
1980年代 SW需要は飛躍的に拡大し,非熟練者の大量参入
産業界は,量をこなす技術を求めた.結果,プロセス指向
品質管理や構成管理などの管理技術と開発環境が注目された
複雑性対策より規模対策!!
1990年代 インターネットによる新天地が開花
80年代の規模の課題から,Web技術による多様なシステムの課題へ
オブジェクト指向による抽象化概念の拡大
レビューに課せられた課題:スピード(技術進歩,納期)
ウォーターフォール・モデルからアジャイルへ
速いレビューペアプログラミング(作りながらレビュー)15
© DebugEng Debug Engineering InstituteET/IoT West2017Booth presentation
完成期
2000年代 主役の交代プロプラソフトからOSSへ Webとの連携が進み,単独プロダクトの相対価値が低下
一部の巨大企業かニッチな分野以外でプロプライエタリ・ソフトウェアはビジネスとして成立しなくなった.
結果,多くのプロダクトはOSSへ
サービスは,企業固有からサービスプロバイダーへ変化
レビュー方式はOSS型が主流となった
GitHubで公開されている
Googleを含め多くの企業が同様の方式で行っている
– クローズプロジェクトでも方式は同じ
レビュー結果は3つ
– いいね,私ならこうする,このように変えるべき
貢献のカウント
– 追加だけでなく,削除もレビューしカウント(重要)16
© DebugEng Debug Engineering InstituteETWest2017 Booth presentation
1.リニューアル概要
Semantic上の問題
5. レビューの転換期
17
<IoT時代におけるコードの品性>
© DebugEng Debug Engineering InstituteET/IoT West2017Booth presentation
新たな問題安全性 ソフトウェアの信頼性技術 =テストとレビュー
順調に発展してきたが,大きな問題に遭遇
警鐘:C言語の安全性問題Misra-C
英国の自技会配下の組織Motor Industry Software Reliability Association
1998年に初版を出版
C言語はアセンブラー並になんでも記述できる言語(特徴であった)
ところが,オーバーランやスタッフオーバーフローなどを防げない
メモリーリークやアクセス違反を防げない
これれは,プログラマー側の責任である=レビューで対処が必要.
致命的なソフトウェア不具合を生む潜在性がある=不安全
テストでは検出が困難
レビューで対処するしか手段が無いが,とても困難18
© DebugEng Debug Engineering InstituteET/IoT West2017Booth presentation
Web接続による課題の拡大
当初,組込み系の安全問題は善良なエンジニアの課題
ポインター操作など複雑なコード記述スキルの課題
Misra-Cはレビューの観点として利用された
Web接続の増加により,悪意のある攻撃が顕在化
組込系もWebに接続されるケースが増加
– ルーター,リモート監視,
安全性は製造者責任・・・・しかし対策が困難
19
© DebugEng Debug Engineering InstituteET/IoT West2017Booth presentation
対策 レビューのSyntax面の改善では対応できない
Semantic系の支援が必要になった
対策の一つとしてMisra-C :こんな場合に危ない可能性がある
代表的な危ない可能性をリストアップした
– 高スキルのリーダは,これをヒントに自チームで対処
– そうでないリーダ(権威型リーダ)のレビューでは無理
– サイクロマティック数は20以下,ポインター使用禁止などの対処療法?
– かなりトンチンカンで迷走
Toolでの支援が始まる
Misra-C準拠を自称するToolが出現 (Misraは認証していない)
使うと,山のように偽陽性を吐き出し,これも対処が困難
多くの現場では・・・・課題の先送り
出来ないことは口にしない
20
© DebugEng Debug Engineering InstituteETWest2017 Booth presentation
1.リニューアル概要
これからどうする
6. IoT時代のレビュー
21
<IoT時代におけるコードの品性>
© DebugEng Debug Engineering InstituteET/IoT West2017Booth presentation
言語の安全性問題 解1 安全な言語を使う
型安全については研究が進んでいる
安全では無い言語 C, C++,
かなり型安全 Java,C#
型安全 Python, Ruby
さらに進んだ言語 Go,Swiftなど
解2 解析Toolを使う
静的解析は実用レベルになっている Coverityなど
– 価格問題がある 対策:安いToolで偽陽性対策を徹底
– :このさいOSS化する(無料でCoverity)
原理的に静的解析は限界がある
– 動的解析を使う・・・ただし研究レベルなので自組織向け対応が必要
解3 レビュー者のスキルを高める
アセンブラーでもCでも,高スキルのレビュー者なら安全を確保できる(可能性として)
22
© DebugEng Debug Engineering InstituteET/IoT West2017Booth presentation
時代のトレンド NASAの例 10のコーディング規則
https://www.reddit.com/r/learnprogramming/comments/4npim9/10_coding_practices_which_allows_nasa_to_write/
その要約:http://qiita.com/tomboyboy/items/1b5625d429ea4aa1ac32
おもしろいのは,静的解析ツールを使いやすくするための規則が含まれていること
23
人力向け
機械向け
人的資源
コードなどレビュー対象
Tool
© DebugEng Debug Engineering InstituteET/IoT West2017Booth presentation
IoT時代のトレンド
未来を予測するのは不可能ですが,
IoT時代の特徴
単独プロダクトでは生きていけない
メジャーサービスの一部に採用(選ばれる)されること
そのためには,
コードの開示は必須
自身の信頼性だけでなく系としての安全性を担保すること
レビュー方式は変化する 今回の結論 人力では限界
Toolとの併用,Toolの能力を引き出すコーディング規約
おまけ:C系のToolとしてはLLVM系のclangなどが有望24
© DebugEng Debug Engineering InstituteET/IoT West2017Booth presentation
まとめ
レビューは今後も(テストと並び)重要な技術
変化が生じる変化の本質を知ること(言語を替えるなど)
人力レビューの限界
機械(Tool)による支援が必要
そのためのコーディング規則の見直しと運用が必要
せめてWarningを無くす・・・Toolを活かすために
今後も技術進歩は加速するので,常に追従して行く必要がある.・・・・70年代にB言語を使ったのが懐かしい老人より
25
© DebugEng Debug Engineering InstituteET/IoT West2017Booth presentation
Q&A
ご清聴を感謝します
26