软件开发流程杂谈：想起PM的点滴(1)

    简单谈谈软件开发流程和PM（项目管理）中几个一般性的再细化原则。软件开发流程在IT界已经透明化，上至项目经理，下至一般码农，谁都能说出个子丑寅卯来。这里也唠叨一下个人对于软件开发流程的一些认识和实践。
 
1.  前松后紧原则——重视需求
    做事情有时候真的要看好方向。方向错了，会严重影响项目进度和投入产出比，你努力工作的成果也许几乎无用，这也是很多项目失败的根本原因之一。所以，负责任的项目经理们总是小心翼翼地反复评审着需求文档和设计文档，因为这是项目或产品成型的前提，是开发的最原始驱动力。从项目时间分配的角度来讲，这就存在一个前松后紧原则。多预留点时间在此处要害，总比做完了又推翻来得有余地。不愿意花功夫在这上面，早晚必自食恶果。
    由此也衍生出来一个架构设计的行当，它完成系统和平台选型、总体方案设计、关键业务逻辑分析和风险点评估等重方向的工作。然而架构设计不是凭空而来的，它需要长期产品优化和改进积累起来的宝贵经验，需要迅速搭建模型验证方案关键技术的实施能力。所以一般来讲，优秀的架构师首先是优秀的产品优化人员。没有做过系统的性能优化，你都不好意思说你是架构师。
 
2.  适度分离原则——再细化
    谈到性能调优，首先要重视程序结构和业务逻辑，其次才是程序细节。如果程序的架构都有问题，优化不知从何谈起。
    Daemon进程是一种比较普遍的设计，但是也会带来一些隐患，比如内存泄露的话就会一直泄露，直到系统内存耗尽。解决的办法之一是分解daemon程序，只将监听和接收部分留下，繁杂的具体业务处理另由其它程序处理，只在需要时才调用它，用完了马上销毁。这是通常说的分离原则应用场景之一。
    还有一个结构性的问题也应重视，那就是主机的应用种类。应用不同，决定了性能调整的方向不同；而对于不同的调整方向，调优使用的方法和工具也可能大不相同。比较常见的有两种典型应用，服务器（server）型和终端（terminal）型。不要迷惑于某些优秀的工具为什么你一直用不上，也许你的环境和资源本就不允许。
    回到研发流程管理方面来说，一般的IT研发过程是：需求分析-系统设计-详细设计-编程实现-单元测试-集成测试-交付使用-产品服务，再加上编程设计与测试的反复迭代。很显然，研发流程的按步就班本身就是分离原则的一种体现。对某些关键步骤的再分解，将细化一些业务和分工，跳开传统PM的观念，做出针对性的部署和处理，会大大地提高研发效率和团队的创新视野。
    分离原则在很多地方在默默地应用着，各有说法。但相信所有的分离，都是为了更好的整合。
 
3.  前紧后松原则——重视调试
    如果设计与编程是程序员的主要工作的话，那么接下来的Debug调试（测试则重点不同，由Integration Test专业人员完成），也许是产品化过程之中交付成果之前，程序员的临门一脚了。此步看似简单，实则暗流涌动。对于一个真正的项目来讲，没有哪份代码可以直接通过，而是必须经历一段不轻松的Debug历程。而且即使交付给Test人员后，反馈回来的必将是一堆问题，仍然要继续De-bug。有经验的项目经理一般将调试与编程的任务时间比例定得很高（2~5），这叫做前紧后松原则。
    当然在中国，特殊的发展阶段和丰富廉价的人才使得Boss们将Debug时间定得很紧，至于Test反馈问题后的Debug时间一般不在项目规划内，码农们只能通过无穷无尽的免费加班来完成。这是闲话，还是少说为妙。

    最后简单说，如果想一个项目成功，请项目经理们重视需求和调试，而不仅仅是完成功能开发的编程，不然害人害己。当然，说说总是容易，而且没有一成不变的原则，有些具体事务的处理总是相对的。比如模块和业务分离，在资源相对紧张的情况下，过度的分离也许会拖慢程序的启动速度。