业务开发与基础设施的分离

专业的软件开发以分工为基础的，每个人的精力有限，不可能既紧跟技术潮流，又精通业务流程，一些人天天挂在嘴上的是先进技术，框架，模式，类库，津津乐道，然而一旦谈起业务，怎样创新自己的业务模型，满足市场需求，就兴趣全无，嗤之曰枯燥乏味，对自己技术并无帮助，何苦化精力去学习它？以至开发出的系统质量不高，成本加大！

 

所以我认为一个专业的软件公司里可以进行分工，一部分人对技术感兴趣，那么他们应该专注于技术，软件基础设施的建立；一部分人觉得业务模型更有趣，那么他们就可以专注于业务对象的开发，业务对象不受运行平台，架构，数据库等的限制，它可以运行在B/S系统，也可以运行在C/S系统，可以在MVC框架里跑，也可以在非MVC框架里跑，也不论哪个容器或者O/R Mapping框架，所有与业务逻辑无关的代码它都不涉及。

 

举个例子，业务对象应该都是些POJO，专注于技术的人用容器或者某个框架对这些POJO进行粘合，或者引申开发以符合某些规范，最后把所有对象进行装配和发布，从而形成一套流程。

 

由于技术的发展，开发工具，类库和框架的进步，以及公司内部公有代码的积累，对业务对象的装配会越来越有效率，所需人力会越来越少，开发人员的产出会越来越高。所以当你看到某些工具越来越强大时，不要感叹：开发越来越傻瓜化了，我们还有饭吃吗？

 

是的，当生产效率提高时，势必某些职位会变少，很多人需要转型，比如更多的人需要研究业务，怎样用创新的模型来快速实现需求，怎样创建业务的"pattern"，这是更具挑战性的工作，更需要创新精神。

 

看看IT发展的历史，从原来的软件硬件一把抓，到后来软件独立开发，然后网络管理独立出来，然后美工独立出来，然后数据库开发独立，应用服务器概念出来，以后软件的基础设施，是不是可以成为一种顾问的职责，让外面的人过来培训，和服务？

 

当然，不同的产品有不同的矛盾，有些产品业务并不复杂，但用户有百万千万级，比如一些大型网站，IM服务器等，这些产品主要还是技术问题，那么就必须对基础技术研究很深；而一些企业内部信息系统，主要矛盾是对业务的深刻理解，这就需要把大量的精力放在业务建模上。