这是一个创建于 3813 天前的主题，其中的信息可能已经有所发展或是发生改变。
开发项目中,用到某框架,该框架刚刚beta不久,主要教程来自官方文档,民间极少有教程.
需要实现一个功能,框架有提供一个很接近的API.
经尝试很多次后,发现失败(原因在于并不知道这个API能达到需要的效果,官方文档给的用例比较少,也没有其他地方可以查阅)
抛弃框架的API进行开发,用自己的代码实现,其实利用框架和自己写代码,逻辑是一样的,代码甚至90%都相同.
但是codeview过不了,上司要求,能用框架提供的API就必须得用,我很是无奈,甚至觉得,假如后来知道了该框架不能完成所要的需求的话,就在这上面浪费了不少时间.有点吃力不讨好的感觉.
不知道各位猿们怎么看?
项目是开源项目.
 | 1 Septembers 2015-06-26 22:22:22 +08:00 via Android 如果框架本身官方接受Pull Request的话 可以考虑重构目标API提交Pull Request （但是如果这样做的话 需要考虑通用性问题 |
 | 2 w88975 OP @Septembers 框架接受Pull Request,但是我的问题不在于是否修改框架,而是这两点之间的抉择问题. |
| 3 w88975 OP @Septembers 如果框架本身能够很轻松的解决问题,那么一定选择框架提供的API,但是在框架不确定的情况下,是否可以先出一个版本,后期再进行迭代? 而且还是这种使用框架API与自己重构的成本基本上相同的情况下,如果选择框架,能很好的踩完需要踩的坑,但是浪费了时间. |
| 4 Septembers 2015-06-26 23:07:57 +08:00 via Android @w88975 麻烦透露下编程语言 |
 | 5 kongkongyzt 2015-06-26 23:08:59 +08:00 我只是好奇为啥要用一个beta不久的框架。。。 |
| 6 w88975 OP @Septembers polymer |
 | 7 w88975 OP @kongkongyzt 搞错了 是release |
 | 8 neoblackcap 2015-06-26 23:24:09 +08:00 @w88975 既然接受pull request的话，你写得又比框架的好，那么你去发个pull request将你的版本合并进去，然后不久光明正大地使用了吗？ |
 | 9 iskyzh 2015-06-26 23:32:24 +08:00 @w88975 = = 这个框架好像很熟悉的样子…… 我看 Polymer 做出来的网页效果很好，虽然没有学过，但我倾向于根据自己的需求读官方文档，如果官方文档里没有，或者自己的需求超出了框架能做的，我会考虑再使用一些更加底层的方式写代码。 本人对前端的美观比较在意，所以肯定不会选择自己写，那么就先用 Polymer 做，实在没法用 jQuery 获取 Polymer 创建的 DOM 对象，然后进行操作…… = = Google Material Design 有一个 Bootstrap 主题…… https://github.com/FezVrasta/bootstrap-material-design , 如果是为了做出 Material Design 的界面效果而使用 Polymer，不如寻找其他可以显示 Material Design 的代码。 |
 | 10 iwege 2015-06-26 23:47:05 +08:00 先修改自用，觉得可以就和官方讨论，不然就自己维护一套。 或者用这个为一个base class 然后extend你自己的API。 以前JQM不支持的tablet的时候就这么搞过。 |
| 11 w88975 OP @iskyzh 并不是UI方面,而是在JS框架方面,基本上没有用到polymer提供的控件,控件都是自己重新基于polymer做的. @neoblackcap 首先是不至于为了一个很少见的需求去提pr,我最大的问题在于,如果框架提供的API仅仅能满足一点点需求,并且开发周期大于自己重新造轮子,这种情况下,是继续踩坑还是自己造轮子解决. |
 | 12 dallaslu 2015-06-27 00:07:24 +08:00 工期紧、框架完成度高并稳定，则用框架。 |
 | 13 88250 2015-06-27 00:10:06 +08:00 开源项目注重的是持续 |
| 16 Septembers 2015-06-27 00:17:31 +08:00 via Android @w88975 1. 你可以考虑自己做个 组件库，打包成一个project，单独维护 然后在项目中引入该 组件库 2. 目标API不满足又不希望提交poll request/issue 可以通过monkey patching的方法解决 （代价是API与文档描述行为不符合既定预期， （从而造成维护困难 3. 开始你说公司不允许不使用API也就意味着，你没有对基础框架的调整权限。 |
 | 17 realpg PRO 选择一个可以充分扩展的框架……开源社区维护的可以贡献代码的就更好了 |
 | 18 jjx 2015-06-27 09:22:51 +08:00 在可能的情况下尽量使用现有的框架,当然框架要符合成熟,开源, 社区好的条件,这样能享受很多人的智慧, 如果什么都是自己实现, 最后结局通常是重写, 特别是换人的时候 |
 | 19 secondwtq 2015-06-27 12:44:51 +08:00 Polymer 感觉确实有坑... 特别是推开官方组件库从头重做的... |
Select Language