最近看了一些技术项目排雷书，分几个方面总结了一下雷区，以及可以做得更好的地方。
工程质量 & 复杂度控制
- 预计变化的影响：需求会变化，系统扩展性需要加强，人员在流动。架构师的职责是管理变化，更确切的说，确保变化的影响是受控的。所以以下的技巧是必须的：
- 只进行小型、增量的改动
- 写可重复运行的测试用例，经常执行
- 让编写和运行测试用例变得容易
- 追踪依赖事项的变化
- 自动化重复事项
- 舍弃自作聪明的设计。这样的设计让系统变得脆弱和难以维护。越老实的系统越容易扩展。
- 关注性能。假如不从一开始就严格控制性能，「暂时不用关注性能」的想法就会在团队中蔓延。很快就变成「不得不马上解决线上的性能问题」。尽早在团队里面传授性能测试工具的用法是很有效的方法，真没那个时间的话，对依赖SQL的团队，普及一下explain的使用和结果解析都会有很大的提高。
- 要评估系统的扩展性，那就尝试向多个方向增长业务规模，看看哪个方面会先支撑不住，那个就是你下个要关注的方向。
- 重视界面设计。对于产品的用户来说，用户交互界面才是系统本身。系统的响应速度提高50%当然是好事，但废老大力气的优化很容易就被糟糕的交互带来的坏心情影响。
- 不要迷信设计模式，不要为了使用设计模式而使用。
- 所谓复用，不仅仅与架构有关，还和人有关。如果没有人知道还有个框架，没有人知道怎么复用，再厉害的框架也是白扯。所以文档是很重要的。
- 构建系统并不是一场选美竞赛，不要为了追求完美而主动寻找错误。
- 追踪每周有多少时间用于解决线上问题。
- 一朵起错名的玫瑰会长成卷心菜（我真喜欢外国人的比喻啊）。做某个事情之前，假如连这个事情应该怎么称呼都没想好，那就别开始做了，想清楚再做。
- 如果解决的问题稳定，那么很容易能得到一个可靠的解决方案。但无论开工之前想得多完善，最后的产出总不会是一模一样的。
- 开发过程中的“新想法”要要慎重考虑。因为一个技术很酷而使用，因为框架升级而要系统跟着升级，因为做A而要重构B，因为有一个关于架构的想法而进行讨论，都隐藏着危险的信号。这些事情会带来系统的变化，使项目变得逐渐不可控。
- 选择当下的最佳解决方案去解决问题。假如想太多关于未来的问题，可能既无法解决未来的问题，而且连当下的问题都不能好好解决。
- 量化你的数据。不断加入统计或埋点数据。
- 不走正路的Bugfix就像借贷，是要还利息的。利息主要表现为：系统变得更难以扩展。为了降低影响，合理的做法是，先上bugfix，并投入时间在下次发布之前做一个合理的bugfix。
团队建设
- 提高团队战斗力（确保他们已有对应的工具，CI，code formatter，性能测试工具；确保有对应的技能，每周五对需要用到的技能进行培训，在书本和讨论上投入；引入流程的时候，确保是用来解决问题，而非引入新问题）
- 寻找并留住有热情的工程师
- 自己写JD。
- 技术人员的顾客并不是真正的顾客（是产品人员），我们顾客的顾客才是真正的顾客。因此，需要考虑真正顾客的需求。例如产品为了赶工期要求暂不对数据进行加密，技术人员应该指出风险而不是默默接受，站在真正顾客的角度考虑问题，而不是提出任务的人。
- 工程师和机器打交道，架构师和人打交道，因此要学会Sell自己的观点。如何推销自己的观点：
- 建立起Value proposition
- 用数据说话，尽早建立起监控进行反馈
- 找一个合适的时间提出方案（例如前一个框架被验证是失败的时候）
沟通
- 在讨价还价的过程中先索取得比需要的更多（以在协商中留有退路）
- 挑战并验证假设。是否用户真的不能忍？是否这个库就是比那个库糟糕？
- 做一个好合作、会说话、但并非好说话的工程师。
- 许下承诺和践行承诺才能得到尊重。这就要求我们考虑预算和时间的限制，尽我们所能让系统变得高效。
- 不断地问需求的提出方，需求能不能加上「在任何场合下，总会有……」的概括。由于需求方会比较谨慎地回答这种问题，因此他会不断地修饰和思考需求。反复地问，这样我们就会得到一个非常简洁、核心的「系统本质」。这个本质才是真正的我们需要关注的。
技术选型
- 影响技术选型的决策因素中，需求比经历重要。不要为了简历好看而用新技术。找那些容易和其他模块配合的框架。
- 决定技术选型之前，不妨真正去试一试。找两个工程师，花时间调研一下优点和缺点，总结对比，最后选哪个在很多情况下都是很显然的。这可能是在浪费时间吗？有可能。但总比匆匆找到一个非最优解马上开工最后发现不得不绕回来要好。
- 记录进行设计的依据。记录做了哪些决策，为什么做了这个决策，以及为什么不用其他选择。
- 为任何的技术决策负起责任。很多正确的设计最后却以失败告终。要避免失败，至少做到以下几点：技术决策应该传达给所有相关的人士。
- 选好趁手的工具，不要轻易切换。
工程师的自身成长
- 理解硬件。起码知道系统的状态和什么相关，各种硬件的性能级别，有线上报警的时候能根据报警项定位问题。
- 软件行业的一个大问题是工程师需要解决远超自己当前理解的问题。因此学习与沟通是关键的能力
- 架构师首先是个工程师。假如我做了设计，那起码我应该有能力亲自实现。