4.5

抽出时间来拜读了Scott Rosenberg的”Dreaming in code”(中译名《梦断代码》)，前六章仔细看了一遍，后面几章由于时间紧迫只是浏览了一遍，感悟很多，愿与大家分享。

本书主要回顾了一个开源软件项目——Chandler的失败案例，该项目一开始被寄予厚望，甚至被誉为可以击败Microsoft Outlook的邮件日历项管理利器 ，并且其项目实施人员是软件开发领域的佼佼者，但最终仍不免失败的厄运，这也充分证明了“软件难做”的论断（正如同书中提到的,Knuth曾言“做软件比写书困难得多”），想想前段时间自己做的一个小程序，因为显示器分辨率不同而在不同PC上显示的结果有差异，因而导致用户体验不好的教训，自己对这四字感悟不免“心有戚戚焉”，体现在Chandler这一具体的项目上有以下几点：

       I.          Chandler的设计嵌入了“Agenda之魂”，卡普尔无法忘掉Agenda带给自己的遗憾而想在Chandler中实现Agenda的功能，这是对于一个新的项目来说必须的创新性特点，否则Chandler跟Outlook差异不大，这样一个简单的替代品又有多少可能性挤占Outlook已有的市场？实现这样一个新的feature必然面临着新的挑战，诸如数据存储管理问题，也正是在这些问题上Chandler停滞不前，因此——被用户认可的软件必须有所创新（请自觉忽略Tenc**t），而这些创新的实现会很困难，联想到我们的Team Project，根据用户的输入产生拳皇人物模型，也正好是我们的创新点和难点^_^

     II.          语言的选择？这个问题不是影响项目进度的关键，不过也曾经让卡普尔挠头，多了选择某些情况下也是很痛苦的~

    III.          代码复用——对于是否使用Python组建ZODB的讨论影响了项目的执行。说实话我还是很企盼高效率的源代码组件——对于一个商业软件，在符合制度规定的前提下能用别人提供的组件高效率地实现部分功能，何乐而不为？但实际应用中，别人的组件是基于自己的程序，它很好契合自己程序的可能性很小，大部分情况下是不规则的契合，因此“乐高积木”的简单堆砌模型，对真正的软甲开发不适合——你可以从一个组件中汲取其想法和部分功能，但完全依赖于组件是不现实的。

    IV.          人员管理问题：Geek是个难于与人接触交流的团体——书中一直在灌输这个观念，并且用管理状态管理器和改进标记工具wiki耽误大量开发时间这一事实证明了管理团队的困难。在我看来使用工具来管理开发团队是个好的方式，程序员可以在管理平台上注入自己的进度和问题，但这并不是全部，毕竟工具是冰冷的，而人与人的交流才是最有效的沟通方式。

     V.          复杂的设计方案和文档导致了工程效率的极大下降。

自己只读了前六章，因此总结的也只限于此，无论如何这些都可以作为我们做Team Project的经验教训，让我们能够更高效的合作。虽然“软件难做”，但作为从业者，我们应该有热爱软件行业的心态，尊重软件工程师的劳动，我相信只要向着一个目标默默努力，坚持做下去，最终总会有好结果。在此与诸位共勉。