Trisha Gee
#GeeCON
来自 10gen 的 Java 驱动程序开发人员
@trisha_gee
要讲什么?向后兼容性?
设计:将需求转化为描述系
统的全局架构和功能的技术
规范。
http://homepages.cwi.nl/~paulk/patents/isnot/node4.html
管理大型软件系统的开发 — Winston
Royce 博士
http://www.cs.umd.edu/class/spring2003/cmsc838p/Process/waterfall.pdf
灵活的设计
< 此页特意保留空白 >
设计是一个过程,而不
是一个文档
• 设计是一次旅行,享受您的旅程
• 您会遇到怪物
• 也会发现密室
• 甚至可能没有目的地……
要讲什么?
史上最好的工作!!
我们出发喽!
向后兼容性
诸多的未知
设计目标
没错,这是一个文档
设计目标
• 一致性
• 更明晰的设计
• 直观的 API
• 稳健的异常处理
• 测试友好
• 向后兼容性
缺乏一致性
编码标准
没有分析错误
不再有争执
设计目标
✓一致性
• 更明晰的设计
• 直观的 API
• 稳健的异常处理
• 测试友好
• 向后兼容
用户
认识我们的用户
1. Java 开发人员
2. ODM / 其他驱动程序 / 第三方
3. 贡献者
三类用户
Java 开发人员
• 一致性
• 更明晰的设计
• 直观的 API
• 稳健的异常处理
• 测试友好
• 向后兼容
第三方库
• 一致性
• 更明晰的设计
• 直观的 API
• 稳健的异常处理
• 测试友好
• 向后兼容
贡献者
• 一致性
• 更明晰的设计
• 直观的 API
• 稳健的异常处理
• 测试友好
• 向后兼容
用户是我们的朋友
向后兼容性
架构
UML ,呵呵
高级架构
Scala 驱动程序
设计目标
• 一致性
✓更明晰的设计
• 直观的 API
• 稳健的异常处理
• 测试友好
• 向后兼容
设计目标
• 一致性
• 更明晰的设计
• 直观的 API
• 稳健的异常处理
• 测试友好
• 向后兼容
高级架构
选择 1 :包装
选择 2 :连接
向后兼容性?
测试通过
我们赢了!
设计目标
• 一致性
• 更明晰的设计
• 直观的 API
• 稳健的异常处理
• 测试友好
✓向后兼容
我们还活着……
公共 API
设计目标
• 一致性
• 更明晰的设计
• 直观的 API
• 稳健的异常处理
• 测试友好
• 向后兼容
注意
• 它看起来不像这样
• 尚未决定一致的名称
• 需要某种适合所有驱动程序的 API
查找
collection.find(query).skip(1000).limit(100);
collection.find(query).skip(1000).limit(100);
查找
collection.find(query).skip(1000).limit(100);
collection.find(query).skip(1000).limit(100);
collection.find(query, fiel...
应选择哪一个?
查找
collection.find(query).skip(1000).limit(100);
collection.find(query).skip(1000).limit(100);
collection.find(query, fiel...
更少的决定
“Cmd + space” 友好
查找
collection.find(query).skip(1000).limit(100);
collection.find(query).skip(1000).limit(100);
collection.find(query, fiel...
删除
collection.remove(query);
collection.find(query).remove();
查找并修改
collection.findAndModify(query, update);
collection.find(query).updateOneAndGet(update);
这令人讨厌!
查找并修改
collection.findAndModify(query, update);
collection.find(query)
.updateOneAndGet(update);
collection.findAndModify(q...
查找并修改
collection.findAndModify(query, update);
collection.find(query)
.updateOneAndGet(update);
collection.findAndModify(q...
缺乏一致性
最终的一致性
collection.find(query).limit(10);
collection.find(query).limit(10).remove();
collection.find(query).sort(sortCriter...
全玩完了
✓一致性
• 更明晰的设计
• 直观的 API
• 稳健的异常处理
• 测试友好
• 向后兼容
设计目标
• 一致性
• 更明晰的设计
• 直观的 API……
• 稳健的异常处理
• 测试友好
• 向后兼容
我们还活着!
教程 / 外聘讲座
本演讲
设计是一个过程,而不
是一个文档
问答
您在使用 Java 驱动程
序吗?
您喜欢它的什么?
您不喜欢什么?
设计是一个过程,而不
是一个文档
问题反馈
• Trisha Gee
• trisha.gee@10gen.com
• @trisha_gee
Upcoming SlideShare
Loading in …5
×

What do you mean, Backwards Compatibility? (Chinese)

5,150 views

Published on

Slides from my session at JavaOne Shanghai

Published in: Technology
0 Comments
3 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
5,150
On SlideShare
0
From Embeds
0
Number of Embeds
3,810
Actions
Shares
0
Downloads
9
Comments
0
Likes
3
Embeds 0
No embeds

No notes for slide
  • Introduce yourself - MongoDB Java driver - Who knows MongoDB? - Actually backwards compatibility is not the subject of this talk - this talk is about design
  • http://homepages.cwi.nl/~paulk/patents/isnot/node4.html - When getting any formal training in Software Delivery Lifecycle, might see this - get the impression that design is about turning requirements into tech specs - then it’s over and you get on to the fun coding
  • Whitepaper that spawned waterfall - “as much as possible” - the output of the stage is a set of documents - this is BUFD, and we hate it - did design die when waterfall died?
  • Did design die when waterfall became unpopular? - Evolutionary design - Minimum viable product
  • - Design is something YOU do every day - Seen this work at LMAX - no large documents, just well designed code - And when you’re doing library/API work, you MUST do design - I would use all the things I learnt at LMAX to improve the Java driver - This is something you’re all doing, but I want to expose it
  • - This is a journey you’ve all been on - Sharing the pain via the example of the MongoDB Java driver
  • - 9 months ago, joined 10gen Not only going to maintain / improve Java driver, actually want to re-write it what developer doesn’t want that? we have an existing driver, we have a server spec
  • - we’re going to re-write it with generics - fluent API - brave new world, Java 8 - Async - Modern, Intuitive, Performant, Easy to Maintain
  • - Java versions - first obvious challenge - we don’t want to support two code bases - we don’t want a big bang upgrade - we have a lot of users - we don’t know who they are - we need them to be able to continue without pain - how do we have new shiny API-ness with the old api intact as well? - Can you use both?
  • - what are our requirements? - what do we not like about the current driver? - what are we hoping to achieve? - encoders vs writers - migration - documentation - test coverage - lack of consistency - regression bugs - Lots of conversations with the C# guys - make it easy for ODMs
  • - Save Point - wrote down everything we were thinking about - what was on the table, what was off - what was important - what was bothering us
  • - (no need to translate the contents of the document) - this is our baseline - starting point - and now we had it, we could use it to measure X against Y - we could point people at it when they asked us what we were doing - we could use it to have conversations with other driver developers - turned it into a more succinct version on the wiki - series of talks - this is now out of date, it was a marker in time
  • - between drivers &amp; shell, different terminology - within the driver: naming, ordering, formatting - distracting - Ubiquitous language
  • - Save Point - easier than expected - knew we wanted some - enforced in build, in jenkins - means we have bigger conversations than just the little things - can also highlight areas where the design is poor, e.g. long methods, complex if statements
  • Started off with over 6000 Checkstyle errors 200 FindBugs Nearly 100 PMD Errors Now we have zero YAY
  • One down! we could actually have conversations about the design, not about tabs vs spaces Ubiquitous language
  • - who are they? - what do they want? - how do they work? - novice or advanced
  • - this is hard because our software is free and open source
  • 1. public api 2. need to be able to wrap 3. like me, make code pretty, design should be documented in the code, HABITABLE
  • - You’re not writing the new Java driver for you - talk to them - involve them - community - Tutorial / hack session - MUG - JUG - This talk
  • - did you notice I didn’t kill that monster earlier?
  • - Now we have design goals - And identified users - ...much easier to talk about architecture
  • - generated from our code - allows us to have conversations with other people - i.e. other drivers - different colours, different responsibilities
  • We’d been thinking the driver was “simple” Actually it turned out that we have a tiered architecture and that our different users will interact with it at different layers
  • - So for example the Scala driver would reuse the connection pooling - the protocol layer - and provide a Scala-looking API
  • Talking about architecture Focussing on Domain We’ve talked about creating a cleaner design Validated by the fact that it works for our users
  • Let’s talk about backwards compatibility
  • Given architecture Can develop strategy for backwards compatibility
  • - Could wrap the API - I think this will let the IDE help you migrate - And you can use both at the same time
  • - or we could treat the old API like any other third party library - this actually validates the design
  • - but we don’t know that we’ve killed this monster yet - how do we know we’ve succeeded?
  • - Our old unit tests - Our new unit/functional tests - Our acceptance tests - Scala tests - Morphia Tests - Other friendly test cases
  • - In order to kill it, we had to understand our design
  • So that was backwards compatibility, the title of this talk. Turned out it was relatively easy in our case: - defined design goals - understood users - outlined an architecture
  • - internal tools - run it against friendly code - ...and finally, run it in the wild
  • - we’ve found a way to be backwards compatible while moving forwards with the API - what should that look like? - everyone has an opinion, tastes differ - and actually it can be the last thing to change - ...except you need feedback - what’s wrong with the old one?
  • Since backwards compatibility affects the API, lets talk about the new API
  • Feedback is welcome, but would be great if you sent it to us
  • - looks the same
  • -take an example with more params - overloading is common in the driver - be more explicit
  • -take an example with more params - overloading is common in the driver - be more explicit
  • -take an example with more params - overloading is common in the driver - be more explicit
  • Take another example that has changed Filter then remove Can you see we’re starting to get the idea of terminators?
  • Let’s look at Find and Modify - filter again - why do you have to change the names?
  • DBObject, DBObject, DBObject, boolean, DBObject, boolean, boolean
  • DBObject, DBObject, DBObject, boolean, DBObject, boolean, boolean
  • DBObject, DBObject, DBObject, boolean, DBObject, boolean, boolean
  • We want the API to be consistent across operations
  • Stole this from Collections Stream from Java 8 Idea is to chain together operations bit of a shift in mindset for some Java people but DSLs &amp; Java 8 will help move us this way
  • Lack of consistency: Well and truly dead
  • - Fluent - Explicit - Auto complete is important - Consistency
  • Public API - lots of decisions to take - need to get agreement across drivers - need feedback from users (old &amp; new, real developers &amp; driver developers) - Things will change - API is both the thing that cannot change very often but should be allowed to evolve - Last responsible moment? - Hack days, blogs, friendly users...
  • - Save Point - forced me to write against the API - changed it - got feedback
  • - This talk is part of the process - Get feedback from all three types of our users
  • - Design is Hard. but it is your job - You do it every day - Working Software over Comprehensive Documentation - Design is a journey, not a destination - YOu are not typists Enjoy yourself What would I do differently?
  • If no-one, ask them what they’re doing -are they here for design? - directly? - ODMs? - Spring Data?
  • Conclusion - it’s not about the destination, it’s the journey - it’s not about producing a document, or a tonne of documents, it’s about the questions you ask, the conversations you have - Design is Hard. But it is your job.
  • What do you mean, Backwards Compatibility? (Chinese)

    1. 1. Trisha Gee #GeeCON 来自 10gen 的 Java 驱动程序开发人员 @trisha_gee 要讲什么?向后兼容性?
    2. 2. 设计:将需求转化为描述系 统的全局架构和功能的技术 规范。 http://homepages.cwi.nl/~paulk/patents/isnot/node4.html
    3. 3. 管理大型软件系统的开发 — Winston Royce 博士 http://www.cs.umd.edu/class/spring2003/cmsc838p/Process/waterfall.pdf
    4. 4. 灵活的设计 < 此页特意保留空白 >
    5. 5. 设计是一个过程,而不 是一个文档
    6. 6. • 设计是一次旅行,享受您的旅程 • 您会遇到怪物 • 也会发现密室 • 甚至可能没有目的地…… 要讲什么?
    7. 7. 史上最好的工作!!
    8. 8. 我们出发喽!
    9. 9. 向后兼容性
    10. 10. 诸多的未知
    11. 11. 设计目标
    12. 12. 没错,这是一个文档
    13. 13. 设计目标 • 一致性 • 更明晰的设计 • 直观的 API • 稳健的异常处理 • 测试友好 • 向后兼容性
    14. 14. 缺乏一致性
    15. 15. 编码标准
    16. 16. 没有分析错误
    17. 17. 不再有争执
    18. 18. 设计目标 ✓一致性 • 更明晰的设计 • 直观的 API • 稳健的异常处理 • 测试友好 • 向后兼容
    19. 19. 用户
    20. 20. 认识我们的用户
    21. 21. 1. Java 开发人员 2. ODM / 其他驱动程序 / 第三方 3. 贡献者 三类用户
    22. 22. Java 开发人员 • 一致性 • 更明晰的设计 • 直观的 API • 稳健的异常处理 • 测试友好 • 向后兼容
    23. 23. 第三方库 • 一致性 • 更明晰的设计 • 直观的 API • 稳健的异常处理 • 测试友好 • 向后兼容
    24. 24. 贡献者 • 一致性 • 更明晰的设计 • 直观的 API • 稳健的异常处理 • 测试友好 • 向后兼容
    25. 25. 用户是我们的朋友
    26. 26. 向后兼容性
    27. 27. 架构
    28. 28. UML ,呵呵
    29. 29. 高级架构
    30. 30. Scala 驱动程序
    31. 31. 设计目标 • 一致性 ✓更明晰的设计 • 直观的 API • 稳健的异常处理 • 测试友好 • 向后兼容
    32. 32. 设计目标 • 一致性 • 更明晰的设计 • 直观的 API • 稳健的异常处理 • 测试友好 • 向后兼容
    33. 33. 高级架构
    34. 34. 选择 1 :包装
    35. 35. 选择 2 :连接
    36. 36. 向后兼容性?
    37. 37. 测试通过
    38. 38. 我们赢了!
    39. 39. 设计目标 • 一致性 • 更明晰的设计 • 直观的 API • 稳健的异常处理 • 测试友好 ✓向后兼容
    40. 40. 我们还活着……
    41. 41. 公共 API
    42. 42. 设计目标 • 一致性 • 更明晰的设计 • 直观的 API • 稳健的异常处理 • 测试友好 • 向后兼容
    43. 43. 注意 • 它看起来不像这样 • 尚未决定一致的名称 • 需要某种适合所有驱动程序的 API
    44. 44. 查找 collection.find(query).skip(1000).limit(100); collection.find(query).skip(1000).limit(100);
    45. 45. 查找 collection.find(query).skip(1000).limit(100); collection.find(query).skip(1000).limit(100); collection.find(query, fields);
    46. 46. 应选择哪一个?
    47. 47. 查找 collection.find(query).skip(1000).limit(100); collection.find(query).skip(1000).limit(100); collection.find(query, fields); collection.find(query).fields(fieldsToSelect);
    48. 48. 更少的决定
    49. 49. “Cmd + space” 友好
    50. 50. 查找 collection.find(query).skip(1000).limit(100); collection.find(query).skip(1000).limit(100); collection.find(query, fields); collection.find(query).select(fields);
    51. 51. 删除 collection.remove(query); collection.find(query).remove();
    52. 52. 查找并修改 collection.findAndModify(query, update); collection.find(query).updateOneAndGet(update);
    53. 53. 这令人讨厌!
    54. 54. 查找并修改 collection.findAndModify(query, update); collection.find(query) .updateOneAndGet(update); collection.findAndModify(query, fields, sort, false, update, true, false); collection.find(query) .sort(sort)
    55. 55. 查找并修改 collection.findAndModify(query, update); collection.find(query) .updateOneAndGet(update); collection.findAndModify(query, fields, sort, false, update, true, false);
    56. 56. 缺乏一致性
    57. 57. 最终的一致性 collection.find(query).limit(10); collection.find(query).limit(10).remove(); collection.find(query).sort(sortCriteria).getOne(); collection.find(query).sort(sortCriteria).remove(); collection.find(query).sort(sortCriteria).count();
    58. 58. 全玩完了 ✓一致性 • 更明晰的设计 • 直观的 API • 稳健的异常处理 • 测试友好 • 向后兼容
    59. 59. 设计目标 • 一致性 • 更明晰的设计 • 直观的 API…… • 稳健的异常处理 • 测试友好 • 向后兼容
    60. 60. 我们还活着!
    61. 61. 教程 / 外聘讲座
    62. 62. 本演讲
    63. 63. 设计是一个过程,而不 是一个文档
    64. 64. 问答
    65. 65. 您在使用 Java 驱动程 序吗?
    66. 66. 您喜欢它的什么?
    67. 67. 您不喜欢什么?
    68. 68. 设计是一个过程,而不 是一个文档
    69. 69. 问题反馈 • Trisha Gee • trisha.gee@10gen.com • @trisha_gee

    ×