 )
 )
|  |      1BB9z OP 技术人可能还是对技术更感兴趣,贴点有意思的: Feel 从自 2014 年 7 月 12 日开发至 2.3.1 版,提交 3376 次,发布 15 个版本。编译次数 18000+,累计增加代码 36 万,删除 21 万( GitHub 上的统计)。下面的数据用粗略快速的方式统计的,供参考。 现有项目的源码文件有 390 个,其中代码 41525 行,空百 9595 行,注释 1934 行;头文件 397 个,代码行有 7286 ,空白 3792 行,注释 4943 行。 应用调用的接口数有 172 个,文档中登记在案的废弃接口有 51 个。 不含第三方资源文件,项目中使用了 164 组图片; Storyboard 14 个,平均每个 Storyboard 有 2538 行; nib 35 个,平均每个 nib 中有 143 行。 项目级别的类有 583 个,其中有 86 个 model , 171 个 view controller , 242 个 view 和至少 7 个 manager ,项目级别的 category 定义了 50 个。在这 583 个类中,有 189 个是框架类。 实例方法总计 3007 个,抛去属性的方法有 615 个是公开的。 342 个类方法中有 162 个是公开的。属性有 2466 个,其中有 950 个是 IBOutlet , 36 个 IBOutletCollection 。 除了以上项目代码,还使用了九种第三方服务,二十种第三方开源组件,并有 28 种自有框架组件。 | 
|  |      20065paula      2015-09-11 15:01:23 +08:00 本来想转发给 iOS 开发小伙伴,直到我看见了“有一定弹性的 996 ”…… | 
|  |      3BB9z OP @0065paula 创业团队加班正常吧。我们这的弹性是这样的, 10 点例会, 10 点前到就行,下班时间自己控制,一般 9 点以后,没有必须要呆够 12 小时的说法。有事群里说一声就行了。 | 
|  |      4nomemo      2015-09-11 15:36:14 +08:00 比较了一下今年 5 月到现的项目一个人也写了 4 万行,文件 490 Storyboard 14 个,平均每个 Storyboard 有 2538 行; 把 storyboard 搞得这么重..维护的成本不小啊 | 
|  |      6zac      2015-09-11 18:13:14 +08:00 996 还是有点,, | 
|  |      7sangmong      2015-09-11 18:16:16 +08:00 170 个 viewController ,这是一个多大的项目啊... | 
|  |      9Tedko      2015-09-11 23:17:21 +08:00 996 就你这工资。。。找不到靠谱的 | 
|  |      10Tedko      2015-09-11 23:18:08 +08:00 你这个维护方法有问题。。。虽然可以但不应该。。 apple 自己都不这么做 | 
|  |      12Tedko      2015-09-11 23:37:42 +08:00 @BB9z 先说工资, 996 ; 12*6=72hr,一般公司是 40hr ,然后一个月工作比例除下……艹了,你给的工资就相当于 1w6 ,麻痹招个屁。而且 3w 的税比 1w6 还要高…… 再说维护方法……首先 Apple 自己在大幅度转到 Swift ,所有 iOS 上的 App 都是纯 swift 了,连键盘也是;刚刚跟 Apple 的人谈过,谈我做的东西的是第一件事(闭源的商业项目)就是问我关于 Swift 的事情,展示了之后也讨论了怎么样更快迁移到 Swift ……然后你们从头到尾没提 Swift ,对于开发效率肯定是没有很好追求。 第二就是拆 Storyboard 的办法。刚下下来你们 app 看了下,拆没错,但是搞成这样一定是最初没有想好大概的结构,拆的乱得不得了了…… 170 个?接口?确定真的要……搞成这样…… | 
|  |      13jesse_luo      2015-09-11 23:52:32 +08:00 | 
|  |      14huanglexus      2015-09-11 23:55:02 +08:00 storyboard 只会随着项目增大而带来无尽的麻烦和效率的降低 | 
|  |      15BB9z OP @Tedko 兄台既在美帝,工作时长这个这边也是无奈。条件好的肯定有,我们也不会靠这个吸引人。 至于 Swift ,去年就考虑转了。之前测试过,因为要附加运行时,包的体积不可接受。而且当时本身语言特性和编辑器都不稳定,不适合迁移。只能等什么时候不用支持 iOS 7 了再考虑。另外,我所追求的第一条是可维护性,开发效率通过重用、工具代码来提高。 Storyboard 的组织其实跟你想象的不一样,主要业务页面的 Storyboard 其实只有 Main 、登录注册、发布流程、打卡和设置这几个,剩下的多是列表展现的 displayer 。 接口这个…… 业务数量摆在那里,瘦身求之不得。 | 
|  |      16BB9z OP @huanglexus 这种观点不能同意。从 iOS 5 开始我和我的团队就开始使用 Storyboard 了,对生产力的提升帮助非常大。第一,有助于提升界面搭建速度与质量;第二,大大降低理解项目的成本,界面、整体流程一看便知,代码也清爽了;第三,便于使用 Auto Layout ;第四,便于复用,对这个很多人可能不解,明明代码才能复用么,这个在这解释不清,但真的能做得很漂亮。 可能大多团队都卡在版本控制这快了,我只能说大部分开发其实是不会合并的吧。在之前的公司,多的时候三个人同时编辑一个 Storyboard ,不需要多 NB 的水平,那时他们的工资不过 6k 。 | 
|  |      17jbeauty      2015-09-13 18:37:36 +08:00 @BB9z Reveal 看了一下....好多 UICollectionView 啊,, 惶恐.... iPhone 5S 上有些卡顿.. 能请教一下,看见你 2014 年 8 月 26 日的推文 “连线强迫症患者有救了~ 有空必须把这堆线理清…… " 很想知道怎么清理呀? | 
|  |      18BB9z OP @jbeauty 对,流的性能非常低。主页流 Cell 里面的布局太复杂, Auto Layout 在复杂布局下的性能很差,以前测试过单个 cell 的光布局的时间就能达到 100ms 。 一直没去优化的原因主要还是没想到一个调整维护起来代价小的方式,像前面几个版本调整就没停过,加之单元里不同元素的显隐组合情况太多了,再不用 Auto Layout 的自适应特性,如果手动去写会很头疼。牺牲掉性能换来的是现在一个 cell 里的工作 20-100 行就能做完,让一个完全没接触过这块的人调整一下结构不用半天就能搞定。产品对这块的优先级定的一直很低,还没到抽出数天来弄这个的阶段…… 确实该想想有没有更好的方案。 连线那个的背景发生在 Xcode 5 升 Xcode 6 阶段, IDE 的变化带来的。对现在来说有帮助的方向可能是这样: Xcode 7 新增了个叫 Storyboard Reference 的特性,这个我们早有类似的实现,可以帮助整理连线。 | 
|  |      19hanangellove      2015-09-14 10:45:30 +08:00 技术招聘贴~~~ |