人月(1)

经典著作这么晚才看，但经过了曲折看起来才更有感悟吧。

关于“人月”这两个字，以前总以为是月亮的月，可能是更容易跟神话发生关系吧。其实英文是MAN-MONTH，这才顿悟。

 

两个1:3和1个1:9还是非常深刻的。

 

产业化团队的1000代码行/年的生产率。具体的成熟软件公司的数字在网上也可找。对于大型项目来说，这个数字是比较真实的。对于小项目来说，敏捷的方法显然可以大大提高代码的生产效率。

 

编程为什么有趣？作为回报，它的从业者期望得到什么样的快乐？

1. 首先是一种创建事物的纯粹快乐。
2. 其次，快乐来自于开发对其他人有用的东西。
3. 第三是整个过程体现出魔术般的力量——将相互啮合的零部件组装在一起，看到它们精妙地运行，得到预先所希望的结果。
4. 第四是学习的乐趣，来自于这项工作的非重复特性。
5. 最后，乐趣还来自于工作在如此易于驾驭的介质上。

这些东西看着挺虚的，都不好意思跟家人同事说我是纯粹的喜欢干这个。但这实实在在是每个程序员都应该先想清楚的。或许我还有一个想法，在这个行业里，避免了人与人之间的纷争。嗨嗨，又要被老婆骂没出息了。 

 

 

职业的苦恼

1. 首先，必须追求完美。实际上，我认为学习编程的最困难部分，是将做事的方式往追求完美的方向调整。 实际上，追求完美也是不完全正确的。应该是最满足要求的，即是产出与成本的一个最优关系。产出包括产品、产品质量，成本包括人力成本、产品成本等。这才是软件工程真正要解决的东西。一味追求完美显然是不切实际的。
2. 其次，是由他人来设定目标，供给资源，提供信息。编程人员很少能控制工作环境和工作目标。用管理的术语来说，个人的权威和他所承担的责任是不相配的。不过，似乎在所有的领域中，对要完成的工作，很少能提供与责任相一致的正式权威。而现实情况中，实际（相对于正式）的权威来自于每次任务的完成。 呵呵，也许这就是为什么大家都愿意做领导吧。当我开始管理小团队时，我就感觉到心情确实愉悦很多，天天不用受制于别人的想法了。这反映出我的工作有几个问题需要注意：第一，我在讨论工作的时候没有坚持原则，正确的情况是，对的想法一定要坚持，不能轻易妥协；第二，管理人员应该注意让每个员工的想法能够得到充分的表达与尊重；第三，管理人员的决定应该力争得到团队中每个人的认可。
3. 对于系统编程人员而言，对其他人的依赖是一件非常痛苦的事情。他依靠其他人的程序，而往往这些程序设计得并不合理，实现拙劣，发布不完整（没有源代码或测试用例），或者文档记录得很糟。所以，系统编程人员不得不花费时间去研究和修改，而它们在理想情况下本应该是可靠完整的。 这里提到了发布不完整，一定要注意劳动结果的保存。在我的团队的执行过程中，开发人员的自测用例和测试程序往往都丢掉了，其实在有问题的时候拿出来看看以前的记录，可以大大加快发现问题的速度。另外，通过检查以前的用例，能快速找到漏测的地方。总之，好处多多啊。
4. 下一个烦恼——概念性设计是有趣的，但寻找琐碎的bug却只是一项重复性的活动。伴随着创造性活动的，往往是枯燥沉闷的时间和艰苦的劳动。程序编制工作也不例外。
5. 另外，人们发现调试和查错往往是线性收敛的，或者更糟糕的是，具有二次方的复杂度。结果，测试一拖再拖，寻找最后一个错误比第一个错误将花费更多的时间。
6. 最后一个苦恼，有时也是一种无奈——当投入了大量辛苦的劳动，产品在即将完成或者终于完成的时候，却已显得陈旧过时。可能是同事和竞争对手已在追逐新的、更好的构思；也许替代方案不仅仅是在构思，而且已经在安排了。