用工厂方法模式分析“业务重要还是技术重要”

上午骑车上班的途中不只不觉又想到了“业务重要还是技术重要”这个问题。在思考的过程中不知怎的将其联想到了工厂方法模式。特分析如下：
“客户“这个对象相当于是一个调用的客户端，“公司“对象在这里就是一个工厂，由它向客户端返回“程序员”这个接口的具体实现类“程序员A”或者“程序员B”。如下图所示：



由图中可以分析得出：客户对象不会直接依赖于程序员A或B这样的具体对象，而只会依赖于程序员接口。因为它关注的是code这个编程方法。而具体的程序员只会由公司对象在程序运行时（对应此处为项目开始时）生成。 所以，对具体的程序员形成调用和依赖关系的只能是公司对象而不是客户对象。
对于业务和技术的结合问题一般会有以下两种做法。
做法一：



此种做法使用了专门的业务员这样一个接口，从而让程序员和具体的业务分析方法解藕。对于编码和分析业务相结合的问题通过在公司对象中提供管理方法（上图的manage方法）来实现，当然具体的实现有可能是方法拦截或者类似模板方法什么的办法不一而足。这就类似于给程序员进行专门的业务培训，而不是让他只在编程的时候再一个需求一个需求的问，在不断犯错和修改的循环中去“精通业务”。

做法二：
在公司对象中不提供管理方法(管理很糟的公司一般如此)，也没有一个专门的业务员接口及其实现类。至于具体的业务问题的解决只能是完全委托给程序员对象的code方法去执行，也就是在编码的过程中去实现“分析业务”方法。当然这种做法就只能是在犯错和改正的循环中去完成业务的功能。这种做法也就好比是在业务逻辑代码中同时加入了数据库访问代码、事务处理代码、日志记录代码等等。 很显然这种做法在编程理论和方法日趋完善的今天已经是被广泛的放弃并被认为是错误的和不当的!这也是IT解的共识。这种错误也只有一个刚开始学习编程的新手程序员才会去犯。

通过以上两种方法的分析很对比，孰优孰劣就很明显了。而我们需要从中得出的结论就是对于一个程序员来说它的核心价值就是它的编程方法而不是其他业务什么的。如果你不这样认为，你认为业务比技术更重要从而将主要的时间和精力花在了业务的”精通“上，那就势必造成你在同等情况下花在技术上的时间减少。那么同样的情况下你就比相对在技术上花主要精力的程序员在技术上相对落后。当有一天你面对更好的机会需要再次择业时（不能保证正好是同样的行业）你的竞争力就会比那个程序员更差。原因如下：
1,你精通的是“具体的业务”而不是精通“灵活的很快的调用和掌握业务”的这种能力；
2,你在技术上又比别人差；
3,你采用这种方法作事情难免让公司领导因为你的“敬业”和“认真”而对你产生技术上的宽容和具体做事犯错的
默认（因为他们没有提供业务培训，而你又这么主动的学习业务）。这样更加深了你继续这样做下去成为业务的精通者的想法。

总之，一个“管理架构”设计良好能够持续良性发展的公司会按照规范的做法和专业的思想来完成具体的事情而不是过多的寄希望于一两个业务高手或技术高手的个人能力。这就好比良好的软件架构设计不会让一个类去完成太多的任务，也不会在一个方法中去作太多的事情。当然，话说回来，你可能会说我们现在就是一个才起步的小公司不可能按照你说的这种做法来做，因为我们要生存。对于这种情况我并没有否定你的这种做法。
我只是在这里提醒那些程序员朋友们：当你因为生活所迫的原因这样作是没有办法的。但是在这样作的同时，你一定要记住当你的管理者在向你灌输类似于“业务重要性大于技术”或者“某某大公司也是靠这种牛人撑起来的”从而希望你内心深处认为这种做法是“正确的”是”潮流所趋“的时候 ，你在内心深处一定要明白世界其实本非必然就是这个样子的。你的管理者要么就是“井底之蛙”真的不明白这个道理，要么就是为了公司的利益故意对你进行误导。你所要作的就是搞清楚身份和“对象”，用面向对象的思维来说就是要分清楚“程序员”对象和“公司”对象是有区别的。他们具有的”方法“（职能）是不一样的，这就好比资本家毕竟不是无产阶级，无产阶级不是资本家。各位看管说到这里可能会骂我：“员工要爱企业，要有主人翁精神！你这样是鼓吹个人主义！”。是的，员工是应该有这种精神但是这个问题又是另外一个范畴是属于道德的范畴，员工搞清楚自己的职能并不见得非要用道德的问题来上岗上线评价他。而且安心本职工作，一头钻研技术的员工对公司来讲也未必一定是一件坏事。相反，这正好是很多公司需要的人才。
为了生存，你可以暂时虚应它，可以装作认同并“崇拜”它。但是你的思想观念一定不能去认同这种错误的落后的观念，以至于当真的有一个更好的机会摆在你的面前的时候因为这种观念的原因而错过！那才是程序员尤其是才参加工作很容易被误导同时又需要新的发展的程序员真正的悲哀！！！