写在第一个 iOS App 上线前夕。
- 2014-12-12 立项，年前完成。
- 2014-12-15 改为 1.5 完成…… 开始学 Objective-C 。
- 2014-12-22 第一个 iOS App 在设备上运行。
- 2014-12-23 开始学 iOS Programming。
- 2015-01-04 协议栈实现。
- 2015-01-07 首次与硬件通信成功。
- 2015-01-09 App 界面试图抱大腿失败，还得自己写。
- 2015-01-13 基本功能与硬件联调通过。
- 2015-01-17 界面小修小补一翻，又发了个 demo。
- 2015-02-02 遇到个顽强的 bug，不知道怎么修，这个版本先把该功能砍掉……
- 2015-02-04 17号 demo 后收到的需求基本都改好了，测一段时间准备发布～
原本只是安静地做个 C++ 程序员。2014 年 12 月中旬，准确的说是 12 号下午，接到通知说要做一款移动应用，很急。那时，deadline 是年前搞定。15 号，风云突变，deadline 变成 1 月 5 号了，我心想这怎么来得及呢，我连一行 Objective-C 都没写过……能做多少做多少吧。
这里插播一条广告，12 月中旬我花 8 天时间看完了 Objective-C Programming The Big Nerd Ranch Guide, 2nd Edition，并做了其中 95% 的 challenge。不得不说这是一本入门神器，章节编排极为合理，每当我写着写着觉得这里有个问题需要解决，过不了几个 section，顶多到下一个 chapter 就会有答案。后来继续读 iOS Programming The Big Nerd Ranch Guide, 4th Edition ，还没读完，采购的 Macbook Pro 到了，开始编码，不然 5 号什么都拿不出手。
基本了解了 Objective-C 和简单的 MVC 写法之后，开始写后台的通信类。UDP 多么简单粗暴，除了 deepsolo 提到的路由器屏蔽广播包之外，很少有坑。
界面就费劲了，处在这个破天荒的 iOS 开发也要考虑屏幕自适应的奇葩年代，一个初学者面对 4s 和 6p 两块屏幕真是欲哭无泪啊。
一句话总结近一个半月的工作就是，将 20 天的 deadline 强加到两个月的活上，最终收获的只能是延期和不够好的架构。
感谢 GitHub，感谢 StackOverflow，感谢 Dash，没有这些工具、网站，我觉得怎么也得到五月份才能自己造出这么多轮子来达到目前到进度。感谢 Shadowsocks，公司的宽带貌似连不上 GitHub 了，12月还可以的……反正 GitHub 已经做到 No.1 了，按照规矩迟早要封，未雨绸缪也罢。
以下为吐槽时间。
以这段时间的开发为例，最影响进度的因素有哪些？
- 采购流程。15号给了个 1.5 的deadline，采购的 MacBook Pro 是 12.26 领到的。我要是自己没个 Mac 私器公用，都不知道该怎么进行思想实验学 iOS 编程……
- 需求变更。既然时间紧，就做关键功能。半路上把之前定 deadline 的时候砍掉的功能今天加回来一个，明天加回来一个，一点都不好玩。
- 依赖管理。这次是软硬件同步开发。软件的调试依赖于硬件是否已经实现。给同一个 deadline。好嘛，硬件 1.4 实现的话，软件 1.5 如何完成呢？如果硬件 1.5 还未完成的话，软件无法测试又怎么办？
其实最直白地说，曾经很常见的「多快好省」就是个扯淡的口号。功能、时间、费用，顶多选两个。在一定的资源下，想突破一个方面的限制，就必须在另一个方面作出妥协。
另外，堆人手是个边际效用递减的手段。在仅有一个开发人员的时候，增加一个人可能加快速度，但是在 N 人增加到 N+1 的时候，可能增加的沟通成本已经超过了新人的生产率。这里的 N 根据人员水平和管理水平不同而变化，我认为在大部分公司的大部分项目，这个 N 不超过10。只有少数巨型项目能够承受巨大的管理成本，比如用300人管理30人来做个国家级项目？？？
这条我也不知道该说是设计水平不够，还是目标不对：一开始要赶 5 号的 deadline，于是各种简单粗暴的解决方案，先把功能实现了再说其他。但是过程中一边延后 deadline，一边不断加新功能，原先的设计需要不断扩展，反而比一开始就确定要这么多功能来得慢。可是起先定的 deadline 不允许考虑这么多扩展性，这个矛盾如何化解？