从程序员到软件开发者：那些让你脱颖而出的技能

程序员和开发人员这两个词经常被互换使用，但两者之间存在重要区别：开发人员的视角更宽广，而不仅仅是编写代码。在这篇文章中，我们将暂时放下编码，来强调成功的开发人员应具备的技能。

本文将介绍

• 建筑技能

• 最佳实践和反模式

• 设计模式
• 沟通
• 消除依赖
• 组建团队
• 建立人脉

• 谁来干活？

• 责任意味着什么？

• 不要为他人完成工作

• 是否应该授权

• 不要问做什么

• 教而学

• 个人特质

• 哪些特质重要？

• 极端是否优于平庸？

程序员 vs 软件开发者

大多数人认为这两个词是同义词，确实如此。不过，如果你在谷歌上搜一搜，你会发现两者其实有细微差别。这种区别不在于它们如何处理代码，而是它们对待工作和软件开发的不同态度。

程序员	开发者
专注于	实现	解决问题
编写	代码	解决方案
参与	开发和测试	整个 DevOps 生命周期
与	代码	代码和团队成员
对	代码	产品负责

上表展示了程序员和全职开发者从不同角度看待工作的视角。程序员的视角较为单一，专注于代码及其直接环境：编写具有良好架构的代码，彻底测试，并将其交付给下一个部门或直接部署到生产环境。

然而，软件开发者对开发有着更为广阔的视角。这不仅限于写代码，而是协同构建能解决客户问题的产品。这不只涉及一个团队，而是横跨DevOps整个生命周期的多个团队，从规划到部署后的产品监控。

DevOps 生命周期

这并不一定意味着开发人员必须全程参与DevOps链的所有环节。重要的是开发人员理解并积极尝试改进和优化整个流程。而且当其他团队需要帮助时，开发人员要能够提供支持，从而确保整个组织能够交付高质量的产品。

看看整个产品解决方案很重要

建筑技巧

我们先从软件开发者必备的最显而易见的技能说起——架构设计，这同样是每个程序员都该掌握的技能。虽然这听起来可能显而易见，鉴于其重要性以及很多人忽视这一点，这点强调一下还是很有必要的。

在软件开发中，架构师是一个常见的角色。一个常见的误解是认为团队中的架构师独自负责团队所有应用程序的架构设计，这其实是不对的。每个开发者都应该为改进代码架构做出贡献，因此每个人都应该了解并应用它。虽然架构师的工作是在更高和更广阔的层面展开，但所有开发者都有责任保持代码的整洁。因此，每位开发者都应该确保代码的易读性和可维护性。

最佳做法和常见错误

对于所有语言和框架来说，都有最佳实践和反模式。这些在某些方面存在差异，并会随时间而变化。例如，我去年写的文章《React 中的注意事项与不当做法》仍然非常实用，但随着 React 19 新编译器的出现，其中几条规则将会过时。

重要的是，当你开始使用新的语言或框架时，要始终研究最佳实践和反模式。这些时间投入可以大大减少调试和重构所需的时间。在极端情况下，我们谈论的是数月甚至数年开发时间的节省。

设计范式

设计模式在架构中扮演着重要角色。好的代码与差的代码之间的区别往往在于是否正确运用了设计模式。大多数设计模式是与语言无关的，这意味着无论你使用哪种语言或框架，都可以应用它们。此外，每个框架都有其特定的设计模式集，这些模式是框架构建的基础，也是用户应该遵循的。

SOLID 是一个非常著名的通用设计模式之一。它适用于大多数框架。使用这些框架的用户会自动遵循该模式。尽管有时如何适应它可能不太明显，其他框架也可以从中受益。例如，React 并不会自动遵循SOLID原则, 但如果你理解SOLID原则是如何工作的，你也可以将这些原则应用于React。

React 还是一个很好的特定框架设计模式的例子，其中包括渲染属性（Render Props）、自定义钩子（Custom Hooks）和高阶组件（Higher Order Components）等模式。

关键是两点：首先要花时间了解一般的设计模式，其次当你开始使用一个新的框架时，要查找特定于新框架的设计模式。

通常来说，设计模式让代码变得更易于：

• 易于阅读
• 易于测试
• 模块化的
• 坚固
• DRY（避免重复）

这些方面对于编写可重用代码和与同事合作是必要的。同时，设计模式也有助于避免出现 bug。

这是关于 Bug 的睡前故事梗
设计模式也不是完全不会出错

沟通

作为一名开发者，你通常是在构建一个更大系统的部分。构建部分时，如果没有充分的沟通以确保你的软件与系统的其他部分兼容，你的部分就没什么用了。而没有和自己团队的沟通，你甚至无法按时完成组件。

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

先记住，沟通是开发者工作中的重要部分，它和编程熟练程度一样重要。如果你想了解更多，我确实有一些建议，关于如何在大公司里有效沟通可以查看。

## 代码审查的艺术及其你为何需要它 丹尼斯·佩尔森 ・ 2023年10月1日 #生产力 #前端开发 #职业成长 #编程

消除依赖

在我早期的日子里，当我跟某些人或团队交流不顺时，我通常会给出非常清楚的指示，并密切关注他们完成任务的过程。如果这样做没效果的话，我会决定自己来完成任务。

那就是我意识到最理想的交流是根本不需要进行的时候。如果没什么需要交流的，就没有沟通上的困扰了。

我建议的不是你应该跳过沟通，代劳做别人的工作。相反，我的意思是应该将工作划分成不同的部分，以减少需要沟通的程度。

在组建团队时，大家通常会提到多功能团队——这些团队拥有开发、部署和监控产品所需的所有技能，无需依赖其他团队的帮助。

跨职能团队通常指的是具备能够自我组织的知识和技能。这意味着他们具备管理依赖关系所需的所有必要技能和知识。

这一次，这篇文章有很多内容要讨论，所以我不会深入研究这个话题。如果你对这个话题感兴趣，可以阅读我在另一篇文章中关于消除依赖的更多内容，这篇文章还包括团队协作和沟通方面的类似建议。

，沟通时，知道何时不该说话也很重要。有时候，闭嘴就是金。

建立团队

团队建设这一概念通常与有趣的团队活动和偶尔的下班后聚会相关。虽然如此，这些方面确实很重要，但团队建设远不止于此。

你的团队有共同的目标吗？你们是否已经同意了如何进行代码审查的规定？你们团队是否从不在Slack频道里回答问题？如果这些问题的答案是否定的，那么你的团队还没有真正组建起来的话。

团队建设应该是讨论想法、解决冲突和分歧，找到一种所有人都接受的工作方式。它包括分享知识和经验，让所有团队成员都感到舒适地与团队合作并面对即将来临的功能和问题。它还涉及帮助团队成员既能独立工作也能协同合作。

通常实现这一点需要开会。这些会议不必是严格遵循议程的正式场合，但团队必须有些时候聚在一起交流。有些讨论可能需要一个小时左右，而其他话题则可以在简短的同步会上解决。

例如，在实际进行代码审查的时候讨论代码审查的期待是个好机会！除了聊聊怎么改代码，还应该讨论为什么认为这些修改是必要的。你觉得这些修改为啥很重要，你的队友又是咋看这些修改的？

最后再强调一下——团队建设是整个团队的责任。虽然像Scrum主管这样的角色不仅要负责构建团队，但并不是只有他们需要努力提升团队。他们并不是唯一需要这么做的人。团队建设是大家一起的事，而不是单靠一个人的任务。

即使是超能力英雄，也需要团队帮忙。

建立网络

你有没有遇到过让你头疼的问题？那时你寻求帮助却没有人有空搭把手？你有没有感觉没有人真的在听你说什么？即使后来你发现自己是对的，为什么会出现这种情况？

大家通常都很忙，不可能每次都顾及每个人的想法。你需要做的就是让自己的声音被听到。很多时候，这样做的方式是自信地大声地宣称你的看法或提议才是关键。

然而，并不是每个人都能做到这一点感到自在。幸运的是，还有另一种方法可以让您发出的声音被听到——找到一个即使你小声说话也能听你的人。

当你遇到困难时，最有可能帮助你的人是家人、朋友和熟人。人们很少会帮助陌生人，尤其是要为此承担额外工作的时候。

多交朋友，建立人脉，你会发现更频繁且更快地获得帮助。人们更愿意帮助朋友，既是因为喜欢朋友，也是因为难以拒绝朋友。

交朋友的容易程度因人而异，但每个人都有机会。你可以在排队买咖啡时对旁边的人说一句简短的评论或提出一个问题，而不是让别人帮你和对方说话。如果你对Figma设计有疑问，可以直接去和设计师交谈，而不是猜测或发送Slack消息。无论是做什么，都不要让别人替你和对方说话，否则就错失了认识新朋友的机会。

到最后，你并不需要和每个人都成为好朋友，他们才会帮助你。和一个人聊五分钟就足够了，让他们认为你很熟，并且想对你有礼貌和尊重。

人越多越开心

这活儿谁来做比较合适？

大家都知道那个出名的“某人”。一有事情不对劲，总是怪“某人”。‘某人’本来应该搞定这件事。

但是这个人是谁呢？不幸的是，这通常很难识别他们，这就是为什么我们需要讨论一下谁应该承担这些责任以及谁来完成这些工作的职责。有意思的是，通常真正负责任的人真的应该去完成这些工作的职责。

责任感到底是什么？

真正地负责任到底意味着什么？负责任并不一定意味着你必须自己动手，而是意味着期望你搞定这件事。你可以完全把整个任务委托给其他人，让他们来负责。

真正的责任不仅包括确保成功的承诺，也包括鼓励其他人为了这个目标而努力。一家科技企业的CEO有很多责任，但最终，真正完成产品开发的是整个团队，包括开发人员、管理人员和其他成员。

同样，团队中的架构师负责确保团队在编写代码时遵循架构指南。不过，这并不意味着架构师的工作是编写所有代码或定义架构的每一个细节。整个开发团队需要一起努力提高代码质量，并遵循大家商定的设计模式和实践。

关于责任的一个有趣点在于，它经常可以交给别人。但是，当这样做的时候，只有处理工作的责任被转移了，而需要负责的总是委托任务的那个人。换句话说，如果出了问题，项目失败或延期，那么最终负责的人还是要为此负责。

有时候这其实是大家该管的事

别替别人干活

难道不是每个人都喜欢那个神奇地能帮助解决各种问题的同事吗？我也是，但我认为这样做并不太好。

接手别人的工作只会让团队陷入依赖别人完成任务的循环。当那位表现杰出的员工离职时，整个团队或相关团队可能会陷入困境。

与其帮别人做这些工作，不如花时间指导他们如何自己处理。虽然会花更多时间，但一旦他们能够独立处理，你就能省下很多时间和精力。

该委派还是不委派

虽然你不应该为别人完成他们的工作，但这并不意味着你最好别避开那些超出你直接职责范围的工作。记住，负责人不应独自承担所有工作，他们可以分配任务，让每个人都能为完成任务贡献力量。

然而，任务类型多样。如果你负责某件事，工作量可能超出一个人的能力。在这种情况下，授权就变得非常重要，但是决定哪些任务适合授权，则取决于任务的性质。如果任务小且只需要做一次，最好不要授权，因为解释任务可能比你自己完成它还要费时。

对于那些耗时或重复的任务，可以考虑把这些任务委派给别人。这时候，你得考虑一下把任务交给别人的影响：如果某个任务特别重要，你可能还是自己来搞定比较好，哪怕这能帮你节省很多时间。

别问该做什么。

偶尔问问是否需要许可，并确认你做的事情是否受欢迎，这样你就不会白白花一个月去做一些完全不必要的工作。不过，每天这么做就别这样做了。

就像一个团队应该是自我管理的，作为开发者你也必须能够独立解决问题。你不能总是指望经理或团队领导来告诉你每天的任务或如何解决问题，或是如何解决问题。

你应该自己弄清楚这一点。但这并不意味着你不能和任何人交流。记住，沟通是发展中的一个重要环节。如果你不确定，或者你在处理更复杂或更大的任务时，可以和你的开发团队讨论一下，看看他们对这个问题有什么看法。确保清楚地描述问题，并提出你已经想到的一些可能的解决方案。

你看出了这里的不同吗？你和你的开发团队一起工作；你们所有人都共同对开发产品负有责任。如果你的团队有八个人，你们有八个大脑可以共同参与做出一个好的决定。你实际上是在忽视你自己做决定的意愿，而把所有的责任都交给了一个大脑。你去找团队负责人询问怎么做，这不是解决问题的好方法。

当然，你会犯错。接受这点没什么大不了的。这就是在生活里成长的一部分。这不仅仅是句空话，那些没把你打死的事会让你变得更强大。

通过教来学。

如果你阅读了我在沟通那一章提到的文章，你应该已经看到了学习金字塔。你可能还注意到，当你教别人东西时，你所教内容的保留率高达90%，相比之下，你通过阅读学到的东西保留率只有10%。

据学习金字塔理论，你教给别人的东西，可以记住90%

没想到，它会让你发现，当你打算教导他人时，你其实学到了最多。接下来，通过实践做某事，你学到的最多。

注意这与我们在这里讨论的其他话题是如何一致的，关于参与到解决问题中、建立团队以及停止向他人询问该做什么。所有这一切的基础都是具体来说采取行动，积极地改进团队，并提出解决方案。这些行动包括小组讨论、实践问题解决以及教导他人，这些都是学习金字塔中的基础活动。

相反，如果你只听别人的吩咐，只关注他们怎么说，阅读他们是如何解决某个问题的，以及写他们让你写的代码，那么你只是在金字塔的顶端行动，这说明你这样学习效率非常低，只是通过看书、听讲和看演示。

教别人作为额外的好处，你会遇到最难回答的问题。当你不知道别人问你的问题的答案时，你可能会抓耳挠腮，甚至感到尴尬，但过几年后，你就会成为那个无所不知的人。

### 解决看似无法解决的组织问题的三条简单规则 Dennis Persson ・ 2023年11月12日 #生产力 #职业生涯 #Web开发 #敏捷开发

个人特点

我们已经讨论了一些开发者所需的技术技能，以及一些软技能，如如何处理沟通和与他人互动——这些技能在与人打交道时非常关键。

我们还没有谈到的是你这个人——那些定义你是谁的个人特质。这些特质可能不易改变，但你可能不需要改变。正如我们将要看到的，最重要的是何时需要调整这些特质。

什么是特点？

当我们谈论个性时，特质就是个性的特征。有许多模型描述人类个性，其中最著名的是DISC、MBTI（迈尔斯-布里格斯类型指标）和五大性格理论。

DISC模型是一个非常简单的性格分类模型，这篇文章不会详细讨论这个模型。

这张图片是关于 DISC 性格模型的

MBTI更进一步地将人分为16种类型。它是一个非常流行且被广泛研究的性格模型，但科学界并没有完全接受它。

MBTI人格类型模型

科学界通常更喜欢五大性格模型，这与MBTI类似，它也包括了外向和内向的性格特征，加上另外四个性格特征。

五大人格模型（The Big Five）

MBTI 和五大人格特质是两个相当相似的模型，大五之所以被科学界接受，并不是因为它包含了更好的特质，而是因为它用一个尺度来定义人。

大五人格理论并不将人归类，而是认为人类的性格比16种人格类型更复杂，每个特质都可以在量表上体现。这表示一个人不一定非得是外向或内向，而可能在这两个极端之间。这种情况被称为中间向或中向型。

大五人格模型用不同的尺度描述个人特质

极端比普通好吗？

如果我们给每个人的特点都设定一个量表的想法，我们就可以开始评判这些特点的好坏了。比如说完美主义。

有许多类型的完美主义者：自我导向的完美主义者、关注他人的完美主义者、受到社会规范影响的完美主义者等。根据大五人格理论（即“大五人格理论”），这些完美主义者大多数会比较神经质且尽责，不太容易接受批评。这听起来是不是有点不太吸引人呢？

就我个人来说，我认为完美主义有很多问题。说实话，我曾经是个完美主义者，但我已经努力摆脱了这一点。然而，我不能说完美主义完全是一件坏事。事实上，它有时候确实很有益；例如，当你是一名大型企业的高级架构师，手下有数百或数千名开发人员时，在这种情况下，某种程度的完美主义是必要的。

关键是，并没有所谓的优劣特质。每个特质都有两面性。一个特质是否有利，要看你所处的环境。

例如，以建筑师为例。我曾经提出过，对于大型企业的高级建筑师来说，完美主义是一种好的品质。然而，在初创公司中，成为完美主义者实际上并不合适。因为初创公司讲求速度和灵活性。你需要快速与客户互动迭代，以找出他们需要的东西，并且要比竞争对手更快做到这一点，并且要在资金耗尽之前完成。

。根据你的职位，你可能更侧重于质量或快速。

通常，在任何领域成为极端主义者很少有好处。不论是性格的外向或内向、宗教信仰还是政治观点，处于任何光谱的极端都可能带来挑战。换个角度来看，也不宜过于平庸。在生活中要完成事情，独特的技能常常是必不可少的。

事实上，一个理想的人并不局限于某个固定的刻度；相反，他们可以在尺度的任何位置自由存在。这样的人对自己的行为有着充分的认识，并能够根据手头的情况调整适应。这种适应性不仅取决于任务本身，还取决于他们与之互动的人的特点——记得，与他人有效沟通非常重要。

即使是同一个角色，你也可能需要根据任务的不同来调整自己的方式

想想彼得·帕克这个角色一段时间。你怎样形容彼得的性格呢？你会用同样的方式来形容蜘蛛侠吗？

有时候你不得不变成另外一个人（没错，说的就是那个彼得·帕克）

或者 点击这里查看 perssondennis 图片

丹尼斯·佩尔松关注 @丹尼斯·佩尔松

我以前是老师，写关于软件开发及其相关话题的文章。我的梦想是为全世界的人们提供免费的教育内容和轻松幽默的文章。