这是一个创建于 3440 天前的主题，其中的信息可能已经有所发展或是发生改变。
开发项目中,用到某框架,该框架刚刚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 2015-06-27 01:17:46 +08:00
选择一个可以充分扩展的框架……开源社区维护的可以贡献代码的就更好了
|
 |
18
jjx 2015-06-27 09:22:51 +08:00
在可能的情况下尽量使用现有的框架,当然框架要符合成熟,开源, 社区好的条件,这样能享受很多人的智慧, 如果什么都是自己实现, 最后结局通常是重写, 特别是换人的时候
|
 |
19
secondwtq 2015-06-27 12:44:51 +08:00
Polymer 感觉确实有坑... 特别是推开官方组件库从头重做的...
|
Select Language