关于程序组织和组织技巧的学习

来博客园有不少日子了,园子一个不变的主题就是捯饬这些。说点我的看法。

本来想正经写文发到首页的。不过算了,目前害怕在这类问题上交流讨论。且我不看好这个讨论对我自己和其他人的价值。

实际上如何组织程序应该从需求出发,而根本不像那些设计指南里说的应该这样应该那样,而不顾前提。这个前提的关键在于你的用户是谁。对于组织这项工作及其结果来说,有俩,一个是咱们自己,一个是其它程序员。

而在应用开发这个水平上,真正为别人设计的时候并不多,而且不具有商业中间件那么重要的意义。

无论是沉浸在面向对象,还是一个非常朴素的程序员,只要我们认真负责,总能设计出不错的接口甚至框架。面条式代码的错误不在于不熟悉某某具体的原则,在于一个人的责任心,这是很多人没有明白的事情。

我逐渐知道,即便一些表现的很热情的学习者,也不过是认为懂得面向对象能更好的找工作(或者是类似潜意识的驱动)。所以我对讨论这些话题,逐渐的从积极参与变成了一个沉默者。因为最终这种讨论变得不击中实质,没有任何指导意义。

划定用户,从需求出发,经过一两个回合的实践,总能找到*目前*较好的一个设计(而不必学习思考太多预备知识)。这无需由任何方法论支撑,它们也无力承受。至于具体的工具(语言或框架),仅仅是为了加快工作速度用的。

不同的设施会有不同的加速指数,所以对工具的广泛了解还是需要的;但必须仅仅从实在方便性上而不是阳春白雪上看这些问题。

我也不赞成通过成熟框架来肯定自己的学习并得出结论的做法。尤其是对于有些程序员,他面临的情景和作者相差太多。

比如ASP.NET这类样的框架和带有的库,有很多设计上的缺点,水平不够的学习者将会很长时间的东施效颦。即便是很多好的决定,仅仅是设计者考虑他认为的最大一部分用户共同的需求才导致的。

不了解这些瞎印证,有不少得出错误结论的几率。而哪怕只有1%的错误,也会影响我们未来的判断。更何况即便找对了路子又能怎样呢?马后炮的人总是马后炮,因为他已经习惯了这个模式;解释正确并不意味着学到了真功夫。

关于对框架的学习,我倒是有一个看法,不妨常常问问自己一些问题。比如“把ASP.NET放到Python的世界,会有人用吗?”

当一个人的选择有限,他就希望这个选择是合理的;那些明显认为不好的,也感觉“无伤大雅”或者认为是Trade Off。当我们跳开这个圈子,看看其它人的选择,最终也许我们就会基于比如Handler自己开发一个东西来用。

就ASP.NET这个例子,虽然没法发放调查问卷,但无论是WebForm还是当前的MVC,恐怕都有不小的几率得到反对的答案。接下来问问为什么、会和不会的都是哪些用户;于是就知道这个东西不好在哪里,或者好在哪里。

有了这些素材,就可以判断自己是不是某个东西的目标用户;如果在很大程度上你和不选择它的那些人有共鸣,它就不适合你了。这时候很多特性,到底应该怎么评价也就变得客观;而不是在很小的一亩三分地上,“哦,这个设计应该是那么考虑的”。

所以你看,这些问题的答案,最终都会和用户是谁,他们(包括我们自己)想要怎么样相关的。

回头说说大多数人所谓的设计,也就是怎么组织程序。有了上面的讨论,不难看出很多看似有价值的文章说的都是废话。我们总能找出不错的理由支持这样或者那样的设计(当然如果这个设计还能被肯定或部分肯定,这也说明它的作者是有一定责任心的)。

但我认为,过了初学者的阶段,当我们碰到真正复杂的问题时,这种学习就变得没有意义甚至拖后腿了。你不能假象你在设计ASP.NET,因为你确实不是。基于其作者的视角和理由去设计自己的东西,最终只能是绣花枕头。毕竟,用户群和问题规模根本就不一样。

每件多余的东西都会付出代价,请注意这一点。奥卡姆剃刀不仅仅用在面向对象内部,对是不是采用某理念照样适用。大家都很希望自己是个了不起的设计师,但什么时候也不能依赖于遐想。象“某牛那样做决定”这是好的,但是往往我们没有看到“某牛在我们这个位置上会怎么决定”。

问问自己,我现在掌握了这么多,我能设计出ASP.NET吗?如果不能,问问自己为什么。我个人的一个答案是,这往往是因为我们没学会正确的方法:即仅通过需求做决定,而不是无谓的琢磨先验知识。

不想当将军的士兵不是好士兵;但是不根据形势而根据内心期许做眼前决定的一定不能当将军。

最后从应用和底层的关系再来看看相同的问题。

想作为一个纯粹的程序员变得更强,就必须认识到真实状况。实际上底层程序员和应用程序员面对的复杂度不是一个级别的。这一点上不能自己骗自己,因为用户群及需要考虑的各方面需求及其数量级都是不同的。

当然,你可以拿一个好的应用程序员去鄙视一个差的底层程序员,但这种自我(群体)肯定,是不讲健康的。当我们认为我们和底层程序员一样棒,甚至和Linus一样棒,我们就会忽略这类大牛不在乎的东西;并以“纯粹的程序员”自豪。

可事实上,很多底层程序员关心的东西我们却也没关心(根本没机会),最终只好搞些徒耗精力的学问求一个充实感。

就我看,作为一个应用程序员,如果说和底层程序员不分高下的话,我们就应该关心很多其它的事情。这些事情是什么,是和你的工作角色相关的。也许是业务也许是其它的,总之你得去挖掘下游的需求(又回到这上面来了)。

甚至我们就不能把自己当作程序员,而是作为一个领域专家,熟悉业务以及业务如何多快好省的实现就够了。

这两个领域的差别带来的区别,也有很多值得玩味的内容。

比如有人说,Linus炮轰面向对象,是因为他和应用程序员面对的领域不同。这话很恶心。

如果一个程序员看不出不同层次不同领域的共性,他也没有真正理解面向对象。但看出来了会如何选择呢?事实上之所以很多方法又漂亮又好使,不过是因为这些方法绝大多数时候只能运用在简单的问题上罢了。

任何方法运用在简单问题上都能找出漂亮的方案。也很容易观察到,除了少数领域,方法论闹得最凶的都是题目相对简单(也许很“高级”)的应用或中间件社区;而大多数热火朝天的学习、实践者又偏偏都不是干少数领域的。

为什么?因为方法论好的一面容易表现出来,自然就吸引人。可最终因为简单,所以其它方法也行得通;这样这些方法论却又不能一统天下。这样它们在大众社区里就表现出一种尴尬:你可以在那津津有味的探讨扩展、重用及其背后的原则,可是难题还是难题,容易的还是容易的。

这就说明,我们每个人碰到的问题,解决之道根本不在我们到底掌握了什么没掌握什么。这不是说某方法论就不能使了,给自己的工具箱添加一些新东西是必要的;只是我们必须避免增加不必要的冗余。

要做到这一点就必须“惰性”一点,只有明显感觉到优势时才使用更多的工具。这样,我们就在多了一种工具的同时,避免了背上Linus所说的“精神包袱”。也许我们应该有一张表,这张表是通过“需求->实践->经验->带有条件的结论”得到的。它记录了工具和场景的一些联系。

而过多的讨论和研习,就相当于:没有正确的、*真正*问题前,我们就回答了它。

posted on 2009-08-22 10:27  怪怪  阅读(1199)  评论(4编辑  收藏  举报

导航