上周末，我与一位顾客进行每周约会，并发现自己陷入了有趣的对话中（请参阅：被问到一个问题，然后大喊大叫以作回应）。 在编写一些代码以实现用于创建新用户的功能时，我写了一些在技术层面上可能不是最好的代码。 “我一直听说这不是做事情的最好方法……”
我对软件开发行业最大的困扰之一是教条式思维。 某人在某个时间点（通常是从某个权威的位置）喃喃地发表意见，最终被接受为不可动摇的真理。 这些智慧通常以“应该”，“总是”或“从不”开头，但是很少在上下文中提供任何推理或因素来检验其有效性。
有问题的代码就是我所说的“一个班轮”。我们试图在数据库中找回一家公司的ID，或者，如果该公司不存在，则要创建它然后获取ID。 为了解决这个问题，我编写了一些代码，使我们可以加入一家变量company ，然后编写如下代码：
// Assume `company` is a variable in scope. const companyId = typeof company === 'string' ? company : createCompanyInDatabase(company);
此处的代码显示为“如果company的当前值具有String类型，则只需返回变量。 否则，我们假设company是一个Object类型，然后将其传递给createCompanyInDatabase() ，它将创建公司并将新ID作为String 。 从技术上讲，这可能不是最明智的方法。 “我一直听着……”是指该代码，指出我们不应在期望变量包含两种不同类型数据的地方编写代码。 有趣的是，这并非不正确。 这样做有可能（基于上下文）引起混乱并创建脆弱的代码。
但是，在这种情况下：它起作用了。 该代码完成了我们需要做的事情，并且根据在工作中讨论过的要求，我们知道它只会在两个上下文之一中使用，因此，如果确实发生了任何错误，它们应该易于修复。 在开发软件时，这类情况经常发生。 您遇到了一个十字路口：我会保留不理想但功能完善的代码，还是将其重写为“最佳”解决方案。
每当我遇到这种情况时（正如我向客户建议的那样），我一定要问“这是书呆子还是商业东西？”“商业”一词在某些圈子里可能是一个鲜红色的字母，但是当您作为开发人员开发产品时，必须考虑到您的决策过程。 如果您的最终目标是生产功能性产品，那么代码是否100％完美是否重要？
我认为，在大多数情况下，答案将是“否”。现实是，大多数代码库绝对是灾难，只有一个或几个人的观点才“完美”。 在每个可能的地方都找不到非常有组织的，技术上正确的软件是非常罕见的。 实际上，我还没有看到它。 原因？ 尽管所有的“您应该”和“您必须”都随处可见，但是没有官方标准来规范我们如何编写代码。 从字面上看，我们采取的一切福音只是一种意见。 根据影响力，某些意见比其他意见更有分量，但它们仍然是意见。
在开发产品时，请务必注意上述情况。 那些时候您发现自己很浪费时间来重构一些实际上根本不需要重构的代码。 我个人决定何时最好保留某样东西的测试是“六个月规则”。如果我在六个月后回到此代码，我是否会理解它的作用？ 如果答案是“是”，并且该代码正在根据需要运行，我将继续。
说像“业务比代码更重要”或“代码比业务更重要”这样的陈词滥调固然很有趣，但最终毫无意义。 两者都很重要。 两者都有优点。 我认为，真正热销的标志是知道如何同时考虑两者和做出明智判断的人。 他们的判断可能并不完美，但他们并没有考虑教条主义的面子价值，而是考虑某事是否只是一个书呆子的有趣借口，还是可能对业务产生负面影响的东西。
当您在开发自己的产品时，请注意在为业务做出决策时与尝试安抚隐形大师时的注意事项。 我敢打赌，当您发现自己花费大量时间在代码上，但是产品却没有什么进展时，您很有可能在书呆子上投入了不必要的时间。
最初于 2017 年10月4日 发布在 cleverbeagle.com 上。
