Keep yourself up to date

41,010 views

Published on

第1回 業開中心会議 基調講演資料
https://itmedia.smartseminar.jp/public/seminar/view/465

0 Comments
19 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
41,010
On SlideShare
0
From Embeds
0
Number of Embeds
34,465
Actions
Shares
0
Downloads
90
Comments
0
Likes
19
Embeds 0
No embeds

No notes for slide

Keep yourself up to date

  1. 1. Keep yourself up to date あなたのスキルを最新の状態に保ちましょう!
  2. 2. 開催概要※より: 10年前の環境でも動作する伝統的な記述方法で も、最近の実行環境が要求される近代的な記述 方法でも、同じような処理内容を記述できる !? ※ https://itmedia.smartseminar.jp/public/seminar/view/465
  3. 3. できる できるって何だっけ?  理論上はできる  採算度外視ならできる  競争力を持ってできる 改めて聞きますが、 できる?
  4. 4. 例えば、非同期処理  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) {
  5. 5. 例えば、データ処理  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++) {
  6. 6. 客観評価指標 行数だけ減ればいいってものではないものの コード メトリックスを計算してみると… LINQ導入前のコード 半減 LINQ導入後のコード  この手の指標を無視しているとバグやテスト負担が増加
  7. 7. オーダーの差 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
  8. 8. 改めて、できる? できるけど  知識のある人が 勉強は必要  かなりの手間をかけて 競争力あるの?
  9. 9. 世の中は常に進歩している 来年、今と同じことしてたら評価が下がる  要求の側のハードルは上がる一方 ITで効率化 = 仕事をなくす仕事  無駄な仕事はやめて、クリエイティブな仕事を  「自分たちだけは別」とか思う?  自分の仕事すら、明日には無駄な仕事かも
  10. 10. ハードルは何か 世の中の進歩にはついていかなければいけない  じゃあ、何がハードルになってついていけないか? 覚えても使えないし… 今日のテーマ 既存資産が… どう乗り越える? 安定性に不安が…
  11. 11. 覚えても使えないし…
  12. 12. 調査報告書部(室)長 殿 申請日 2013年 1月26日 確認実践日 年 月 日 所属部(室) 基盤技術二部 氏名 岩永信之 印 費用対効果への課題 下記の通り、調査結果を報告いたします  お客様の環境がXPで…  更新にかかる費用を考 えると.NET 2.0しか使 えない…(受付・確認欄)
  13. 13. 思うところはあるけども… 新しいものをきっちり提案して、きっちり業務効 率化して、お客様のコスト削減するのがプロ! といっても、具体的な数字ベースのメリットが見 えてないとなかなか難しい  「工数が○日減ります」とか  「何年で○円浮きます」とか そんなことない やっぱ使えないし覚えるの無駄…となるのか!?
  14. 14. 使えなくても覚えなきゃ なくてもやってた  機能としてなくても、パターンとしてやってた 何で覚えるの?  ×「新しいものが出たから覚えなきゃ」  ○「より高度な要求に応えるために覚えなきゃ」
  15. 15. なくてもやってた(先ほどの例) 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); }  昔はパターンとして知られていたものが標準に  中身まで知っていれば実装簡単
  16. 16. なくてもやってた(大昔から) C言語でもオブジェクト指向  データ構造中心の設計  仮想メソッド テーブルを自分で書いたり C++でも自動メモリ管理  参照カウント C++テンプレートも元はマクロでやってた Set/Getアクセサー地獄 Add/Removeオブザーバー・パターン地獄。
  17. 17. つまり、何も新しくない かつては Effective デザイン入門本 開発本 パターン本攻撃力 : 227 攻撃力 : 327 攻撃力 : 411価格 : 1,360 価格 : 3,780 価格 : 4,410 簡単! 基本だけだと まだだ! つらくなってきた! まだ何か足りない! 今は入門本 かつて • パターンとしてやっていたもの攻撃力 : 344 • 高度だといわれていたもの価格 : 2,814 が基礎文法レベルに
  18. 18. なくてもやれる C# 3.0/.NET 3.5しか使えなくて困ったけども…  Taskクラスもどき作った  データ バインディングもどき作った 車輪の再発明、务化コピーでしかないけど ないよりマシ  ない場合の問題を知っている  元々知ってるものは楽に作れる  その後、チーム全体の作業効率が向上
  19. 19. 改めて、覚えても使えない? どのみち知識としては必要  必要なものが基礎文法・標準ライブラリになっただけ 新機能は学習の足掛かり  古い書き方にはどういう問題があったのか  どういうパターンで解決していたのか 必要昔 Effective デザイン入門本 開発本 パターン本今入門本 必要なものは最初から詰まってる
  20. 20. 既存資産が…
  21. 21. 調査報告書部(室)長 殿 申請日 2013年 1月26日 確認実践日 年 月 日 所属部(室) 基盤技術二部 氏名 岩永信之 印 既存資産への依存性 下記の通り、調査結果を報告いたします  既存資産は.NET 2.0で 作られており…  いきなり全部を新環境 にできるわけない(受付・確認欄)
  22. 22. 新機能導入システム全体 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
  23. 23. 何でできないの? この辺 ひっぱったら 全部動くの!
  24. 24. スパゲッティ コード 昔は「ダメなコード」くらいに思ってたけど 経験積めば積むほど味わい深い言葉  一か所引っ張ったら全体が動くの 末代までたたられる  そんなもん、修正できるわけない 呪い × ○ 解呪が必要 (疎結合化) • 大きな粒度 • 多い接点 資産には負債もあります
  25. 25. 負債 たとえ話「緩い地盤」  上物ばかりのきれいさにとらわれていると…
  26. 26. 負債 たとえ話「未来を前借した発展」  つけを払うのはいつか成長期 高齢社会 わかってても目先の発展 破たんしてからあわてる http://www.ipss.go.jp/ より
  27. 27. たたられないために たたられないための新技術  依存を減らす  プログラミング言語・フレームワークはそういう方向で 進化してる 新技術導入 部分修正しやすい 疎結合に作りやすい 疎結合 (依存が少ない)
  28. 28. 依存を減らす機能 オブジェクト指向のカプセル化 ○ × 外との接点は少なく 不要な依存の危険が 関数型の参照透過性 同じ入力なら 関数 同じ出力に 外に何も依存していない
  29. 29. 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の歴史でもある
  30. 30. フレームワークの進化も サービス指向  細かい粒度のサービスの連携でシステムを作る XAML、データ バインディング、MVVM  ViewとModelの分離  自動生成コードの分離  UXデザイナーと開発者の協業
  31. 31. 余談 スマホ向けゲームを作ったときの話 「 昔作ったブラウザー ゲームも 最初からサービス指向で作っていれば 今頃スマホ版出てたのにね 」  企画的には同系統作品を  1から作り直し UIは陳腐化激しい 差し替え可能に作らないと 時代に乗り遅れる 資産が資産になってない
  32. 32. 改めて、活かせる既存資産 スパゲッティ コードには末代まで呪われる  修正できない  新機能を取り入れる余裕もなくなる 多くの新機能は解呪のための道具 新技術導入 部分修正しやすい 疎結合に作りやすい 疎結合
  33. 33. 安定性に不安が…
  34. 34. 調査報告書部(室)長 殿 申請日 2013年 1月26日 確認実践日 年 月 日 所属部(室) 基盤技術二部 氏名 岩永信之 印 品質担保への課題 下記の通り、調査結果を報告いたします  ノウハウがたまるまで には時間がかかる  たまる前に新しい何か に置き換わるし…(受付・確認欄)
  35. 35. 変わる部分変わらない部分 確かに、変化が激しくて安定しない部分はある ただし… 変わっている部分はどこか 何がどう変わっているのか
  36. 36. 変わりやすい部分 同じ.NETでも 不安定 安定 すぐに陳腐化する クライアント Web Web クライアント 基礎 UI UI UI UI データ 通信 データ ワークフロー 認証 通信 基礎 安定 割とどこでも 末永く使える
  37. 37. 疎結合 つまるところ、「疎結合」の話に戻る  「サービス指向で作っていれば 今頃…」 ここだけ修正 安定なところだけを使う  Portabl Class Library 大きなリリースは時代にそぐわない  .NETですらCodePlex公開、NuGet公開
  38. 38. ちなみに、言語レベルは超安定 C#ですら、あれでもかなり保守的  ライブラリの進歩と比べたらどうってことない 「Andersの機嫌がよくないとゴー サイン出ない」 なんて都市伝説も
  39. 39. 何が変わってるの? 変わってるのは「時代」 デスクトップ ブラウザー スマートデバイス • WPF • Silverlight • WinRT  時代に合わせた変化  新技術追わない = 時代の変化追わない  実際の中身はそんなに変わっていない
  40. 40. どう変わってるの? シフトなんてしない 古き良き シフト 新世界 世界 ほぼ連続な進歩 ほぼ連続な進歩 ときどき脱皮
  41. 41. 積み重ね 結局、何事も積み重ね こちら側の積み 重ねがない人は こちら側に 行くのも大変  いつ取り組み始めても、勉強すべきことは変わらない
  42. 42. 改めて、安定するために 安定な部分を切り分ける  サービス指向 ここだけ修正  Portabl Class Library  言語レベルは安定 不安定なのは時代の方  待ってても安定しない 急な変化はない  結局は積み重ねが必要
  43. 43. どうやってハードル乗り越える?
  44. 44. ハードル?わかってるよそんなの。乗り越えろ? という意見もあるだろうし じゃあどうしようってのが本当のテーマ
  45. 45. やれるのはなぜ こんな絵を出しましたが 新機能導入 ループ 疎結合 ループができているということは…
  46. 46. 余裕のある日常/ない日常 日常ループ 日常タスクに必要な量 余裕のある人 MP 余裕のない人 MP 余剰で遊ん学んでる 足りない分を何かで 埋め合わせてる
  47. 47. 余裕のある日常/ない日常 日常ループ 余裕のある人 MP 余裕のない人 MP 要求水準も 日々上がる 取り残されていませんか
  48. 48. フィードバック ループ 余裕は余裕を呼ぶ デスマはデスマを呼ぶ MP 一度でいいから こちら側に来ないといけない MP これがたぶん、一番のテーマ
  49. 49. チーム チームこそ力の源  1人だけに余裕があっても回らない  個人技能よりもプロジェクト進行技能 の方がプロジェクト成否に直結 自分を変えるには環境を変えろ  個人レベルではデスマ側から余裕ある側への脱出は難し い  チームとしての取り組み必要
  50. 50. チームに余裕があるから プロジェクトの継続的な成功の中にいるから テスト整備 ペアプロリファクタリング ライブラリ整備 レビュー 修正しやすい みんなの余裕 みんなの成長  コードの責任を個人に帰属させない  負債解消にどのくらいの時間を使うか、戦略を持つ
  51. 51. ツールに頼る 属人的に進めるのはかなり大変 ツール管理 (今いるチームだと) (希望を言えば…)  Redmineで作業項目管理 作業項目管理  gitでソース コード管理  TFSで ソース コード管理  gerritでコード レビュー コード レビュー  Jenkinsで自動ビルド 自動ビルド All in Oneなのが楽だし Visual Studio連携が楽だし 今なら自前サーバー不要だし (tfs.visualstudio.com)
  52. 52. Visual Studio ALM Visual Studioの進化の方向性  Application Lifecycle Management※ 2012 2010 • チーム全体 • 開発チーム ステークホルダーや運用者 2008 との連携性強化 • 個人開発 作業項目管理 つまるところ、 Team Foundation Server (がほぼ完成) ソース コード管理 の強化、VSとの一体化※ 開発・運用のライフサイクル全体の統合管理
  53. 53. Visual Studio ALM プロジェクト状況の可視化  問題の早期発見
  54. 54. Visual Studio ALM 各種コレボレーション 作業項目管理 優先度付け 人的リソース 配分 コード レビュー
  55. 55. Visual Studio ALM 自動ビルド・配置  テスト漏れや配置ミスを減らす ゲート チェックイン  ビルドの通らないソース コードのチェックインを認めな い  ビルド自体を厳しくすれば、ある程度の品質担保に  ビルド後にテストを実行  静的解析ツールを通す
  56. 56. 大規模開発でもいけるの? Visual Studioは3500人体制で開発されてる 分割統治  5~10人程度のチームに分かれて開発  可視化やゲート チェックインで全体の品質担保 このためのALM このためのTeam Foundation Server 紙ベース/Excelベース納品してる限り無理じゃないかな
  57. 57. 改めて、ハードルを越えるために 余裕は余裕を、デスマはデスマを呼ぶ  フィードバック ループ  何も手を打たないと抜けられない デスマ ループから抜けるためには  チームこそ力  言語機能やツールに頼る  言語機能やツールから学ぶ
  58. 58. まとめ(1/2) ハードル  使えなくても覚えなきゃ  新技術から学ぶ  技術の変化は時代の変化 ここだけ修正  既存資産を負債にしないために  疎結合  だからこその新機能  不連続はない  あくまで日々の積み重ね
  59. 59. まとめ(2/2) MP フィードバック ループ MP  余裕は余裕を 新機能  デスマはデスマを ハードルを乗り越える  チームで乗り越える 余裕  言語機能やツールに頼る  言語機能やツールから学ぶ

×