关于优秀的程序猿应具备哪些编程思维，我也经常问自己这个问题，所以这篇文章聊聊对编程思维的看法，当然我的从业经验有限，不会讲得太学院派，主要是从项目开发过程的实操角度来讲，因此下面讲的一些观点有局限性，欢迎大家留言拍砖或向我提问题。
一．面向对象而不是基于对象的思维
当前大部分编程语言如Java、C++、Python等等，都是支持面向对象编程特性的，这几年我当面试官时经常会问这个问题：你是如何理解面向对象思想的？很多求职者现场都能熟练背书般说出面向对象的三大特性：继承、封装、多态，再问如何使用面向对象进行分析和设计就基本上就答不上来了，感觉他们对面向对象思想的认识仅仅停留在熟记这些概念上，基本都会在简历中写上自己熟悉面向对象思想，但实际上却没能真正理解掌握和运用它，更别说具备面向对象的程序设计和开发能力去解决问题了。同时在项目开发过程中，你也会发现好些童鞋编写出来的代码仅仅是基于对象而不是面向对象的，也就是说还停留在面向对象的初级阶段，什么是基于对象？即是仅仅用了面向对象的封装特性，把各种业务逻辑处理简单地封装成对象，然后杂乱无章地使用这些对象来实现业务，而面向对象是对业务的客观世界关系逻辑进行抽象，并利用面向对象的封装、继承和多态的特性进行对象的设计，判断是否做到面向对象主要看对象的关系结构是否使用了继承和多态进行科学合理地设计，有没“科学合理地设计”是它们的本质区别。
面向对象是一种思维方式，正确运用它使我们更好地进行软件编码构建、组织以及复用，但要想掌握这种思维方式并不简单，面向对象的结构化和模块化编码思维方式需要通过不断地思考和实践运用才能获得，然而很多企业基本都有自己相对成熟的技术体系和架构，很多程序猿只需纸葫芦画瓢地写代码实现业务逻辑即可，不会主动去学习和思考，这样几年下来编程思维方面将毫无提升，这一定程度上减弱了他们的编程能力，所以应该多看那些优秀的开源代码或牛人写的代码，并认真思考自己的每一次的编码设计，及时进行总结和思考，你将会从中逐渐获得面向对象的正确编程思维。
二．软件工程的设计思维
1.一些重要的系统设计原则
当我们理解和掌握了需求的全貌后就要开始系统设计，如网络服务架构和代码架构设计以及技术方案的选型等，这时我们应把握好如下设计原则，总之系统设计不是寻求万能的解决方案，而是追求合适和简单，越简单越好。
把握好CAP原则
CAP是指一致性（Consistency）、可用性（Availability）和分区容错性（Partition tolerance）。
一致性（Consistency）。
一致性指“all nodes see the same data at the same time”，即更新操作成功并返回客户端完成后，所有节点在同一时间的数据完全一致。
可用性（Availability）
可用性指“Reads and writes always succeed”，即服务一直可用，而且是正常响应时间。
分区容错性（Partition tolerance）
分区容错性指“the system continues to operate despite arbitrary message loss or failure of part of the system”，即分布式系统在遇到某节点或网络分区故障的时候，仍然能够对外提供满足可用性的服务。
CAP理论认为：一个分布式系统最多只能同时满足一致性（Consistency）、可用性（Availability）和分区容错性（Partition tolerance）三项中的两项。通过CAP理论，我们知道无法同时满足三个特性，那要舍弃哪个呢？对于多数大型互联网应用的场景来说，主机众多、部署分散，而且现在的集群规模越来越大，所以节点故障、网络故障是常态，当出现故障时可以降级服务，即保证P和A，舍弃C，虽然会影响用户体验，但没达到造成应用无法服务的严重程度。
用好BASE原则
BASE是指基本可用（Basically Available）、软状态（ Soft State）、最终一致性（ Eventual Consistency）三个原则。
基本可用（Basically Available）
基本可用是指分布式系统在出现故障的时候，允许损失部分可用性，即保证核心可用。如电商应用促销时，为了应对访问量激增，部分用户可能会被引导到降级页面，服务层也降级服务，这即是损失部分可用性的做法。
软状态（Soft State）
软状态是指允许系统存在中间状态，而该中间状态不会影响系统整体可用性。分布式存储中一般一份数据至少会有三个副本，允许不同节点间副本同步的延时就是软状态的体现。
最终一致性（Eventual Consistency）
最终一致性是指系统中的所有数据副本经过一定时间后，最终能够达到一致的状态。弱一致性和强一致性相反，最终一致性是弱一致性的一种特殊情况，在互联网应用大量使用数据同步和分布式缓存即是数据最终一致性做法。
BASE理论是对CAP理论的延伸，核心思想是即使无法做到强一致性（Strong Consistency，CAP的一致性是强一致性）时应用可采用适合的方式达到最终一致性（Eventual Consitency），因此互联网应用应该遵循BASE原则来进行系统设计是科学合理的。
2.一些重要的数据库设计原则
其实编码大多时候是在跟数据打交道，即代码是围绕数据结构编写的。良好的数据结构可以提升性能，使代码变得简单、清晰，数据结构清晰，围绕着数据操作的代码自然就清晰。所以我们在进行数据表结构设计要充分考虑如下设计原则。
满足当前需求
这点无需赘述，数据表结构设计必须得满足当前需求。
适当冗余
为了提高性能，利用空间换时间是常用的方法，所以适当的冗余是必要的，严格追求第三范式是不现实的，能做到第二范式已很不错了。
适应可能的需求变化
设计就要考虑需求一定范围的变化，所以预留一些表字段设计适应可能发生的需求变化是完全合理的设计，当然不能过度设计。
应对数据量的高速增长
在设计表结构时要充分考虑好业务数据的增长速度及查询条件字段的情况，如果数据量在短时间内会快速增长且读写频繁的数据，那就要考虑分表甚至是分库，如果是爆增的一般不适合数据库存储了，要考虑大数据等存磁盘的技术实现方式。
3.一些重要的面向对象编码设计（即程序设计）原则
实现业务功能不是如何去完成代码而是如何设计和组织代码，注意，是如何设计和组织代码，设计和组织代码除了要用到面向对象的思维外，个人认为还须重点把握如下5个编码设计原则。
代码重用原则(Code Reuse is Good)
重用代码能提高代码的可读性，缩短开发时间。即是我们常说一些工具类和基类方法等抽出来，免得重复造轮子。
单一职责原则(Single Responsibility Principle)
任一方法代码的功能应该保证只有单一的明确的执行任务。
低耦合原则(Minimize Coupling)
代码的任何一部分应该减少对其他区域代码的依赖关系，尽量不要使用共享参数。低耦合是完美结构系统和优秀设计的标志。
开闭原则(Open/Closed Principle)
即对扩展是开放的而对修改是关闭的，这意味着模块的行为方法是可扩展的。当需求改变时，我们可对模块进行扩展，使其具有满足那些改变的新行为，也即是说我们可以改变模块的功能，对模块行为进行扩展时，不必改动模块的源代码。这个原则比较难掌握，可在不断编码设计的思考总结中实现。
三．做懂业务的技术人
很多程序猿在进行编码实现业务功能时不太愿意想太多，只是照本宣科根据需求文档按需实现出来，至于为什么要做这样的业务功能，其对业务运营作用有多大？有无更好技术代替方案？一概不想，只为做需求而做需求，只做需求翻译机，做得更好些的主动进行技术优化，在我看来，程序猿只做需求翻译机和技术优化机是远远不够的，要想成为优秀的程序猿必须成为懂业务的技术人，这样有助于我们更准确理解把握好需求并能优质地实现业务功能，做产品的主人，能为产品运营提供更多技术支持，同时能为运营寻找更多技术驱动的业务点!
注：部分资料摘自网络。
文/阿青，写代码写诗写职场的程序猿大叔，倾力原创简单实用的硬干货，转载此文请联系阿青。
