编者按：要想成为一名软件开发者需要学习各种专业知识、技术与框架。比如算法、数据结构、编程语言、流行框架等。但是要想成为更加出色的软件开发者，你要学习的就不仅仅是专业上的知识了。devtrails.io的编辑Pavels根据自己的经验提供了相关建议，供各位想在新年更进一步的开发者参考。
今天我想分享一点关于软件开发者如何改进职业技能从而变得更擅长于自身工作的技巧。这里要谈的主题是通用性的，并没有针对任何特定的技术栈。其实这里要谈的大部分甚至都不是针对IT的。这些都是如何形成个人特质，跟同事、客户改进协作，以及拓展作为软件开发者职业生涯的一般性建议。
本文里面有些东西属于主观性判断，反映的是我的个人经验，还有一些则已经被其他人采纳并成功运用。
端到端理解整个流程
很多开发者认为软件开发纯粹就是写代码，其他事情根本就是别人在打扰自己，浪费他们宝贵的时间。这种说法距离事实再也不能再远了。在你卸下第一行代码之前，需要经历从模糊到精心设计准备可以实施的解决方案这样一个转变过程。当你把最新的变更推动到Git之后，软件需要经历测试、部署、监控、分析以及改进等过程。编码只是流程众多步骤之一而已。
为什么会这样？因为项目的不同阶段经常是由不同的团队甚至不同的部门来处理的，大型组织尤其是这样。一切都先从收集需求的商业分析师开始。需求然后递交给设计师，为开发者输出原型。开发者编码把结果提交给QA工程师。如果一切都OK，成品就会发送给运营团队交付给最终用户。这个流程被当作一组离散的步骤，没有任何反馈。因为部门间缺乏沟通，其代表通常并不真正理解别人的目标，这会导致误解甚至冲突。
软件开发流程往往被当作一组离散的步骤，没有任何反馈。
对于现在的很多人来说这种说法似乎太过夸张。随着敏捷方法论的崛起，更多的公司已经从此类僵化的做法转移至混合不同专业的小型化团队。但即便这样我们也还是看到大家并不真正理解别人的工作。你有多少次因为设计师要你实现一个太过耗时的定制化复选框而被激怒？反之亦然，你又有多少次因为忘记使用正确字体而受到指责？
这些差异很多都可以克服，如果你留意别人的工作的话。跟你的设计师坐到一起，解释给他听，说实现定制化复选框要花点时间，但是有个库可以提供你可以重用的类似复选框。反之，你也得学习一下字体排版基础，理解为什么选择正确的字体会有影响。对待经理、商业分析师、QA工程师、支撑人员以及营销专家等也要养成同样的态度。借用赫胥黎的话来说：
尽可能广泛地涉猎各门学问，并且尽可能深入地择一钻研。
通过尽可能广泛地涉猎各门学问，你将能够预测他们的需求，简化反馈回环，促进更频繁的交付。此外，这还会为你赢得很多的爱以及所有其他人的尊重。
理解你客户的需求
关于你的客户，有一件重要的事情你需要理解：他们并不理解你做的大部分事情。敏捷、函数程序设计或者非关系式数据库对他们来说都是黑暗魔法。甚至那些密切跟进你的工作并且真心感兴趣的人仍然大部分都不了解。这会有几个后果。
大多数客户跟软件开发者交谈时的面部表情。
雇软件开发者需要有一定程度的信任。要为某个自己不理解的东西支付一大笔钱的时候大家往往会觉得不舒服。还记得上一次你走进一家不熟悉的汽车维修店却不担心他们是否值得信任是什么时候吗？你的客户也会有同样的感受。只是这里没有车，而是一堆抽象的、不可触摸的概念，你得将其具体化成产品或者收入。跟新客户合作是赢得他们的信任非常重要。确保他们理解你是怎么工作的，然后小规模频繁地交付迭代结果。这样他们就能看到你的工作进展，评估中间结果并且提供他们的反馈。
客户经常会提出他们自己的解决方案而不是分享他们的问题。由于他们对你的能力几乎一无所知，他们的解决方案往往会误判，不是过于保守就是太过激进。记住亨利·福特的那句老话（也可能是杜撰的）：
每当我问顾客需要什么的时候，他们总是会说需要跑得更快的马。
这时候你不能总是默默地按照他们的要求去实现，有时候请他们先后退一步讨论一下自己想要解决的问题是什么会很有用。在结合了他们的领域知识与你的专业技术时，你就有可能得出一个更好的解决方案。
记住，并不是每个人都喜欢自己的想法受质疑，这种策略需要你机智一点，不要挫伤客户的信心。你还得离开你的舒适区，让自己沉浸到他们的业务当中，从而真正理解问题所在，推荐更好的解决方案。如果你要做的是金融或者医疗保健等复杂行业的话，这会比较有挑战性。但如果你搞定了一次，下次客户的心态可能就会更加开放一点。
为工作选择合适的工具
如果你手里只有一把锤子，其他一切看起来都像钉子。
只学了一门技术的开发者往往会急急忙忙就想用它来解决遇到的任何问题。毫不奇怪，这种做法会导致次优结果。相反，在处理新问题时，要停下来思考一下你手头的工具是否真的适合这类工作。如果你有疑虑，就要做点调查提出一组可能更加出色的替代者。为了让这个过程简单一点，可以编译一个问题清单来评估不同的选择。每次评估的问题可以不一样，但大概可以是这样的：
回答这些问题应该有助于你在脑子里构思相关选项，将可选的名单范围缩小。
安全地进行试验
识别你首先需要测试的东西。采取“快速失败”的办法，识别在得出实验结论前你需要评估的关键东西。对某个系统的性能有疑问？做一个最小化的原型然后进行负载测试。对特定库或者与外部服务集成不确定？单独实现它然后开发剩下的。
记住，这条路走下去对你和你的客户来说依然是有风险的，他们需要意识到这样既有风险也有潜在的好处。毕竟，从长远看，2周的调查可能可以省下几个月的时间，这听起来像是个相当好的交易。即便试验失败了，你也只损失2个星期。你的客户对你的信任越大，他们就更有可能同意类似这样的事情。
站在巨人的肩膀上开发
重新发明单车往往会导致怪异的结果。
做IT的往往有两个常见特征：善于独出心裁并且欣赏自己的工作。这听起来是件好事，但却会有尴尬的副作用：对于此前已被解决的问题，我们往往会想出自己的解决方案。所以只要我们面临使用某框架、库或者服务还是自己实现的选择时，我们往往会选择后者。这会让我们走上重新发明单车这条徒劳无功的道路。导致这样的一些常见的误解包括：
通过重新实现来学习
这个故事还有另一面。自己重新实现某样东西其实是很棒的学习方式。尽管给生产项目写自己的框架几乎永远都是坏主意，但是做来作为学习练习就非常有价值。通过用自己的办法重新解决一遍同样的问题，还有比这更好的熟悉待解决问题的方式吗。不过兔子洞不要钻太深，一个简化的粗糙实现就足以让你了解情况了。
在做的时候，不要羞于参考类似项目的做法。研究开源项目的代码可以让你从更有经验的开发者那里获益。
按照你的工作方式工作
争取改进不只是技术方面，也要在方法上。就像设计得当并且优化过的软件一样，一个固定下来的工作流可让你少费力也没那么大压力就能产生更好的结果。确定一套既有效率又有效能的工作流程并不是容易的任务，这方面有无数的书本和材料。不过就起步而言，可以考虑以下的改进之处：
记住，没有可适用每个人的流程，你需要在自己的环境下试验一下。此外，要确保你完全理解流程并且正确地实现它。要从已经走过该流程的团队那里寻求建议，从他们的经验中获得一些东西。不要忽视有助于你采用该流程的软件和具体工具。弄一块真正的看板以及一个现代的平台用于持续交付。采用新流程需要付出努力，甚至还会导致短期内生产力的下降。要给它一些时间然后对事情是否有改进进行评估。
排除障碍
排除障碍这事儿得单独说说。忽视看似不重要但对你的工作却有毒性作用的小麻烦是常见的错误。你的设计师是不是单独坐一间房或者在另外一座建筑内？这意味着他过来讨论要费点功夫，有些事情就不会得到讨论。写心的测试是不是很困难？那就会有很多东西不会经过测试。
这些做法本身并不是特别危险，但是小事情积累起来往往会导致严重后果。令人不快的是，等你注意到这些事情是往往已经太晚了。尤其是在你总会有更严重的问题要处理时。还记得温水煮青蛙的寓言以及蔓延常态（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（害怕错过）。如果你起码留意一下发生的事情的话，就不会错过任何重要的事情。
额外提示
本文已经讨论了很多东西，但是在总结前我还有几点想补充一下。这几点主要关注的是个人特质而不是职业上的，但我仍然认为它们对你的工作会产生很大的影响。