keep yourself up to date

Keep yourself up to date

あなたのスキルを最新の状態に保ちましょう！++C++; // 岩永 信之

開催概要※より :

10 年前の環境でも動作する伝統的な記述方法でも、最近の実行環境が要求される近代的な記述方法でも、同じような処理内容を記述できる

！？

※ https://itmedia.smartseminar.jp/public/seminar/view/465

できる できるって何だっけ？

理論上はできる 採算度外視ならできる 競争力を持ってできる

改めて聞きますが、できる？

例えば、非同期処理 async/await （ C# 5.0 ）導入前後

参考 : [雑記] 非同期制御フロー※

if (this.Check1.IsChecked ?? false){    var result = Dialog.ShowDialog(" 確認 1", "1 つ目の確認作業 ");    if (!result) return false;}

if (this.Check2.IsChecked ?? false){    var result = Dialog.ShowDialog(" 確認 2", "2 つ目の確認作業 ");    if (!result) return false;}

if (this.Check3.IsChecked ?? false){    var result = Dialog.ShowDialog(" 確認 3", "3 つ目の確認作業 ");    if (!result) return false;}

return true;

if (this.Check1.IsChecked ?? false){    Dialog.BeginShowDialog(" 確認 1", "1 つ目の確認作業 ", result =>    {        if (!result)        {            onComplete(false);            return;        }         if (this.Check2.IsChecked ?? false)        {            Dialog.BeginShowDialog(" 確認 2", "2 つ目の確認作業 ", result2 =>            {                if (!result2)                {                    onComplete(false);                    return;                }                 if (this.Check3.IsChecked ?? false)                {                    Dialog.BeginShowDialog(" 確認 3", "3 つ目の確認作業 ", result3 =>                    {                        onComplete(result3);                    });                }                else                    onComplete(true);            });        }        else if (this.Check3.IsChecked ?? false)        {            Dialog.BeginShowDialog(" 確認 3", "3 つ目の確認作業 ", result3 =>            {                onComplete(result3);            });        }        else            onComplete(true);    });}else if (this.Check2.IsChecked ?? false){    Dialog.BeginShowDialog(" 確認 2", "2 つ目の確認作業 ", result =>    {        if (!result)        {            onComplete(false);            return;        }         if (this.Check3.IsChecked ?? false)        {            Dialog.BeginShowDialog(" 確認 3", "3 つ目の確認作業 ", result3 =>            {                onComplete(result);            });        }        else            onComplete(true);    });}else if (this.Check3.IsChecked ?? false){    Dialog.BeginShowDialog(" 確認 3", "3 つ目の確認作業 ", result3 =>    {        onComplete(result3);    });}else    onComplete(true);

[ 参考 ] 同期版 (19)

導入前 (73)if (this.Check1.IsChecked ?? false){    var result = await Dialog.ShowDialogAsync(" 確認 1", "1 つ目の確認作業 ");    if (!result) return false;} if (this.Check2.IsChecked ?? false){    var result = await Dialog.ShowDialogAsync(" 確認 2", "2 つ目の確認作業 ");    if (!result) return false;} if (this.Check3.IsChecked ?? false){    var result = await Dialog.ShowDialogAsync(" 確認 3", "3 つ目の確認作業 ");    if (!result) return false;} return true;

導入後 (19)

() 内は行数 ※ http://ufcpp.net/study/csharp/misc_asyncflow.html

例えば、データ処理 LINQ （ C# 3.0 ）導入前後

参考 : Road to LINQ※

private static void  コンソール _ 奇数の二乗 _1 行 1 個 (){    while (true)    {        int x;        if (!int.TryParse(Console.ReadLine(), out x)) break;        if ((x % 2) == 1)        {            Console.WriteLine(x * x);        }    }} private static void  配列 _ 奇数の二乗 _1 行 1 個 (){    for (int i = 0; i < array.Length; i++)    {        var x = array[i];        if ((x % 2) == 1)        {            Console.WriteLine(x * x);        }    }} private static void  連結リスト _ 奇数の二乗 _1 行 1 個 (){    for (ListNode node = list; node != null; node = node.Next)    {        var x = node.Value;        if ((x % 2) == 1)        {            Console.WriteLine(x * x);        }    }} private static void  コンソール _ 偶数の絶対値 _1 行 1 個 (){    while (true)    {        int x;        if (!int.TryParse(Console.ReadLine(), out x)) break;        if ((x % 2) == 0)        {            Console.WriteLine(Math.Abs(x));        }    }} private static void  配列 _ 偶数の絶対値 _1 行 1 個 (){    for (int i = 0; i < array.Length; i++)    {        var x = array[i];        if ((x % 2) == 0)        {            Console.WriteLine(Math.Abs(x));        }    }}

長すぎるので後略

導入前 (300 行以上 )private static void  表示 (Action<IEnumerable<int>>  表示方法 ){     表示 ( 表示方法 , source => source.Where(x => (x % 2) == 1).Select(x => x * x));     表示 ( 表示方法 , source => source.Where(x => (x % 2) == 0).Select(x => Math.Abs(x)));     表示 ( 表示方法 , source => source.Where(x => x <= 3).Select(x => -x));} private static void  表示 (Action<IEnumerable<int>>  表示方法 , Func<IEnumerable<int>, IEnumerable<int>>  加工方法 ){     表示方法 ( 加工方法 (new ConsoleInput()));     表示方法 ( 加工方法 (array));     表示方法 ( 加工方法 (list));} private static void  表示 1 行 1 個 (IEnumerable<int> list){    foreach (var x in list)    {        Console.WriteLine(x);    }} private static void  表示スペース区切り (IEnumerable<int> list){    var line = string.Join(" ", list);    Console.Write(line);} private static void  表示コンマ区切り (IEnumerable<int> list){    var line = string.Join(",", list);    Console.Write(line);}

導入後 (10 数行 )

※ http://www.atmarkit.co.jp/fdotnet/chushin/roadtolinq_01/roadtolinq_01_01.html() 内は行数

客観評価指標 行数だけ減ればいいってものではないものの

この手の指標を無視しているとバグやテスト負担が増加

LINQ 導入前のコード

LINQ 導入後のコード

コード メトリックスを計算してみると…

半減

オーダーの差 LINQ の例の本質的な差

掛け算と足し算

1-i-a

1-i-b

1-i-c

1-ii-a

1-ii-b

1-ii-c

1-iii-a

1-iii-b

1-iii-c

2-i-a

2-i-b

2-i-c

2-ii-a

2-ii-b

2-ii-c

2-iii-a

2-iii-b

2-iii-c

3-i-a

3-i-b

3-i-c

3-ii-a

3-ii-b

3-ii-c

3-iii-a

3-iii-b

3-iii-c

1

2

3

i

ii

iii

a

b

c

3×3×3=27 3+3+3=9導入前 導入後

3 軸 3 種ずつだからこの程度の差ですむ5 軸 10 種とかだと…

10×10×10×10×10=1000010+10+10+10+10=50

組み合わせを選べるモジュール化

改めて、できる？ できるけど

知識のある人が

かなりの手間をかけて

勉強は必要

競争力あるの？

世の中は常に進歩している 来年、今と同じことしてたら評価が下がる

要求の側のハードルは上がる一方

IT で効率化 = 仕事をなくす仕事 無駄な仕事はやめて、クリエイティブな仕事を 「自分たちだけは別」とか思う？ 自分の仕事すら、明日には無駄な仕事かも

ハードルは何か 世の中の進歩にはついていかなければいけない

じゃあ、何がハードルになってついていけないか？

覚えても使えないし… 既存資産が… 安定性に不安が…

どう乗り越える？

今日のテーマ

覚えても使えないし…

部（室）長 殿 2013 年 1 月 26 日

基盤技術二部所属部（室）

岩永信之氏名

調査報告書

印

申請日

年 月 日確認実践日

費用対効果への課題下記の通り、調査結果を報告いたします

お客様の環境が XP で…

更新にかかる費用を考えると .NET 2.0 しか使えない…

（受付・確認欄）

思うところはあるけども… 新しいものをきっちり提案して、きっちり業務効

率化して、お客様のコスト削減するのがプロ！

といっても、具体的な数字ベースのメリットが見えてないとなかなか難しい 「工数が○日減ります」とか 「何年で○円浮きます」とか

やっぱ使えないし覚えるの無駄…となるのか！？そんなことない

使えなくても覚えなきゃ なくてもやってた

機能としてなくても、パターンとしてやってた

何で覚えるの？ × 「新しいものが出たから覚えなきゃ」 ○「より高度な要求に応えるために覚えなきゃ」

なくてもやってた（先ほどの例） async/await

LINQ

昔はパターンとして知られていたものが標準に 中身まで知っていれば実装簡単

var x = await task1;

_state = 1;if (!task1.IsCompleted){    task1.ContinueWith(a);    return;}case 1:var x = task1.Result;

C# 5.0 なら 展開

data.Select(x => x.Name);

IEnumerable<int> Select( IEnumerable<int> source,  Func<int, int> selector){    foreach (var x in source)        yield return selector(x);}

C# 3.0 なら自前実装

なくてもやってた（大昔から） C言語でもオブジェクト指向

データ構造中心の設計 仮想メソッド テーブルを自分で書いたり

C++ でも自動メモリ管理 参照カウント

C++ テンプレートも元はマクロでやってた Set/Getアクセサー地獄

Add/Remove オブザーバー・パターン地獄。

つまり、何も新しくない かつては

今は

入門本

攻撃力

価格

： 227

： 1,360

Effective開発本

攻撃力

価格

： 327

： 3,780

デザインパターン本

攻撃力

価格

： 411

： 4,410

簡単！ 基本だけだとつらくなってき

た！

まだだ！まだ何か足りない！

入門本

攻撃力

価格

： 344

： 2,814

かつて•パターンとしてやっていたも

の•高度だといわれていたもの

が基礎文法レベルに

なくてもやれる C# 3.0/.NET 3.5 しか使えなくて困ったけども…

Task クラスもどき作った データ バインディングもどき作った

ない場合の問題を知っている 元々知ってるものは楽に作れる その後、チーム全体の作業効率が向上

車輪の再発明、劣化コピーでしかないけど

ないよりマシ

改めて、覚えても使えない？ どのみち知識としては必要

必要なものが基礎文法・標準ライブラリになっただけ

新機能は学習の足掛かり 古い書き方にはどういう問題があったのか どういうパターンで解決していたのか

入門本 Effective開発本

デザインパターン本

入門本

昔

今

必要

必要なものは最初から詰まってる

既存資産が…

部（室）長 殿 2013 年 1 月 26 日

基盤技術二部所属部（室）

岩永信之氏名

調査報告書

印

申請日

年 月 日確認実践日

既存資産への依存性下記の通り、調査結果を報告いたします

既存資産は .NET 2.0で作られており…

いきなり全部を新環境にできるわけない

（受付・確認欄）

新機能導入システム全体

3.0 3.0 3.0 3.0 3.0 3.0 3.0

3.0 3.0 3.0 3.0 3.0 3.0 3.0

3.0 3.0 3.0 3.0 3.0 3.0 3.0

3.0 3.0 3.0 3.0 3.0 3.0 3.0

ここを修正したかったら

5.0ここだけ新機能導入

すればいいじゃない！

何でできないの？

この辺ひっぱったら

全部動くの！

スパゲッティ コード 昔は「ダメなコード」くらいに思ってたけど経験積めば積むほど味わい深い言葉 一か所引っ張ったら全体が動くの そんなもん、修正できるわけない

末代までたたられる呪い

× ○

解呪が必要（疎結合化）

• 大きな粒度• 多い接点 資産には負債もあります

負債 たとえ話「緩い地盤」

上物ばかりのきれいさにとらわれていると…

負債 たとえ話「未来を前借した発展」

つけを払うのはいつか

成長期 高齢社会

http://www.ipss.go.jp/ より

わかってても目先の発展破たんしてからあわてる

たたられないために たたられないための新技術

依存を減らす プログラミング言語・フレームワークはそういう方向で

進化してる

新技術導入

疎結合に作りやすい

疎結合

部分修正しやすい

（依存が少ない）

依存を減らす機能 オブジェクト指向のカプセル化

関数型の参照透過性

外との接点は少なく

×○

不要な依存の危険が

関数同じ入力なら 同じ出力に

外に何も依存していない

C# の歴史※

依存切りの歴史

C# 1.0• Manage

d

C# 2.0• Generic

s• partial

C# 3.0• LINQ

C# 4.0• Dynami

c• Interop

C# 5.0• Async• WinRT

※ VB 7～ 11 の歴史でもある

共通型システムバージョン管理言語への依存バージョン依存

型とアルゴリズムの分離自動生成コードの分離

データの入力 / 加工 /出力の分離

外部システムとの連携

非同期ゆえのスパゲッティ化回避

外部システムとの連携

一枚岩システム

フレームワークの進化も サービス指向

細かい粒度のサービスの連携でシステムを作る

XAML 、データ バインディング、 MVVM View と Model の分離 自動生成コードの分離 UX デザイナーと開発者の協業

余談 スマホ向けゲームを作ったときの話

企画的には同系統作品を 1 から作り直し

昔作ったブラウザー ゲームも最初からサービス指向で作っていれば今頃スマホ版出てたのにね

「」

UI は陳腐化激しい差し替え可能に作らないと時代に乗り遅れる

資産が資産になってない

改めて、活かせる既存資産 スパゲッティ コードには末代まで呪われる

修正できない 新機能を取り入れる余裕もなくなる

多くの新機能は解呪のための道具

新技術導入

疎結合に作りやすい

疎結合

部分修正しやすい

安定性に不安が…

部（室）長 殿 2013 年 1 月 26 日

基盤技術二部所属部（室）

岩永信之氏名

調査報告書

印

申請日

年 月 日確認実践日

品質担保への課題下記の通り、調査結果を報告いたします

ノウハウがたまるまでには時間がかかる

たまる前に新しい何かに置き換わるし…

（受付・確認欄）

変わる部分変わらない部分 確かに、変化が激しくて安定しない部分はある

ただし…

変わっている部分はどこか 何がどう変わっているのか

変わりやすい部分 同じ .NET でも

クライアントUI

Web UI

通信 データ

基礎

Web UI UI

クライアント基礎 データ

通信認証ワークフロー

安定安定 割とどこでも末永く使える

安定不安定 すぐに陳腐化する

疎結合 つまるところ、「疎結合」の話に戻る

「サービス指向で作っていれば　今頃…」

安定なところだけを使う Portabl Class Library

大きなリリースは時代にそぐわない .NET ですら CodePlex公開、 NuGet公開

ここだけ修正

ちなみに、言語レベルは超安定 C# ですら、あれでもかなり保守的

ライブラリの進歩と比べたらどうってことない

「 Anders の機嫌がよくないとゴー サイン出ない」なんて都市伝説も

何が変わってるの？ 変わってるのは「時代」

時代に合わせた変化 新技術追わない ＝ 時代の変化追わない

実際の中身はそんなに変わっていない

デスクトップ

• WPF

ブラウザー

• Silverlight

スマートデバイス

• WinRT

シフトなんてしない

ほぼ連続な進歩

どう変わってるの？

ほぼ連続な進歩

ときどき脱皮

新世界古き良き世界

シフト

積み重ね 結局、何事も積み重ね

いつ取り組み始めても、勉強すべきことは変わらない

こちら側の積み重ねがない人は こちら側に

行くのも大変

改めて、安定するために 安定な部分を切り分ける

サービス指向 Portabl Class Library

言語レベルは安定

不安定なのは時代の方 待ってても安定しない

急な変化はない 結局は積み重ねが必要

ここだけ修正

どうやってハードル乗り越える？

ハードル？わかってるよそんなの。乗り越えろ？

やれるならとっくにやってる

という意見もあるだろうしじゃあどうしようってのが本当のテーマ

やれるのはなぜ こんな絵を出しましたが

新機能導入

疎結合

ループ

ループができているということは…

余裕のある日常 / ない日常 日常ループ

余裕のある人

余裕のない人

日常タスクに必要な量

MP

MP 余剰で遊ん学んでる

足りない分を何かで埋め合わせてる

余裕のある日常 / ない日常 日常ループ

余裕のある人

余裕のない人

MP

MP

LEVEL UP

要求水準も日々上がる

取り残されていませんか

フィードバック ループ 余裕は余裕を呼ぶ デスマはデスマを呼ぶ

MP

MP

一度でいいからこちら側に来ないといけない

𝑎𝑥

𝑎−𝑥

𝑎𝑥

𝑎−𝑥

これがたぶん、一番のテーマ

チーム チームこそ力の源

1 人だけに余裕があっても回らない 個人技能よりもプロジェクト進行技能

の方がプロジェクト成否に直結

自分を変えるには環境を変えろ 個人レベルではデスマ側から余裕ある側への脱出は難し

い チームとしての取り組み必要

チームに余裕があるから プロジェクトの継続的な成功の中にいるから

コードの責任を個人に帰属させない 負債解消にどのくらいの時間を使うか、戦略を持つ

テスト整備リファクタリング

修正しやすい

ライブラリ整備

みんなの余裕

ペアプロレビュー

みんなの成長

ツールに頼る 属人的に進めるのはかなり大変 ツール管理

Redmine で作業項目管理 git でソース コード管理 gerrit でコード レビュー Jenkins で自動ビルド

（今いるチームだと）

作業項目管理 TFS で ソース コー

ド管理

コード レビュー

自動ビルド

（希望を言えば…）

All in One なのが楽だしVisual Studio 連携が楽だし今なら自前サーバー不要だし（ tfs.visualstudio.com）

Visual Studio ALM Visual Studio の進化の方向性

Application Lifecycle Management※

2008• 個人開発

2010• 開発チーム

2012• チーム全体

ステークホルダーや運用者

との連携性強化作業項目管理

ソース コード管理（がほぼ完成）

※ 開発・運用のライフサイクル全体の統合管理

つまるところ、Team Foundation Serverの強化、 VS との一体化

Visual Studio ALM プロジェクト状況の可視化

問題の早期発見

Visual Studio ALM 各種コレボレーション

作業項目管理 優先度付け

人的リソース 配分 コード レビュー

Visual Studio ALM 自動ビルド・配置

テスト漏れや配置ミスを減らす

ゲート チェックイン ビルドの通らないソース コードのチェックインを認め

ない ビルド自体を厳しくすれば、ある程度の品質担保に

ビルド後にテストを実行 静的解析ツールを通す

大規模開発でもいけるの？ Visual Studio は 3500 人体制で開発されてる 分割統治

5～ 10 人程度のチームに分かれて開発 可視化やゲート チェックインで全体の品質担保

紙ベース／ Excelベース納品してる限り無理じゃないかな

このための ALMこのための Team Foundation Server

改めて、ハードルを越えるために 余裕は余裕を、デスマはデスマを呼ぶ

フィードバック ループ 何も手を打たないと抜けられない

デスマ ループから抜けるためには チームこそ力 言語機能やツールに頼る 言語機能やツールから学ぶ

まとめ (1/2) ハードル

使えなくても覚えなきゃ 新技術から学ぶ 技術の変化は時代の変化

既存資産を負債にしないために 疎結合 だからこその新機能

不連続はない あくまで日々の積み重ね

ここだけ修正

まとめ (2/2) フィードバック ループ

余裕は余裕を デスマはデスマを

ハードルを乗り越える チームで乗り越える 言語機能やツールに頼る 言語機能やツールから学ぶ

新機能

余裕

MPMP