如何做到 4 天上线一个小程序

[zengqz]

写了一篇文章，总结做小程序兼容的详细技术方案（ PS：小程序太坑了）

黑客说：如何做到 4 天上线一个小程序？

[FEDT]

网页版也挺不错的，打算开源吗

[linhongye]

不是抬杠哈。
想问下，大概项目的代码量是多大呢？是不是除了 4 天上线之外，还有更多的考量？
我试了一下小程序端，也对比了下网页端。
一是网页端功能没有完全移植过来。
二是初略看来，就是以现在这个小程序的功能丰富程度，大概是一个人 3 ～ 5 天能够实现的… （当然，对内部细节不清楚，还请指教。）
而文章中说了团队协作流程的重要性，那我想程序员应该数量达到 3 人或以上，所以我猜想即使没有代码复用，大概完成时间也在 4 天之内…
我自己也写过小程序，用过 react 、用过 taro 、用过原生，也写过 ios 、安卓和网页。因为我开发过很多个平台，也试过不同的跨平台方案。
所以，我想的一个问题就是，有多少时候追求代码复用是伪需求呢？
有些时候，追求复用是能大幅提高效率的，比如 vs code 在 mac 和 win 上跨平台。
然而，ios 、安卓、微信小程序 这些都在极力创建自己封闭生态的地方，而且前端工作量不大的情况下。就我自己的体验来说，前端放弃直接的代码复用，而选择环境生态下本身优秀的开发思路，其实更快更省人力，后期可维护性也更强。

[daimaosix]

PPT

[qiayue]

我花了 1 小时上线了一个小程序，因为用的 webview 嵌入已经做好的网页版，并且网页版做了微信公众号授权登录，所以小程序真的就是一个浏览器。
写代码加审核发布时间加起来 1 个小时。

[cz5424]

@qiayue 之前全是网页审核不给过的，可能后面松了

[zengqz]

@linhongye 是的 就现在看到的功能来说重新写一个也不麻烦，这是第一个版本，原因是很多代码没有迁移过来，目前实现的是一个简化版本，文章是介绍一些兼容的手段，小程序端向 web 兼容，而不是类似 taro 那种相反的做法，代码复用真的很重要，因为就 UI 来说可以直接迁移而不需要重新根据小程序端重新设计（当然有很多精细排版后续需要手动优化）

[zengqz]

@linhongye 这个项目前端工程量不大，4 万行代码左右，但是想象一下，如果按文章的做法操作，这些代码可以直接迁移使用，不是极好的吗？而且这种做法不受规模影响，上线新特性的时候总是先完成 web 版本，连数据、UI 逻辑直接迁移小程序而无需改动，这样开发效率是最高的。你提到的另一个问题是封闭生态上的开发，这个我很赞同你，直接在这些生态上开发无论体验还是性能都是杠杠的！比 react-native 和 flutter 之类的方案好太多，但是从商业角度来说，复用能够明显降低开发成本，加速上线

[linhongye]

@zengqz #7 我的也是商业项目... 踩坑以后发现... 每个端始终得做单独优化...
也就是说, iOS 的人不能少、网页的人不能少、小程序的人不能少... 还得有个高手来做底层优化... 看看美团他们, 多大的团队专门在优化 flutter, 性能还是那个样子... 小公司更不可能了...
代码复用能不能降低成本、提高速度, 是一个不等式, 需要考虑的东西很多...
有时候, 追求尽量多的代码复用, 反而让总体效率下降. 我现在是后端用 graphQL, 所以向后端请求数据的部分代码复用.
剩下的全部原生撸.
在我的项目上, 这种方案效率比, 开发一个复用率高的版本, 再去做各端优化来的高.... 毕竟现在前端撸起来还是快且容易的.... swiftUI 撸起来又滑又优雅; 微信小程序自己那么多坑, 自己去解决起来也比 copy 其他端的代码来的容易解决...
如果只有网页版和小程序需要适配, webView 其实是一个非常简单明了的办法...
ps. 小程序的 navigateTo 不能用超过 10 次, 你们的小程序里现在这个事件没有处理.

[zengqz]

@linhongye oh! 感谢🙏，已提单

[linhongye]

@zengqz #9 想问下.. 你们现在这个小程序 4 万行了?...

[zengqz]

@linhongye 网页端，在编辑器部分，你可以体验下网页端编辑器，小程序没有那么多（小程序版本很简单的）

[zengqz]

@FEDT 网页端编辑器有考虑开源，后面再看吧～这部分难度不低

[wq2016]

用微搭