工程师思维之工程思维，我们应如何理解与拥有？

工程思维的起点是流程。流程的背后是科学，以既定的步骤、阶段性的输入 / 输 出去完成价值创造，通过过程控制确保最终结果让人满意。由于流程涉及每一个工程 师的工作质量与效率，其含义不只在于定义、工具化、检查等内容，而是应基于工程 师的日常工作习惯，将流程与工程师的工作环境无缝整合。“无缝”体现于流程中的 概念与工程师群体已建立的专业常识相一致、没有增加毫无价值的负担，根本仍是确 保易用性。 机制的含义是通过对所需解决问题的分析，以一种模式去解决同类问题。机制应 体现一定的系统性，而非“头痛治头，脚痛治脚”。系统性不是一开始就能被洞察到， 可能在演进的过程中逐步发现和完善的，因而需要工程师在工作的过程中不时回顾并 付诸实践去落实。对于工程师来说，机制是通过系统性的软件设计去达成的。 可以说产品质量直接决定了工程师的工作和生活幸福感。一个质量不可靠的产品 一定会给用户和工程师自己带去麻烦，甚至造成无法挽回的经济损失并造成负面的社 会影响。对于工程师来说，那势必打乱个体的工作与生活节奏。为了让产品的质量做 到可靠，单元测试、静态分析、动态分析等确保工程质量的手段应成为工程师的基本 工作内容，通过将这些手段与 CI（Continuous Integration）流程进行整合去持续构 建起对软件产品的质量信心。 在互联网行业，除了软件产品的质量得可靠外，风险可控是另一个不能忽视的内 容。而风险可控是建立于系统性机制和质量可靠之上的。对于服务端软件来说愈是如 此。风险往往出现于资源使用的极端场景，当从外部涌入的过多事务远超软件产品的 处理能力时，需要有一定的机制让整个产品能相对平滑地应对，或是扩充资源、或是 限制涌入事务的流量。 软件所需的机器成本是比较容易忽视的话题，软件成本不只与软件性能相关，还 与软件之间的依赖、技术方案等因素相连。当一个软件需要从公司的内部对外输出 时，平时忽视对成本的关注就会暴露出成本问题。比如，为了运行某个软件需要数量 庞大的计算资源，所导致的资金开销对于客户来讲很可能是无法接受的。 至此，大致介绍完了自己所理解的工程师思维。