标签：
作者迷恋于一个开放代码并可以由游戏玩家更改程序的一个游戏，并为在它的基础上创新和增添一些功能而乐此不疲。我想这大抵是一个程序员开发伊始的兴趣吧。
随着科技行业的兴盛，互联网时间带来了快速发展的技术产生、公司创立、创造财富等也同时带来了程序的缺陷问题。而对软件开发者来说，则过的是时快时慢：如果灵感到了，一切顺利，则全然忘记时间，全心投入高速的开发之中。反之遇到瓶颈，则举步维艰的软件时间。软件不能像建造桥梁那样一劳永逸可以造福上百年。反而漏洞百出，麻烦不断，错误不停。带来无穷尽的改进和苦恼。
而同样在这一章，我认识到的hello world的意义。微博上有个段子，是IT工程师的墓志铭可以写成Goodbye world，无限调侃甚至有些许消极色彩。事实作者对它的诠释完全颠覆了我对编程的看法。尽管它一无所用，却足以蛊惑人心。没错。我想当我意识到这个意思的时候，我也同样产生了“既然能叫它说话，就能让它做任何事！”强烈欲望。
第1章：死定了
这一章与上次读的《人月神话》有异曲同工之处。都是论述人和月的相互制约相互矛盾又相互依赖不可缺失的关系。一个错误就可能让一个项目“死定了”。往往带来不可知因素的时间陷阱。布鲁克斯法则：往已延误的项目中补充人力，只会使其继续延误。最理想的开发组规模式孤军奋战。但是对于庞大且涉及面极广的一个程序来说几乎不可能。从理论上团队开发就是不得不被认可的，何况实践上它几乎必不可少。
开源代码，也是一个矛盾产物，一方面可能对商业上产生消极影响，一方面却在工程师开发和拓展角度有促进作用。从我的角度来说，当然希望代码是开放的，但当一个产业在某方面几乎形成了垄断，它也许没有仁慈的心来共享知识和财富吧。
第2章：Agenda之魂
软件或项目并没有真的“正在”改变世界，但是正是为了改变世界之梦所驱动。
卡普尔自己以及他的莲花公司还有更多开发者对项目的执着与对灾难的坚持。正是某种意义上的开发者的精神。
第3章:原型与Python
把生活的某些方面融入到软件代码中之后，就很容易被各种新奇诱人的可能性所迷惑，看不到自己放弃了什么。软件缺失给生活带来了很大的便利，却也一定程度上剥夺了我们对于物理世界的感知，感性世界的理会。而意识到这个问题或者想改进这个问题的时候，工程量异常庞大。软件的灵活性并不高，这也成为一种很大的阻碍。工具、材料、语言和技术等等随着软件的庞大而越来越不灵活。
接下来就是各种各样的语言的盛行。Python是解释型语言，但是简单易懂的语言，很明显在修改错误和拓展程序上事半功倍。这恰恰说明了，解释型语言这种往往被忽略的“脚本语言”是至关重要的。它的另一个优点是变量类型设定宽松。
Java我们并不陌生，且它的优点--跨平台、面向对象等我们更是耳熟能详。好吧，不得不承认，学好它对于我们来说还是非常重要的。
第4章：乐高王国
从软件抽象层的另一种维度来看，软件开发者常常谈及前台和后台。用户在前台，前台是程序中和用户打交道的部分--显示窗体、对话框和鼠标指示，告诉你正在发生什么，让你有办法输入信息并得到输出信息。后台是前台发生的事件和用户输入流向的地方，计算机对事件和输入进行处理、保存、取回。前台应该精致、直观、功能强大；后台应该隐形、搞笑、如岩石般强固。前台与人对话，后台与比特对话。
乐高假设指未来程序将由可复用的部件组合而成。部件将在全球范围内提供。虽然实际上这种假设不太容易实现，甚至不能实现。做好项目的关键在于复用，而不是重复发明。把前人的成功经验集成进来，少写新代码。软件复用的两难选择：创建还是借用？
这一章主要描述乐高积木式的软件制作方式，如果这一块块积木是程序代码，则很难做到尽善尽美，完全适用且精简的代码。最终这个方式是卡塞尔团队在这方面的一个尝试探索，值得我们钦佩和敬仰。
终日与比特为伍的环境要求程序员们有一颗自闭症患者般的内心。交流很重要，但是软件不是在博客和聊天软件中交流出来的，而是一些人一行行写出来的。 这个过程需要集中注意力，避免打扰。在一个 “集市” 风格， “共享” 的开发氛围中，如何能保证关起门来开发呢？
chandler团队决定预计9月份发布chandler0.2版，遵循时钟驱动制度。事实证明最后的0.2版是一个很烂的版本，但是chandler团队还是发布了，因为承诺的发布时间到了。了解到了后果，团队吸取了教训不再以这种约束条件发布。但这种方式其实有好有坏，好处在于有一个约束的条件，团队自然也就有了目标和效率。而坏处自然就是如果到了预期时间还是没有做出东西，发布的东西自然也就质量不高。
后来，团队开始使用“白板上的即时贴”，这也是王老师教我们使用过的东西，在白板上分区，列出一些正待解决的问题。我认为这种方法有利于项目的发展，当然，不是像chandler团队这种半个小时内问题贴就直逼一百张的那种。萨奇的灵机一动，为团队带来了一角希望，相册blog被面世了，而其中的东西使用了chandler的框架，只使用了大概两个小时的时间。作为一个程序员是需要这种灵机一动的，但灵感的来源一定不是单纯的灵光一线，它一定是因为早已拥有不少的积累，比如调用chandler早已存在的框架。
公开宣告后两年，OSAF在外界看来一直做得不如预期的好，0.4版发布后的下载量就是最好的证明。但OSAF有了工作流程，还有一套可能让他朝目标行进的可行的方法论。卡普尔从一开始就要有计划和进度安排，但进度却总是不能够按预期的进行。这些我也曾在王老师的课上听过，软件实际的时间一定与估计的不同，怎样估计的更加准确就是一个问题了。
总结几点如下：
1.“没有所谓典型的软件项目，”安迪·赫兹菲尔喜欢这样说，“每个项目都有其不同之处”。我们开发软件的时候没有固定的模板，每一个项目的核心都会不同，软件开发就像是造物主创造的生命一样，没有那一条生命是一摸一样的，即使是一个眸子刻出来的也有不同之处。更别说面对客户的各种各样的需求了。
2.那么面对客户五花八门的需求时候，程序员的应对方案就有所不同了，当然每个程序员的能力也不一样，好的程序员懂得写什么，而卓越的程序员知道改写（并复用）什么。
3.软件开发和堆砌乐高积木就完全不一样了，乐高积木式的插件不合适。软件它就像洋葱般层层叠叠，每一层都辛辛苦苦的建立于前一层基础之上，危如累卵，指望着底下那层不要移动或者改变太多。做软件的人喜欢讨论垒砖头；而怀疑论者眼中只看到空中楼阁，无论如何，日积月累，一层一层搭建起来。也正如麦卡斯柯说道：“我们打算尽可能多得复用现有代码，少些新代码，要加快工作进程，就得尽量避免踏入新的编码地带”。
4.软件开发还有一个规律，质量三角不能兼得，即速度、便宜、优质。三者往往只能选其二，就像盖高楼一样，人们总是习惯延期完工，这样就不会被别人怀疑质量问题，反过来，如果一个大楼十天就盖好了，人们肯定会觉得太不可能了，这样的楼房人们也不会住进去，软件开发也是这个样子，有速度就可能不会保证质量，有质量可能就得延误完工，当然这也与程序员有着紧密的关系。
5.软件开发的团队组建也是一个比较的难的事情，因为不同的程序员的生产力相距甚远，常会达到10倍的差距。所以，考虑如何配置项目人员，和预估项目所需的时间一样叫人充满挫败感。团队里还不乏出现“奇客”，如何管理与发挥出奇客的优势也是一个问题。
6.软件开发过程中不能太过于急功近利，不能想着一口吃一个胖子，别指望在短时间内达到大成就，否则会重头再来。
7.开发过程中要注意客户对某些细节东西的需求，尽最大可能让客户满意。
8.开发过程中要注意一些变成习惯，比如参数的命名方法等。
9.软件开发虽然是一个艰难的过程，但是只要坚持，总会有成绩，如果不坚持，什么东西都不会做出来。
标签：
原文地址：http://www.cnblogs.com/feifeishi/p/4594196.html
