语源科技BlogJava-Coding Maniahttp://www.blogjava.net/felixtsu/zh-cnMon, 13 Apr 2026 10:45:40 GMTMon, 13 Apr 2026 10:45:40 GMT60OOD闲聊http://www.blogjava.net/felixtsu/archive/2011/12/09/366003.htmlFelix.TSUFelix.TSUFri, 09 Dec 2011 15:23:00 GMThttp://www.blogjava.net/felixtsu/archive/2011/12/09/366003.htmlhttp://www.blogjava.net/felixtsu/comments/366003.htmlhttp://www.blogjava.net/felixtsu/archive/2011/12/09/366003.html#Feedback0http://www.blogjava.net/felixtsu/comments/commentRss/366003.htmlhttp://www.blogjava.net/felixtsu/services/trackbacks/366003.html
在OOD这个domain里面，类比数学公理，我认为Robert.C.Martin的OOD Principles已经说的非常清楚，当中最为核心的一条，就是SRP。所有其他的编程原则如同在五大Principles中的OCP、DIP更多的是基于SRP的一些推论，更不必说DRY原则等等一系列五花八门，变化多端的buzz word。我认为所有的程序设计工作，其实最终的目标都是为了达到隔离关注，将特定的需求交给专门的组件去完成。这里的组件在不同的上下文中含义不同，小至在单个系统模块内部，组件指的可能就是完成特定功能的Class/Function，大至SOA(另外一个buzz word)中，组件指的可能就是某个业务域服务系统。当明确了SRP是终极目标之后，OCP说的，只不过是“部分特定条件下的情况已经被本组件解决完毕并隔离，如需要处理其他特殊逻辑，请通过扩展的方式在特定的地方完成”；DIP则说“本实现所依赖的组件的具体实现选择过程应该由专门的选择策略组件完成，本类的主要关注是利用这些依赖完成本类所标称需要解决的问题”；至于那个DRY原则，则更显浅易懂了，本来就已经有特定的组件把特定的关注解决掉了，还有必要重新解决一次么？
那么所谓的封装、多态、继承，甚至是GoF的各种模式，到底是什么呢？同样的，类比数学中的概念，它们就是一些基于数学公理的推论，虽然我们可以通过公理一步一步的将所有的定理推论都推理出来，但极少数人会在实际运用计算的时候这么做，因为太慢了。同样的，这些类似Best practice的东西的价值也仅仅在于，解决某一特定前提下的某一特定问题，这样，你就明白为什么我深恶痛绝模式驱动编程：模式是为了解决特定问题而产生的，但这帮人的做法是为了运用某种模式，而去创造该模式所符合的问题，这让我想起那个关于数学家的笑话。然而我经历的团队中，这样的情况屡屡发生，成为过度工程的头号原因。
之前经常有人问，如何锻炼设计能力？我就会建议他们看一下那几个principles，每天读，读通读透，让它们成为你的条件反射。在做设计和review设计的时候，不停的问自己，我一共有多少个问题？正在考虑的这个组件要解决什么问题？在它所处的粒度来看，它是否只有单一职责？等到每个问题的答案都是Yes的时候，我认为这个设计至少不差。我之前看到过很多这样的设计，大多数情况下，它们不会有一些fancy的设计模式名称在里头，但却渗透着一股身经百战的老练，比如JQuery的core。
同样的，有一种显而易见的bad smell：当你的代码库中充斥着大量的设计模式名称，而实现代码却看起来极其幼稚（我认为至少得读过Implementation Patterns或者Clean code），那么百分百的，你的团队中就至少有着一个急于想证明自己却又适得其反的成员，该是时候找他谈谈他的定位和成长计划了。

Felix.TSU 2011-12-09 23:23 发表评论
]]>过早的细分扼杀了你的可能http://www.blogjava.net/felixtsu/archive/2011/12/07/365738.htmlFelix.TSUFelix.TSUWed, 07 Dec 2011 03:57:00 GMThttp://www.blogjava.net/felixtsu/archive/2011/12/07/365738.htmlhttp://www.blogjava.net/felixtsu/comments/365738.htmlhttp://www.blogjava.net/felixtsu/archive/2011/12/07/365738.html#Feedback0http://www.blogjava.net/felixtsu/comments/commentRss/365738.htmlhttp://www.blogjava.net/felixtsu/services/trackbacks/365738.html
当然毕业生里面也有厉害的，比如topcoder component development里面大量在校生，但如果仅仅是抱着希望而去开展校园招聘，那么必然是浪费时间精力的事情。实际上，如何用好应届生，是一个教育问题，而不是管理问题。

作为一个应届生的第一个目标，首先就是成长为一个合格的coder。
所谓合格的coder，是要能清醒的知道，自己写下的每一行代码，到底将会产生什么样的作用。这个方法的语义是什么？他的用户是谁？参数是从何而来的？中间经历了那些处理？可能会有多少个输入的来源？这些不同的来源之间是否有业务上的差异？如果有，我该如何处理？方法的返回值将会被如何使用？我的经验是，只有把这些问题都问完了，有结论了，才会有安全感。
可是，能够问出这样的问题，就要求他心中必须有一个全局的视图。这正是大部分人get lost的地方：过早的关注细节。早早的，这些人就因为这样那样的原因，选定了某个细分小工种，然后对工种以外的知识技能弃之不顾。于是我们见过太多这样的人，身为一个标称的J2EE程序员，毫不羞愧的承认自己不知道如何获取Select控件的值、数据库中表和索引是如何存储的。或者你可以说这是因为我一直在小公司工作，资源紧缺，职责划分不清造成的。那么，退一万步说，一个合格的coder，至少要知道目前工作的项目是如何集成、部署、运行的。之前我的团队中，总是只有少数几个人能成功的完成集成部署，而这些人恰恰又正是能在系统分析、设计阶段提出自己想法的人。对于至今不懂的如何集成部署的人，我想问：一堆不能运行的代码，到底能为你的用户递交什么价值？
除了有全局观，第二个要素就是追求。是的，如果没有追求与那份狂热，你是永远无法成为Jamie Zawinski这样的人（他在Netscape时写的日记）。有了这份狂热，精益求精，或者精益说的Continuous Improvement就已经成为了你的本能，在做何事情的时候，你都在思考，什么东西通过哪种方式，可以变得更好。于是，在不知不觉中，每分钟你都在做各种refactor or even re-design的方案，思考权衡各种利弊，慢慢的你和那种工作八小时内闲着无聊上上网的普通程序员拉开距离了。

各位广大的应届生，你们最大的优势在于，充满着无限可能。越早的开始你的一万小时，就越早到达终点。

Felix.TSU 2011-12-07 11:57 发表评论
]]>