曾经的同事(后面简称同事),现在自己开了一家公司从事一种数字设备的开发,这一设备也是一个软件密集型的产品。同事的公司所从事的行业有很多强有力的大公司,应当说,同事的公司不大可能与这些大公司去进行正面的竞争,但是,市场上也的确存在他们公司生存的空间。通过某种途径,了解到了同事公司现在的软件开发方法,而这些信息促使了我的一些思考。
 
其实,说到他们的软件开发方法,总的一句话吧:没有方法!为什么这样说呢?我觉得他们现在采用的就是一种手工作坊式的开发模式。其实,我很想问问我的同事:有什么方法来应对公司的快速成长?用什么方法来保证软件产品的质量?我想我的这位同事很有可能答不上来,或者说只能告诉我“没有”。我相信,这位同事能开一个公司并生存下来近两年,而且短期得到了发展,一部分原因他们抓住了市场的一面,也就是对于客户群这个层面他们找准了方向。但是光是从应用层面找准方向短期能见效益,但长期来说是不够的,必须得从软件行业上找出一种适合自己公司的、有效的开发方法来,来应对日益庞大的客户群和日益复杂的客户需求。
 
在我看来,不少与软件挂钩的产品公司,其实一开始都找准了应用的方向,也得到了机会,但最后还是没能让自己的企业做大、做强,为什么呢?因为,他们很有可能忽视了其应用产品还有软件行业的一些特点,而这些特点对于公司的成长却是至关重要的。这些特点主要有以下几点。
 
其一,我们知道,软件行业并不是人多多亦善的,而应当是宁缺勿烂、少而精。这与生产性行业相比,是完全不同的,如果我们在运营一个公司时没有这种意识,那会得到一个“花了钱找人,却不见工作成效”的令人沮丧的结果。《人月神话》这本书很好地阐述了软件待业的这个特点。
 
其二,软件行业也是一个很讲究方法论的一个行业。比如,我们采用什么样的方法来保证开发出来的软件在质量上至少是自己放心的(先不说客户放心吧)。这是一个非常大的话题,也是软件行业一直在努力的一个方向。当然,话题大并不表示没有一些有效的方法。比如,Unit Test和Automatic Test都是行之有效的(但不是终级方案)。对于UT和AT,很多人会说:公司小哪有那么多的人力去做啊?其实,这不完全对,公司小时的确应当去平衡各方面的人力,这是无可厚非的。但UT和AT确能从长远来看解放人力的,在开始阶段,的确需要较大的人力,但一旦平台构建好了,后面发挥作用后,却能显著的提高效率。不可否认,维护这些平台也需要一定的人力,但与没有这一方法相比所花费的人力相比要小得多。关键是质量能上一个台阶。当然,这里讲到的只是方法论中的一小点,其它还有很多很多,比如平台、框架、设计等。对于软件开发方法论没有认识的话,企业要长久地发展是非常的困难的。
 
其三,别把测试当作是取得高质量软件产品的救命稻草,而实际上质量很重要一部分是来自于设计,应当是设计为主测试为辅。关于这一点,我很喜欢这么一句话(忘了出处):测试只能证明失败,但不能证明成功。这句话听起来有点别扭,但我想作者想表达的意思是:由于我们的测试用例并不是完整的,所以我们对于现有用例测试的成功并不代表所有的用例测试都是成功的。其实,不可否认测试是一种质量保证手段,但我们需要有一种意识,这种意识就是时刻关注我们的代码(实现)架构,对于出现的问题应从更高的层次去分析。比如,问一问自己,现在提出解决问题的方案,是一完整的方案呢还是只是解决了10%的问题?能找出一种通用机制来解决类似问题吗?这一问题的发生是一个简单的应用实现问题还是一个系统性的问题?方案的实施是否会造成软件架构质量的退化呢?等等。一个项目,如果软件的实现架构有问题,那么再多的测试也只是制造一个更大的“资源黑洞”。