[北京] Feel App 30k+ 诚邀 iOS 开发工程师加入

开始之前啰嗦几句。百天前发过一个帖子，那时大家还挤在一间小屋子里，都忙于手头的工作也没人弄什么福利。现在，我们能提供好得多条件，期待你能加入我们一起创造。（平时低调惯了，这次试着高调一点吧）

------

我们是 Feel App ，我们在寻找 iOS 开发伙伴。 Feel 是一款运动社交 App ，通过社区附带工具的模式，丰富与促进用户的运动生活。

![Feel App](

)

应用链接 https://itunes.apple.com/cn/app/id915390036

整个团队现在有二十多人， iOS 两个，融资处于 A+ 阶段。团队比较务实，跟侧边栏中的其他招聘相比，可能我们看上去没那么酷（没有人去拍那么好看的照片），但是，我们的产品不会逊于其中任何一个。我们要做最好的 App ，因为离我们的目标还有很大的距离，所以我们迫切需要你！

薪资外其他福利
-----

* 自助午餐
* 各种饮料、零食、酸奶、水果
* 咖啡机、微波炉、冰箱等设备可用
* 好几个可以追的单身美女算么……

上面的都是已经落实的，年末据说会安排体检，像这种没落实就不提了。 7 月份团队组织大家泰国游玩了近一周，以后类似的活动还会有，平时的团建更不必说。小团队，有需求提就是了，现在也有服务部门去落实了。

希望你
----

* 对代码质量有追求，但不苛求
* 工作上自觉、主动，小团队——你就是主人
* 有一定品味，创造美好事物要有颗美好的心，我们相信美是由内向外的

其他
----

工作地点：朝阳区曙光西里时间国际 A 座 2703 室
工作时间：有一定弹性的 996

简历投递依旧是 bb9z@me.com ，觉得合适尽情砸过来吧

期待你的回应 :)

BB9z

2015-09-11 13:10:44 +08:00

技术人可能还是对技术更感兴趣，贴点有意思的：

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 种自有框架组件。

Tedko

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 个？接口？确定真的要……搞成这样……

BB9z

2015-09-12 00:14:37 +08:00

@Tedko 兄台既在美帝，工作时长这个这边也是无奈。条件好的肯定有，我们也不会靠这个吸引人。

至于 Swift ，去年就考虑转了。之前测试过，因为要附加运行时，包的体积不可接受。而且当时本身语言特性和编辑器都不稳定，不适合迁移。只能等什么时候不用支持 iOS 7 了再考虑。另外，我所追求的第一条是可维护性，开发效率通过重用、工具代码来提高。

Storyboard 的组织其实跟你想象的不一样，主要业务页面的 Storyboard 其实只有 Main 、登录注册、发布流程、打卡和设置这几个，剩下的多是列表展现的 displayer 。

接口这个…… 业务数量摆在那里，瘦身求之不得。

BB9z

2015-09-12 00:36:40 +08:00

@huanglexus 这种观点不能同意。从 iOS 5 开始我和我的团队就开始使用 Storyboard 了，对生产力的提升帮助非常大。第一，有助于提升界面搭建速度与质量；第二，大大降低理解项目的成本，界面、整体流程一看便知，代码也清爽了；第三，便于使用 Auto Layout ；第四，便于复用，对这个很多人可能不解，明明代码才能复用么，这个在这解释不清，但真的能做得很漂亮。

可能大多团队都卡在版本控制这快了，我只能说大部分开发其实是不会合并的吧。在之前的公司，多的时候三个人同时编辑一个 Storyboard ，不需要多 NB 的水平，那时他们的工资不过 6k 。

BB9z

2015-09-13 23:09:33 +08:00

@jbeauty 对，流的性能非常低。主页流 Cell 里面的布局太复杂， Auto Layout 在复杂布局下的性能很差，以前测试过单个 cell 的光布局的时间就能达到 100ms 。

一直没去优化的原因主要还是没想到一个调整维护起来代价小的方式，像前面几个版本调整就没停过，加之单元里不同元素的显隐组合情况太多了，再不用 Auto Layout 的自适应特性，如果手动去写会很头疼。牺牲掉性能换来的是现在一个 cell 里的工作 20-100 行就能做完，让一个完全没接触过这块的人调整一下结构不用半天就能搞定。产品对这块的优先级定的一直很低，还没到抽出数天来弄这个的阶段……

确实该想想有没有更好的方案。

连线那个的背景发生在 Xcode 5 升 Xcode 6 阶段， IDE 的变化带来的。对现在来说有帮助的方向可能是这样： Xcode 7 新增了个叫 Storyboard Reference 的特性，这个我们早有类似的实现，可以帮助整理连线。