IoT時代におけるコードの品性 - IPA ·...

© 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


１．リニューアル概要

知的な活動を評価する唯一の手法

1. レビューとは

3

＜IoT時代におけるコードの品性＞


レビューの構造

例：専門家（博士など）の認定（ジャーナル論文の数）

分野を問わず論文は，第三者の査読による判定

長い歴史（３百年？）がある．他の手段が無い

査読者複数（３）

当該分野の専門家

表記法Syntax

意味Semantic

博士の修行者

論文成果をまとめる結果は1.採録2.条件付き3.不採録

4


産業界では設計の良否を判定するための設計査閲として定着

機械系

Syntax :３面図など製図の規則，現在はCADシステム

Semantic: 強度や加工の容易性など

電気系

Syntax :回路図の規則，現在はCADシステム

Semantic: キルヒホッフの法則，過渡応答，電磁輻射など

建築デザイン系

Syntax :スケッチ，意匠設計

Semantic: 感性による判断？

製品企画

？？

企業の場合，人材育成の側面がある5


（一般的な）レビューとは

知的な成果物に対する，客観的な評価手法

レビューを可能にするには（前提条件）

1. 当該分野の専門家が共有するSyntaxに従った表現

レビュー結果の良否

1. レビューを行う専門家のスキルに依存

2. 客観性を高めるため複数の査読者（目の数を増やす）

レビューの費用効果

レビューにはコストがかかる

良否の判別と並行して，コメントによるフィードバック育成へ6



ソフトウェア工学におけるレビューを概観する

2. ソフトウェア工学とレビュー

7



ソフトウェア工学とレビュー

専門家の育成と認定

SEの博士認定システムは，他の分野と同じ査読（レビュー）システム

産業界におけるレビューの変化

黎明期：個人依存のため体系的なレビュー未完成～1970代

構造化プログラミング：エドガー・ダイクストラの提案

発展期：チーフプログラマ制，アジャイルを経て現代のOSSへ

転換期：MIRSA-Cとコードの安全性

混乱期：セキュリティ問題

IoT時代：これからの課題と対策

日本では，ちょっと違ったレビュー道もあった

外部品質保証とエビデンスのレビュープロセス系のレビュー

– 今回は対象外

8


エビデンスのレビュー技術分野とは別の分野：会計監査など

SWの世界では，システム監査など

基本構造

対象はプロセス

前提はプロセスに対して守るべき標準ありき

Syntax:標準で定義されたエビデンス書式

Semantic:標準で定義された活動が行われたか？

客観性を保つため，内部監査と外部監査

時代背景

国内のSW産業が受託型であり，プロダクトの品質保証ができない

よって，受託するプロセスの品質保証として流行った

その費用効果は？？9



ソフトウェア工学はレビューから始まった

3. 黎明期のレビュー

10



黎明期？？

書物によると

1946年のENIAC コンピュータの出現

1964年 IBM360の発表 OS360（すでに巨大 5Mlines)

1960年代：軍事システムや社会システムなど巨大システム開発

– ソフトウェア危機が発生 1968年 NATO主催の会議ソフト工学

1960年代における変化

個人技，職人技でSW開発は進んだが，大規模化で破綻！！

1970年代の発展期へ流れを変えたのはエドガー・ダイクストラの構造化プログラミング

11


構造化プログラミングとは？師匠から聞いた話(1983年頃)

師匠は，エドガー・ダイクストラからその発見や原理について直接話を聞き，深く内容を理解していた．

師匠は，我々に次のような話をした．

1. 学者であるエドガー・ダイクストラが発見できた訳？

バローズ社のコンサルとして統計分析とヒアリングの結果

高生産性チームの事例分析

2. 「制御構造の抽象化」はsyntax側面

追従実験:おれおれコードとgoto-lessコード，どっちのQCDが良いか？

個人の生産性とチームの生産性

3. ２つの側面

1. リーダがレビューしやすい構造産業界：チーフプログラマ制度

2. 構造上の誤りが入りにくい構造その後も研究者のテーマ

– 最終的には抽象構文木（AST)として完成しコンパイラーで対応（現代）12


個人からチームへ当時は

書物などから得られる知識はほとんど無かった．

コンピュータは高価であり個人では経験知識を得られなかった．

有能な棟梁に弟子入りするチームの起源 1960年代，IBMやバローズではチームが自然発生

ところがチームの生産性には大きなばらつきがあった

– 1981年バリー・ベームの著書 Software Engineering Economics

高生産性チームの分析

エドガー・ダイクストラの分析：構造化プログラミング

レビューを容易にする制御構造（レビューのSyntaxとして）の導入

メンバーの成長が速い

チーフプログラマー制の定着

IBMを始め多くの企業が取り入れ，現代に至る

日本は違った解釈をした・・・権威型チーフプログラマ制？

13



SW需要の拡大に翻弄される

4. 発展期のレビュー

14



発展期

1970年代構造化プログラミングからSW工学技術開花

DFD,ER図，ミニスペックなどの手法が広まった

1980年代 SW需要は飛躍的に拡大し，非熟練者の大量参入

産業界は，量をこなす技術を求めた．結果，プロセス指向

品質管理や構成管理などの管理技術と開発環境が注目された

複雑性対策より規模対策！！

1990年代インターネットによる新天地が開花

80年代の規模の課題から，Web技術による多様なシステムの課題へ

オブジェクト指向による抽象化概念の拡大

レビューに課せられた課題：スピード（技術進歩，納期）

ウォーターフォール・モデルからアジャイルへ

速いレビューペアプログラミング（作りながらレビュー）15


完成期

2000年代主役の交代プロプラソフトからOSSへ Webとの連携が進み，単独プロダクトの相対価値が低下

一部の巨大企業かニッチな分野以外でプロプライエタリ・ソフトウェアはビジネスとして成立しなくなった．

結果，多くのプロダクトはOSSへ

サービスは，企業固有からサービスプロバイダーへ変化

レビュー方式はOSS型が主流となった

GitHubで公開されている

Googleを含め多くの企業が同様の方式で行っている

– クローズプロジェクトでも方式は同じ

レビュー結果は３つ

– いいね，私ならこうする，このように変えるべき

貢献のカウント

– 追加だけでなく，削除もレビューしカウント（重要）16



Semantic上の問題

5. レビューの転換期

17



新たな問題安全性ソフトウェアの信頼性技術 =テストとレビュー

順調に発展してきたが，大きな問題に遭遇

警鐘：C言語の安全性問題Misra-C

英国の自技会配下の組織Motor Industry Software Reliability Association

1998年に初版を出版

C言語はアセンブラー並になんでも記述できる言語（特徴であった）

ところが，オーバーランやスタッフオーバーフローなどを防げない

メモリーリークやアクセス違反を防げない

これれは，プログラマー側の責任である＝レビューで対処が必要．

致命的なソフトウェア不具合を生む潜在性がある＝不安全

テストでは検出が困難

レビューで対処するしか手段が無いが，とても困難18


Web接続による課題の拡大

当初，組込み系の安全問題は善良なエンジニアの課題

ポインター操作など複雑なコード記述スキルの課題

Misra-Cはレビューの観点として利用された

Web接続の増加により，悪意のある攻撃が顕在化

組込系もWebに接続されるケースが増加

– ルーター，リモート監視，

安全性は製造者責任・・・・しかし対策が困難

19


対策レビューのSyntax面の改善では対応できない

Semantic系の支援が必要になった

対策の一つとしてMisra-C :こんな場合に危ない可能性がある

代表的な危ない可能性をリストアップした

– 高スキルのリーダは，これをヒントに自チームで対処

– そうでないリーダ（権威型リーダ）のレビューでは無理

– サイクロマティック数は２０以下，ポインター使用禁止などの対処療法？

– かなりトンチンカンで迷走

Toolでの支援が始まる

Misra-C準拠を自称するToolが出現（Misraは認証していない）

使うと，山のように偽陽性を吐き出し，これも対処が困難

多くの現場では・・・・課題の先送り

出来ないことは口にしない

20



これからどうする

6. IoT時代のレビュー

21



言語の安全性問題解１安全な言語を使う

型安全については研究が進んでいる

安全では無い言語 C, C++，

かなり型安全 Java,C#

型安全 Python, Ruby

さらに進んだ言語 Go,Swiftなど

解２解析Toolを使う

静的解析は実用レベルになっている Coverityなど

– 価格問題がある対策：安いToolで偽陽性対策を徹底

– ：このさいOSS化する（無料でCoverity)

原理的に静的解析は限界がある

– 動的解析を使う・・・ただし研究レベルなので自組織向け対応が必要

解３レビュー者のスキルを高める

アセンブラーでもCでも，高スキルのレビュー者なら安全を確保できる（可能性として）

22


時代のトレンド NASAの例１０のコーディング規則

https://www.reddit.com/r/learnprogramming/comments/4npim9/10_coding_practices_which_allows_nasa_to_write/

その要約：http://qiita.com/tomboyboy/items/1b5625d429ea4aa1ac32

おもしろいのは，静的解析ツールを使いやすくするための規則が含まれていること

23

人力向け

機械向け

人的資源

コードなどレビュー対象

Tool


IoT時代のトレンド

未来を予測するのは不可能ですが，

IoT時代の特徴

単独プロダクトでは生きていけない

メジャーサービスの一部に採用（選ばれる）されること

そのためには，

コードの開示は必須

自身の信頼性だけでなく系としての安全性を担保すること

レビュー方式は変化する今回の結論人力では限界

Toolとの併用，Toolの能力を引き出すコーディング規約

おまけ：C系のToolとしてはLLVM系のclangなどが有望24


まとめ

レビューは今後も（テストと並び）重要な技術

変化が生じる変化の本質を知ること(言語を替えるなど）

人力レビューの限界

機械(Tool)による支援が必要

そのためのコーディング規則の見直しと運用が必要

せめてWarningを無くす・・・Toolを活かすために

今後も技術進歩は加速するので，常に追従して行く必要がある．・・・・70年代にB言語を使ったのが懐かしい老人より

25


Q&A

ご清聴を感謝します

26

IoT時代におけるコードの品性 - IPA ·...

Documents

Transcript of IoT時代におけるコードの品性 - IPA ·...