如何成为一名更好的软件开发者？

编者按：要想成为一名软件开发者需要学习各种专业知识、技术与框架。比如算法、数据结构、编程语言、流行框架等。但是要想成为更加出色的软件开发者，你要学习的就不仅仅是专业上的知识了。devtrails.io的编辑Pavels根据自己的经验提供了相关建议，供各位想在新年更进一步的开发者参考。

今天我想分享一点关于软件开发者如何改进职业技能从而变得更擅长于自身工作的技巧。这里要谈的主题是通用性的，并没有针对任何特定的技术栈。其实这里要谈的大部分甚至都不是针对IT的。这些都是如何形成个人特质，跟同事、客户改进协作，以及拓展作为软件开发者职业生涯的一般性建议。

本文里面有些东西属于主观性判断，反映的是我的个人经验，还有一些则已经被其他人采纳并成功运用。

端到端理解整个流程

很多开发者认为软件开发纯粹就是写代码，其他事情根本就是别人在打扰自己，浪费他们宝贵的时间。这种说法距离事实再也不能再远了。在你卸下第一行代码之前，需要经历从模糊到精心设计准备可以实施的解决方案这样一个转变过程。当你把最新的变更推动到Git之后，软件需要经历测试、部署、监控、分析以及改进等过程。编码只是流程众多步骤之一而已。

为什么会这样？因为项目的不同阶段经常是由不同的团队甚至不同的部门来处理的，大型组织尤其是这样。一切都先从收集需求的商业分析师开始。需求然后递交给设计师，为开发者输出原型。开发者编码把结果提交给QA工程师。如果一切都OK，成品就会发送给运营团队交付给最终用户。这个流程被当作一组离散的步骤，没有任何反馈。因为部门间缺乏沟通，其代表通常并不真正理解别人的目标，这会导致误解甚至冲突。

软件开发流程往往被当作一组离散的步骤，没有任何反馈。

对于现在的很多人来说这种说法似乎太过夸张。随着敏捷方法论的崛起，更多的公司已经从此类僵化的做法转移至混合不同专业的小型化团队。但即便这样我们也还是看到大家并不真正理解别人的工作。你有多少次因为设计师要你实现一个太过耗时的定制化复选框而被激怒？反之亦然，你又有多少次因为忘记使用正确字体而受到指责？

这些差异很多都可以克服，如果你留意别人的工作的话。跟你的设计师坐到一起，解释给他听，说实现定制化复选框要花点时间，但是有个库可以提供你可以重用的类似复选框。反之，你也得学习一下字体排版基础，理解为什么选择正确的字体会有影响。对待经理、商业分析师、QA工程师、支撑人员以及营销专家等也要养成同样的态度。借用赫胥黎的话来说：

尽可能广泛地涉猎各门学问，并且尽可能深入地择一钻研。

通过尽可能广泛地涉猎各门学问，你将能够预测他们的需求，简化反馈回环，促进更频繁的交付。此外，这还会为你赢得很多的爱以及所有其他人的尊重。

理解你客户的需求

关于你的客户，有一件重要的事情你需要理解：他们并不理解你做的大部分事情。敏捷、函数程序设计或者非关系式数据库对他们来说都是黑暗魔法。甚至那些密切跟进你的工作并且真心感兴趣的人仍然大部分都不了解。这会有几个后果。

大多数客户跟软件开发者交谈时的面部表情。

雇软件开发者需要有一定程度的信任。要为某个自己不理解的东西支付一大笔钱的时候大家往往会觉得不舒服。还记得上一次你走进一家不熟悉的汽车维修店却不担心他们是否值得信任是什么时候吗？你的客户也会有同样的感受。只是这里没有车，而是一堆抽象的、不可触摸的概念，你得将其具体化成产品或者收入。跟新客户合作是赢得他们的信任非常重要。确保他们理解你是怎么工作的，然后小规模频繁地交付迭代结果。这样他们就能看到你的工作进展，评估中间结果并且提供他们的反馈。

客户经常会提出他们自己的解决方案而不是分享他们的问题。由于他们对你的能力几乎一无所知，他们的解决方案往往会误判，不是过于保守就是太过激进。记住亨利·福特的那句老话（也可能是杜撰的）：

每当我问顾客需要什么的时候，他们总是会说需要跑得更快的马。

这时候你不能总是默默地按照他们的要求去实现，有时候请他们先后退一步讨论一下自己想要解决的问题是什么会很有用。在结合了他们的领域知识与你的专业技术时，你就有可能得出一个更好的解决方案。

记住，并不是每个人都喜欢自己的想法受质疑，这种策略需要你机智一点，不要挫伤客户的信心。你还得离开你的舒适区，让自己沉浸到他们的业务当中，从而真正理解问题所在，推荐更好的解决方案。如果你要做的是金融或者医疗保健等复杂行业的话，这会比较有挑战性。但如果你搞定了一次，下次客户的心态可能就会更加开放一点。

为工作选择合适的工具

如果你手里只有一把锤子，其他一切看起来都像钉子。

只学了一门技术的开发者往往会急急忙忙就想用它来解决遇到的任何问题。毫不奇怪，这种做法会导致次优结果。相反，在处理新问题时，要停下来思考一下你手头的工具是否真的适合这类工作。如果你有疑虑，就要做点调查提出一组可能更加出色的替代者。为了让这个过程简单一点，可以编译一个问题清单来评估不同的选择。每次评估的问题可以不一样，但大概可以是这样的：

• 它必须支持哪些平台或者设备？

• 有哪些非功能性的需求，比如性能或者内存使用方面？

• 购买授权是不是可选，还是说你需要免费或者开源的？

• 该解决方案是否提供了你所需要的一切，还是说你需要自己写些东西？

• 你还没有其他的限制，比如公司政策，法律方面的考虑，或者你的团队缺乏专家？

回答这些问题应该有助于你在脑子里构思相关选项，将可选的名单范围缩小。

安全地进行试验

• 如果你懂得的东西没有一个合适你要解决的问题，所以你想尝试一些新东西的话，会发生什么事情呢？你没有经验并不意味着就不可能。只是你需要额外考虑一些事情：

• 你有足够时间准备吗？如果项目的时间安排不紧张的话，你可以在实现前尽可能多地去学习，剩下的再边做边学。或者至少采取“假装自己可以直到成功”的态度，并且说服客户你知道你在做的事情。

识别你首先需要测试的东西。采取“快速失败”的办法，识别在得出实验结论前你需要评估的关键东西。对某个系统的性能有疑问？做一个最小化的原型然后进行负载测试。对特定库或者与外部服务集成不确定？单独实现它然后开发剩下的。

记住，这条路走下去对你和你的客户来说依然是有风险的，他们需要意识到这样既有风险也有潜在的好处。毕竟，从长远看，2周的调查可能可以省下几个月的时间，这听起来像是个相当好的交易。即便试验失败了，你也只损失2个星期。你的客户对你的信任越大，他们就更有可能同意类似这样的事情。

站在巨人的肩膀上开发

重新发明单车往往会导致怪异的结果。

做IT的往往有两个常见特征：善于独出心裁并且欣赏自己的工作。这听起来是件好事，但却会有尴尬的副作用：对于此前已被解决的问题，我们往往会想出自己的解决方案。所以只要我们面临使用某框架、库或者服务还是自己实现的选择时，我们往往会选择后者。这会让我们走上重新发明单车这条徒劳无功的道路。导致这样的一些常见的误解包括：

• 自己实现某个东西要比学习第三方解决方案容易。尽管这也许是个完美的正当理由，但是不要将手头的工作过度简化很重要。经常一些开始看起来很简单的东西结果表明在过程会变得困难许多。最终，你得花很多的时间处理别人已经替你处理好的bug和极端情况。

• 这个解决方案做的事情超出我的需要了。除非有特殊理由，否则的话这怎会是坏事情呢？增加成品的规模，增加潜在漏洞或者显著放缓编译速度，这通常不算什么坏事。你到头来可能会需要的。另一方面，只用一项功能就增加一整个库也许是大炮打蚊子了。

• 我们能做得更好。尽管有一些成功的项目是按照这样的话开始的，但通常并非如此。优质的第三方解决方案是由既有经验又有资源且致力于解决这一特定问题的团队维护的。要想跟他们竞争既需要能够投入更多的时间和资源。大多数项目既没有资源也不需要这么做。

• 代码所有权和长期维护会成为问题。一些人害怕如果用第三方解决方案的话，项目会有到一定时候会被放弃或者出于某种原因变得不可用的风险。产品被锁定的风险是真实存在的，你应该考虑可能的缓解风险策略。如果那是个开源项目的话，有没有可能fork出来自己维护？或者如果是专有项目的话，取代它需要多大成本？基于这些输入你就可以确定风险是否值得。

通过重新实现来学习

这个故事还有另一面。自己重新实现某样东西其实是很棒的学习方式。尽管给生产项目写自己的框架几乎永远都是坏主意，但是做来作为学习练习就非常有价值。通过用自己的办法重新解决一遍同样的问题，还有比这更好的熟悉待解决问题的方式吗。不过兔子洞不要钻太深，一个简化的粗糙实现就足以让你了解情况了。

在做的时候，不要羞于参考类似项目的做法。研究开源项目的代码可以让你从更有经验的开发者那里获益。

按照你的工作方式工作

争取改进不只是技术方面，也要在方法上。就像设计得当并且优化过的软件一样，一个固定下来的工作流可让你少费力也没那么大压力就能产生更好的结果。确定一套既有效率又有效能的工作流程并不是容易的任务，这方面有无数的书本和材料。不过就起步而言，可以考虑以下的改进之处：

• 团队和项目管理方法论。既然我们大多数都是团队作战的，采用可改进协作的流程并且让大家建立起共同的工作节奏就显得非常重要。软件开发的敏捷运动催生了若干广为采用的方法论，比如Scrum 或者 Kanban。他们帮助组织总体的工作架构但并未全面覆盖一切。还有其他一些方法论帮助你做出估计，确定问题的轻重缓急，改进沟通等。你需要找出自己感到困难的地方然后寻找最佳实践来应对那些困难。

• 个体过程。就像一支管弦乐队一样，高效团队必须有相同的节奏，但这并未意味着每个人都必须按照相同的方法行事。每个人都有自己的喜好，应该按照能让自己更有效率的方式去工作。比方说，很多人在编程的时候不喜欢被打扰，但我个人喜欢短冲刺1、2个小时然后就休息一下子（不那么严格版的番茄工作法）。我也不喜欢在家工作，以避免家务相关的干扰，而是喜欢在办公室或者咖啡店工作。找出适合你的工作方法，坚持下去，但也要确保你的习惯不会给其他团队成员造成问题。

• 工程实践。很多实践都是游走在技术与方法论的边缘，聚焦于改进实际的开发流程上。比方说，测试驱动开发和行为驱动开发帮助保持代码库结构良好并且是经过测试的。代码评审帮助减少代码瑕疵也在团队中传播了知识。持续集成和持续交付确保更容易更安全的部署流程。采用这些实践再结合上其他的组织方法论来实现结果的最大化。

记住，没有可适用每个人的流程，你需要在自己的环境下试验一下。此外，要确保你完全理解流程并且正确地实现它。要从已经走过该流程的团队那里寻求建议，从他们的经验中获得一些东西。不要忽视有助于你采用该流程的软件和具体工具。弄一块真正的看板以及一个现代的平台用于持续交付。采用新流程需要付出努力，甚至还会导致短期内生产力的下降。要给它一些时间然后对事情是否有改进进行评估。

排除障碍

排除障碍这事儿得单独说说。忽视看似不重要但对你的工作却有毒性作用的小麻烦是常见的错误。你的设计师是不是单独坐一间房或者在另外一座建筑内？这意味着他过来讨论要费点功夫，有些事情就不会得到讨论。写心的测试是不是很困难？那就会有很多东西不会经过测试。

这些做法本身并不是特别危险，但是小事情积累起来往往会导致严重后果。令人不快的是，等你注意到这些事情是往往已经太晚了。尤其是在你总会有更严重的问题要处理时。还记得温水煮青蛙的寓言以及蔓延常态（creeping normality）的概念吗？

要保持警惕，在刚有苗头就要将这些小问题消灭。

聚焦基础

基本概念是你职业生涯的建构块。

IT是一个节奏极快的行业。每周都会有新工具推向市场。我之前已经提到过臭名卓著的“JavaScript疲劳综合征”了。很多开发者对每做一个新项目似乎都要重新评估一下技术栈感到很有压力和抓狂。的确，想要永远保持领先是很有挑战性的，但我有几个主意可以让这件事情变得容易一点。

首先，要专注于基本面。即便新技术似乎出现得相当频繁，新的基本概念出现频率却要低得多。在学习新东西的时候，确保你理解了导致出来这个东西的背后想法。很可能这些思路也已经用到了其他项目上了，一旦你遇到类似东西时，掌握起来就会更加容易点。比方说，现代JavaScript UI框架是基于组件的，一旦你理解了如何用React建构面向组件应用，就可以在使用Angular的时候利用这种经验。类似地，Redux的思路也可以在Angular里面找到，而Angular的反应式状态管理也在React中通过Mobx实现了。

花点时间去熟悉一下软件开发常见模式方面的经典书籍，比如Gregor Hohpe和Bobby Woolf的《企业集成模式》，四人组（Gang of Four）著名的《设计模式：可重用面向对象软件的元素》，或者Martin Fowler的不同作品。尽管书中描述的一些东西也许已经过时了，但你也可以利用来学习模式是如何演进成今天这样的。

其次，不要匆匆忙忙就赶着去学所有的新东西。我知道，跟踪在Hacker News上出现的新事物是很有诱惑力的，但是其中有很多其实都是杂音。还不如关注一下那些在社区出现了一段时间，已经过了最初炒作的高峰期而逐渐变得成熟的东西。不要陷入FOMO（害怕错过）。如果你起码留意一下发生的事情的话，就不会错过任何重要的事情。

额外提示

本文已经讨论了很多东西，但是在总结前我还有几点想补充一下。这几点主要关注的是个人特质而不是职业上的，但我仍然认为它们对你的工作会产生很大的影响。

分享知识

大家通常以为自己把有价值的知识藏起来会让自己变得不可或缺。如果你的团队里面有这样的人的话，这人也许就会成为你的“巴士因子”，当他离开项目的时候让你陷入困难处境。如果你是这样的人的话，你还得这么想，虽然你的私货能让你变得不可或缺，但也会导致你失去晋升或者休假的机会。你可能会错过组织内其他的职业机会，因为你已经被当前的角色绑死了。反过来，要把自身知识跟同事分享，如果可能的话，把部分工作委派给他们去做，利用这种协作，在他们工作基础上做出更伟大的事情来。

不要责怪自己或者别人

很久以前我记得有一个项目因为我的错出了点事故。我们相当迅速地设法从事故中恢复过来，我记得客户当时是这样告诉我的：

判断一个团队不是看一切顺风顺水按计划进行的时候他们的表现，而是要看出现大麻烦的时候他们的反应。

不管你有多出色，有时候总会出问题，这种情况下能够保持冷静并且用体面和相互尊重去处理就显得非常重要。当火被熄灭后，不要把焦点放在寻找替罪羊上。这不会帮助你在将来避免同样错误的发生，只会在公司内传播恐惧和怀疑。相反，要把受影响的各方聚到一起进行共同的事后剖析。把焦点放在导致问题发生的东西上，找出为什么会发生，并对夏天或工作流可以改进的地方进行头脑风暴，以避免将来再出现这个问题。

不要变成一个混蛋

开发者社区很有趣。一方面我们看到很多开放思维的人通过做开源项目、在会议上发表演讲或者写文章来给社区做贡献。另一方面，我们又碰到过那些高谈阔论新想法的人，对新进入者无礼的人，并且对周围所有人都表现得很粗鲁的人。不要成为这样的人。要怀有善意，要传播爱。

很多职业建议都可以总结成4个字。

总结

我们工作最好的一面在于它没有限制。总会有新的路可以走，总有新的龙等你去屠。不管你是刚刚开始旅途还是一名经验丰富的专业人士，都要谨记这些东西。这些建议应该可以帮助你找到自己的办法，在一步步当中成为一名更好的开发者。

原文链接：https://medium.com/devtrailsio/how-to-become-a-better-software-developer-dd16072c974e

编译组出品。编辑：郝鹏程。