在不了解业务上下文情况下请容忍软件瑕疵Bug - jackhodkinson

21-02-09 banq

牢记业务上下文的技术决策建议,业务上下文是唯一的衡量软件质量的关键指标。

如果有事情不对劲,软件工程师会感到不安。学生或初级工程师由于不熟悉编程概念而感到不安。渐渐地,我们对更高层次的抽象感到不安:我们不再会像当初因缺乏理解而烦恼,而是知道系统确实属于有害反模式时,会更加不安。

不安情绪是我们即将面临问题的可靠指标。

普通或优秀的工程师都会感到这种不安,优秀的工程师会倾听自己的直觉,但会用自己的意识来思考是否应该执行某些操作。优秀的工程师会在不安和行动之间建立空间。优秀的工程师可以容忍缺陷。

在做出所有工程决策时,应了解其周围的业务环境。为什么要编写这段代码?这必须为您做出的决定提供依据。

 

假设您正在开发一个对某些数据进行操作的系统。您是否应该将某些数据保留在数据库,有序日志或属性文件中?是否需要永久保留它,还是可以在开始时重新计算?甚至接受重启后数据将丢失的信息?在真空环境中,你不可能就这些解决方案中的任何一个提出有效的论据。

根据上下文,所有这些解决方案(以及更多解决方案)都是合理的。它们都有权衡:初始实施工作,运行成本,维护,监视。但是我经常看到工程师选择过于复杂,过于昂贵的选项,因为愚蠢的简单解决方案使他们感到不安。

当您有很多可用的解决问题的方法,而简单的方法使您感到不安时,您应该退后一步,考虑一下原因。通常,是否有一个合理的原因解释为什么简单的解决方案不起作用?如果没有的话,您就可以省去实施复杂解决方案的麻烦,而您的队友则可以维护它。

到目前为止,我仅讨论了编写新软件所涉及的权衡。但是主要的罪过是拒绝现有代码中的缺陷。

技术债务有其合理存在的原因。

您有多少次听到一个队友说他们正在重构:却造成失控并完全停止了其主要目标的进展?这些重构中有多少最终在完成之前就被放弃了?导致同一事物的两个并行模型的频率如何,使代码库更加混乱?(重构还不如不重构,不折腾,折腾前先搞清原因再入坑,不要等入坑以后才知道原因)

 

容忍瑕疵还有其他优点。旧代码的原始作者可能做出了完美的权衡,但您无法从自己的位置或角度看到这一点(每个人的视角不同)。您的不安是没有根据的,更类似于初级工程师或学生的不安。始终考虑直觉是错误的可能性。重写初级工程师的代码使人沮丧。如果大三学生做了不正确的事情,请不要自己重写。

如果您要完成任何事情,您必须能够容忍缺陷。我们做过的任何事都不完美。尝试这样做是愚蠢的事,放手吧。

坏习惯不能随便改,减肥不能随便减:切斯特顿栅栏和二阶思维的教训

 

1
猜你喜欢