从程序员到软件开发人员——成就非凡的技能

程序员和开发人员经常互换使用，但它们之间有一个重要的区别：开发人员拥有更广阔的视野，并且关注点不仅仅局限于代码。在本文中，我们将从代码本身入手，重点介绍成功开发人员应具备的技能。

在本文中

• 建筑技能
  • 最佳实践和反模式
  • 设计模式
• 沟通
• 消除依赖关系
• 组建团队
• 建立网络
• 谁应该做这项工作？
  • 责任意味着什么？
  • 不要为别人做工作
  • 是否委托
  • 不要问该做什么
  • 通过教学来学习
• 个人特质
  • 什么是特征？
  • 极端比平凡好吗？

程序员与软件开发人员

大多数人都知道这两个词是同义词，事实也确实如此。然而，如果你用谷歌搜索，就会发现它们之间有区别。区别不在于他们如何使用代码，而在于他们对工作和软件开发的看法。

上表展示了程序员和成熟开发人员可能拥有的不同视角。程序员的视角较为狭隘，主要关注代码及其直接环境：编写具有适当架构的简洁代码，进行彻底的测试，然后将其交付给下一个部门或直接投入生产。

然而，软件开发人员对开发的视野要广阔得多。这不仅仅是编写代码；而是要协作构建一个能够解决客户问题的产品。这很少只涉及一个团队，而是涉及整个 DevOps 生命周期中的多个团队，从规划阶段一直到监控部署的产品。

DevOps 生命周期

这并不一定意味着开发人员要参与整个 DevOps 链。重要的是，开发人员要了解并参与整个生命周期，并积极尝试改进和优化流程。当其他团队需要帮助时，他们也需要随时待命，以便整个组织能够交付高质量的产品。

审视整个产品解决方案至关重要

建筑技能

让我们从软件开发人员最需要掌握的技能——甚至程序员也应该具备的技能——架构设计开始。虽然这看起来显而易见，但由于其重要性以及许多人忽视它的事实，它值得强调。

软件开发中一个常见的角色是架构师。一个容易犯的错误是认为团队架构师独自负责团队所有应用程序的架构，但这完全是错误的。每个开发人员都应该为改进代码架构做出贡献，因此必须了解并实践它。虽然架构师的工作范围更广，但所有开发人员都有责任保持代码的整洁。

最佳实践和反模式

所有语言和框架都有最佳实践和反模式。它们略有不同，并且会随着时间推移而变化。例如，我去年写的一篇关于React 中应该做和不应该做的事情的文章仍然非常实用，但随着 React 19 中新编译器的推出，这 17 条规则中的一些将会过时。

需要记住的是，在开始学习一门新语言或框架时，务必研究最佳实践和反模式。这些阅读时间可以节省大量原本需要花在调试和重构上的时间。在极端情况下，我们甚至可以节省数月甚至数年的开发时间。

设计模式

设计模式在架构设计中扮演着重要的角色。好代码和坏代码的区别通常在于设计模式的使用。大多数设计模式与语言无关，这意味着无论您使用什么语言或框架，都可以使用它们。此外，每个框架都有一套自己的设计模式，并且建立在用户应该遵循的模式之上。

最著名的通用设计模式之一是 SOLID。它是一种通用的设计模式，适用于大多数框架。一些框架已经基于它，这些框架的用户会自动遵循该模式。其他框架也可以从中受益，即使如何适应它并不总是显而易见的。例如，React 不会自动遵循 SOLID 原则，但如果您了解 SOLID 原则的工作原理，您也可以将它们应用于 React 。

React 也是框架特定设计模式的一个很好的例子，其中有诸如 Render Props、Custom Hook Pattern 和 Higher Order Components 之类的模式。

关键点有两个：花时间了解一般的设计模式，并确保在开始使用新框架时查找特定于框架的设计模式。

总体来说，设计模式使代码更加：

• 可读
• 可测试
• 模块化的
• 强壮的
• DRY（不要重复自己）

这些方面对于编写可重用代码和与同事协作至关重要。设计模式也有助于防止出现错误。

设计模式并非完全杜绝错误

沟通

作为开发人员，你通常会构建一个大型系统的一部分。如果没有与其他团队进行良好的沟通，以确保你的软件与系统的其他部分兼容，你的部分就会变得毫无用处。而如果没有团队内部的沟通，你甚至无法按时完成你的组件。

沟通在每个项目中都至关重要。不幸的是，沟通非常具有挑战性。我可以写很多关于沟通困难以及如何有效沟通的文章，但这不是我今天的重点。

现在，只需记住，沟通是开发人员工作的重要组成部分，它与精通编程同等重要。如果您想了解更多信息，我还有一些关于如何在大型组织中有效沟通的建议。

代码审查的艺术以及为什么需要它

丹尼斯·佩尔松・23年10月1日

#生产力 #webdev #职业 #编程

消除依赖关系

在我早期与某些个人和团队沟通遇到困难时，我的第一反应往往是提供非常清晰的指示，并密切跟进流程，确保其他人完成任务。如果这些方法不管用，我最终会放弃，自己动手完成工作。

那时我才意识到，最好的沟通方式是完全不需要沟通。如果没有什么需要沟通的，就不会有任何沟通问题。

这里有一个重要的细节：我并不是建议你跳过沟通，自己去做别人的工作。而是说，应该把工作划分成不同的领域，以尽量减少沟通的需要。

在组建团队时，人们通常谈论跨职能团队——拥有开发、部署和监控其产品所需的所有能力而无需依赖其他团队的团队。

跨职能团队通常指拥有自我组织的知识和技能，这意味着他们拥有管理依赖关系所需的所有专业知识。

再次强调，本文内容非常丰富，因此我不会深入探讨这个话题。如果您感兴趣，可以阅读我的另一篇文章，了解更多关于消除依赖关系的信息，其中也涵盖了类似的团队协作和沟通技巧。

沟通的一个重要部分是知道何时不沟通

组建团队

团队建设这个词通常与趣味活动和偶尔的下班后聚会联系在一起。虽然这些无疑是团队建设的重要方面，但它们远非团队建设的全部。

你的团队有共同的目标吗？你们就如何处理代码审查达成了一致吗？你知道为什么你的团队从来不在团队的 Slack 频道上回答问题吗？如果这些问题的答案都是否定的，那么你还没有完全建立起一个团队。

团队建设应该关注讨论想法、解决冲突和分歧，并找到整个团队都认同的共同工作方式。它致力于分享知识和经验，以便所有团队成员都能轻松地与团队合作，并应对即将推出的功能和错误。它旨在帮助团队成员独立工作和协作。

实现这一目标的方法通常是开会。这些会议不必是有着严格议程的正式会议，但必须有团队聚在一起交流的机会。有些讨论可能需要整整一个小时，而其他主题则可以在小型同步会议中讨论。

例如，讨论代码审查期望的最佳时机是在实际代码审查过程中！不要只讨论如何修改代码，一定要讨论你认为为什么需要进行这些修改。你为什么认为这些修改很重要？你的队友对此有何看法？

最后一点：团队建设是整个团队共同的责任。虽然某些角色（例如Scrum Master和团队领导）也肩负着建设团队的责任，但他们并非唯一应该努力提升团队效率的人。团队建设是团队合作，而非个人的任务。

即使是超级英雄也需要团队

建立网络

你有没有遇到过难题？你寻求帮助却无人问津？你是否觉得即使后来证明你是正确的，却没有人认真听你说话？为什么会发生这种情况？

人们通常都很忙，不可能总是考虑每个人的意见。你需要做的是让你的声音被听到。很多时候，这样做的方法是大声自信地说出你的解决方案或问题才是需要考虑的。

然而，并非每个人都乐意这样做。幸运的是，还有另一种方法可以让你的声音被听到——找到一个即使你低声细语也能倾听的人。

当你需要帮助时，谁最有可能伸出援手？是家人、朋友和熟人。人们很少会帮助陌生人，尤其是当这意味着需要承担额外的工作时。

通过建立人脉网络并结交朋友，你会发现自己能更频繁、更快地获得帮助。人们优先帮助朋友，一方面是因为他们喜欢对方，另一方面是因为他们更难拒绝朋友。

交朋友的难易程度因人而异，但每个人都有机会。在排队买咖啡时，只需简短地评论或问别人一个问题，或者特意与设计师讨论你对 Figma 设计的一些疑问，而不是猜测或发送 Slack 消息。无论你做什么，都不要让别人帮你聊天，那样你就会错失新朋友。

说到底，你不需要和每个人都成为好朋友才能得到他们的帮助。只要和别人聊上五分钟，就足以让他们把你当成认识的人，一个他们想要尊重和礼貌对待的人。

人越多越热闹

谁应该做这项工作？

大家都知道那个著名的“某人”。只要事情出了问题，总是“某人”的错。“某人”应该来处理。

但这个人究竟是谁呢？遗憾的是，我们通常很难确定他们的身份，因此有必要讨论责任以及谁应该做这项工作。有趣的是，通常情况下，责任人应该做这项工作。

责任意味着什么？

负责任的真正含义是什么？负责任并不意味着你必须亲自完成工作，而是意味着你被期望完成工作。你完全可以把整个任务委托给别人，让他们承担责任。

真正的责任不仅在于确保成功的承诺，也在于鼓励他人为实现这一目标做出贡献。科技公司的CEO肩负重任，但最终，真正负责开发产品的是整个组织，包括开发人员、经理和其他人员。

同样，团队中的架构师负责确保团队在编写代码时遵循架构指南。然而，这并不意味着架构师的工作就是编写所有代码，甚至定义架构的每个方面。整个开发团队应该协作，以提高代码质量，并遵守商定的模式和实践。

关于责任，有趣的一点是它通常可以委托给他人。然而，委托完成后，责任通常仍然由委托人承担；转移的只是处理工作的责任。这意味着，如果出现问题，导致项目失败或延期，那么责任人必须承担。

有时这实际上是每个人的责任

不要为别人做工作

难道不是每个人都喜欢工作中那种能为大家解决所有问题的人吗？嗯，我也喜欢，但我知道这不是最佳行为。

承担别人的工作只会形成一种恶性循环，人们会依赖别人来完成自己的任务。一旦那位优秀的员工辞职，整个团队，甚至多个团队都会陷入困境。

与其替别人做事，不如花时间指导他们如何自己处理。虽然一开始可能需要更长的时间，但一旦他们能够独立完成，你就能节省大量的时间和精力。

是否委托

虽然你不应该替别人做事，但这并不意味着你应该回避你直接职责之外的任务。记住，工作不应该完全落在负责人身上，负责人可以委派任务，这样每个人都能为完成任务出一份力。

然而，任务类型各有不同。如果你负责某项工作，很可能工作量超过一个人独自完成的能力。在这种情况下，授权至关重要，但决定授权哪些任务取决于任务的性质。如果是一次性的小任务，请避免授权，因为解释起来可能比自己完成要花更长的时间。

对于耗时或重复的任务，可以考虑委派。这时，你应该权衡委派的后果：如果一项任务至关重要，你可能会选择亲自处理，即使委派可以节省大量时间。

不要问该做什么

偶尔请求许可，并再次确认你的行为是否受到赞赏，这样做是很好的，这样你就不会花一个月的时间去做一些完全不必要的事情。但从日常习惯上来说，请停止这样做。

正如团队应该自组织一样，作为一名开发人员，你必须能够照顾好自己。你不能让经理或团队负责人总是告诉你每天应该做什么，或者如何解决每个问题。

你应该自己解决这个问题。这并不意味着你不能和任何人沟通。记住，沟通是开发的重要组成部分。如果你不确定，或者你正在处理更大的任务，请与你的开发团队讨论，看看他们对此有何看法。确保清晰地描述问题，并提出一些你想到的潜在解决方案。

你看出区别了吗？区别在于，你和你的开发团队一起工作；你们共同负责开发你的产品。如果你是一个八人团队，你们有八个大脑，可以共同做出正确的决策。如果你去找团队负责人询问该怎么做，你基本上就是在忽视你自己的决策意愿，把所有责任都推到一个人身上。这不是解决问题的好方法。

当然，你会犯错。接受它。这才是人生成长的方式。“那些杀不死你的，终将使你更强大”并非只是一句谚语。

通过教学来学习

如果你读过我在“沟通”章节中链接的文章，你应该已经看过学习金字塔了。你可能已经注意到，当你教别人时，你学到的知识的保留率高达90%，而你阅读的内容只有10%。

根据学习金字塔，你记住了你教给别人的90%的内容

令人惊讶的是，这个金字塔告诉你，当你的意图是教别人时，你学得最多。其次，通过实践，你学得最多。

请注意，这与我们在此讨论的其他主题是如何一致的，例如参与解决问题、组建团队以及停止向他人寻求指导。所有这些的基础都是采取行动，积极努力提升团队，并提出问题的解决方案。这些行动包括小组讨论、练习解决问题和教授他人，所有这些都位于学习金字塔的底部。

相反，如果你只接受别人的命令，只听他们说的话，阅读他们如何解决问题或编写他们告诉你编写的代码，那么你就只是在金字塔的顶端工作，这意味着你通过阅读、听和观看演示的学习效率非常低下。

教别人的额外好处是，你会遇到最棘手的问题。你可能会因为不知道别人问你的问题的答案而抓狂或感到尴尬，但几年后，你就会成为无所不知的人。

解决组织难题的三条简单规则

丹尼斯·佩尔松・24年11月12日

#生产力 #career #webdev #agile

个人特质

现在我们已经讨论了开发人员需要的一些技术技能，以及一些如何处理沟通和与他人互动的软技能——这些技能对于如何与他人互动非常重要。

我们还没讨论的是，你究竟是怎样的人——你的个人特质决定了你的为人。这些特质或许很难改变，但你或许并不需要。正如我们将看到的，最重要的部分是学会何时需要调整它们。

什么是特征？

说到性格，特质指的是人格的特征。市面上有很多模型试图模拟人类的性格，其中最著名的是 DISC、MBTI（迈尔斯-布里格斯性格类型指标）和“大五”性格测试。

DISC模型是一个非常简单的模型，它将人分为四种不同的性格，我们不会在本文中深入探讨。

DISC人格模型

MBTI 更进一步，将人分为 16 类。这是一个非常流行且研究颇深的性格模型，但尚未得到科学界的认可。

MBTI人格模型

科学界普遍倾向于“大五”理论。“大五”与MBTI类似，它包括外向性与内向性，以及其他四个特质。

大五人格模型

MBTI 和“大五”是两个相当相似的模型，“大五”之所以被科学接受，并不是因为“大五”具有更好的特质，而是因为它在一个量表上定义了人。

大五人格并不对人进行分类，它声称人类远比16种性格特征更为复杂，每种特征都有相应的量表。这意味着一个人不一定是外向型或内向型；他们也可能处于量表上的中间位置，即所谓的“中向性格”。

大五人格代表了个人特质

极端比平凡好吗？

如果我们按照为人类的每个特征都设立一个量表的思路，我们就可以开始判断特定特征是好是坏。就拿完美主义来说吧。

完美主义者有很多种类型：自我导向型、他人导向型、社会导向型等等。根据“大五人格理论”，这些类型的人大多神经质，做事认真负责，不太接受批评。听起来不太吸引人，不是吗？

就我个人而言，我看到了完美主义带来的诸多问题。坦白说，我自己也曾有过完美主义，但一直在努力摆脱它。尽管如此，我也不能说完美主义是一件应该避免的坏事。事实上，它有时非常有益；例如，如果你在一家拥有数百或数千名开发人员的大公司担任高级架构师，那么成为一个完美主义者就显得尤为必要。

重点在于，没有绝对好或坏的特质。每种特质都有其优点和缺点。某种特质的好坏取决于你所处的环境。

比如，以架构师为例。我说过，完美主义对于大公司的高级架构师来说是一个好品质。然而，在初创公司，完美主义者真的不受欢迎。初创公司讲究速度和敏捷性。你需要快速迭代客户，了解他们的需求，而且你需要比竞争对手更快地完成，并且在资金耗尽之前。

根据您的角色，您可能需要关注质量或速度

一般来说，在任何领域成为极端主义者都很少有好处。无论是外向还是内向，宗教信仰还是政治观点，处于任何极端都会带来挑战。更复杂的是，严格保持平均水平也无益。独特的技能往往是成就人生事业的关键。

事实上，理想的人无法被固定在一个固定的尺度上；相反，他们有能力存在于任何尺度上。这样的人完全了解自己的行为，并能够根据实际情况进行调整。这种适应性不仅取决于任务本身，还取决于与他们互动的人的性格——记住，与他人进行有效的沟通至关重要。

即使在同一角色中，你也可能需要根据任务采取不同的行动

想一想彼得·帕克。你会如何描述他的性格？你会像描述蜘蛛侠那样描述他的性格吗？

有时候你必须成为别人（是的，那就是彼得·帕克）

丹尼斯·佩尔松跟随

我以前是一名教师，撰写有关软件开发及其相关领域的文章。我的愿望是为全世界的人们提供免费的教育和幽默的阅读。