对自己能力的两个要求:架构的能力和解决技术问题的能力

Posted by LuckXiang on April 29, 2018

架构

架构就是控制事物的熵。之前复杂度在脑中只是一个抽象的概念,现在渐渐觉得复杂度本质是自然规律的反应,熵越高,复杂度就越高,当熵达到一定程度的时候,事物就寂灭了。我们做的种种努力,都是为了减少熵,或者减少熵增加的速度。大到国家,小到家庭。人人各司其职,井然有序,我们就说这个国家是一个和谐的国家,家庭是一个和谐幸福的家庭。由此推之,架构能力高,说明一个人能控制的熵越高。在别人掌控不了的情况下还能去抽丝剥茧。把熵给降下来。虽然我并不知道熵和美之间是否有足够强的联系,然而一个极度混乱的事物,显然也不能带来美感。其他先不谈,我先探讨一下软件的架构,软件开发的产出是一个实际可用的产品,产品在公司内部来说是为业务提供服务的。因此业务需求是导致熵增加的一个主要原因。只有从业务出发,才能理清软件的关系,什么是需要的,什么是不需要的,后续产品可能往什么方向发展,了解了这些,再根据公司的实际情况去选型具体的技术,创建合理的框架。架构需要几个能力,识别问题,抽象,组合拆分。自己的学习思考方向也就是这三个类别。

解决技术问题

解决问题需要准确识别问题的层次,然后在问题的层次上严谨认真的思考试验。最后得出一个解决方案或者不可能解决的结论。原来在公司很重要一部分工作就是处理核心客户的技术问题,自己这一块还算比较资深,拿到一个问题,通常需要经过以下几个步骤:

  • 1.简单分析,确定问题优先级。
  • 2.重现问题,明确具体是什么问题。
  • 3.分析问题,确定问题在哪一个层面哪一个模块,应用,内核,还是驱动,硬件。
  • 4.进一步分析问题,确认问题是新引入的还是遗留问题。
  • 5.针对不同的分析结果采用不同的技术去定位问题点,比如网络问题就抓包,新引入的问题就对比修改部分代码,应用就上调试器单步调试,驱动问题去看寄存器状态,硬件问题丢给硬件处理,配合做一些分析测试。不熟悉的功能就去看文档,查资料,读代码。
  • 6.不管问题有没有处理,都要出具处理报告,解决的要说明解决过程,不能处理的也要说明原因。
    解决问题是一件让人很兴奋的事情,然而技术人员也要知道,问题不一定要解决,不一定要自己解决。处理问题之前一定要了解足够多的信息,不然很可能白忙活一场,浪费时间。

社会在快速发展,技术层出不穷,然而我想往这两个方向努力总不会错,大道至简,渴求入无人之境。自己的架构能力还很欠缺,以前在公司只设计过一个基于duktape的js插件系统,对架构的理解还有很多不足的地方。现在在做物联网方面的产品设计。 Stay hungry, Stay foolish。加油。