回到2004年,那时我还是一名初级开发者,工作在一个大型团队中,主要从事有线电视公司的账单与供应系统。就像所有的大型系统一样,这个系统由大量相对比较独立的组件构成,不同的小组负责不同的组件开发工作。模拟电视与数字电视供应系统几乎是完全分开的,由两个不同的小组分别进行开发。 模拟电视团队决定根据Microsoft Biztalk的一个早期版本来构建他们的系统。团队有4个人以及一个来自于微软的团队共同开发并运行这个系统。他们看起来工作非常努力,常常工作到深夜,周末也在加班加点。当遇到生产问题时,团队的每个人都会放下手头的工作,围拢在一起,提供各种建议和意见,以及如何修复问题的见解。你会看到,这个团队中的每个人都有很强的团队凝聚力,而且他们工作都非常努力。 数字电视供应系统则大相径庭。系统的代码几乎是由一个家伙搞定的,我们暂且称这个家伙为Dave吧。我是团队的一名初级维护工程师。一开始,我在理解代码时遇到了很多麻烦。程序中并没有长长的过程语句,相反有大量的小体积类和方法,每个方法的代码也只有寥寥数行而已。我有几个同事抱怨Dave将事情搞得过于复杂了。不过Dave却建议我应该阅读几本关于面向对象编程的图书。他教会了我设计模式、SOLID原则以及单元测试等知识。很快,他所编写的代码开始变得具有现实意义了,随着我不断加深对代码的理解,我也越来越发现它优雅的设计。代码在产品中没有出现问题,只是一直在默默地工作。要想对代码做出修改也是轻而易举的事情,因此实现新的特性简直是手到擒来。单元测试意味着进入到生产系统中的Bug数量变得微乎其微。 结果就是我们这个团队看起来工作不那么努力。我每天下午5:30下班,周末也从来不用工作,我们也不必围聚在一起猜测到底是什么原因导致了生产系统的问题。从外人的角度来看,我们所从事的工作肯定要比模拟电视团队的简单得多。事实上,二者的需求非常相像,只是我们开发出了设计更好的软件、提供了更好的支持基础设施,特别是单元测试。
更多见:http://blog.csdn.net/ricohzhanglong/article/details/17485219
写的好的代码,出现bug少, 容易维护,看起来外人觉得你很闲......
时间: 2024-11-06 18:33:20