最近处理的一些技术难题的感悟
我从自己的实践来说下对于一些技术难题的思路。当然不同的人对于“难”的定位差异很大，对我而言，难主要在两个地方：一个是自己不熟悉的技术方向或者具体的技术，而第二个难要更难一些，就是自己没有深入的实践经验，很多事情孰轻孰重难以平衡，所以难免要走一些弯路。
第一类难其实相对好办一些，不会就了解，就学习，能够花点时间掌握的事情，主要就是技能层面。技术方面很多东西都是相通的，既然掌握了一门技术，再去学习另外一门技术，其实触类旁通是很有帮助的。在技术细节上有很大差异，但是思路是可以借鉴的。
比如很多开发和运维的同学，对于前端技术就是一个薄弱的地方。 我们没办法什么都做到精通，但是最起码不要很多方面都是空白，一旦成为空白，就潜意识中会成为你的一个瓶颈，做什么事情都会受到牵制。所以这一点上从思想上要说服自己，否则就没有然后了。
比如最近在参与的运维开发，有很多朋友问我使用的技术栈是什么，为什么使用了jquery的方式，不适用流行的Vue或者React呢，在目前的阶段，我的技术栈是经历了静态页面（html）,样式改进（css,bootstrap...）,等到要交互和异步的时候，发现很多都需要JS的支持，而这个学习成本着实也不小，在这里就是权衡了，我是花很多时间去搞定前端还是后端，其实说白了就是两个边界，一个是好看，一个是好用。最后我选择了后者，虽然离好用也还有距离，但是也算是功能的实现了。
对于技术难题的改进，我信奉的思想就是迭代。 除了一刹那的灵感或者绝妙的产品点子，我们很多时候都要一步一个脚印的走下来。前端技术的改进肯定是要做的，我的迭代思路是分为了以下几个阶段：
- 先做到前后端分离，把前端的依赖降低 ，后端的接入使用API化。
- 着重建设后端的设计，后端的建设基本上在功能和性能的保证下，就可以考虑改进前端了。
- 前端的改进是并行的，对于基础的改进，其实更多是在动态交互方面，比如我们做一个数据的增删改查，怎么做是一个相对较好的方式，就是一个页面，不用反复做页面的跳转和链接就能够搞定，这个过程中难免会有很多的交互设计。 这个难点的事情我花了很长的时间，才找到思路，但是丝毫不影响我之前的实现方式。
- 对于前端的方案改进，可以逐步考虑使用一种更加成熟和支持力度更大的框架，这个建设的过程中，我们的后端就会逐步演变为后端 。
后端的技术层面，现在随着业务的接入情况，会发现业务线开始复杂起来，这个时候就需要提前规划和构建更加可靠的服务，微服务是我需要入手的一个方面。在这个过程中会逐步引入一些好的设计思想，一点一点细化起来。
而在后端的功能设计上，任务调度就是一个重点和难点，这个模块的建设虽然有很多思路，但是一个人的力量毕竟有限，还是需要团队和社区的力量。
而在这个运维开发的过程中，在方向的建设中，流程是一个核心的主线，什么事情都要规范，都要流程，标准化和流程化不是纸面上的事情，所以如何落实流程，让流程能够看得见，用得着就是一个难点了。
在安全方面，我们会逐步发现，已经开始有一大堆不规范的脚本或者开发习惯了，里面其实有很多的安全隐患，比如代码中嵌入了明文密码，密码的管理不能联动等。就如同我昨天所说，密码是一个看起来没有意义的字符串，但是它的意义却很大，反而是我们不够重视的一个方面。
所以对于密码管理的建设就是我的一个试点，这个模块足够简单，逻辑足够清晰，我一个人也可以做，但是我希望让一些同事也参与进来，于是可以把进度延后一段时间，在整个建设的过程中，就是一个普惠的过程，要不双方都很累。
以上的思路的核心就是分层，迭代。 很多事情不一定一气呵成，但是可以通过迭代的方式快速实现自己的目标，通过目标的进度把控，让我们对于结果才能够更加可控，否则很容易造成一种互相等待，互相制肘的局面，相对比较被动。
在技术层面，我是开放的，如果有更多的人参与进来，我就能够投入更多的精力把基础架构和设计做得更好一些，在系统的建设上，不能闭门造车，你的系统的价值有一个维度就是和系统的交互，有了系统间的通信交互，就会彼此互相补充和完善，当然也是一种变相的认可。
有些问题确实很难，我们要懂得平衡，或者暂时放弃，不要一根筋卯到底。其实付出和收获不会成正比。
有的同学可能说，我是进来看你说难题的解决思路的，我在这里提供的只能是思路，具体问题的适用面太窄。如果只在技术深度上下功夫，但是业务层面的支持不足，你的工作也会大打折扣。
所以在某种程度上，我们的价值就是解决问题，尤其是很多人解决不了的问题，让听见炮声的人来指挥，才能更加贴近业务和实际的需求。