《梦断代码》书中讨论了“软件时间”这一概念，布鲁克斯在书中提出了一个十分著名的观点，“往以延误的项目中补充人力，只会使其继续厌恶”，经过了无数年间的实践，这一观点都成了程序猿和开发经理的梦魇。布鲁克斯指出了其中要害，”只有在任务能分派给许多相互之间无须沟通的工作者时，人和月才是可互换品。“制作软件的大量工作受困与”序列约束“”，它限制的任务分解的程度：完成某项任务是处理其他任务的先决条件，这与人力投入多少无关。
“在对软件系统的加速依赖和踱步学习怎么做好软件之间，有一条巨大的叫人恐惧的壕沟，梦之所寄，行之所为，地狱之们就此洞开”，也许真的和作者说的一样，软件就是麻烦一堆，做软件和寻宝差不多，需要人手指点，在开工之前，要找到线索，但是却不知道花多久才能找到
一个处理bug的故事，其实在现实中也有体会，有时候写代码容易，改代码难，这不是4个小时或是8个小时的问题，想到就是想到了，没想到就改不出来了，就像人月神话中，工作量怎么可以是累加时间就可以解决的呢？几个月后bug终于解决了。可能就像安德森说的：“你一早醒来，脑中灵光一闪，于是手到擒来——大抵如此。”或许做梦是真的有用的呢。对于开发模式，大教堂的模式可以说是传统的开发模式，而集市模式被很多开源项目采用,比如Apache Web服务器,Linux。咱们一般开发自然用的是大教堂模式了。
失败，其实是一个很平常德问题，谁的成功没有失败过，今天看来，NLS不断闪烁的单色屏幕和粗糙模糊的字体已经是老古董，但其功能和设计确实树立了协同软件的标杆，现代系统克服重重困难才得以企及。所以，如果你正在做的项目失败了，别太气馁，你不是第一个，也不是最后一个。
项目语言的选择其实并不是很关键，但是还是使用自己熟悉的语言比较好，现在我们学过C++也帮其他专业的同学做过C语言作业，此外，我们也用JAVA编程，其实语言的差异并不是很大，大致的道理都是相同的，曾经有一次写代码总是报错，为什么呢？因为在eclipse里混用了C语言的输入输出却不自知，也检查不出俩错，可笑的是同学也看不出来，就像是就像是邓超经常说的那句“what are you 弄啥嘞”，呵呵呵。现在写小程序习惯了用C++写界面用qt，每个语言都有自己不同的特性，所以项目组有机会选择语言的话，最好还是考虑一下开发人员对哪种语言最熟练。
做一个项目有时间限制自然是极好的，用时间驱动版本发布是一种比较有效的方式，它让开发人员有一个奋斗的目标，尽快完善自己的开发模块。就像我们的软件工程课留的大作业，真的是在挤时间逼着自己去做的，如果王老师没有给我们时间约束的话，估计我们的项目就放到长毛了。
把自己应该做的事情列举出来，然后安排什么事情先做，什么事情后做，这样的生活有规律而又清晰，不会一头糟。做程序也是如此的啊，将需要做的项目分成几个板块由量力的人来认领，分工清晰，这样真的很好。
开发的软件会出现问题吗？当然会出现，可是会出现什么 问题呢？谁也不知道，每个软件在发布之前都是经过多次测试的，可是谁又能保证测试就能万无一失呢，可能问题连测试员都没有发现呢，这就是吃狗食了吧。
编程这种创造性的工作感觉就像是将一个个文字通过语言巧妙地结合，结合不好就得改，语法用错了还得改，但是他终归不是不是我们能够轻而易举级就能读懂的语言，所以注释当然是必要的，省得那天你看到自己以前写的代码都不认识了这可就糗大了。
关于程序员的考核到底什么才是一个标准呢？编写代码的行数？那就大错特错了，其实我觉得重要的是思路，就像一个简单的查找帖子中的水王，我们可以一遍遍的查然后计数在做比较，谁都做得到，可是怎样实现才能让我们编写的代码少而且软件运行的又快呢，同学的思路真是一语惊醒梦中人。
程序员的梦和实际有着巨大的鸿沟。
————————————————
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
原文链接：https://blog.csdn.net/qq_42672770/article/details/111713024