|
| |
 精品推荐 |
 |
|
| |
|
|
|
|
你的代码真的很健壮吗
|
日期：2007年5月16日 作者： 查看:[大字体
中字体 小字体]
|
《别人的棺材》说的正好是一个相反的例子。有A,B,C等模块，A负责分析，执行指令，B负责生成指令。这样的设计十分合理， B不用考虑指令是否合法，由A负责指令的检查、分析，然后再执行。但是，也许负责B模块的人觉得A模块不可靠或是效率太低，所以他也加入了对指令的分析模块。作者认为这样的设计会产生冗余，当需要修改指令分析流程时，许多模块需要修改，系统变得难于维护。
在网上的评论中，有的人认为这两篇文章相互矛盾。我觉得相反，这两篇文章恰巧揭示出需要防御和假设的两种情况。对于前一个例子，应该防御的条件，作者做了假设；对于后一个例子，B模块应该假设，却多做了一份防御。
当我们做假设的时候，切忌不能凭空假设，我们必须清楚谁对这个假设负责。所谓对假设负责，其实就是在划分系统的职责。当我们假设一个条件时，就是把保证这个条件成立的职责分配到外部系统。在做这种划分的时候，我们应该确信外部系统有这个能力，并且这种划分是合理的。在《你防御了吗？》中，作者把保证SQL语句不会超过4000个字符的职责交给最终用户，这显然不可靠。
当我们要防御一个条件时，切忌不要过度防御，过度防御虽然不会造成程序崩溃，但是会影响系统的结构。《别人的棺材》中，B模块就属于过度防御。造成过度防御的原因，我以为主要有两点：一点是由于程序员的“悲观”态度和简单分析造成的。在悲观的态度下，程序员认为一切条件都不可靠，然后，不加分析的一概做防御处理；另一点是由于社会原因造成的，我猜想《别人的棺材》中，作者就碰到了这类由于团队内部沟通上造成的。我也碰到过类似的情况，以GetItem()为例，本来我们在GetItem里是不检查index的合法性的。但是突然有一天，另一名使用这个函数的工程师告诉你，程序在GetItem里崩溃了，你调试后，告诉他，他必须负责检查index的合法性。然而，也许他是你的老板，或者你是个“菜鸟”，你争执不过他，最后只好你修改代码，加入index的检查代码，这样程序再崩溃的时候，至少不会在你写的代码里，“万事大吉”了。
结束
当我们追求一个目标时，由于时间很长，过程艰难，到后来真正的目标往往会变得模糊不清。什么才是健壮的程序？能够正确运行的程序才是健壮的程序。在追求写出健壮的程序时，我们往往只考虑程序会不会崩溃，更有甚者，只考虑程序会不会崩溃在自己写的代码里，这离健壮程序的目标已经偏离了许多。这时有必要停下来，想一想，反思一下我们的目标和经历的过程。这篇文章就是我的一次反思。 （出处：清风网络学院）
上一篇:软件架构训练基础教程之Intenet技术
下一篇:64位计算中的Java虚拟机(JVM)性能测试
|
| 你的代码真的很健壮吗 相关文章： |
|
|
|
| 你的代码真的很健壮吗 相关软件： |
|
|
|
|
