技术复杂性

通用代码与特定代码

专门针对手头的问题编写代码，但要尝试找出您可以负担得起的地方，使其具有一点通用性。
通常我们会尽可能编写通用的代码，但最终编写出无助于解决问题的代码。相反，专门为这个问题构建代码，然后试图找出可以使它更通用的地方，完全消除了我知道如果我没有考虑过以后必须再次重构的时间。
有几个通常讨论的原则涉及设计复杂性。在极限编程世界中，您拥有：

你不需要它，这表明程序员在必要之前不应该为程序添加功能。
做最简单可行的事情——快速进步，而不是为未来做计划。
这两个原则都旨在防止过度设计。然而，这些原则可能被滥用来创建多个不能很好集成的简单解决方案。
另一方面，抽象原则旨在通过抽象和泛化在可行的情况下减少代码中的重复结构。我更喜欢在极端抽象和极端简单之间取得中间立场，让代码稍微通用一点。 AHA（避免仓促抽象）原则促进了类似的想法。

深度模块

编写代码，为其他开发人员解决复杂问题，但通过清晰的界面公开功能。
如果您是 API 设计人员或开发人员 - 您的职责是为其他开发人员提供简化复杂功能的接口。如果接口太难理解并且给使用它的程序员带来成本，那么目的就失败了。这个想法体现在深度模块的概念中——“最好的模块是那些收益最大、成本最低的模块。一个模块提供的好处是它的功能，而一个模块的成本是它的接口。”虽然接口的简单性是可取的，但复杂的问题有时需要复杂的代码来解决（如果不是通用规则，但通常是正确的）。这种复杂性最好嵌入代码中。当复杂的功能被抽象出来时，提供给最终用户或界面用户的价值就更高了。与使用较少公共函数/类实现相同功能的另一个 API 相比，具有多个可见函数和包含某些功能的类的 API 更复杂且更难搜索。新的函数和类增加了维护程序员和库用户的接口成本。

学习维护项目

在旧系统中处理遗留代码时，了解应该保留的代码和应该保留的代码之间的区别。
任何高级工程师都应该努力理解应该留下的代码和应该移除的代码之间的区别，这是很重要的。在大型、长期的生产系统将有一些糟糕的代码或没有充分理由保留的代码。理解为什么存在某些东西是健康的（好的理由？坏的理由？）。我们应该删除坏代码，保留好代码。我曾在许多公司工作过，人们认为遗留代码是不可触碰的，或者是出于充分的理由按原样设计的，被时间流逝了。这可能会导致对变化的恐惧，你只是不断地在薄弱的基础上添加抽象。软件行业已经到了许多项目处理旧系统或遗留系统的维护和迁移的阶段。如果您发现自己在这样一个团队中，请不要感到沮丧。通过查看旧代码，您可以获得许多特定于领域的知识。虽然生产中存在较旧的代码/验证可能有充分的理由，但不要假设每一行仍然是健康的。一些软件工程师对接触生产环境中的代码持谨慎态度，因为他们害怕引入错误。因此，它们包含条件并针对较新的用例重复一些代码。这样的变通办法可能会在那一刻节省时间，但随着时间的推移，它们会成为维护的噩梦。不要假设现有的代码是高效的或绝对可靠的。您可以解决以前忽略的可扩展性或效率的某些方面。

在新建项目中学习

实验、创新、快速失败并更好地解决问题。
当您的任务是从头开始构建系统时，您的学习之旅将完全不同。当您开始迭代地制作原型或实现功能时，您会了解哪些有效，哪些无效。敏捷方法和快速失败原则可帮助您以更少的资源更早地验证您的想法。它们使您能够划分和克服复杂的问题。

完成的定义

定义工作怎么样才算“完成”可以节省时间，因为它可以帮助您估计所需的工作量、规划开发并避免以后不必要的修改。
另一个在处理复杂性时派上用场的敏捷原则是就完成的定义达成一致。除了满足用户要求和验收标准外，这还可能包括其他条件，例如代码审查、测试、文档等。

分阶段推出

一个大版本可以分为一系列风险较低且易于理解的发布。
在规划大规模生产系统的发布时，推出计划与架构和代码一样重要。具有迭代开发的分阶段发布可帮助您更好地管理因重大更改而导致的风险。您还可以使用开发和测试策略创建发布策略，以便为复杂的发布制定端到端计划。

系统调试

调试时，应尽量系统地、严谨地解决问题，以解决所有的测试条件。
始终阅读错误消息和堆栈跟踪。那里可能有有价值的信息可以帮助您找到问题并解决它。很多工程师在通过调试寻找问题之前忽略了错误消息可以提供的信息。假设您的机器告诉您什么是错误的，而不是假设进行小的编辑并不断地重新运行代码会更快地解决问题。通常错误或异常消息是一个很大的提示，如果您编写的解决方案引发了异常并且没有仔细阅读异常，那么您可能会浪费时间。

设计文档

设计文档的重要性

设计文档不应该是事后的想法，而是软件工程过程的一个组成部分。
设计文档是一种无处不在的工具，它可以帮助您从需要与您的系统部分交互的同行或其他团队那里获得共识。其他人的反馈使您能够识别差距并改进您的设计。设计文档还可以为将来加入团队的工程师提供宝贵的帮助。这将帮助他们了解问题空间以及设计解决方案时考虑的权衡和替代方案。设计文档提供了一个空间来记录参与设计的所有参与者及其贡献，作为文档历史的一部分。这有助于其他人了解谁推动了具体决策以及与谁联系以进行进一步阐述。

文档过程

协调设计文档的审查，并将设计与原始文档进行比较，以验证是否解决了所有相关约束。
虽然一个人可以记录设计，但实际的设计过程发生在一系列白板会议、随机的面对面讨论、闲散线程或电子邮件/电话讨论中。只有在你把它写在纸上之后，你才能确定相互矛盾的承诺，看看你讨论过的不同部分是否适合在一起。创建初稿后，协调审查可确保所有相关方都参与进来。但是，实施的设计可能与文档中的内容不匹配，因为在此过程中发生了一些变化。

沟通

谦虚，沟通清晰，尊重他人。友善不花钱，但影响是无价的。有人可能会说，良好的沟通会消耗精力和体贴。
沟通是成为有效、高效和高效的软件工程师所需的软技能或人际交往能力的关键部分。沟通不畅可能导致不正确的功能、不兼容的代码或不友好的团队动态。沟通可以帮助人们更好地理解需求并防止问题升级。世界可能会将软件工程师想象成每天都在编写代码的人。但是，为了确保我们的产品对他人有所帮助，我们必须与团队中的其他人以及业务和用户期望同步我们的努力。这使得协作和沟通成为我们工作的关键支柱。初级开发人员主要与其他团队成员、测试工程师和团队领导交流，以分享想法并讨论解决问题的替代方案。随着我们职业生涯的发展，有效完成工作所需的沟通量也会增加。电子邮件、会议和公开演讲的数量增加了。我们必须与业务领导者、经理、利益相关者和团队成员进行沟通。你的工作越专业，别人不容易理解你的风险就越大。

定制通信

使用与您的受众相关的语言、概念和详细程度。
无论我们对问题或情况的理解程度如何，当我们与他人讨论时，我们必须调整措辞，以便他们能够快速掌握与他们相关的内容：

与业务人员交谈时，请谈论您所做的事情对业务的影响。避免使用过于专业的术语。
在与工程管理人员交谈时，传达技术影响或挑战。
在与决策者交谈时，您描述了可用的选项及其影响和风险，而不是选项如何运作的细节。
在提供状态更新时，请注意还发生了什么以及您的更新与项目目标的相关性。
同样的原则也适用于编写电子邮件和向更多受众展示时。写下与接收信息的人相关的内容。您可能需要在演示时捍卫您的想法。以深思熟虑的方式表达问题和回答，不假思索的方式回应某事通常不利于沟通。

友善

友善是一种超能力——运用它。
保持冷静、善良和乐于助人比切断某人的联系更能让你走得更远。善待团队中的人，因为这将有助于使团队更强大和成功。对团队以外的人也要友好。同等尊重组织中的所有职能部门（人力资源、财务或营销）。您可能无法直接帮助他们，但您始终可以理解他们的工作并同情他们。当他人表现出色或获得赞誉时，向他们表示祝贺或赞赏。善良是会传染的。与你相处融洽的人将来更有可能回应任何寻求帮助的请求。自由地告诉人们他们做得很好。虽然在需要改进时给予反馈很重要，但如果事情进展顺利，给予人们积极的反馈也很重要。这有助于您的团队知道他们正在发挥作用并受到重视。

拒绝的力量

说不比过度答应要好。
我们大多数人都不擅长在涉及更多工作时说“不”。要么是因为他们没有意识到“不”是一种选择，要么是因为我们喜欢挑战。但是，过度答应是一种负担，因为它可能导致延迟。让其他人知道你的盘子里已经有什么，并提供一个合理的估计需要多长时间，这是一种尊重的表现。它让其他人有机会考虑他们的选择 - 询问其他人或延长他们的时间表。如果管理层知道这会显着影响产品质量，他们不会要求您在创纪录的时间内交付产品。如果您是高级经理，请授权您的团队对坏主意说不。

高级开发人员（或任何有生产力的人）擅长说不。人们会要求你的时间超出你的空闲时间。您可以温和而坚定地拒绝，将其他人引向其他地方（代表），或要求人们与您的经理讨论是否可以分配更多时间来帮助他们。

你不能取悦所有人——在说“是”和“不”时要格外小心。领导对一切说“不”的对应物是对一切说“是”并且没有设定明确的界限。承担比您当前资源实际能够合理执行的范围更大的范围可能会导致您、您的团队以及最终您的客户出现意外。这对于领导者来说尤其重要，因为其他人会在他们应该说“是”或温和地回击时指望你制定规范。

接受和尊重

承认你不知道的事情，并愿意寻求帮助，即使是来自初级工程师。
当你不知道的时候承认是可以的。软件中最重要的技能之一是能够找到答案并从中学习。作为高级领导者，要学会接受你周围的下级可能更了解项目的技术细微差别。不知道的事情可以承认，让初级工程师来解释。他们会因为你的诚实和对学习的兴趣而更加尊重你，你会更好地了解正在发生的事情并增加价值。作为初级工程师，您应该根据他们的舒适程度，公开或闭门向更高级的工程师解释技术概念。

信息共享

使用会议和问答环节来提出正确的问题、交流知识并通知团队。
开会时，不要成为唯一说话的人。会议是其他人分享想法和提供诚实反馈的机会 - 所以倾听并为其他人提供贡献的空间。初级工程师可能会回避问太多问题。如果你是一名资深人士，你可以通过提出上下文来提示他们提出正确的问题。在回答问题时，让提问的人知道你很高兴他们提出来。

灵活性

尖锐地捍卫你的观点，但每当你有新的证据反驳它们时，也要审查它们。
听取其他意见是沟通的关键部分。这很重要，因为一个问题可能有不止一种解决方案。与其固执己见，不如倾听和评估其他选择。也许他们会提出你之前忽略的一个方面。 Paul Saffo 的“强意见弱持有”原则告诉我们要尖锐地捍卫我们的意见，但每当我们有新的证据与之相矛盾时，也要对其进行审查。这是一种基于科学证据的方法，不考虑提出想法或意见的人。

保持记录

非正式会议后的友好电子邮件有助于重申讨论期间做出的关键点或承诺。
完全口头交流的一个缺点是它可能会被遗忘或记错。记录所发生的一切并在相关讨论中获得批准可以消除这种风险。如果您或其他人同意帮助完成某项任务，请通过电子邮件确认截止日期，以确保包括您的主管在内的每个人都在同一页面上。在评估讨论期间，记录此类计划外工作也很有帮助。