快速上手 Objective-C
喜欢折腾 Swift

看门人的称呼，个人觉得词性来说无所谓好坏。

不是什么“尊者”级别的称呼。

刚才说得不对，应该说“很多时候，预见风险是门槛很低的事情，尤其是比你外行太多的人做业务决策的时候”。

“预见风险”不同场合难度不一样。

一般这种情况，如果你觉得公司还不错，在可预见风险的情况下，应该做一个预防方案。

预见风险是一个门槛很低的事情，但是绕过风险才是真正的挑战。

而楼主这种情况可是锻炼沟通和业务能力能力，另外提升公司地位的好机会，只会“让你不听我的”就是在浪费了。

@luckyzhe 翻译辛苦了

最近面试的几个帖子，我都觉得用人方没什么问题。

五个月不到的经验，问你这类，我觉得还可以吧。社招遇到愿意培养自己的公司也算是运气，大家还是希望社招能直接上手是最好的。人之常情而已。

另外，工作这种东西得两情相悦比较好。一个月其实很短，短期提升水平很难的。

只能说，还在校招的范围内真好啊。虽然不喜欢阿里，但是我觉得这回阿里的做法没什么太大问题。

楼主项目有几点个人的建议：

1.引用 CocoaPods 来进行三方库管理。

2.代码风格统一，另外注意一些词的大小写。

3.虽然整体结构比较简单，但是所有文件可以分门别类的分在不同文件夹里。

其实吧，我觉得每年 v2ex 上都有这种主题帖子的重复的出现，已经说明了，对于校招，名校文凭真的很重要。

社招考量的是过往履历，学校文凭会是其中一环，虽不是全部，但也是一部分。

将心比心，你的公司预算充足，你负责招人，如果同时两份简历，不相伯仲，一个985计算机科班毕业，一个没什么名气的学校非计算机专业毕业。如果只能留一份简历，留谁的。

楼主真是深知如何在v2ex上炒作。

上次是“精通”这次是“H5”。

木板就是不知道湿度和温度对于木板的形变影响有多大就是了。

@oa414 我知识觉得它这里边的示例代码提取出来，会发现有好多种风格（也就是原文并没有真正的按照自己所说的代码风格的规范去写代码），你干脆帮他集中改了好了。

Swift 的出现，使得原本使用 Objective-C 的一些 iOS 开发教程改用 Swift 进行教学，这个其实权重应该不小。

译文再加上小广告，这是硬广吧？

“如果你忽略了与旧的手机版本进行兼容，那么你将会失去数以百万计的用户。”说得好像支持了旧版本就能获得这几百万用户一样。

贵司的用户估计定位都是开发能力不怎么富余的团队，做好只支持安卓或者只支持 iOS 的少数新版本，就已经很难得了。

Cyclomatic complexity 应该可以用维基百科上的翻译。

in-line 可以翻译成“一致”。

“interface 文件”对应了“实现文件”，有点怪。

Literals 翻译成“字面值”有问题的，翻译成“写法”“语法”都要好，另外对于那段不推荐 mutableCopy 的写法的意见以及原因持保留态度。

建议统一“app”、“crash”以及“objective-c"这几个词的大小写。

如果你要改代码的风格，先把他的此前作为范例的代码风格参照“Beautifying the code”这一节整理一下。

“也应该用冒号对其方法”应该打错字了“也应该用冒号对齐方法”。

“blocks”有些时候原文中其他部分翻译了之后，就没必要在译文里继续用复数形式了。

block那里的“Case 1”、“Case 2”、“Case 3”翻译过来成“1.”、“2.”、“3.”，有点怪，排版也出问题。

“这回让优化性能变得困难”应该是“这会让优化性能变得困难”

另外用“Notifications”做 Notification 常量结尾不认同，估计是写错了，应该没有复数的。

只能说翻译辛苦了。

弱弱的觉得原作在不统一代码前提条件下，还达不到“禅”的地步，只是把一些博客和 SO 上的问题混合了下。

原文有些代码格式不对，比如懒加载那里，另外存在不少代码风格不统一。

有些看法个人不认可。

另外“属性定义”的 @implementation 部分是不是写错了？