JavaからRubyへの変遷を約10年見てきて、プロジェクトで変わったこと、変わっていないこと12集
•
5 likes•3,065 views
TokyuRuby会議09 (http://regional.rubykaigi.org/tokyu09/)
Recommended
More Related Content
What's hot
What's hot (20)
Similar to JavaからRubyへの変遷を約10年見てきて、プロジェクトで変わったこと、変わっていないこと12集
Similar to JavaからRubyへの変遷を約10年見てきて、プロジェクトで変わったこと、変わっていないこと12集 (20)
More from Koichi ITO
More from Koichi ITO (20)
Recently uploaded
Recently uploaded (7)
JavaからRubyへの変遷を約10年見てきて、プロジェクトで変わったこと、変わっていないこと12集
- 1. JavaからRubyへの変遷を 約10年見てきて、プロジェクトで 変わったこと、変わっていないこと12集 (株) 永和システムマネジメント アジャイル事業部 Ruby x Agile グループ 伊藤 浩一 (@koic) 2015.08.29 (Sat) 株式会社VOYAGE GROUPさま会議室 TokyuRuby会議09 from Practices of XPE1st
- 4. Computer programmer, guitarist. Leader of an Agile software development team at Eiwa System Management, Inc. Lives in Shinjuku. @koic photo token by @NaCl
- 5. TO MAKE THE END OF DECADE 2015.09.12
- 10. 今日の話
- 11. 1999
- 15. 『Extreme Programming Embrace Change』より
- 17. 観察記
- 19. お題に ちりばめつつ 話しますよ
- 20. #01 計画ゲーム
- 22. #01 • オレオレフレームワークからの解放が及ぼしたもの • RubyコミュニティのWebプログラマーはだいたい触れ る (すごい！) • Railsによる実装技術と、AEPによる見積り技術の知見 共有によって、ある程度プロジェクトを越えて見積れる ようになってきた • 実装の見積りは開発者の仕事 (XP緑本参照) 計画ゲーム
- 23. #02 短期リリース
- 24. #02 • 小さな差分であれば、比較的追いやすい、切り戻しやすい、影 響の目が届きやすいのは、以前から変わらない • リリース後もサービスは続き、データマイグレーションへの 注意 • リリースしてお仕舞いではなく、フィードバック、KPIをとる 仕組みやA/Bテストの重要性が高まってきた • リリースの周辺の重要性に対して意識が高まってきた (オレオレ • インデックス殿∼で本番で死なないようにリードレプリカを用 意するなどインフラも重要 短期リリース
- 25. #03 メタファ
- 27. #03 • 顧客プロキシーではなく、顧客 (あるいは企画) という要 求者と直接会話する機会に恵まれてきた • システムの世界観という曖昧なものについて、ひとつの チームとして近いものを捉えられるようになってきた • とりわけ、インセプションデッキのパッケージデザイン づくりはこれから作るシステムに対する、要求者と開発 者のチームビルディングのプラクティスとしてオススメ メタファ
- 28. #04 シンプルな設計
- 30. #04 • UMLを見なくなってきた。Database-orientedなRails でschema.rbを見れば良くなったのと、CoCによって書く ことが減り、すばやく作れるようになったから (?) • ソーシャルコーディングを支えるサービスの登場で、コード(設 計) のフィードバックがカジュアルにできるようになった • おおきくなったら「アーキテクト」になりたいかい？ • 間違っているものを正しく作っていないか判断できるために、 インプットとなる要求の打ち合わせは全員同席がオススメ。 アウトプットのソースコードを PR でピリッとみれる(かも) シンプルな設計
- 31. #05 テスト
- 33. #05 • 「テストを書く時間が欲しい」とかではなく、勝手に書 くようになった (書きますよね？) • データベースへのスタブとかやらなくなった • 千本モックを見なくなった • コンパイルの待ち時間へのストレスから、スローテスト へのストレスにボトルネックが移行した (生き急げる!) • データディレクトリをメモリにするとか見たことある テスト
- 34. #06 リファクタリング
- 36. #06 • ようこそデータベースリファクタリングの世界へ • データベースリファクタリングも、大きなリファクタリ ング (テーブルの切り出しなど) 、小さなリファクタリン グ (カラム名の変更など) • データは超重要な領域、小さな差分を無理ない範囲で堅 実に (ヒリヒリ感↑↑↑) • コードとデータマイグレーションのリリースを分ける選 択肢 リファクタリング
- 37. #07 ペアプログラミング
- 41. Diversity
- 42. #07 • ソーシャルコーディングのレビューで減ってきた? • きっとみんな使うエディタが違うという話ではない(?) • 常時レビューの即時フィードバックがないリスクと、瞬 間ベロシティ向上コストの釣り合い • 一度できればだいたいできる (自転車の運転と同じ) • 私見として、熟練度低い同士だと進まない傾向がある ペアプログラミング
- 43. #08 共同所有
- 45. #08 • csv→svn→git (hub) • チーム内リポジトリでコンソールログ→ソーシャルコーディングで チーム (リポジトリ) 横断レビューの加速 • コードにコメントが付くようになった！ • 業務知識部分は分からなくてもRailsの部分ならレビューできる • インフラの環境構築についても、コードとして共有できるようになっ てきた (Immutable Infrastructure) • 仮想環境へのプロビジョニングで環境構築の手早さ↑↑↑ 共同所有
- 46. #09 継続した結合
- 48. #09 • コンパイルが通るかは、期待する振る舞いが実装されてい るかのリトマス紙にはならない • テストを書くことがあたり前になってきた (本日2度目) • CIのSaaSが現れて導入が楽になってきた • Jenkins→Travis CI, Circle CI • 自前で立てる→サービスで導入 • チームビルディングの早めに用意しよう 継続した結合
- 49. #10 40時間労働
- 50. #10 • E和さん定時で帰ってますね (ホワイト企業？) • GitHubの登場で、電車の中でもレビューやマージがで きるぞ (無限に働ける！) • "Rails超はやく機能が作れて、どれだけでもやれそうで きちんとコントロールしないと息切れする" @nawoto • 継続可能なペース維持重要 40時間労働
- 51. #11 オンサイトのユーザー
- 53. #11 • 作って納品して終わりではなくなってきた • 開発チーム、保守チームという分け方も減ってると感じる • 新規サービスの立ち上げを自社の受託メンバーだけで実装した 結果、発注側が自身で欲しいものを作れない • 顧客に届けるものがシステムだけでなく、システム構築のため のエンジニアリングやRails周辺の文化も込みになってきた • バトンタッチ一発の引き継ぎではなく、一緒に開発をして徐々 に馴染むのが正攻法 (Baby Steps) オンサイトのユーザー
- 54. #12 コーディング規約
- 55. #12 • 本質でないところに目がいって気になる • コードレビューが熟達したチームは割りと できている • Rubocop (がいいかどうかは分からない) • 単に個人的に好きではない コーディング規約
- 56. おわりに
- 58. 『エクストリームプログラミング』23章より Tools and techniques change often, but they don't change a lot People, however, change slowly but deeply. ツールや技法は何度も変化するが、大きく変化するわけでは ない。一方、人はゆっくりとだが、深く変化する。