梦断代码读书笔记2

第4章 乐高王国
这一章主要描述乐高积木式的软件制作方式，如果这一块块积木是程序代码，则很难做到尽善尽美，完全适用且精简的代码。最终这个方式是卡塞尔团队在这方面的一个尝试探索，值得我们钦佩和敬仰。

乐高假设指未来程序将由可复用的部件组合而成。部件将在全球范围内提供。虽然实际上这种假设不太容易实现，甚至不能实现。做好项目的关键在于复用，而不是重复发明。

把前人的成功经验集成进来，少写新代码。软件复用的两难选择：创建还是借用？

可复用软件之梦有一个悖论：几乎总能找到一段满足大部分需要的代码。但这些拿来的代码所不能做到的部分，恰恰是项目与众不同的创新之处----也是创建这个项目的出发点。

模块化和组件化是软件人员的梦想，谁都想把几个模块插到一起就可以完美的运行并完成任务，但现实却相当残酷，可以运行的模块通常不能与自己想写的程序配合工作。程序员们很久前就解决了“小复用”问题，即通过构建子程序库来为自己减负。但一直悬而未决的间题则是“大复用”——创造并使用真正有用的软件大型可复用组件。

书中提到一个叫考克斯的人，他创办了一家叫做Stepstone的公司，致力于向C语言系统搭造者提供插入式芯片级软件组件，最后的结论是：即便采用最新的技术，要想设计和制造既有用又真能复用的组件、为组件写文档以便于客户理解、移植组件到潮水般不断涌现的新硬件平台上、确保最新的改进或发布版本不与现存接口冲突、将组件销售到类似威廉姆斯堡枪械行业那种鼓励从头做起的价值体系，都是极其困难的。

美国西海岸时间2003 年4月21 日下午3:07, 第一个公众版Chandler0.1上载到OSAF 服务器。24 小时内，就被下载15000 次。卡普尔在blog 上写道“我把Chandler0.1叫做‘B超’版本：胎儿只能在母腹中存活，但如果仔细查看，就能看到小小的手臂和腿脚在划动，你会相信最终它将诞生。”

团队讨论后认为Chandler数据模型的核心应该是“条目( item)”。

什么都可以是条目——对用户来说，可能是一封电子邮件、一条随笔记录或者一次约会事件，但它也要体现程序自身的一些机制，例如某”类”条目的定义(“电子邮件”或“随笔记录”或“约会事件”)。

条目采用面向对象方式加以组织，构成一种继承层级结构。如果一组中的每一条目都被定义为某一”类”——例如，都是电子邮件一一则它们将继承“电子邮件类”条目的所有特性。所有条目都应该保存在资料库中。

这种方案让Chandler 具有“以条目为中心”的特点，它还引申出几个要点。其中之一是程序彻底从RDF 的世界中转移出来，回到摩根·萨奇编写第一个资料库时Chandler 的出生地。

在RDF 中，数据存储的基本单位是“属性(attribute)" ; Chandler 条目可以包含许多不同属性（对于一封电子邮件，典型的属性可能是“日期”、“发件人”、“ 主题”、“正文”等等）。

现在，Chandler 团队终于回到有所进展的世界。

第5章 管束奇客和狗
从狗的需要管束引论到程序员需要管束。工程的质量、进度、成本也需要进行策划决策。

质量三角，既好、又快、还便宜，同时满足的事情不太可能发生。

软件经理非常重要，他制定进度、推动程序员按进度工作、决定先干什么后干什么，需要沟通能力、决策能力、市场感知能力、粘合团队能力、程序掌控能力等等。

用代码行数做判断标准只会鼓励程序员写臃肿、蹩脚的代码。

闲逛式管理MBWA(Management by wandering around)：这种严密的方法要求经理们走出办公室，遍访坐在隔间里的下属，和他们谈话。“做得怎样了？”它鼓励人们观察和接触他人。

但在软件领域开发进度是闲逛的管理人员看不到的，因此不能移植到软件领域中。

多数开发者都乐意告诉经理自己的进度，问题是，就目前的软件实践而言，开发者们对于自己的进度也不比经理知道得多。

奇客的2种定义：

以（计算机）程序缺陷为食----不善社交、身有恶臭、面色苍白的偏执狂，具有奶酪刨丝器一般的人格特点。

专注于己事的人；追求技术（特别是专业技术）和梦想、不融入主流社会的人。

群件(Groupware)：即时通信、聊天室、缺陷跟踪、源借故传统的邮件列表等工具，个人感觉要慎用这些工具，否则你的工作时间会被这些工具吃得一干二净。

Wiki在chandler项目中也建立了起来，感觉这个chandler项目用到的工具太多，如果程序员不能合理地安排自己的时间，估计会被这些工具所淹没。

对于程序员来说，确实有一种制造工具的冲动。磨刀不误砍柴功本身没错，但程序员在磨刀的过程中会想弄到一块最好的石头，并花了大把的时间去把刀磨得吹毛断发，却忘了还要砍柴。

第6章 搞掂设计方案
卡普尔认为， 软件设计不仅只是在程序员代码之上覆盖一层诱人的图形。它是一种设想用户需求并在软件结构中满足这些需求的创造性基础工作。

良好设计的原则：

坚固–良好的结构、没有缺陷；适用–程序应符合其设定目标之所需；愉悦–使用程序的体验应令人愉快。设计方案与实际过程没有先后，而是相辅相成，同期发展。

在软件世界中，集成(integration ) 的意思就是把一段运行正常的代码连接到某个程序中另一段运行正常的代码上。

集成往往是软件项目遇到大麻烦的环节。分开来运行相当正常的代码， 在合起来时就闹罢工：不能正确挂接、发送不可解释的消息、或者顽固地拒绝启动或停止。

现今的多数项目都接纳了“持续集成”的观念：程序员不断向主干代码中签入最新的代码，每个人负责确保自己加进去的代码不会导致问题发生。持续集成应该更利于产品的定期发布。

戴维·艾伦是一位生产力教练，其著作《GettingThings Done》一书在程序员人群中近乎圣典。

GTD 的核心原则之一是建议有规律地安排定量时间处理收件箱：

查看胡乱塞进系统的每个比特填料并做出决定，“下一步怎么处理这东西？＂艾伦建议，如果在两分钟之内就能处理好， 马上就开始做。否则， 决定是存档、丢弃、推迟， 或者分类到某个有下一步操作建议的具体项目中。

关于Linux的作者李纳斯托瓦茨的话：

别做大项目。从小项目开始，而且永远不要期望它变大。如果这么想（指做大型软件），就会做过度设计，把它想象行过于重要。更坏的情况是，你可能会被自己想象中的艰难工作所吓倒。所以要从小处起步，着力考虑细节。别去想大图景和好设计。如果项目没解决某些需求，多半就是被过度设计了。

别指望在短时间内达到大成就，我致力于Linux达13年之久，我想后面还得花上好些时间。如果一早就妄想做个大东西，可能现在还没动手呢。

第7章 细节视图
程序员和机器、程序员和程序员、程序员和用户之间往往达不到某种共识。

程序员们对于信息的需求显而易见。他们需要细节。他们需要蓝图。他们需要规格说明（specifications)。

规格说明是程序员的圣经，而且，通常程序员也会是忠诚信徒：规格说明就是法律。

需求搞错的严重后果，18英尺的巨石拱门变成了18英寸的石桩子。

最著名也最声名狼藉的匈牙利命名法：在匈牙利语标记法中，程序员给每个变量名加上前缀， 好让代码阅读者了解变量的类型。

匈牙利命名法可能在用C++写Windows程序的时代是需要，因为各种类型、结构、枚举、控件等等让人眼花缭乱，让人容易出错，而在Java和C#等这种强类型的语言中，这类命名法完全是对程序员审美观的践踏。