《Creative Selection》主要讲了 Ken Kocienda 在 Apple 工作期间，开发几个软件项目的经历。从这本书中，可以看出 Apple 在软件开发、设计方面的独特流程。在这个十一假期，我读完了这本书。
iPad 虚拟键盘的设计
书中首先介绍了作者开发 iPad 虚拟键盘的经历。与 iPhone 不同，由于 iPad 拥有更大的屏幕尺寸，用户在虚拟键盘上输入文字的方式，也和 iPhone 上有着不少不同之处。这时候，键盘上是应该尽量还原真实键盘的布局，拥有更多按键（TAB、Shift、Command、数字键等），还是应该去掉一些按键，让每个按键的尺寸保持一致？作者和其他人有着不同的看法。
这时候，作者就引出了 Apple 软件开发中的一个独特流程：demo。大家将自己设计的键盘，制作成可以实际运行、能够演示的软件，然后让 Steve Jobs 等人操作。通过这种实际体验的方式，选择出更合适的设计。
Safari 浏览器的开发
接下来，书中介绍了 Safari 浏览器的开发。对于浏览器的开发，用到了另外一种形式的 demo 流程：
早期的 Mac OS X 没有自己的 Web 浏览器，而是使用了微软的 IE。Apple 需要自己的浏览器，而当时开源软件的概念正比较热门，所以他们也决定基于开源浏览器进行开发。首先，也需要开发出一个 demo 版本……
作者打算移植 Mozilla 浏览器的代码，使其在 Mac OS X 上可用。由于底层 API 不同，移植的过程并不顺利，移植了几个星期，也没法使浏览器正常运行。而新员工移植的 Konqueror 代码，只需要两天，就能够正常运行了。
为什么两个人开发浏览器的 demo 版本，花费的时间有这么大的差异？除了 Konqueror 的代码更简单之外，最主要的是，新员工通过开发一个兼容层，来实现 Linux/KDE API 和 Mac OS X API 之间的翻译。从而无需大量修改代码，就可以让 Konqueror 在 Mac OS X 上运行。
虽然通过兼容层的方式运行 Konqueror，由于多了 API 翻译的步骤，软件运行效率并没有那么高，而且软件界面也无法符合 Apple 的设计规范。但是在开发 Safari 的初期，首要任务是让浏览器能够运行起来，所以新员工开发 demo 版本的方式，是更加合理的。这也让我感受到，有时候转变一下思维方式，对提高软件开发效率会有更大的提升。
当然，开发完 Demo 版本后，后续的过程，就比较无聊，但也是必须的，例如反复编译消除编译告警、code review 等等……
书中还有一点值得关注，在开发 Safari 的过程中，整个团队有一个明确的目标：让浏览器的运行速度尽可能的快。所以团队开发了一个运行速度检测工具，能够直观检测出代码优化后，速度能够提高多少。另外，每次添加新功能，编译之后，都要运行一个这个工具，保证新功能不拖慢浏览器速度。
如何打造「智能」的 iPhone 键盘
在 iPhone 发布之前，Blackberry 手机的实体键盘，被认为是一种高效的输入方式。在 iPhone 这样的小触摸屏上打造一款好用的输入法，对当时的大家来说是一个挑战。
起初大家设计是 QWERTY 全键盘，每个字母的按键太小，很容易误触，几乎无法使用。接下来，又有不同人提出了几种大按键的方案，每个按键包含多个字母，通过点触和滑动等方式进行输入。但是，这种方式不够直观，入门成本较高……
而作者将自己的思考方向又回到 QWERTY 键盘上，但将多个按键连在一起。同时在输入法中内置单词表，通过在单词表查找的方式，匹配到正确的单词。这样以来，误触概率大大降低。
所以，在作者演示完自己的键盘后，就被安排做为 iPhone 键盘开发的负责人。接下经过不停的修改，iPhone 的键盘逐渐完善，最终成为了我们看到的样子。当然，这也是建立在一次又一次的 demo 上的。
另外，作者还提到了有意思的一点。在设计 iPhone 主屏幕图标大小的时候，大家都难以确定图标到底应该有多大。这时候，一位同事通过设计一个小游戏，在屏幕上不同位置上随机出现不同大小的方块，通过统计正确点击方块的概率，来确定最合适的图标尺寸。
总结
通过这本书，我可以感受不同公司、不同团队的软件开发方式、以及团队内的氛围，其实是有着很大的区别的，例如 Google 常用的 A/B test，和 Apple 的 demo，分别代表了两种不同的思路。书中关于开发、设计流程的描述，整体上比较有趣，是值得一读的。
唯一的不足之处，是每一章的后半部分，都要花费不少篇幅，刻意总结出一些「大道理」……