@Tairy 那就无法理解了……

贴主这标题误导人了吧，导致上面 60 多楼都在说性能……

被要求的是 PHP 代码发布到生产环境去注释，会不会是团队在安全或产权保护（客户的服务器，不想给产品代码）上考虑的？

另，应该是有工具去除的吧。

对于 UAC 有这么一种说法，微软通过降低用户体验的方式鼓励大家写出少使用系统权限的程序。

UICollectionView 发生操作到访问可能 data source 有一个延迟，这点和 UITableView 不同。

像这样的逻辑，是可能崩溃的。

UICollectionView *cv = ...;
[cv insertItemsAtIndexPaths:...];
[dataSource insertObject:... atIndex:...];

如果不用 reloadData 强制刷新，需要用 performBatchUpdates:completion: 来保护。

路过，注意到 android_frameworks_native 的 53k ，足够诚意了。

用户 ID 一般是够了，但用户产生的数据可能要多两个甚至三个数量级，业务发展好的两三年可能就需要考虑了。

赞。现在比较简陋，但是可以一用，收藏使用方式很需要现在这样的，移动文件方式也理想。

易用性上提点建议，可以把支持的操作列到菜单里并标上快捷键，非高频操作一般是记不住的，现在我截了张热键图放桌面上以便忘了看一眼……

更清晰思路：整个系统里，供货方收益 80 货币，顾客骗到 100 货币，邻居收支平衡，意味着老王赔 180 。

180 ，鞋进价 80 ，给顾客骗走了，再加上赔给邻居的 100 。中间交换过程可以忽略。

试试异常断点 catch 的类型改成只抓 Objective-C 的。

我对这个帖子有 17 个顶表示奇怪，正常的撕逼热贴没见过这么高的。

有两次听出来音乐家跟自己是一个星座的。

赞楼主，找到了点 windows 上用 strokeit 的感觉。

手动帮顶，楼主不易。

把 model 变重一些，多建一些可读性更好的 getter 。

笔记方案一直比较犯愁，我没跨平台需求， Windows 上还是 OneNote 比较靠谱。 Mac 还在试用 MacJournal + OmniGraffle 这种奇葩方案。

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

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

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

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

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

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