温故而知新，人月徒伤悲

左手的ㄟ右手 2021-09-10 13:10 267阅读 0赞

**前言**：“[扒一扒你遇到过最NB的开发项目][NB]”，看到CSDN上举行这个活动，就迫不及待的赶紧点进去看看到底是什么玩意er，一不小心看到了《人月神话》的试读活动，内心有两个声音就悄悄钻了出来：一个有点怨言，一个有点激动。所谓怨言，就是活动姗姗来迟，如果《人月神话》能够早一点让我一睹芳容，而不是在苦苦寻找后相见恨晚该多好；所谓激动，自然是“终于等到你，还好我没错过”（好像词有点跑偏）。

## 温故而知新 ##

其实在CSND举行这个活动之前，我已经认识了《人月神话》，那是在看Jeff的《高效能程序员修炼之道》一书后，强烈的感受到，作为一个程序员，我竟如此的孤陋寡闻，Jeff推荐的必读书籍列表，我一本都没有读过。深深地自责后，我从京东上买下了《人月神话》和《软件方法上册》。对于《人月神话》，我的札记已经写到了“[祸起萧墙][Link 1]”一章，然而当我今天重新再读“焦油坑”、“人月神话”两个章节时，一种素不相识，却又似曾相识的感觉”扑面而来“。

“***我所收集的书中，软件工程书大都属于精品，神品只有两本，Brooks的这本就属于神品之列***”。我对“Dave wang”的代序之言由衷的表示赞成，所谓“书读百遍其义自见”，有幸再次拜读Brooks的书籍，我深感自豪。

## 程序员的苦与乐 ##

我自认为，程序员很“闷骚”，当然我自己就是一个程序员，哈哈。不过我认为闷骚的含义应该是这样的：  
闷，代表我们很单纯，我们通过编程，不断地解决用户的痛点，我们深陷于这种快乐而无法自拔，我们不愿意花费精力在其他方面，唯有编程；骚，代表我们富有活力，一旦有事情激起我们的兴趣，我们为之亢奋，不惜暴露我们的激情。

编程，Brooks称之为焦油坑，这个让我们苦苦挣扎，却又充斥着苦恼，但又充满着快乐的创造性活动。作为程序员，我们爱之深，责之切，我们经常抱怨加班、需求变更、外行的无厘头要求，但是我们享受软件发布后的快乐，我们享受编程过程中的美好时光，我们享受用户使用后的赞美。

那么快乐来自于什么呢？

> 1.  创造事物的纯粹快乐
> 2.  开发对他人有用的东西

而那些苦恼又从何而来呢？

> 1.  追求完美
> 2.  他人设定目标、提供资源
> 3.  项目完工了，她也该香消玉碎了

## 人月徒伤悲 ##

在国内，有这样一群领导：  
\- 他们要求产品应该在一个月、两个月、半年内完成；  
\- 他们认为项目进度一旦拖延，立即增加人手就可以马上解决问题；  
\- 开发能遇到什么问题，产品优良他们并不看重，他们只在乎利益。  
\- ……

显然，我们的领导迷信了人月的“**神话**”，对于这样的神话，Brooks在书中论证了为什么“***Adding manpower to a late software project makes it later***”，也就是说向进度落后的项目中增加人手，只会使进度更加落后。

Brooks举了两种类型的例子：  
1. 无论对于哪一个母亲，孕育一个孩子都需要10个月。  
2. 割麦子的时候，人手多一些，显然麦收会提早完成。

对于软件开发领域的我们来说，人月徒伤悲的原因有哪一些呢？  
\- 开发团队需要沟通，很少有项目是一个人来完成的，即使只有一个开发人员，也免不了和外界沟通，况且孤独的开发者需要被鄙视，闭门造车会让项目更容易失败。  
\- 开发团队的成员能力并不能确保完全同级，如果相互差距比较大的时候，沟通的成本就会越高。所谓木桶理论就是一个证明，决定木桶盛水的容量是由高度最低的那块木板决定。

## 让神话离我们远去 ##

我从一篇人月神话的读者感言中了解到，为了能够主动出击，我们可以做一些改变：  
1. **不再低估每一个产品的难度**，保持警惕而不是“乐观”会让我们更从容。也就是说，在计划每一个任务的时候，尽你所能，保持客观冷静。  
2. **提前多干一些**。进度表上的时间与实际开发中的时间不可能步调一致，那么很多人容易这样想，反正今天的任务已经完成了，就算是有空闲时间，我也不再继续了；更糟糕的是，今天的任务虽然没有解决，但是明天的任务好像挺简单的，今天就结束吧，明天再继续。请抛弃这种可怕的想法吧，尽量提前多干一些！！！  
3. 在领导施压下，请尽力**坚持自己的进度安排**。Brooks也说了：“在顾客的催促下，厨师选择把火加大，不过结果常常是无法挽救的煎蛋—-一面已经焦了，而另一面还是生的”。

## 从华夏三方存管平台对接中总结经验 ##

我们的“期货交易平台”要对接华夏的三方存管平台，任务从今年4月份已经开始了，我曾经这样和客户讲：“如果一切顺利的话，我只需要一天半的时间就能对接完”。现在回想起来，我自己都情不自禁的笑了，我是有多欠！时至今日，两个月就要过去了，正式环境上的接口对接还迟迟没有疏通完成。

首先，**乐观主义害死人**。说乐观都有点牵强人意，我当时完全是一种盲目自大，当然我还给自己留了一点点余地，“如果一切顺利的话”。但是，现在回想起来，正应了Brooks那句话“他们所犯的第一个错误是假设一切都会进行得很顺利”

其次，“**编程人员很少能控制工作环境和工作目标**”，这两个月的工作让我深有体会，依赖别人，太过痛苦。

在对接华夏接口的两个月内，先是CFCA的keystore断断续续阻碍了三个星期的时间；

再者是华夏银行的阻力：  
1. 现在都2015年了，华夏提供的接口文档竟然是2011年做成的，最后我们要了一份2014年改版的。  
2. 华夏提供的jar包有严重bug，他们的getter、setter方法有的是大写，有的是小写，导致转换json字符串时出现问题，最后只能是采用迂回战术解决。  
3. 分行的对接人员垃圾的一塌糊涂，你还必须强颜欢笑，他们对业务的熟练程度还不如我。  
4. 总行的一些人员推脱责任，早上说下午就可以了，下午说明天就可以了，尼玛明天是星期六，他们不上班！  
5. 华夏内部的审核机制有太多NM，这个就不能太多透漏了。

再者，**轻视测试**。在完成代码编写后，没有代码评审、没有单元测试、系统测试也不够全面，这就会滋生很多显而易见的bug，不过值得庆幸的是，我在正式上线前解决了这些问题。

## 完美与放弃 ##

我个人在生活和工作中都有点追求完美，这一点在工作中表现的尤为突出：  
我受够了那些垃圾代码，从2014年2月接收项目，到如今，我对代码进行了不计其数的重构，举个例子，我们使用的一个web管理系统最开始打完war包足足有48M，而现在只有17M，当然这还有点多。

而对于一些功能，我会选择放弃，尤其是对于客户那些”无理取闹“的需求，我会通过各种手段让他放弃自己的想法。

Brooks说了：”实际上，我认为，学习编程最困难的部分，是将做事的方式向追求完美的方向调整“，好吧，看到这点，我有点沾沾自喜了。

**总结**：《人员神话》不愧是一本”神品“，前两个章节，我已经读了不下十遍了，但每次都完，都觉得如沐春风，哈哈！最后，来看看文言版的”人月神话“：

> 问：今有程序员五人，需时日几何？  
> 答曰：一年。  
> 问：吾急需之！若有十人，几何？  
> 答曰：两年。  
> 问：百人若何？  
> 答：万世。

[NB]: http://blog.csdn.net/blogdevteam/article/details/45846519
[Link 1]: http://blog.csdn.net/qing_gee/article/details/45934271