Keep yourself up to date

Keep yourself up to date
あなたのスキルを最新の状態に保ちましょう！

開催概要※より:

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

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

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

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

例えば、非同期処理
 async/await （C# 5.0）導入前後
 参考: [雑記] 非同期制御フロー※
導入前(73) 導入後(19)
if (this.Check1.IsChecked ?? false) if (this.Check1.IsChecked ?? false)
{ {
Dialog.BeginShowDialog("確認 1", "1つ目の確認作業", result => var result = await Dialog.ShowDialogAsync("確認 1", "1つ目の確認作業");
{ if (!result) return false;
if (!result) }
{
onComplete(false); if (this.Check2.IsChecked ?? false)
return; {
} var result = await Dialog.ShowDialogAsync("確認 2", "2つ目の確認作業");
if (!result) return false;
if (this.Check2.IsChecked ?? false) }
{
Dialog.BeginShowDialog("確認 2", "2つ目の確認作業", result2 => if (this.Check3.IsChecked ?? false)
{ {
if (!result2) var result = await Dialog.ShowDialogAsync("確認 3", "3つ目の確認作業");
{ if (!result) return false;
onComplete(false); }
return;
} return true;

if (this.Check3.IsChecked ?? false)
{
Dialog.BeginShowDialog("確認 3", "3つ目の確認作業", result3 =>
{
onComplete(result3);
});
}
else

[参考] 同期版(19)
onComplete(true);
});
}
else if (this.Check3.IsChecked ?? false)
{
Dialog.BeginShowDialog("確認 3", "3つ目の確認作業", result3 => if (this.Check1.IsChecked ?? false)
{ {
onComplete(result3); var result = Dialog.ShowDialog("確認 1", "1つ目の確認作業");
}); if (!result) return false;
} }
else
onComplete(true); if (this.Check2.IsChecked ?? false)
}); {
} var result = Dialog.ShowDialog("確認 2", "2つ目の確認作業");
else if (this.Check2.IsChecked ?? false) if (!result) return false;
{ }
Dialog.BeginShowDialog("確認 2", "2つ目の確認作業", result =>
{ if (this.Check3.IsChecked ?? false)
if (!result) {
{ var result = Dialog.ShowDialog("確認 3", "3つ目の確認作業");
onComplete(false); if (!result) return false;

()内は行数 ※ http://ufcpp.net/study/csharp/misc_asyncflow.html
return; }
}
return true;
if (this.Check3.IsChecked ?? false)
{

例えば、データ処理
 LINQ （C# 3.0）導入前後
 参考: Road to LINQ※
導入前(300行以上) 導入後(10数行)
private static void コンソール_奇数の二乗_1行1個() private static void 表示(Action<IEnumerable<int>> 表示方法)
{ {
while (true) 表示(表示方法, source => source.Where(x => (x % 2) == 1).Select(x => x * x));
{ 表示(表示方法, source => source.Where(x => (x % 2) == 0).Select(x => Math.Abs(x)));
int x; 表示(表示方法, source => source.Where(x => x <= 3).Select(x => -x));
if (!int.TryParse(Console.ReadLine(), out x)) break; }
if ((x % 2) == 1)
{ private static void 表示(Action<IEnumerable<int>> 表示方法, Func<IEnumerable<int>, IEnumerable<int>> 加工方法)
Console.WriteLine(x * x); {
} 表示方法(加工方法(new ConsoleInput()));
} 表示方法(加工方法(array));
} 表示方法(加工方法(list));
}
private static void 配列_奇数の二乗_1行1個()
{ private static void 表示1行1個(IEnumerable<int> list)
for (int i = 0; i < array.Length; i++) {
{ foreach (var x in list)
var x = array[i]; {
if ((x % 2) == 1) Console.WriteLine(x);
{ }
Console.WriteLine(x * x); }
}
} private static void 表示スペース区切り(IEnumerable<int> list)
} {
var line = string.Join(" ", list);
private static void 連結リスト_奇数の二乗_1行1個() Console.Write(line);
{ }
for (ListNode node = list; node != null; node = node.Next)
{ private static void 表示コンマ区切り(IEnumerable<int> list)
var x = node.Value; {
if ((x % 2) == 1) var line = string.Join(",", list);
{ Console.Write(line);
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個()
{
※ http://www.atmarkit.co.jp/fdotnet/chushin/roadtolinq_01/roadtolinq_01_01.html

for (int i = 0; i < array.Length; i++)
{

客観評価指標
 行数だけ減ればいいってものではないものの
コードメトリックスを計算してみると…
LINQ導入前のコード

半減
LINQ導入後のコード

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

オーダーの差
 LINQの例の本質的な差
 掛け算と足し算
導入前導入後
組み合わせを
1-i-a 2-i-a 3-i-a 1 i a
選べる
1-i-b 2-i-b 3-i-b モジュール化 2 ii b

1-i-c 2-i-c 3-i-c 3 iii c

1-ii-a 2-ii-a 3-ii-a

1-ii-b 2-ii-b 3-ii-b 3軸3種ずつだからこの程度の差ですむ
1-ii-c 2-ii-c 3-ii-c 5軸10種とかだと…
1-iii-a 2-iii-a 3-iii-a

1-iii-b 2-iii-b 3-iii-b

1-iii-c 2-iii-c 3-iii-c

改めて、できる？
 できるけど
 知識のある人が

勉強は必要

 かなりの手間をかけて

競争力あるの？

世の中は常に進歩している
 来年、今と同じことしてたら評価が下がる
 要求の側のハードルは上がる一方
 ITで効率化 = 仕事をなくす仕事
 無駄な仕事はやめて、クリエイティブな仕事を
 「自分たちだけは別」とか思う？
 自分の仕事すら、明日には無駄な仕事かも

ハードルは何か
 世の中の進歩にはついていかなければいけない
 じゃあ、何がハードルになってついていけないか？

 覚えても使えないし… 今日のテーマ

 既存資産が… どう乗り越える？
 安定性に不安が…

覚えても使えないし…

調査報告書
部（室）長殿申請日 2013年 1月26日

確認実践日年月日

所属部（室）基盤技術二部
氏名岩永信之印

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

 お客様の環境がXPで…
 更新にかかる費用を考
えると.NET 2.0しか使
えない…

（受付・確認欄）

思うところはあるけども…
 新しいものをきっちり提案して、きっちり業務効
率化して、お客様のコスト削減するのがプロ！

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

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

使えなくても覚えなきゃ
 なくてもやってた
 機能としてなくても、パターンとしてやってた
 何で覚えるの？
 ×「新しいものが出たから覚えなきゃ」
 ○「より高度な要求に応えるために覚えなきゃ」

なくてもやってた（先ほどの例）
 async/await _state = 1;
if (!task1.IsCompleted)
C# 5.0なら展開 {
task1.ContinueWith(a);
var x = await task1;
return;
}
case 1:
var x = task1.Result;

 LINQ
IEnumerable<int> Select(
C# 3.0なら IEnumerable<int> source,

data.Select(x => x.Name);
自前実装 {
Func<int, int> selector)

foreach (var x in source)
yield return selector(x);
}

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

なくてもやってた（大昔から）
 C言語でもオブジェクト指向
 データ構造中心の設計
 仮想メソッドテーブルを自分で書いたり
 C++でも自動メモリ管理
 参照カウント
 C++テンプレートも元はマクロでやってた
 Set/Getアクセサー地獄
Add/Removeオブザーバー・パターン地獄。

つまり、何も新しくない
 かつては
Effective デザイン
入門本
開発本パターン本
攻撃力： 227 攻撃力： 327 攻撃力： 411
価格： 1,360 価格： 3,780 価格： 4,410

簡単！基本だけだとまだだ！
つらくなってきた！まだ何か足りない！

 今は
入門本かつて
• パターンとしてやっていたもの
攻撃力： 344 • 高度だといわれていたもの
価格： 2,814 が基礎文法レベルに

なくてもやれる
 C# 3.0/.NET 3.5しか使えなくて困ったけども…
 Taskクラスもどき作った
 データバインディングもどき作った

車輪の再発明、务化コピーでしかないけど
ないよりマシ
 ない場合の問題を知っている
 元々知ってるものは楽に作れる
 その後、チーム全体の作業効率が向上

改めて、覚えても使えない？
 どのみち知識としては必要
 必要なものが基礎文法・標準ライブラリになっただけ
 新機能は学習の足掛かり
 古い書き方にはどういう問題があったのか
 どういうパターンで解決していたのか
必要
昔
Effective デザイン
入門本
開発本パターン本
今

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

調査報告書



既存資産への依存性

 既存資産は.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 5.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

何でできないの？

この辺
ひっぱったら

全部動くの！

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

× ○

解呪が必要
（疎結合化）

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

負債
 たとえ話「緩い地盤」
 上物ばかりのきれいさにとらわれていると…

負債
 たとえ話「未来を前借した発展」
 つけを払うのはいつか

成長期高齢社会
わかってても目先の発展
破たんしてからあわてる

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

たたられないために
 たたられないための新技術
 依存を減らす
 プログラミング言語・フレームワークはそういう方向で
進化してる

新技術導入

部分修正しやすい疎結合に作りやすい

疎結合
（依存が少ない）

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

外との接点は少なく不要な依存の危険が

 関数型の参照透過性
同じ入力なら関数同じ出力に

外に何も依存していない

C#の歴史※
 依存切りの歴史非同期ゆえの
スパゲッティ化回避
データの入力/加工/出力
の分離
C# 5.0
共通型システム C# 4.0
• Async
バージョン管理 C# 3.0 • Dynamic • WinRT
言語への依存 • Interop
• LINQ
バージョン依存 C# 2.0 一枚岩システム
• Generics
外部システムとの連携
C# 1.0 • partial
• Managed 型とアルゴリズムの分離
自動生成コードの分離

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

フレームワークの進化も
 サービス指向
 細かい粒度のサービスの連携でシステムを作る
 XAML、データバインディング、MVVM
 ViewとModelの分離
 自動生成コードの分離
 UXデザイナーと開発者の協業

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

「昔作ったブラウザーゲームも
最初からサービス指向で作っていれば
今頃スマホ版出てたのにね」
 企画的には同系統作品を
 1から作り直し
UIは陳腐化激しい
差し替え可能に作らないと
時代に乗り遅れる
資産が資産になってない

改めて、活かせる既存資産
 スパゲッティコードには末代まで呪われる
 修正できない
 新機能を取り入れる余裕もなくなる

 多くの新機能は解呪のための道具
新技術導入

部分修正しやすい疎結合に作りやすい

疎結合

調査報告書



品質担保への課題

 ノウハウがたまるまで
には時間がかかる
 たまる前に新しい何か
に置き換わるし…


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

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

変わりやすい部分
 同じ.NETでも
不安定
安定
すぐに陳腐化する

クライアント Web Web クライアント
基礎
UI UI UI UI データ

通信データ
ワークフロー
認証通信
基礎

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

疎結合
 つまるところ、「疎結合」の話に戻る
 「サービス指向で作っていれば
今頃…」ここだけ修正
 安定なところだけを使う
 Portabl Class Library
 大きなリリースは時代にそぐわない
 .NETですらCodePlex公開、NuGet公開

ちなみに、言語レベルは超安定
 C#ですら、あれでもかなり保守的
 ライブラリの進歩と比べたらどうってことない
 「Andersの機嫌がよくないとゴーサイン出ない」
なんて都市伝説も

何が変わってるの？
 変わってるのは「時代」
デスクトップブラウザースマートデバイス

• WPF • Silverlight • WinRT

 時代に合わせた変化
 新技術追わない＝時代の変化追わない
 実際の中身はそんなに変わっていない

どう変わってるの？
 シフトなんてしない

古き良きシフト新世界
世界

 ほぼ連続な進歩
ほぼ連続な進歩

ときどき脱皮

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

こちら側の積み
重ねがない人は
こちら側に
行くのも大変
 いつ取り組み始めても、勉強すべきことは変わらない

改めて、安定するために
 安定な部分を切り分ける
 サービス指向ここだけ修正
 Portabl Class Library
 言語レベルは安定
 不安定なのは時代の方
 待ってても安定しない
 急な変化はない
 結局は積み重ねが必要

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

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

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

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

新機能導入

ループ

疎結合

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

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

日常タスクに必要な量
余裕のある人
MP

余裕のない人
MP
余剰で遊ん学んでる

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

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

余裕のある人
MP

余裕のない人
MP 要求水準も
日々上がる

取り残されていませんか

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

MP

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

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

チーム
 チームこそ力の源
 1人だけに余裕があっても回らない
 個人技能よりもプロジェクト進行技能
の方がプロジェクト成否に直結

 自分を変えるには環境を変えろ
 個人レベルではデスマ側から余裕ある側への脱出は難し
い
 チームとしての取り組み必要

チームに余裕があるから
 プロジェクトの継続的な成功の中にいるから
テスト整備ペアプロ
リファクタリングライブラリ整備レビュー

修正しやすいみんなの余裕みんなの成長
 コードの責任を個人に帰属させない
 負債解消にどのくらいの時間を使うか、戦略を持つ

ツールに頼る
 属人的に進めるのはかなり大変
 ツール管理
（今いるチームだと）（希望を言えば…）
 Redmineで作業項目管理作業項目管理
 gitでソースコード管理  TFSでソースコード管理
 gerritでコードレビューコードレビュー
 Jenkinsで自動ビルド自動ビルド

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

Visual Studio ALM
 Visual Studioの進化の方向性
 Application Lifecycle Management※

2012
2010 • チーム全体

• 開発チーム
ステークホルダーや運用者
2008 との連携性強化
• 個人開発作業項目管理つまるところ、
Team Foundation Server
（がほぼ完成）ソースコード管理
の強化、VSとの一体化

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

Visual Studio ALM
 プロジェクト状況の可視化
 問題の早期発見

Visual Studio ALM
 各種コレボレーション
作業項目管理優先度付け

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

Visual Studio ALM
 自動ビルド・配置
 テスト漏れや配置ミスを減らす
 ゲートチェックイン
 ビルドの通らないソースコードのチェックインを認めな
い
 ビルド自体を厳しくすれば、ある程度の品質担保に
 ビルド後にテストを実行
 静的解析ツールを通す

大規模開発でもいけるの？
 Visual Studioは3500人体制で開発されてる
 分割統治
 5～10人程度のチームに分かれて開発
 可視化やゲートチェックインで全体の品質担保

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

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

改めて、ハードルを越えるために
 余裕は余裕を、デスマはデスマを呼ぶ
 フィードバックループ
 何も手を打たないと抜けられない
 デスマループから抜けるためには
 チームこそ力
 言語機能やツールに頼る
 言語機能やツールから学ぶ

まとめ(1/2)
 ハードル
 使えなくても覚えなきゃ
 新技術から学ぶ
 技術の変化は時代の変化
ここだけ修正
 既存資産を負債にしないために
 疎結合
 だからこその新機能
 不連続はない
 あくまで日々の積み重ね

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

 余裕は余裕を新機能
 デスマはデスマを
 ハードルを乗り越える
 チームで乗り越える余裕

 言語機能やツールに頼る
 言語機能やツールから学ぶ

Keep yourself up to date

Empfohlen

Empfohlen

Weitere ähnliche Inhalte

Was ist angesagt?

Was ist angesagt? (20)

Mehr von 信之岩永

Mehr von 信之岩永 (20)