前面我们聊了很多关于怎么做设计，怎么做编码的事情。我们今天聊一下，什么是真正的技术能力，我们每个人和团队又如何去修炼。
什么是真正的技术能力
每个工程师都怀揣着成为技术达人的梦想。努力地学习着各种新奇的技术方向。执着于争论哪种开发框架、哪种开发语言更好等等。但是，技术的革新实在太快，一路追逐的过程中往往是迷茫的。到底什么东西真正体现了技术水平呢？什么技能才是值得修炼的呢？又如何去修炼呢？
我们先来看一下什么是真正的技术水平。当我们做系统设计的时候，做编码的时候，做线上服务运维的时候，很多工程师都会期待有一个高大上的、一劳永逸的解决方案出现。就会觉得所谓的技术水平就是高手突然间的灵光乍现，就会觉得这个东西需要悟性，无迹可寻。
但实际过程中，根本不是大家想象的那么玄幻，而且也是有路径去修炼的。所有高大上的方案，都是一个个小的问题，被扎扎实实的解决后，最后累积的结果。
这个过程说难很难，说简单也很简单。简单说就是，回到你要解决的问题本身，彻底搞清楚，拆解到具体细节，把细节做到极致。拆解思考的能力和做到极致的心才是真实的技术能力。怎么去修炼呢，就是要重复这个拆解的过程，刻意练习，把他变成你骨子里的习惯。
如何修炼
下面，我们来看看在具体的开发过程中，怎么来修炼。
我们先来看看架构设计阶段。看过了这么多设计思想，是不是就能够信手拈来呢。实际上很难，即便我们把现成的设计思想端来，也往往不能适应我们实际的情况。要解决这个问题，我们还是要回归到设计的本质，明确我们的目标。设计的目标就是解决业务功能和非功能性的需求。明确了这个目标，事情才变得简单、可操作。
比如我们要解决业务功能问题，就需要仔细的研究需求细节。将问题拆解为具体有哪些功能点来实现，每个功能点又有哪些业务逻辑。这些业务逻辑又有哪些特殊的地方，怎么实现才可以让时间和空间成本最合算，再就是有哪些边界的情况需要考虑等等。
比如要解决非功能性需求，那就是考虑未来系统的可扩展性和稳定性。可扩展的点到底有哪些？当前设计里怎么来支持。核心流程有哪些？每个流程的核心节点有哪些，哪些节点是可以降级的呢？整个系统的架构又如何，可能的故障单点在哪，又怎么来备份等等。
你会发现，架构设计没那么高大上。无非就是拆解问题，解决问题，一个个细节考虑到极致。
再来看看测试阶段。是不是采用了高大上的测试工具和技术，就算水平高呢？其实不全是，再好的测试技术和工具也只是一个辅助。我们要先想清楚测试的目标是什么。我们的目标就是尽可能的把功能测全面、测透彻，而且每次变更都要保证质量。比如每次更改了测试环境，上线的各个过程等等。只要有变更就要测。想清楚了这个目标，就可以进一步进行拆解。
怎么测试全、测试透，就是仔细地扣每个测试用例。仔细地看是否覆盖了所有的功能点，每个测试点的边界条件是否都考虑清楚。
你看，高深的测试技术和工具只是提升了我们的效率，但并不能提升我们的测试水平。如何提升？还是明确目标，拆解细节，每个用例仔仔细细的扣，坚决的执行到极致。这样才能真正保证质量。
再看看运维阶段。我们会看到运维工作全是细节。大家可以看看前两篇写的高效运维文章。明确目标，拆解细节，剩下的就是极致执行。再好的监控体系，如果你不重视每一个收到的报警，不找到报警背后的原因，就会造成意想不到的后果。同时，也错过了优化系统的好时机。当系统发生变更的时候，还需要及时去更新监控策略，不要留下死角。我们越觉得不可能发生的事情，就越会发生。
每次系统上线的过程中，任何一个环节没做到位，都会是巨大的风险。我们看这是马虎大意的问题吗？我觉得不是，这是认识是否深刻的问题。如果你疏忽了，就说明你根本没有把他重视到极致的程度。高手与低手的差距就在于此。这就类比职业运动员和业余选手的区别，业余选手可能也会有偶尔的极致发挥，但是，职业运动员能稳定持续的高质量表现。
最后看看客户端的开发。在移动互联的时代，产品的体验只有极致好，没有中庸。中庸的产品就是失败。这个认知是有点反常识的，我们觉得差不多也算及格吧，但是，这里没有及格线。而产品体验都是什么东西呢，就是每一个小处的细节的用心。
所以，一切都是细节。什么代表了技术的水平，不是高大上的设计、技术、工具，而是明确目标，拆解细节，以及对细节极致的把控。
如何修炼呢？针对别人高大上的解决方案，我们不能简单模仿，而是还原他当时面临的问题，看他是怎么拆解的，一个个细节又是怎么考虑的。我们也不能只看几个解决方案，而应该大尺度的看各个行业的大量的解决方案，不好的方案也要看，也要看他不行的点在哪。我们看的是门道，看的是别人拆解的过程和思路。
然后，忘记别人的方案，回到要解决的问题上来。把复杂问题简单化，简单的事情重复做。每个细节做到极致。量变才能带来质变，我们才能有真正的提升。
网友评论