为什么许多项目的技术方案高、大、上，具体实现却种种问题，代码惨不忍睹？
一、架构师欠缺深入编程的一线工作经历，容易泛泛而谈
许多架构师自身并没有长时间的深入编程工作的经历，在技术上的沉淀不足，导致对于软件工程的理解、目标没有清晰的认识。在做架构设计时，非常容易泛泛而谈，并且给出的方案，太过高屋建瓴，缺乏对具体实现的理解和把握。许多架构设计方案，仅仅停留在PPT上，具体的落实完全依靠一线开发人员。
二、技术选型阶段：技术选型不是出于项目需要，而是个人喜好
在技术选型阶段，较好的团队第一件要做的事情，通常并不是局限在技术本身，而是深入的理解业务，搞清楚自己要做的到底是什么，并且明确的给出期望的技术指标。
在此基础之上，团队会开展多次头脑风暴，共同探讨业务流程中可能会涉及的技术细节，以及可选的方案并制定客户认可的技术指标，这一点相当重要，在项目中不能单纯的追求高技术指标，而是权衡时间成本，人力成本，以及项目经费，制定合理的技术指标。
在这一阶段，许多架构师在技术的选型上，往往更倾向使用自己并不熟悉的，甚至完全没有用过的技术，借此机会提高自己，充实自己的简历。他们可能会选择更新，更激进的方案，不管项目是不是真的需要；也不太懂得权衡技术与成本，不愿意选择看上去好像落后一些但更稳定，更可靠，综合成本更低的技术，片面追求高大上，到了实施阶段，就非常容易出现种种不可控的技术因素影响项目的进度及品质。
三、实施阶段：缺乏对开发团队强有力的管理，存在技术断层
这一点几乎在所有的项目中都存在，架构师在设计好方案或搭建好开发框架之后，团队的开发工作与进度管控完全由项目经理控制，架构师不参与团队管理，大部分时间埋头写文档或自己研究技术，这种情况的项目，几乎必然会出现许多技术上的问题并影响项目进度及品质；很多项目的方案非常漂亮，但是具体实现和代码编写却惨不忍睹，就是架构师失职的重要体现。
架构师除了前期技术选型及框架搭建，最重要的工作，以及架构师这一职位的根本意义，我认为在于对整个团队的传、帮、带。
架构师要能够放低姿态，对整个团队进行必要的技术培训，对代码实现的质量担负第一责任，必要时对开发人员进行手把手的帮扶与指导，关于这一点其实没有什么技巧与方法好总结，只能以我自己的经验来说，过去我带过一个全部由工作经验一年以下的小朋友组成的团队，虽然他们的经验和能力有所欠缺，但是好在都很好学，在项目的前两个月中，我每天要花大量的时间用笔、用纸教他们具体怎么分析怎么实现，然后再去Review他们的代码，刚开始的时候所谓的Review，基本是两个人做在一起，看着我重写，这种方式他们进步的非常快，慢慢的在Review的过程中只需要我少少改一部分内容。不用一个月，整个团队的编码风格、代码品质就已经高度一致（注意我说的是高度一致，不是高水平，但这就够了）。
四、缺乏与项目经理的通力协作
与上一点所谈的问题相辅相成，大多数项目的开发阶段项目经理是主要话事人，架构师不参与团队管理。而理想的情况应该是两个人协同共管、架构师做为司令员，主管开发品质，技术建设，项目经理做为政委，主管项目方向、进度、人员问题及部门协调、客户沟通。
项目经理要有一定的包容心，能够容纳一个架构师与己分权，要给予架构师一定的人事权利，甚至是团队人员绩效考评的第一考评人，没有任何权利的管理工作是很难落到实处的。
关于这一点，大概需要一点缘分。