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