1
MengQuadra 2019-12-23 19:42:45 +08:00
最需要的是写文档, 不然维护火葬场_(ˊཀˋ」∠)_
|
2
arnoldxiao OP @MengQuadra 可是我们貌似缺少这玩意
|
3
qyizhong 2019-12-23 19:46:49 +08:00
工具链要完善,要不然就很痛苦
|
4
loveuqian 2019-12-23 19:50:55 +08:00 via iPhone
其实每个模块第一版我都很组件化的
可是改着改着 我都懒得把属性放到.h 公开了 直接 runtime 去拿属性。。。 |
5
arnoldxiao OP @loveuqian 其他同事会不会很痛苦??哈哈哈哈哈
|
6
arnoldxiao OP @qyizhong 就是说初期会很痛苦?维护好了后期会很爽,维护不好照样痛苦?
|
7
arnoldxiao OP 我个人觉得代码规范和文档很重要,决定着不管是新同事还是老同事,能不能愉快的码代码
|
8
UncleJar 2019-12-23 20:18:46 +08:00
自动发版
|
9
qq2511296 2019-12-23 21:58:30 +08:00
我个人感觉,不是所有项目都适合组件化。感觉组件化比较适合在大项目、人员多、业务复杂的场景。
不然 1,2 个人维护 N 个组件,感觉也好麻烦。 看看其他 v 友的见解吧 |
10
ai277014717 2019-12-23 22:02:23 +08:00
目前感受,统一规范化 /工具链完善,发布卡口治理。
|
11
lizhuoli 2019-12-23 23:48:00 +08:00 via iPhone
CI/CD(以组件为核心,而不是仓库),多仓工具链,二进制方案,这套先建设完善。如果连基本的这套都没有,用组件化开发业务需求,是伪架构,效率是劣化的
|
12
lizhuoli 2019-12-23 23:49:41 +08:00 via iPhone
不过这种问题能问出来,是小厂?截止 2019 年还没有内部的完善解决方案的话,建议尽量用用开源方案建设先起来,不要自己想当然做了
|
13
lizhuoli 2019-12-24 00:20:45 +08:00 via iPhone 4
Router: 开源方案很多,MJRouter 那种老架构也可以,解藕页面,更好的是不只路由页面,路由模块 Biz App 更高层次的也可以
RPC 跨业务调用:只要能实现面向模块协议编程而不是头文件即可,比如阿里开源的 BeeHive 就行 注册启动: 组件化需要管理组件的注册和启动周期,如果彻底解藕,使用注解以避免+load 方法或者把启动项写在一起。开源项目有 AnnotationKit,BeeHive 自己也有一个精简版 包管理:结论来看,要么 CocoaPods+自定义插件路线,要么像 Facebook 走自己的 Buck。业务组件的迭代会很频繁,严格语义版本和频繁更新 Podspec 是很繁琐的,只要能自动化这一套都行,CI 建设也需要打通 网关接口:网络请求抽象化,IDL 脚本化,这样能够快速实现 API Mock,网络调试,降级熔断等等一系列事情,避免直接访问底层接口 壳工程化:同上,所有代码在组件中,做得好可以使用类似 xcodeproj 插件动态生成 Xcode Project,描述+组件就是一个项目,类似百度的 共用组件:抽离通用层,以及适配层,不同业务差异考适配层实现协议,通用层对外屏蔽细节。跨 App 依赖均采取此方案 开发工具:组件化以后就是多仓库开发,一定要有衬手的工具去管理仓库。就我知道的实践来看,多仓工具比起类似 Google/FB 那种单仓库多组件(Monorepo)更适合大部分项目,工具用类似阿里 mPass 或者 mbox 那种都行 |
14
arnoldxiao OP @qq2511296 目前项目组 iOS 三人,App 四个,组件几十上百个,组件分支管理较为混乱,因为人员流动问题,留下代码比较难维护
|
15
wupher 2019-12-24 10:00:56 +08:00
原来所在的上一家公司曾经启动“应用工厂”项目。所有的常用组件要求必须组件化,组件之间可以通过工具链装配再通过胶水代码生成各种应用。
iOS 开发团队当时有上百人,开发力量还是非常雄厚的。 最后的结果么,只能说能用。交互上实在是悲剧。产品和设计如果有创新或者尝试,很容易就被相关组件团队枪毙。不过也能理解,光改 bug 都改不完。 更要命的是,公司规定,有组件必须用组件……产品和设计对这个应用工厂的反感,就可想而知了。 后来,我就离职了。 公司大了,应该都会有类似的趋向,倒也不光 iOS 组件了。那种小而美的,让人眼前一亮的东西,你很少能在诸如 支付宝、微信这样的 App 中看到。 同样的道理,我估计升降式摄像头也不会在 Apple 上看到吧? |
16
imkerberos 2019-12-24 10:11:29 +08:00
这种推组件化的, 往往是一些一瓶子不满半瓶子咣当的人推动的. 根本做不好, 难用的一 B,比不用组件还难用.
|
17
arnoldxiao OP @qq2511296 目前 iOS 三人,有四个 App,组件几十上百个,组件分支管理较为混乱,因为人员流动问题,留下代码比较难维护
|
18
1219178163 2019-12-24 10:41:19 +08:00
@wupher 体验最好的应用都是先定制化开发,然后模块组件化,先组件化,界面交互都固定化了,产品体验创新的路都堵死了。
|
19
1219178163 2019-12-24 10:44:15 +08:00
fastlane 必须的,git 复杂流程脚本化必须的, 支持 OC && Swift 必须的,路由(不知道具体细节如何实现)
|
20
arnoldxiao OP @imkerberos 灾难级维护
|
21
wupher 2019-12-24 11:04:54 +08:00
@imkerberos 看来是我表达方式有问题,我其实并不反对组件化。
很多组件,特别是开源组件其实大大方便了我的日常开发,也让我学习到了很多优秀的技术和思想。组件化也是推动了 iOS 以及开源 iOS 开发的。 但是,在公司层面执行时,难免种种不尽人意。 能坚守初衷不是件容易的事。 |
22
ldehai 2019-12-24 11:07:39 +08:00
不用组件怎么招客户端架构师呢?客户端都需要架构师,以前真的不敢想
|
23
arnoldxiao OP @wupher 同意,对各方面要求都比较高,而且不能急于求成
|
24
a455455b 2019-12-24 15:13:43 +08:00
当初是按客户端架构招我的,现在裁员裁到我开始写 UI 了
|
25
arnoldxiao OP @a455455b 卧槽 无情~
|
26
imkerberos 2019-12-24 17:28:39 +08:00
我的一个口号是 “珍爱生命,远离 FB”。垠神曾经批判过“只要是有钱人发布的东西,神马垃圾都能被吹捧上天。”自从 FB 发布了一个叫做 Three20 的垃圾 UI 库,里面带了一个叫做 "router" 东西以来,一帮脑残粉就把这个 router 当成了银弹,到处吹嘘并狂热得推广,并美其名曰“组件化”,不知道是孤陋寡闻还是坐井观天,没有听说过前端码农的血泪:“动态代码一时爽,代码维护火葬场”,把本来可以静态化的代码非得用动态化去实现,看上去貌似高大上,实际上是花拳绣腿,为了 KPI,什么垃圾都拨拉到碗里面。
|
27
arnoldxiao OP @imkerberos 的确,BUG 超多,代码难以维护,光布局就三四套,没有规范,每个人照着不同的框架写
|