加班的“嫦娥”

我们的探月卫星“嫦娥”已经上天了，对于其先进性的质疑，以及和日本早些时候发射的探月卫星的比较，都成了热门话题。以上暂且不表，只说说从“嫦娥”项目背后一则新闻产生的一些臆想。

这篇新闻是关于70后的航天员工在这次的项目中的贡献的事迹，文中多见“连续十几日”、“十几小时的加班”之词，“嫦娥”诞生过程的热火朝天跃然纸上，但是，“事物都有两面性”，从普通的软件项目角度看，这样的开发过程仍然值得商榷。

加班对于整个社会来说，是相对的工作机会的损失。换句话说：正因为一个人加班工作，另外一个人才之所以失去了工作机会。

对于软件项目来说，加班的原因无外乎几种：需求发生变化，时间计划和实际人力安排不合理，人力估算出现偏差等等。项目需求变化，对于“嫦娥”这般的重大项目，如果存在，很难说不是前期预研和审阅的问题：不想新闻中真的出现因为“任务总体更改”而重新编写程序的事情，而这个需求变化，竟然发生在这个软件开发了14个月之后！

时间计划和人力的估算安排，新闻中看不出明显的问题，只是希望在项目计划中考虑到“准妈妈”或者“新郎官”，安排相应的备份人员，以免出现“因劳累过度晕倒在机台上”，却“刚从病床上苏醒过来，就回到岗位上，一手打着吊瓶一手敲击键盘，最终完成自己的工作”的事情。

现代的软件开发，提出过很多种方法来保证项目的顺利进行，比如RUP、“敏捷开发”（包括”双人开发“、“每日构建”等具体方法）等等，甚至包括一些软件开发流程的认证，如CMM、CMMI等，都是力图维持项目的需求设计开发的有序运作，没有任何一种方法是鼓励加班的。毕竟，很多时候，“一鼓作气”可以做成很多事情，却不是理性的工作态度。这种聚焦全国人民目光的项目，还是从科学的角度出发，合理安排，制定计划来的妥当。

疾书之余，却闻奥运门票销售系统出现故障，不知道是不是“再而竭，三而衰”碰巧出现了……

C++

使用C++开发做了几年，并且自己业余时间开发了一个完整的Posix的SIP服务器架构，因此，期间体会若干，记录之以此分享。之前，仔细看一遍《设计模式》的书是很有必要的，这是指导如何设计的基础。
其一，抽象出所需要设计功能的最简单的流程，就是需要从最基本的角度去看待业务的功能，进行基本类的设计。譬如：通信的功能，通常就是把消息从一个地方发到另外一个地方，基于此设计最基本的类，然后根据具体的业务功能需要，再进行子类的设计，通过不断的细化来完成业务功能。不要指望可以一步到位的设计好所有的结构，因为，事物是不断发展的，业务也是如此，因此，在明显看到需求的地方进行子类的设计，在尚不清楚的地方可以用函数，或者其他的方法解决问题。以后，再对需要持续改进，久而久之，程序的框架就会显得清晰和有条理。在此过程中，根据需要使用虚拟继承。
其二，不要过分追求技巧，好的程序的判别标准是别人给的，因此，让别人能看懂程序如何实现是至关重要的。如果用指针之类去提高效率，可是几个星期之后，别人阅读时不知所云，则显得得不偿失了。毕竟，硬件是在不断发展的，提高效率，优化程序，还是交给硬件和编译器优化器去做吧，在这一点上，JAVA无疑是非常成功的。因此，我还想和负责面试的同事说说，不要用那些指针，括号去为难人，考察应聘者对于程序的设计能力显得更重要，你总不想在同事离职之后接手他程序时什么都看不懂吧。
其三，如果你学习C++原理，但是实在搞不清楚虚拟表怎么实现，那就不要去管他了。没有读过JAVA的GC代码的人难道就不能做一个好的JAVA程序员了吗？务实的学习如何把程序写的简洁清晰，培养良好的开发习惯，如要不知疲倦的写测试用例，并且“画蛇添足”的多写注释，对于开发真正为我们生活服务的产品来说，显得更加重要。