用户思维
代码的抽象源自于现实世界，产品未来的受众必然是给人看的，与人交互的内容要面向用户，除了一些是面向业内人士，另外的产品要面向大众，不管是C端用户还是B端用户，想让用户看的懂，能用、易用、好用。比如一个交互页面上的必输项校验时抛出异常：“ID is required"，这是ID必输提示语，普遍用户看到会完全摸不着头脑。正确的做法应该是稍做加工包装后再反馈给前端用户，比如”请输入身份证号“，简单明了，客户就能轻松发现问题所在。普通用户不具备软件专业使用能力，所以要尽可能站在他们的角度思考问题，否则开发出来的东西使用门槛很高，用户群体必然会很少。产品的迁移成本当下是很低的，因为一个色调的问题都有可能导致用户大批出走。
产品思维
写代码的如果看到只是代码，还处在一个比较低级的层次，只见树木不见森林。代码的集合是功能，功能的集合是系统，系统的集合是产品，产品的集合是生态。一定要看清代码背后的价值，这堆代码最终面向的用户是谁，能产生什么价值?或是个人价值，或是业务价值，或是社会价值。还有一个注意点：把产品当成一个完整的，可以交付给用户使用的是个很重要的理念，而不是一个独立的功能，独立功能再强大，产品不完整，同样不会有用户使用。举个栗子：很多产品场景中需要实名认证，并提供扫描身份证自动识别功能，识别率很高不代表不出错，当出现异常情况时，应该请允许用户手动调整信息，如果不提供入口，这一功能的不完整，导致后续一系列操作都无法完成。
工程思维
软件工程作为工程类中较为奇葩的一点在于，其生命周期有可能很短、返工率很高，不像路桥坝堤工程，规划完成后，需要结合大规模实施团队使用大量的工程机械进行严格施工，花费大量的时间成本、资金成本、人力成本，这些工程遵守现实的物理定律，力、电、热、能量等等，而软件工程除了硬件设施，其它基本由不可见的、不可量化的脑力思维活动组成，更多的是时间成本。构建之初，就要基于软件工程的思想指导实际工作，凡违背软件工程的基本规律的实施过程，规律必然会反作用于项目或产品，必须是先设计再编码，否则写到后期会发现很多不合理，必然导致返工。前期调研不到位，必然会做出来一堆没有市场的东西。质量、速度、成本是软件工程的不可能三角，只能平衡，不能打破。
这是职业规律，抓住重点，就相当于摸清了脉络，从哪里来到哪里去，也就容易回答的多。规律可以指导实践，实践可以反哺经验，不断的拔高层次，来提升一个小小技术的格局。
以上三点，不难做到，稍做留意，稍加训练，后期即是习惯。
