架构师可以说是一个工程师技术方向的灵魂向导，任何一个程序员都渴望成为架构师，刚开始也会觉得架构师是神一样的存在，但是很多时候我们回过头来思考，其实我们很多时候都在做架构。只是我们处理的项目复杂度不一样而已。小到一个小小的测试程序，大到整个企业所有产品技术层面的总架构，我们都是在设计、组织、实现、运维这样的工程。而一个牛掰的总架构师也必然是从一个个小项目的架构中，不断的反思总结，积累经验，汇总方法，最后涅槃成一种成熟、经过验证的架构模式，笑对云云众项目。
在近十个月以来，我大大小小也经历了五六个项目（新文档播放器，视频播放器2.0，云资源播放器SDK，直播，接手营销平台）从无到有的设计、实现、优化以及维护，回国头来突然发现，原来自己也在做项目的前端架构工作。这一路走来，踩过不少的坑，突击过不少的技术难点，也得到了些许的经验，也到了该简短的总结一下的时候了。可能涉猎到的比较粗浅，希望以后再慢慢的深挖。
在我看来，是选择合适的语言、框架、工具，深入的理解业务，用好的设计实现，保障业务的“顺利”“完成”。
上面这句话可能看起来像是一句很华丽的空话，下面通过“顺利”和“完成”这两点深入讲讲为什么我是这样认为的。
怎么理解顺利的完成中的顺利呢？它主要包含以下几方面：
- 开工顺利。在一个项目开始之前，项目架构着要提前做好技术选型：语言，框架，工具等。这就涉及到你的选型落实到开发人员身上，他们是否已经掌握？如果没有掌握，是否在短期内可获得？也就是学习成本是不是较低？另外一方面你选的这个框架是否足够高效？这个框架是否能让你更加的去关注产品的业务，而非一些技术细节的实现？还有，公司级别是否已有一些组件可以拿来用？业务场景是否适合都需要考虑周全，保障开工顺利。
- 开发顺利。开工之后诸多的开发者就要进入密集的开发周期了。这个时候你会发现速度非常快。你以前一个人开发的时候遇到一个问题，可以不着急慢慢解决，但是现在你发现所有开发遇到的问题都会汇总到你这里来，而且必须尽快解决，因为你现在再去慢慢解决，拖慢的是整个团队的开发进度。这就需要开发前对产品需求的深入理解，对功能点的预估，以及可能遇到的技术难点提前想好解决方案。我的经验是：对产品的需求不但要理解，而且要给出合理的意见，对难度非常大的需求，提前和产品沟通，从产品设计上去解决。对产品的理解越深越好，你要把产品都没有想到的逻辑问题提前抛出来，避免开发的中途发现产品的逻辑有漏洞活着冲突。
- 对接顺利。和后端主程一定要经常交流，一些功能的实现，一定要一起讨论，设计。不然会死的很惨。有可能你这样做了，需要这样一个接口，结果他是那样做的，给你了那样的一个接口，这个时候谁也不愿意否定自己已经完成的工作，GG。送你一首《凉凉》。
- 推进顺利。随着开发的进行，会经历这样的一个阶段，前期速度很快，后面逐渐的慢下来，最后可能会停下来。因为前期的代码量急剧增多，整个产品的复杂度上去了，每个人开发的单点都集成到一起，复杂度就是指数级的。如果每个人的代码风格不一样，大家谁都看不懂彼此的代码，然后就GG了。你可能会说都是同一门语言，为什么会看不懂。你可能不知道，程序员的天性是：和自己的代码风格不一致的都是烂代码，而对待烂代码的统一想法是：想删了重写。所以规范的重要性。制定统一的规范，包括代码风格规范，实现规范，目录规范，以及一些常用的，基于框架和项目的最佳实践。而且这件事情做的越早越好，否则，后面调整起来想死的心都有。
- 发布顺利。其实在一堆人都在密集开发的时候，你除了要不时的关注进度，质量，和解决突发的技术问题外，就已经要开始考虑发布的事情了。有的人可能理解起来发布挺简单的，代码扔上去就完事儿了。其实不然，首先发布一般都会有两到三个环境：测试环境，灰度环境，正式环境。对于密集开发阶段，测试环境会密集发布，要考虑发布工程化，要针对不同的发布环境实现发布脚本。对于第一次的发布压力可能会小很多，但是要考虑后面的正式发布，针对发布异常如何快速回滚等等。
怎么才叫“完成”了。以前我们会有个DOD(Defination of Done)概念。对于一个项目架构者非常重要，可以说正是人对于DOD的不断近乎苛刻的追求，才促进自己成长成牛掰的架构师。如果你觉得你的项目开发完成了，那么我问你一下几个问题：
- 需求是百分百完成了吗？如果没有，完成了多少 ？
- 是按时上线的吗？如果没有，为什么？是什么阻碍了进度 ？
- 项目发布后，测试覆盖全了吗？如果没有，线上报错怎么办 ？错误监控做起来了吗 ？监控如果做了，有没有完善的响应机制 ？
- 做了埋点统计了吗？一个新功能，新产品上线，用户的反映怎样样？曝光率怎么样 ？
- 性能优化做了吗？不同网络环境的首屏响应是多久 ？是否还有可以优化的空间 ？如果有，方案出了吗 ？
- 工程化做到什么程度了 ？自动测试做了吗？是否能做到随时发布，随时回滚了 ？
- 整个项目的逻辑完全理顺了吗？解耦彻底了吗？能否应付后续的产品需求改动而快速实现了？框架准备好应对更高的复杂度了吗？
- 后续的架构方案改进计划有没有做？
以上也只是我能想到的，也是在我做项目中去追求，去实践的东西，当然我自己做的还远远不够，但是我知道有这些东西去做。
其实当你开始涉及到架构的工作的时候，就要转变思路，要走在前面。项目为开始就要技术选型，需求分析，功能拆解，制定规范，项目开始后，要处理疑难杂症，制定发布计划，考虑提高效率降低人力成本，提升稳定性。让开发，测试，发布流程化，常规化。
写这些东西，第一是为了总结积累，第二是让以后的新人在走过相同的路时，有迹可循，有方法论，按照这些方面去思考问题，至少大的方向不会太偏。