您是否应该编写好的文档和简洁的代码来增加“总线系数”？

软件开发公司的主要目标之一是提高其总线系数。Google在一次演讲中也倡导了这一点。

这意味着您应该以一种方式对所有内容进行编码和文档编制，以确保明天您要在公共汽车上运行时，项目仍然可以继续进行。换句话说，您应该使自己很容易被具有类似技能的其他程序员替换。

可替换，这是否违背了开发人员的利益？在这本书中，有48条权力定律第11条规定，您应该设法使人们依赖于您，以便获得权力，然后将其转化为金钱奖励。

除了这种情况，您需要自己准备一些文档才能在暂停6个月后继续进行项目，开发人员和软件公司之间显然存在利益冲突。

因此，作为一名程序员，您应该为所有人真正编写出色的文档和易于阅读的代码吗？还是应该以一种可以完成工作的方式编写代码和文档，并且您自己可以理解它，但是另一个人可能很难理解它？

您应该努力变得不可替代，而不是通过编写其他人都无法理解的代码，而是通过积累比其他人更多的经验和知识。前一种方法使您成为每个人都尽量避免使用的开发人员，因为他们会害怕并讨厌维护您编写的代码。使用后一种方法，您将成为受人欢迎的团队成员，经理希望将其加入团队。

以我的经验，编写干净，有据可查（最好是自我记录）的代码总是有回报的。实际上，我几乎抓住了每一个机会来帮助和教导他人（以及在他们了解更多东西时向他们学习），而且我几乎没有遇到过被能力比我低的人取代的危险。实际上，这通常可以帮助整个团队更好地工作并更快地解决问题，这是每个经理的梦想-明智的经理不想替换一个好的团队的成员。

如果您要如此透明地操纵组织或人员，那么他们最好是愚蠢的或陷入困境，让他们别无选择。一个运行良好的软件开发商店将查看您晦涩的代码和丢失的文档，并在您造成多大损失之前将您开除。如果他们运行不佳，或者无法让其他开发人员为他们工作，那么为什么要与他们交往呢？

PS格林先生和马基雅维利先生实际上都没有取得什么成就，除了写那些试图吹捧当时的“硬汉”的书。听一听他们的建议。

如果您无法替代，就无法晋升。

您不想成为不可替代的人。您不想让人们感到依赖您，而是希望他们欣赏您。通常，您希望与人们保持距离，他们认为甚至一半的权力定律也应适用于关系（专业或个人）。
这些规则是有关如何成功建立双赢局面的指导。您想要的是双赢的局面。
一旦人们开始感觉到，您就试图将他们推向输赢局面的失败者，他们将进行反击。尝试建立双赢局面通常会导致双输局面，因为您实际上是在浪费资源来使您的伴侣陷入失败的境地，而不是将其投资于整个伙伴关系的成功。

如果您与雇主一起这样做，他们将尝试对您采取措施，以减少您的知识垄断。通常，这些准则对于您必须如何进行工作是荒唐的准则，从而将您的工作生活变成一个活生生的地狱。另外，如果出现问题，他们会在晚上3点给您打电话，因为您是唯一可以解决此问题的人。尝试利用杠杆等情况可能适得其反，并给您带来更多麻烦。

墓地里到处都是必不可少的人。
-戴高乐（Charles De）

因此，请不要胡言乱语，并做好工作。如果不是为了其他目的，那么为了您，因为您很可能是可怜的灵魂，从现在起2年后必须对代码进行一些更改。

鉴于该网站吸引了比平均水平更好的程序员，因此负面反应并不令人惊讶。有才华的人通常不需要求助于这种通过混淆来实现安全的策略。但是，我在一家财富500强汽车供应商中工作，与一些不那么有才华的开发人员一起，为他们自己雕琢了一些小小堡垒，他们通过为他们设计的可怕界面创建大量文档来积极地保护他们。

一个人的全部工作是维护一个模块的代码，该模块桥接了两个完全独立的子系统，从而允许每个系统上的模块通过UART进行通信。基本上，它是“串行编程101”。不仅仅是创建一个看起来像这样的通用接口：

  int sendData（int targetModule，void * data，size_t byteCount）;
  int recvData（int sourceModule，void * data，size_t maxBytes）;

他为任何两个通信模块可能希望发送给彼此的每条消息创建了单独的操作码。这意味着他的模块需要了解每条消息，并且每当添加或更改消息时就需要更新。谈论不适当的亲密关系！

关键是，这个人保留了一个Word文档，整齐地列出了所有操作码/消息，并根据需要进行了认真的更新。这成了他的全部工作。每周几次，他会向所有不幸的人发出新版本，以至于让他走上关键的道路。由于管理层喜欢查看文档，因此这被视为“专业” 。Kinda让我为汽车行业而哭泣。

我想我的意思是：有时编写文档实际上可以保护普通的程序员。经理们常常无法分辨出好的设计与坏的设计之间的区别，许多经理被迫在有限的信息下做出技术决策。对他们来说压力很大。看到包含数十个格式整齐的表格的Word文档可能会非常令人欣慰-即使它描述的内容从根本上来说也是个坏主意。

可替换，这是否违背了开发人员的利益？

我讨厌把它给你，但每个人都可以更换。当然，有时候更换您可能是一个小挑战（如果您有足够的经验和足够聪明的经验），但是距离不可能只有很短的几年。

真正成为您的雇主（不仅是现任雇主，而且是任何雇主）有价值的商品的方法是展示出能够编写易于阅读的代码的人（很少花时间来工作）和编写文档的能力代码（任何人都可以深入了解您的系统，而无需深入研究代码）。

实际上，如今精通代码文档已经很难了，因此仅此一项就可以帮助您与众不同。

干净且文档齐全的代码也值得放在简历上（至少，有形的结果，即“ n由于我的文档，我们能够以最小的投入和帮助使新开发人员加入），在那里偷偷摸摸地制作自己“不可替代”不是。

可替换，这是否违背了开发人员的利益？

取决于该开发人员的利益。如果您想在整个职业中将其坚持一份工作，那么对于一家奖励无能并赚钱的公司来说，这是绝对不可或缺的，那么绝对可以。

但是当公司倒闭时会发生什么，可能是因为他们雇用了太多这样的人？你下一步要去哪里？当他们问您为什么要在同一份工作中待15年时，该怎么办？等等。

现在以另一种方式来看待：有多少开发人员由于编写了任何人都可以阅读的代码而失去了工作？

发生这种情况的唯一可能性是，如果公司陷入困境并导致人员冗余。如果发生这种情况，您最好离开，并且为即将进行的面试做好充分的准备。另外，您的良心将完全免费-您将不会留下为自己的自利而编写的莫名其妙的代码。

我不知道你是什么样的人，但是这样做可以更好地满足我的兴趣。

就个人而言，我认为我最大的优势之一就是可以自动完成自己的工作。当我对自己的要求过剩时，您认为公司会怎么想？他们是在考虑“好吧，我们现在将他除掉”还是在考虑“为什么我们不将他转移到另一个职位上让他再做一次”？

可替换，这是否违背了开发人员的利益？

您是对的，但我认为您误解了可替换的含义。我可以找到1000名编写忙碌代码的开发人员，这些文档没有文档记录，很快就会变成难以维护的混乱局面。

开发人员不仅可以生成稳定的程序，还可以生成干净的代码，内容丰富的文档，并确保项目的连续性，这不仅是不可替代的，而且是无价的。

我已经从几个不同的角度解决了这个问题，因为已经有了好几个答案。

考虑一下在玩小游戏时，尽管使其他人无法学习代码的工作原理，却使自己“不可替代”会发生什么。只要公司允许您，您就可以继续保持自己的混乱状态。那是最好的情况，最坏的情况是您公司中其他更有才华，更有道德的工程师和经理看到您不良做法对公司造成的障碍，他们决定对此采取措施：解雇您并改写从头开始的一切。已经做完了 实际上，这是相当普遍的事情。

现在考虑编写好的代码和好的文档时会发生什么。您创建了一个运行良好的组件或系统，该组件或系统在运行一段时间后，可以很轻松地解决bug，并且几乎不需要检查它们。维护它几乎不需要任何努力。然后，您可以继续进行更大和更好的项目，并取得坚实的胜利。人们会认可您所做的出色工作，并将开始尊重您的意见。您将有能力在食物链中向上移动，做出更有意义的决定，或者进行更重要和更具影响力的工作，或者更高级别地管理项目。您的职业将得到改善，您将获得晋升，您将获得更多的收入，您将获得同行的认可和认可，您将在越来越重要的项目中获得越来越多的成功。

您会选择哪一条路线？

如果您是单点故障，那么您的客户（或雇主）可能会尝试替换您；总是有一个观点，即不管看起来多么重要，更换软件的成本都比维护软件的成本低。IT是最可外包的专业之一。

另一方面，可替换为您提供了许多无价的好处：

• 能够休假
• 不待命
• 自由离开并从事新的和正在退出的项目

如果您不花5分钟编写一些快速文档，那么您将花费一个小时重新阅读并向需要使用代码的人解释。

更糟糕的是可能要花几天时间寻找新工作，因为老板发现您没有编写可维护的代码。

优秀的文档最终将因重构/演进而被淘汰，而使其保持最新状态确实非常耗时。

干净的代码+单元测试>优秀的文档

您的问题的答案是“是”。是的，您应该编写好的文档和简洁的代码。故意进行其他操作会显示出缺乏完整性，而这种完整性虽然在商业世界中日渐流行，但在某种程度上并不是突然间变得“好”。

没有人是不可替代的。制造一种他们认为自己处境艰难的人往往会发现自己并非如此的艰难方式。为自己建立一个相互依赖关系会适得其反，因为它不仅限制了雇主，还限制了您。

软件开发公司的主要目标之一是增加其总线系数

错误的前提。一家软件开发公司（无论如何，我从事过的每家公司）的主要目标都是生产他们能做到最好的软件并赚钱，而不一定要按此顺序进行。减少“总线系数”只是避免赔钱的一种方法。

法律11学会让人们依赖您。

这对你来说代表着什么？

您是否希望人们依靠您，因为您破坏了人们，使他们只能在您的帮助下前进？还是您希望人们依靠您，因为您聪明，有见识，可靠，值得信赖，并且能够帮助他人更好地完成工作？您是否想在没有您帮助的情况下让同事看起来不好，还是要让他们感谢您使他们看起来更好？

是你的电话。

（假设生产代码）

我倾向于走得更远。我已经写过有关使程序成为“白痴证明”的文章，但我并不总是这样认为：我编写了很多其他人不会看到或无法使用的代码（至少是在编写时所期望的）。一世是那种我想捍卫自己的白痴。当您的程序为您检测到问题时，这是一件好事，而且问题已被简化得如此之多，以至于很明显，有一个错误及其起因。事实是，实现细节在您编写程序时很明显（除非您过早实现），但应该对它们进行抽象化处理，以防客户端出错（即使存在模块局部性）。原因是程序变得非常复杂。有时您可以分离问题，但并非总是如此。如果您保持组件的严格性，简单性，良好的封装性和白痴性，那么它们确实会很好地扩展，并且大多数缺陷会在发货前被发现。重用起来更容易，您更有信心，重用程序的时间也更短，在离开程序一段时间后，您编写的那些复杂程序只会变得更加复杂（甚至对您而言）。在6个月内阅读完该书后，与白痴证明版本相比，它可能会花费大量的时间来理解和调试。如果组件引入了重大更改，否则很长一段时间都不会被发现。程序很复杂；您无法逃避现实，但是可以使它成为白痴证明，当出现问题或必须重用或更改某些事物时，这将使您的生活变得更加轻松。因此，白痴证明方法意味着您的软件也可以被您的初级人员或团队中的新人（不仅是像您一样优秀/有经验的人）理解，重复使用或维护。替换是一个单独的问题：如果人们喜欢使用您的程序，那么您做得很好-不要 不用担心更换。当然，我可以提出一些方案，在这些方案中，难以理解的程序可以节省您的工作，但是编写其他人可以使用和维护的好的程序显然会减少麻烦（请看其他人的回应）。如果我发现自己写的东西不是白痴证明的，我会设法解决。

除了这种情况，您需要自己准备一些文档才能在暂停6个月后继续进行项目，开发人员和软件公司之间显然存在利益冲突。

当您重新访问休眠的实现时，您确实不知道自己在想什么。当您真正有经验时，问题就更简单了，因为您可以更多地依赖已建立的方法或所使用的方法。但是，那也假设这些方法是不变的。即使文档可能不那么严格，您仍然必须在实现中保持防御（例如，您比在这种情况下传递NULL更了解-测试该条件）。

因此，作为一名程序员，您应该为所有人真正编写出色的文档和易于阅读的代码吗？还是应该以一种可以完成工作的方式编写代码和文档，并且您自己可以理解它，但是另一个人可能很难理解它？

我建议使用白痴证明方法，该方法比总线因子方法更清晰，更耐错误。编写程序和文档，使项目外部的人容易理解它-对您也有好处。这样做会增加你的价值，你的公司和团队，他们不会想代替你。

您从根本上误解了游戏。游戏不是要继续做以前做过的事情，而是要对所编写的所有代码负责，因为没人能得到。游戏的目的是完成一个项目并移至下一个项目，留下其他人可以在您不在的情况下轻松理解和使用的代码，以便您可以做新的事情并承担更多和不同的责任。仅当您高兴地一遍又一遍地坚持做同一件事而没有机会学习或改进时，前提才起作用。

我还要指出的是，如果您没有机会经常查看该代码，那么如果您故意对其进行混淆的话，那么在六个月之内就无法解决该问题。

我记录什么小码我写的，不是让别人可以读出来，但是让我可以在3个月时间读它！这是为了简化维护。如果您负责编写的代码，并且无法修复稍后出现的错误，那么您将需要对其进行充分的记录……如果您无法执行此操作，则与可替换性无关紧要做你的工作！

我遇到过的每一个不幸的“不可替代的”计算机专业人员都被替换了，这在很大程度上是因为他们试图控制雇主的资源为人质。当我有一些向我报告的人告诉我他们的时间对于“浪费”文档很有价值时，我将尽快替换他们。

看起来，如果准员工认为48项权力定律在道德或道德上是可以接受的，那么没有这些定律，您会更好。

如果您真的想成为不可替代的人（阅读完所有答案后可能要重新考虑...）-为什么停止不记录代码？

关于如何编写不可维护的代码，您绝对应该阅读一本非常出色的指南：http : //thc.org/root/phun/unmaintain.html

请享用！（我当然可以...）