Location via proxy:   [ UP ]  
[Report a bug]   [Manage cookies]                
SlideShare a Scribd company logo

「レガシーコード」とはいったい？

•
•
Hiroyuki Ohnaka
Hiroyuki Ohnaka

オープニング＋「実践レガシーコード」

Related slideshows

210110 deformable detr
210110 deformable detr210110 deformable detr
210110 deformable detr
 
Apport de la simulation sur maquette adaptative à la démarche de conception d...
Apport de la simulation sur maquette adaptative à la démarche de conception d...Apport de la simulation sur maquette adaptative à la démarche de conception d...
Apport de la simulation sur maquette adaptative à la démarche de conception d...
 
Shared Preference in Android App
Shared Preference in Android AppShared Preference in Android App
Shared Preference in Android App
 
1 of 59
Download to read offline
「レガシーコード」とはいったい!? レガシーコード」 ～あなたも書いてるレガシーコード～ あなたも書いてるレガシーコード～ レガシーコード 高橋邦彦 大中浩行 13-E-4 中谷秀洋 川西俊之
自己紹介 高橋邦彦（たかはし くにひこ） 本日進行役 id:kunit 新しいフレームワークを作ろうとしていろい ろ調べているうちに REST と TDD の魅力 に取り付かれて今に至る 2008年5月より株式会社ディノで Web アプ リケーション開発を行っている
自己紹介 大中浩行(おおなかひろゆき) (株)エルテックス 商品開発室 azusa@fieldnotes.jp / @setoazusa Working Effectively With Legacy Code 読 書会幹事 Seasarプロジェクトコミッタ
自己紹介 中谷 秀洋(なかたに しゅうよう) サイボウズ・ラボ株式会社 Web 間アプリフレームワーク flowr 英単語タイピングゲーム iVoca コンピュータと無縁の就職をするも、社長の鶴の 一声で、一人情シス(兼業)として内製＆外注 (中略) 現在に至る
自己紹介 川西 俊之（かわにしとしゆき） 仕事ではC/C++で開発からテストまで テスト管理システムTestLink C言語用BDDフレームワークCSpec
それでは
「レガシーコード」とはいっ たい!? ～あなたも書いてるレガシーコード～
あらため
現場で闘う あなたに贈る レガシーコード迎撃 座談会
副題： 副題： クラウドもSaaSも iPhoneも レガシーやろ！
スタート！
まず、皆さんに 問題
Q:レガシーコード とはいったい何?
COBOLで書 A: かれたコード
「レガシーコード」とはいったい？
Win NT 4.0 A: 用のコード
「レガシーコード」とはいったい？
あの先輩か A: ら引き継いだ コード
「レガシーコード」とはいったい？
その答えを求めて 教科書を ひもといてみましょう
「レガシーコード」とはいったい？
現場で闘う あなたのための バイブル ※翔泳社から 日本語訳出版決定!
レガシーコード とは
一般には 「理解しづらい・変更しにく いコードのこと」 を指すかもしれない
ただ、この本に よれば
レガシーコード とは
ずばり テストのないコード を指す Working Effectively with Legacy Code p.xvi
そう
明日あなたが 書くコードも
レガシーコード かもしれない
では、私たちは いったいどうしていけば 良いのだろう
それを共々に 考えていきましょう
本日の 本日の目標 レガシーから 逃げない レガシーを 作らない レガシーを 作り込ませない
本日の 本日の目標 そのために 各人がすべきことを 探すきっかけを作る
それが レガシーコード 迎撃 座談会
それでは、 ここで、 本題に入る前に
レガシーを語る上での 基本用語を押さえましょう Edit & Pray Cover & Modify
Edit & Play 編集し、そして祈る 不安を抱きながらコードを変更 うまくいったと一息つくのも束の間 たまに、納品後にその不安が的中 現在のソフトウェア開発の主流 (by Working Effectively with Legacy Code)
Cover & Modify カバーして、変更する 変更の正しさ確めるテストを用意 作成したテストをセーフティネットと してコードを変更 変更の影響がわかるので安心 このセッションでこれを目指したい
ということで ここからが本題
今日のお題 今日のお題 のお 実践レガシーコード レガシー座談会 コミュニケーションとしての レガシーコード まとめ
実践レガシーコード ※フィクションです。たぶん
その1 その //コンストラクタ //コンストラクタ public TooLong (String path,Map map1,Map map2,String id, IIF intf) ….
どうやって生成 すりゃいいんだ ？
その1・ その ・テストケース public void testTooLong() { TooLong tooLong = new TooLong(null,null,null,nul l,null); …. }
→Pass Null
その２ その２ private DataSource dataSource; public void doLogic() throws Exception { Connection con = dataSource.getConnection(); ….. }
その２ その２ InitialContext ictx = new InitialContext(); DataSource ds = (DataSource) ictx.lookup(quot;java:comp/env/jdbc/SampleDSquot;) ; Field[] fields = Demo2.class .getDeclaredFields(); for (Field field : fields) { if (field.equals(quot;dataSourcequot;)) { field.setAccessible(true true); true field.set(instance, ds); } }
テストのためなら リフレクションも 厭わず
その３ その３(Before) Properties prop = new Properties(); ServletContext servletContext = ContextFactory.getContext(); prop.put(quot;PROP_PATHquot;, servletContext.getRealPath (quot;WEB-INF/prop.propertiesquot;));
その３ その３(After) Properties prop = new Properties(); if (ContextFactory.hasContext()) { // 本番 ServletContext servletContext = ContextFactory.getContext(); prop.put(quot;LIB_PATHquot;, servletContext .getRealPath(quot;WEB-INF/prop.propertiesquot;)); } else { // テスト prop.put(quot;LIB_PATHquot;, quot;WEB- INF/prop.propertiesquot;); }
やりすぎ？ そこで…
その３ その３(ContextFactory内) 内 public static void setContext(ServletContext fakeServletContext) { servletContext = fakeServletContext; }
→静的setter
その4 その MysteriousObject obj = new MysteriousObject(); Result result = obj.mysteriousLogic(); //どうassertするの？ …
その４ その４ Result result = obj.mysteriousLogic(); assertEquals(quot;ありえない リターンquot;, result.getString());
→Characterization Tests
いろいろ データベースのテストには Seasar2(S2Unit)が有効 DBの操作とトランザクション管理が分離 されていることが前提ですが… どこにテストを書くのか？ 何をテストしたいのか →どこにバグがありそうか →プログラマーとしての直感を信じよう
まとめ 依存性を解決するために、本番 コード側に手をいれることがあり ます テストを通すことよりも、今ある コードの振る舞いを明らかにす ることを優先しましょう

More Related Content

「レガシーコード」とはいったい？

Editor's Notes

  1. <number>
  2. <number>
  3. <number>
  4. <number>
  5. <number>
  6. <number>
  7. <number>
  8. <number>
  9. <number>
  10. <number>
  11. <number>
  12. <number>
  13. <number>
  14. <number>
  15. <number>
  16. <number>
  17. <number>
  18. <number>
  19. <number>
  20. <number>
  21. <number>
  22. <number>
  23. <number>
  24. <number>
  25. <number>
  26. <number>
  27. <number>
  28. <number>
  29. <number>
  30. <number>
  31. <number>
  32. <number>
  33. <number>
  34. <number>
  35. <number>
  36. <number>
  37. <number>
  38. <number>
  39. <number>
  40. <number>
  41. <number>