全文共2350字，预计学习时长8分钟
图源：unsplash
笔者就是一个开发人员。对我来讲，开发者不仅仅是一份工作，更是一种心态，不能轻易放弃。对于那些满怀激情地从事这个职业的人来说，做开发可能会上瘾。
作为一名开发人员，我在职业生涯中遇到过许多挫折，处理过很多棘手情况。我承担过团队领导的角色，后来又担任了首席技术官（CTO）。这些都曾改变了我的一些观点，在观察团队成员的过程中，我也很快开始审视自己。
如何证明自己能够避免错误，并促使人们找到正确的解决方案，从而避免陷阱，这是一个有趣的话题。这并不是因为我有什么超能力，只是由于犯的错误比他们多。本文中，笔者将直面每个开发人员无意中对他人（但首先是对自己）说的小谎言。
笔者不是要评判任何人。开发是世界上最复杂的工作之一，特别是对一个初级人员而言，或者对在一个结构不太完善的团队而言。开发人员的小谎言来自于这项工作的难度。
“成功了”
这个借口有很多种变体，但都会导致相同的情况：测试好的东西在别人使用时不起作用。这可能是因为测试时不够准确，也可能是由于测试过程中的两极分化，即开发者创建了一种功能，但只使用了一种直接的方式，而最终用户使用时需即兴发挥。
问题不在于为什么本应起作用的东西失灵了。开发人员无法相信——他测试时是奏效的，为什么现在无法工作了?没人否认这个功能在某个时候起过作用，问题在于，这儿确实有一个漏洞需要解决。
图源：unsplash
软件是问题的解决方案
我们生活在一个任何事情都可以用软件来完成的世界，软件是我们的良药。需要时间表怎么办？打开的标签太多怎么办？使用软件就OK。
我们试图用应用程序或软件去解决生活中的任何问题。这个过程是数字转换的一部分，但软件只是一个工具。用Dijkstra的话来说，要求软件解决企业问题就像要求潜艇游泳一样。年轻的开发人员看到了CRM或任何SaaS解决方案等软件的威力，认为它们可以解决所有问题，但实际可能比想象的要难得多。
这并不是工具的问题。最商业化的解决方案所提供的比普通需求多得多。问题是来自于公司的。在采用工具之前，必须调整流程，并通过培训和文化培育来支持这种变化。
如果产品不好或者品牌太弱，那么没有任何电子商务解决方案可以提高销售额；如果销售团队不了解正在销售的产品，那么没有任何CRM能有助于销售的推进。软件解决方案是一种推动力，所以当开发人员提出一个解决方案时，请思考一下需要付出哪些努力才能使这种无用的东西开始生效。
“我们什么都能做，只是时间问题”
图源：unsplash
当需要设计复杂的解决方案时，时间是一个关键的点。例如，创建Facebook显然比创建一个简单的网站需要更多的时间。
但问题是，时间不是唯一重要的东西。正确的答案应该是“如果我们有时间、能力和经验的话，我们可以做到。”但我们往往不愿意承认有些事情对我们来说太困难了。
“别担心”
听到“别担心”或“相信我”之类的话时，你应该敲响警钟。
我们总是思考因果关系的逻辑。事情不发生，就不会有任何后果吗？观点会受到个人经验和认知的限制，在复杂的情况下，我们很难有更宽范的见解。而解决方案恰恰需要更深入的解释。
这有助于细节的深入，让真正的问题浮出水面。问题不在于信任，我们必须信任从资历最浅的到即将退休的每一位同事，问题在于回答太迅速或将问题最小化。
“更干净了”
当有人想说服开发人员选择一个长度选项或复杂选项时，通常会得到这个答复。软件与干净与否无关，有使用正确代码实现的稳定、可靠的解决方案，也有让开发人员暴露于范围蔓延的、不稳定的、棘手的软件。
说服某人走一条路而不是另一条路，是因为这条路即使实现时间更长，但会更好，你需要给予其动力。
图源：unsplash
“责任由另一个团队/人/物承担”
“这是别人做的”，“这是硬件问题”，“这是后端问题”，笔者听过太多次这样的话了。
这是完全错误的软件开发方法。在多团队项目中工作时，开发出可工作的软件是共同使命。及时完成项目，产出可靠，是大家共同关心的问题。简单地把责任推卸到另一个部门并不是什么好办法。一个高级开发人员不会让别人沉迷在错误中，而是帮助他们快速理解问题所在。
大多数项目是使用两个独立的团队（前端和后端）实现的，其实这种情况很普遍。笔者相信别人说“不是我的错”，但我们需要向前迈进一步，需要把目前得到的信息传递给另一个团队，然后一起进行测试。这不是责任问题，而是承诺问题。
当不确定问题出在哪里，而只是指出硬件的时候，也是一个意思。如果没有正确的信息，系统管理将如何提供帮助？如何确定这些问题是由于客户端屏幕分辨率而不是一个漏洞造成的？如何处理这个棘手的屏幕分辨率问题？
也许只要通过一些努力，就可以解决这个问题。
永远不要相信开发人员，要相信可工作的代码
图源：unsplash
作为一个开发者，笔者可以告诉大家：永远不要相信开发人员！这不是诚信问题，这只是开发人员工作的难度使然。在理论和实践之间，任何事情都有可能发生，特别是对于初级开发人员而言。
在大项目中，没有人能完全知道所有需要了解的事情。通常，开发人员可以根据任务中编写的内容来执行任务，因为他对业务逻辑一无所知。这意味着每次误解都会导致错误。
要信任开发人员并与他有效地工作，最好的方法是理解他的工作，并向他解释你的需求，告诉他为什么需要做一些事情。在一个具有防错指南的非常结构化的项目里，以任务为导向的方法（现在就做）十分奏效。
请相信代码！
开发工作的难度导致了上述这些小谎言有时是不可避免的，意识到它们的存在是改变的第一步。
