梦断代码2

　　当我继续读下去的时候，深深的感触到程序员的不容易，经理的不容易，通过作者对自己工作和身边一些人的描述，我是真实的感受到了作为一个程序员的辛苦之处，尤其是作者当时作为一个经理人的辛苦。每次当他有想设计的的方案时，都要仔细的掂量，因为这就是他的决策，他必须要为自己的团队负责。我记得有人说过这样的一件事情，原话记不清了，那就是：当你成为一个项目经理的时候，你拿着比别人多的薪水，这是无可厚非的，因为你是这个项目的决策者。但是，当一个项目出现问题的时候，你应该怎么做？一个好的项目负责人是要承担责任的，因为出错的话就是你的决策失误，你要为此承担责任，因此，这个时候，你必须要离职。这是一个对很多人来说很艰难的决定。所以，作者也说了，要仔细的掂量自己设计。对于我们这些小菜即来说也是一样的，我们需要的就是处理这些问题，并且要为这些事情的到来做准备，虽然为时尚早，但是“早起的鸟儿有虫吃”，这谁都知道。

　　《梦断代码》书中讨论了“软件时间”这一概念，布鲁克斯在书中提出了一个十分著名的观点，“往以延误的项目中补充人力，只会使其继续厌恶”，经过了无数年间的实践，这一观点都成了程序猿和开发经理的梦魇。布鲁克斯指出了其中要害，”只有在任务能分派给许多相互之间无须沟通的工作者时，人和月才是可互换品。“制作软件的大量工作受困与”序列约束“”，它限制的任务分解的程度：完成某项任务是处理其他任务的先决条件，这与人力投入多少无关。

　　“在对软件系统的加速依赖和踱步学习怎么做好软件之间，有一条巨大的叫人恐惧的壕沟，梦之所寄，行之所为，地狱之们就此洞开”，也许真的和作者说的一样，软件就是麻烦一堆，做软件和寻宝差不多，需要人手指点，在开工之前，要找到线索，但是却不知道花多久才能找到。一个处理bug的故事，其实在现实中也有体会，有时候写代码容易，改代码难，这不是4个小时或是8个小时的问题，想到就是想到了，没想到就改不出来了，就像人月神话中，工作量怎么可以是累加时间就可以解决的呢？几个月后bug终于解决了。可能就像安德森说的：“你一早醒来，脑中灵光一闪，于是手到擒来——大抵如此。”或许做梦是真的有用的呢。对于开发模式，大教堂的模式可以说是传统的开发模式，而集市模式被很多开源项目采用,比如Apache Web服务器,Linux。咱们一般开发自然用的是大教堂模式了。

　　失败，其实是一个很平常德问题，谁的成功没有失败过，今天看来，NLS不断闪烁的单色屏幕和粗糙模糊的字体已经是老古董，但其功能和设计确实树立了协同软件的标杆，现代系统克服重重困难才得以企及。所以，如果你正在做的项目失败了，别太气馁，你不是第一个，也不是最后一个。

　　项目语言的选择其实并不是很关键，但是还是使用自己熟悉的语言比较好，现在我们学过C++也帮其他专业的同学做过C语言作业，此外，我们也用JAVA编程，其实语言的差异并不是很大，大致的道理都是相同的，曾经有一次写代码总是报错，为什么呢？因为在eclipse里混用了C语言的输入输出却不自知，也检查不出俩错，可笑的是同学也看不出来，就像是就像是邓超经常说的那句“what are you 弄啥嘞”，呵呵呵。现在写小程序习惯了用C++写界面用qt，每个语言都有自己不同的特性，所以项目组有机会选择语言的话，最好还是考虑一下开发人员对哪种语言最熟练。

　　做一个项目有时间限制自然是极好的，用时间驱动版本发布是一种比较有效的方式，它让开发人员有一个奋斗的目标，尽快完善自己的开发模块。就像我们的软件工程课留的大作业，真的是在挤时间逼着自己去做的，如果王老师没有给我们时间约束的话，估计我们的项目就放到长毛了。

　　把自己应该做的事情列举出来，然后安排什么事情先做，什么事情后做，这样的生活有规律而又清晰，不会一头糟。做程序也是如此的啊，将需要做的项目分成几个板块由量力的人来认领，分工清晰，这样真的很好。

　　开发的软件会出现问题吗？当然会出现，可是会出现什么 问题呢？谁也不知道，每个软件在发布之前都是经过多次测试的，可是谁又能保证测试就能万无一失呢，可能问题连测试员都没有发现呢，这就是吃狗食了吧。编程这种创造性的工作感觉就像是将一个个文字通过语言巧妙地结合，结合不好就得改，语法用错了还得改，但是他终归不是不是我们能够轻而易举级就能读懂的语言，所以注释当然是必要的，省得那天你看到自己以前写的代码都不认识了，现在自己就是这么一个状态，以前写的代码需要花费好久才看得懂，所以一定一定一定要写注释，这对于自己还是他人看自己的代码都是有很大的帮助的，不对，是极大的帮助。