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

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

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

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

@Tedko 具体说说看？

这是很正常的，通常来说也是对的。随着积累的增多，折腾付出的成本与之产生的回报越来越不成比例，那还折腾干嘛。

@sangmong 唉，功能特别多，接口就 171 个。

@nomemo 界面多啊。 Storyboard 的维护很容易啊，全用代码写才是噩梦。

@0065paula 创业团队加班正常吧。我们这的弹性是这样的， 10 点例会， 10 点前到就行，下班时间自己控制，一般 9 点以后，没有必须要呆够 12 小时的说法。有事群里说一声就行了。

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

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

除了 MBP ， iPad 、 iPod Touch 齐备，但手机就是坚定的用 Android 。 Mi 2S 没有换的打算，尺寸完美， MIUI 调教后省电省心。

XHei mono

只考虑成本的话， GitHub 一年才 300 美刀，比自己人维护剩多了。

精密的实现可以用 Core Text ，这有个关联的参考： http://stackoverflow.com/questions/21938643/how-to-get-the-rect-of-the-last-character-using-core-text

看到上面的讨论我比较惊讶。

1. 这是公司，怎么能如此随便
2. 这是创业公司，不能有像大公司那样按时完成工作就 ok 的想法，创业是种生活方式，没点自觉可不行

我觉得你们人有点多了……

1. 楼主你了解父亲的情况吗？我看你们很缺乏沟通
2. 钱这么多肯定要慢慢还，当务之急是改善父亲的颓废状态，救急不救穷是对的
3. 我认为解决心理问题是最重要的，建议征询心理咨询师的意见。以下都是猜测：你父亲估计长期缺乏理解支持，他还是做过生意的，曾经应该是上进吧，其中遇到了什么最后一蹶不振的？现在一切都不得而知，你应该去了解他的故事。猜你父亲的病根在屡受打击而得不到他人支持，失去了希望，最后自暴自弃的。多站在他的角度，去试着理解他吧，这是我的建议。

不换行党，理由：大部分编辑器折叠后的样式更好。

可以先 clean 一下试试，不行再重启。

@adjusted 摸摸脑袋，你可以自学的。

@sangmong 没那么脆弱，不怪不怪，感谢告知。

这楼歪的啊……

@sangmong
@nsa
我真的不理解…… 头像的问题是什么？拜谢

@zac
@nsa
向两位兄台确认一下你们认为难的点在哪。太累，待遇低？