͡° ͜ʖ ͡°兼问：编程
三分观点：呈现、跟踪、信息同步
现在已经是信息社会，数据已经成为重要的生产要素。对数据进行采集、存储、检索、加工、变换和传输有很多种方式，其中通过计算机程序的处理方式是最高效的，而编写计算机程序的过程就称之为编程。
计算机软件已经成为信息社会基础建设的一部分了，所以计算机科学也应该成为基础教育的一部分。虽然不要求学计算机的都会编程，但可以做为一种思考模式。 正如乔布斯所说:“编程可以帮助我们完成工作，它没有明确的实用性，重要的是我们把它看作思考的镜子，学习如何思考，我们都应该学习编程，学习一门编程语言，学习编程教你如何思考，就像学法律一样。学法律的人未必都成为律师，但法律教你一种思考方式。所以我把计算机科学看成基础教育，是每个人都应该花一年时间学习的课程。”
为了使计算机能够理解人的意图，人类就必须将需解决的问题的思路、方法和手段通过计算机能够理解的形式告诉计算机，使得计算机能够根据人的指令一步一步去工作，完成某种特定的任务。下面只整理我对于编程方面的理解：
编程发展简介：
首先理解什么是程序（主要指软件程序）？【回归它的原义，本质】
微观：数据+操作（微机时代）
中观：数据结构+算法（高级语言时代）
宏观：对象+消息（面向对象编程时代：OOP）
分布式：数据+操作（微服务、大数据时代）业务内闭环
现在接触的技术层面，都是通过数据的角度去切入，数据--》数据流转--》数据流量控制。
数据流转主要分为：数据读（取值）/写（赋值）
1.方法内： 变量，常量
2.方法间： 参数传递，全局变/常量，静态变/常量
3.系统内： 配置文件，全局变/常量，静态变/常量,文件，数据库
4.系统间：报文（XML，JSON，定长，分隔符）
通讯：理解通讯（TCP/IP，HTTP，MQ，socket[三次握手、单双工、水池机制]）
TCP/IP:相当于定长，分隔符的报文，只能参与方知道什么意思
HTTP： 标准化的通信，相当于XML，所有参与人都能了解意思。
5.框架：可复用的设计构件，提供业务场景的处理机制
6.中间件：支撑（起到连接、沟通的作用）服务的中间软件或服务程序；提供特色服务。
7.平台：所有即角色
参考： Linux 所有即文件，引申--》通讯：所有即报文，报文：所有即数据，数据处理：所有即Map。其他：设计--》图片--》符号（需要准确定义）。
我发现“所有即...”这个思路对于我理解计算机技术的发展非常有帮助。
构建系统的思路（自上而下）：
1. 业务背景：认识系统相关方，参与对象
2. 业务流程：系统通路/回路，谁发起
3. 业务处理：业务逻辑，事务切分，唯一性，有效性
4. 业务细节：理清系统直接相关方所暴露的接口，清晰其所实现的功能与作用
业务系统简单说：记与计。只是记录的系统是相对简单实现的（无非增删改查），通常不会这么纯粹，业务系统的规则会比较多。
所有计算机问题都可以通过加一层的设计来解决。随着应用场景的扩大，空间复杂度的提升，由于看问题的角度不同，关注点不一样，同一类场景出现了不同的解决方案。但基本上遵循时间空间的矛盾：时间换空间，或者空间换时间。
写代码的思路：
1. 把代码跑通，就算是空代码，也要先建立起来
2. 弄清数据流转： 需要哪些数据参与和运算
2.1 检查数据有效性（空？有值？）
2.2 状态有效性
2.3 数据流转
a.直接的对应关系
b.转换关系（字典规则）
c.默认值
d.请求有值，使用请求的值，没有值，使用默认值
3. 理清业务规则： 某些行业有自己的默认规则（如银行存款默认失败，贷款默认成功）； 理解事务概念：要么成功，要么失败。
3.1 业务：事务怎么切分。
3.2 涉及到数据变更：如修改，删除，建历史表；
3.3 分表处理：如数据量大的，当前表和历史表，如流水
4. 编写、测试整个业务流程
5、异常处理：在计算机中，一切都有可能的情况下，特别需要针对异常场景进行容错设计。按经验，这部分的代码会占到4成左右，为什么需要？这么形容吧，异常就像地雷，不小心踩到，特别容易引起连锁反应（如银行账务）！异常的处理机制有4种：
5.1 捕获：捕获并进行相应处理
5.2 抛出：抛出给调用方处理
5.3 拦截：检查数据值、状态值，控制异常进来
5.4 切片：交由框架处理
必须强记一点：每一行代码都有出错的可能，随着技能的提升，经验的积累，越到后面，对异常场景的考虑，越能体现设计者的高度。何时用？一个参考依据：动作的终点。
技巧的本质就是规则，而规则使人成长。自从理清了技术发展的逻辑，我就不追新了，常用的熟练运用，已经足够。但也不是意味着，不学习新的知识，这是两种概念。通常我会注意下面一些规则：
1. 编码规范： 有自己熟悉的，最好是通用的编码规范，如命名、内容格式、注释、复杂度（类[<1500]，方法[<200]不能太长）、日志异常、提交、接口发布、其他
2. 常量化： 常量化也是一种抽象，方便理解和维护
3. 就近原则： 变量定义和使用要尽量在相近的地方，方便管理
4. 嵌套：计算机中很重要的概念，也是生活中很重要的概念。 简单--》复杂
5. 术语：有应用场景的名词解释。像过程，模块，子程序，函数，方法，其实指的是相同的东西，能实现一个特定功能的代码段，只不过这在编程语言不同发展阶段给的相对精确合理的定义。
现在又更加丰富了，加了个接口的概念，这个就非常有意思了，只告诉你我大概要做什么功能，具体里面的实现细节，我只有在确定的场景下才能告诉你。通讯的就更有意思了，术语更是层出不穷。
6. 数据完整: 保存中间数据，结果数据根据中间数据去生成。
针对应用场景的不断扩大，使用计算机来辅助处理的解决方案也越来越丰富，编程思想的发展也是百花齐放。Don't Repeat Yourself.(DRY 不要重复自己)这个我是常常用来警示自己，尽量从以往的代码中重用，复用，维护，更新，首先从概率论角度推论，假设0.9999是单步的成功率，后面是代码行数: 0.9999^1000=0.905 ; 0.9999^10000=0.368。
即白话点解释：写得越多，错的概率越大，而这只是从线性的角度去看，还不涉及到逻辑层面比较隐蔽的问题。
针对应用域提出的解决方案，机制设定也是非常的多彩，其中比较常见的几个机制：
1、分层：分而治之，模块化。分层设计将问题抽象为不同的层次，使得与某层打交道的人不需要了解其他层的信息，比如，写java程序不需要了解java怎么编译成机器语言的。不论从设计、实现、测试还是合作等方面，分层都是非常重要的思想。
2、渐进：这主要是对于解决问题思路（算法）的改进，只要每次接近目标一点点（或者总体趋势在一点点接近）以其庞大的运算能力很快会找到有效解。
3、鲁棒性：健壮性，容错处理，异常处理；现实往往有很多随机因素，一个好的系统应该有很好的鲁棒性。
4、松耦合：
4.1.单体系统，分多个项目，而不是多个源文件夹
4.2 微服务系统，接口先行，不可直接依赖对方库
4.3 接口实现分离，不要依赖对方系统的实现类，建议开发期强约束
4.4 开放封闭原则，对扩展开放，对修改封闭
5.递归。
策略：可以实现目标的方案集合，可简单认为由机制组成，即在这个情况下我这么做，在另外一种情况下我要那样做。
1.轮询：多用于定时任务，关键字：队列，频率，时长
2.优化与折衷：其实计算机说来说去，无非是以时间换空间，还是以空间换时间。
3.池化技术：共同点实现的原理都是类似的，通过对连接或线程的复用，并对复用的数量、时间等进行控制，从而使系统的性能和资源消耗达到最优的状态。实际项目中，我们可以考虑使用池化技术来解决程序性能的瓶颈。
技术实现成熟了，业务多了，后面考虑的是渠道的问题了，像银行中间业务，就是开拓渠道的一种方式，除了渠道，还有一种通道的说法，这二者通常会混淆，我简单做个区分：
通道：对内的说法；转发，没有或很少业务处理逻辑，如银行业的ESB
渠道：对外的说法；指具体的终端系统，有业务处理逻辑
高手到最后考量的是拆分组合的能力。随着复杂度的提高，如何在纷繁杂乱的对象中有个相对正确的认知，不同的人都会有不同的解决方案。
扩展话题：
跟在信息时代前沿，始终感觉自己的知识面太窄，有种不进则退的紧迫感。人最难打败的是自己的懒惰，渐趋于封闭，或放纵，或秃废，或陷于自恋。
“判断一个哲学家或作家的作品是否有价值的前提，就是他是否是真诚的。”这一点，对于做技术的同样适用。
