我最常用的一些开发箴言（1/2）

声明：我认为它是这样工作的！

口头禅：假设是所有混蛋之母

让我们从Under Siege2中的这段简短片段开始： http : //www.youtube.com/watch? v = wg4trPZFUwc

在这种情况下，他的假设产生了相当致命的后果，如果您看过电影，您可能会记得。 但是，好的，作为佣兵，他的情况似乎与每天的开发人员不同。 因此，进一步讲这个例子，您可能还记得火车上还有一个计算机天才，它在操作卫星。 现在想象您是那个家伙，您被要求启动卫星通信。 您可以快速编写一些代码，并为此编写以下代码：

i = i++;

通常，我们会写一些“ i ++”来省略分配。 但是，该任务最多似乎是多余的。 我们假设它没有任何其他副作用，因此我们启动了程序。 但是突然.... BOOM！ 通讯失败，凯西·雷巴克（Casey Rayback）被踢了（实际上我很想看到这一点），核武器被发射了，世界和平距离很远。 我们的假设产生了相当负面的影响。

好的，让我们看看这是怎么回事，并做一个小测试。 您希望它打印出来什么，您知道为什么会这样吗？

int i = 0;
i = i++;
System.out.println("i:"+ i);

当您考虑这一点时，让我解释一下会发生什么。 可以看出，我们有一个表达式，存在一个一元运算符和一个赋值。 如前所述，分配是多余的。 但是，除了多余之外，还引起了不愉快的副作用。 它使此代码的行为不同于预期的行为。 如果我们放弃该赋值（只留下“ i ++;”），代码将完全按照您的想法去做。

发生的事情是，在使用赋值时，JVM会在对操作数进行处理之前将它们的值放在所谓的操作数堆栈上。 计算表达式时，将从操作数堆栈中弹出分配给左手变量的值。 那狡猾的一元运算符遵循不同的规则。 它使用“ iinc”指令。 iinc指令将当前帧的局部变量数组中的一个位置作为参数作为其值。

因此，发生的是将“ 0”压入本地操作数堆栈。 接下来，由于iinc指令，变量“ i”加1。 此时，局部变量“ i”实际上将具有值“ 1”。 由于赋值/表达式是在单个步骤中评估的，因此我们无法以正常的方式显示此信息。 进行分配后，它将从操作数堆栈中弹出最新值，并将其分配给变量“ i”。 这意味着'i'将被操作数堆栈中的值覆盖，将其值从1更改回0。

注意：当您写“ i = ++ i;”时 认为会按预期工作，分配只是多余而没有副作用。 在这种情况下，将在将局部变量值压入操作数堆栈之前执行iinc指令。 实际上，有理无异，就像在方法调用中增加变量时一样。 someMethod（++ i）或someMethod（i ++）。 但是，对于赋值，似乎不太清楚前一元或后一元有什么区别，因为我们倾向于将它与i ++或++ i关联在一行上，而如果++是pre或post，则绝对没有区别。

在几乎每行代码中（取决于经验和知识），我们都进行假设。 这在大多数情况下都是可行的，因为某些假设是正确的。 错误的假设不一定会导致错误，因为它们可能会被其他假设所抵消。 或者，也许由于我们软件运行的边界而从未检测到副作用。

跟踪代码中错误假设的一种好方法是编写测试。 但是，仅凭这一点还不够。 接受此规则也很重要。 无论您多么出色，总会有（很多）您不了解或不完全了解的内部信息。 需要保持怀疑态度，不要偷懒。 始终尝试尽可能多的查找内容。 即使在只有一点疑问的情况下：查找它并/或制作一个小的测试用例。 它确实花费时间和精力，但是投资回报率（能够编写有效的高质量代码）将是值得的。

声明：不用担心，这只是暂时的！

口头禅：没有临时代码之类的东西

同意，生活中的许多事情都是暂时的。 我冰箱中的Westvleteren 12库存仅是一个例子。 但是在软件项目中，“临时”往往会自己开始生活，从而在设计过程中造成设计或编写不佳的代码。

如果您考虑一下，这是有道理的； 如果某事被认为是暂时的，我认为没有人会花费相同的精力或精力。 问题是，临时代码在您意识到之前就将变成永久性的。

我可以在这个主题上分享的一个例子是我们为上一个项目设计的用户管理系统。 该系统将成为“临时”用户管理系统，因为“永久”系统由于某些原因而延迟。 我不会详细介绍，但是软件名称需要反映它是临时的。 因此，它被命名为TUM（临时用户管理系统）。 你猜对了； 最终，该系统存在了很多年，随着时间的流逝，它成为了唯一的UAM。 一段时间后，甚至很难说服新同事“ T”实际上代表“临时”。

我将对此进行一点苛刻，但“临时”对任何人都没有帮助，并为开发人员提供了通配符，以证明错误的决定，懒惰或无能。 在这种情况下，设计的机率很大，而最终的代码将遭受质量问题的困扰。 因此，规则很简单：在设计或编写代码会持续一段时间的前提下，总是这样做。 从长远来看，这将是有益的，因为几乎所有代码都会以一种或另一种形式出现。

但是，千万不要误会朋友，无论您有多专注或有多出色，黑暗的一面总是在拐角处等待。 如果您被诱惑，只需问一个问题，如果您的汽车修理工决定暂时“刹车”，因为当时他不知道如何正确刹车，您会感觉如何？ 我想足够了。

像大多数规则一样，也有例外。 认为总体上没有真正的临时软件项目会很天真。 当然有，如果这样的话，从根本上讲不是什么大问题。 重要的部分是使此决策保持在项目管理级别。 这样做可以避免感染团队。

不要忘记，最终您永远不确定项目将是多么临时。 而且即使该项目确实是临时的，它的代码在将来仍可能会找到通往其他模块或项目的途径。

参考： 我的JCG合作伙伴 Koen Serneels在“ 科恩Serneels –技术”博客上发表的一些我最常用的开发箴言（1/2） 。

翻译自: https://www.javacodegeeks.com/2014/02/some-of-my-mostly-used-development-mantras-12.html