架构优化的工作，是提前为业务的将来做准备，等业务需要时再进行技术架构的搭建时间就来不及了。可是在当下，对于业务的现有的架构是合理的，是可用的。架构的升级优化是有风险的，是不确定的。如果你把事情想清楚了，还得把事情讲清楚，获得支持，有资源才可以投入相关的工作。否则的话，这件事就很难获得认可，在推进的过程中遇到的阻力就会大很多。

架构优化的工作，是对现有的已经面向用户的产品的技术架构的优化，这个架构的优化是基于自己之前设计的技术架构，或者是其他同学设计的架构进行优化。之前的架构的存在有的必然逻辑，基于当时的大背景肯定是合理的，并且也有一定的价值的。新的技术方案需要具备足够的理由，否则在推进方案落地的过程中，原有方案的设计者就有可能成为新的方案落地的阻力。

架构优化的工作，是基础的能力的建设，是流程标准的设定。架构的产出影响这个产品中的业务，也就是说架构的好坏会直接影响整个产品中的业务接入成本和研发效率。在架构优化的过程中时，需要对现有的业务进行流程的改造。在架构优化完成之后，对于新业务的接入也是需要参考架构的流程和机制，进行功能的构建。

架构优化的工作，是基于一定的历史的背景，技术和业务的需要，才会发起新一轮的技术架构优化。基于现有的问题，明确解决方案是架构优化的基础，同时也是将来业务上的天花板。这与架构的设计者关注的层面有关，这与近一段时间的业务需要有关，不论怎么样，需要打开想象力为架构赋予更多的可能。

架构优化的工作，是持续进行的，并且是多任务并行的，并且与正常的需求迭代是有冲突的。一般来说一次架构的升级及优化需要花费的时间，至少是月级别的，而需求迭代中的某个功能的实现时间可以使几天获几周就可以完成。在这个过程当中，架构的升级和功能的迭代，一直处于并行的研发状态，直到这两部分的代码合并，上线，查看相关的指标是否符合预期，最终全量架构优化的工作才算是告一段落。。

架构优化的工作，是基于现有的线上的业务进行架构的优化，这就说明技术架构的优化，在上线的之后直接就可以影响，现在已有的用户群体。对于已有大规模用户在线上使用的App是需要考虑架构的升级，直接上线，对于用户的影响，对于服务端的影响，对于流程的变化等等，同时对于相关的指标的影响等。对于这些的影响在架构的设计过程之中，需要进行考虑，具备在出现不可预期的情况时可以有效地止损的能力。

架构优化的工作，是以技术为主导的，是带有一定的目的性的，是要解决现有的问题的。 这个理由需要足够的充分，并且足够的容易理解，有经常性的使用场景，符合长期的发展规律。符合团队的大的目标，同时也符合协同的伙伴们的预期。不论是目标已经确定去做，还是这件事情还是问题发现没有确定目标，最终作为技术研发的同学在确定架构优化方案的同时，也需要明确架构优化的目标。目标和方案的区别在于目标是大家要完成的最终的效果，而方案是实现这个效果的具体的手段。同一次技术架构的优化，可以有多个目标，一般来说一个目标可以有多个方案。

架优化的工作，大部分是重要，而不紧急的。也就是说，在持行的过程中，存在资源被调整，人力不足的情况。这就好比一家人，家庭的收入决定一家人的生存问题，而培养下一代有前题是先活下来，如果有了下一代，家长把精力投入到陪娃还是赚银子，这得看家长陪娃时，这一家人的生存是不是问题是吧。如何让家长把精力向陪娃倾斜，这还真是个头痛的问题，总不能让娃总哭吧，娃也得长大。

架构优化的工作，是支撑业务的产出，在架构优化完成之后，能拿到一部分收益，同时在后续的版本迭代，业务和技术的需求在上线的时候，也会因为架构的变化产生收益。也就是说架构优化的工作，对于业务和技术的收益评估是一个间接的过程，是一个持续的过程。这个过程当中存在的很多变数，坦白的说这些变数就是风险。