程序随感
程序随感
1 潜规则
各行各业都有“潜规则”，程序也不例外：顺序、选择、循环
顺序（main），即底层逻辑顺序；判断（if），即业务标准或规则；循环（for），即日复一日坚持。
2 关系
在社会上，没有一处人事关系不复杂。其实，程序也一样。
在软件项目（工程）的大系统中，对象与对象之间的关系也很复杂。
3 辈分
在现实中，往往存在排资论辈的现象。
在程序中，一个对象继承于谁也非常重要。
4 比较
在程序中，想要比较两个对象，必须先保证类型一致。
正所谓在现实中，有些东西不可相提并论。
5 找对象
程序员不好找对象与职业有密切原因。
长期从事编程工作很理性，逻辑思维强，而感情恰恰没有逻辑可循，太理性不宜与女孩子沟通。
比如，绝大多数女孩子分不清楚东南西北，要换种方式用前后左右来描述交流。
6 类比
所谓类比，即同类问题对比分析。
计算机程序本质是对现实世界的模拟，那么：
每一条语句、每一行代码客观上都可以映射到现实世界中每一种具体应用。
7 类与对象的关系
引用刘润这句话加深理解：不抽象，我们就无法深入思考；不还原，我们就看不到本来面目。
认知事物和思考有两个基本的逻辑法则：归纳法和演绎法。
归纳法是从个别到一般，终极是程序中的基类；演绎法是从一般到个别，即所谓的派生类（子类）。
8 核心竞争力
客观上，每个公司都会有很多坑，公司招员工进来就是为了填坑，即解决公司遇到的问题。
所谓核心竞争力，即解决问题的综合能力。
从微观而论，遇到一个严重BUG可以认为掉坑里去了；
由宏观而论，入职一个公司其实也就是跳进了一个大坑里而已。
9 并发症
医学上，患糖尿病时间长了会引起一系列并发症。
其实，程序也是一样的，当一个坑不及时解决，程序演化得越久可能会引起更多的并发症。
10 没有绝对的正确
在程序江湖也是如此。
比如，很多语言逻辑操作符都认为0为假，但是Lua语言就认为0为真，仅有nil或false为假。
11 填坑力
每个公司都有很多坑，每个公司招聘员工都是为了填坑，所以工作的核心正是填坑。
填坑力是一种核心竞争力。
12 不世故
理解计算机系统比理解人简单，因为她不世故，一视同仁，不讲人情，没有主观情绪。
13 现代简约式Python
装修行业有个推荐风格：现代简约式。
编程语言也类似，Python语言就对得起这个风格，现代、简约、优雅。
14 可重建性
可重建性，即可重新构建的特性。
软件与实体的主要区别在于其可重建性，若发现重大问题，修改代码，可重新构建新的版本。
假如建一座大楼，一旦建成后，发现有什么致命的缺陷，想推倒重新建一次，是非常不切实际的。
但是，软件可以实现这个理想，其实，也可以理解为试错成本低。
当然，这也可以被认为是软件世界发展快的一方面因素。
15 场景
程序开发的前期预研阶段，需要尽可能考虑清楚功能或问题的所有场景。
比如，人与人之间的利益关系场景：
损人损己、损人利己、损人不利己，利己不损人，利己利人、利人不利己、舍己为人。
共七种可能性。那怎么可以考虑全面呢？
必须有个内在的逻辑，如上按境界由高到低进行归纳排序，越往后境界越高。
16 综合能力
什么叫综合能力？不能仅仅会一方面，要兼顾相关方面。简单理解：
作为程序员必须要会修电脑；作为厨师必须要会修电磁炉；作为理发师必须要会修吹风机。
17 内在技术 外在业务
作为一名程序员，始终要保持学习状态，对于技术的要求，必须是内在的动力。
因为公司侧重于利用你，而不会花太多时间或财力培养你。
对于工作的考核，公司更侧重于业务培养，而业务的实现本质上依赖技术的支撑。
因而所谓，内在技术，外在业务。
18 系统性
所谓系统性，坚持从整体性原则出发，考虑问题时坚持立足整体、统筹全局、把握规律。
成为一个做事情拥有一套完整科学方法的人。
19 人、事、方法论
在公司工作，概括起来 ，每天不外乎三样事情：人、事、方法论。
20 增删改查
增删改查是代码程序中最常见的行为操作，其实还是那句“计算机是对现实世界的模拟”，反观生活中的网购：
下单算作增，退货即删，换货即改，货比三家即查。
有时候，甚至觉得，家里的某件东西（比如：剪刀、胶带、钳子等）都可以如此理解，用剪刀来举例：
买了一把剪刀，即增；
扔了一把剪刀，即删；
换了一把剪刀，即改；
在诺大个房间找一把剪刀，即查。
综上所述，想表达的是，家里用东西一定要有固定的地方，因为如上分析你会发现查是最频繁且浪费时间的行为。
21 每个函数都不简单
一个类中每个函数对应着就赋予了此类的对象某种能力，所以，每个函数都不简单。
22 认知
人与人之间最大的差别不是智商或财富，而是思考问题的层次和模式。程序员尤其需要提升认知维度。
比如，一个优秀的开发人员，会在需求人员进行需求交底时，挖出需求人员真正的潜在期望。
有了这个能力，就为方案设计时争取更多的主动权，也为程序未来的扩展性奠定了基础。
其实，个人认为，所谓认知就是抽象、归纳、总结的能力。
23 高手
三百六十行，行行出状元。承认每个行业都有高手，那么一般怎么能识别出高手和一般人呢？
看问题抓本质，高手可以把很专业的领域内容通过形象的类比解释得通俗易懂，人人都能理解并欣赏，老少皆宜。
一般人是把简单的专业名词包装粉饰装潢搞得让同行业都看不懂，反而觉得自己很牛逼的人。
24 底层逻辑
其实，“底层逻辑”这个词是由《毛选》造出来的。
事物发展的底层逻辑是什么？如何一眼看破？翻开中学思想政治课本，读一读这句话：
事物的内部矛盾，是事物发展的根本原因。
所以，底层逻辑纯属快餐知识学者造出来的词，其实本质就是推动复杂事物发展内在的主要矛盾。
25 “温开水”需求
生活中，经常被医生告知，饭前用温开水服用药。那么，温开水到底是什么样的水呢？你心目中对温开水认知与医生所要求的温开水一样吗？温开水到底是多少度的开水呢？
作为开发人员，每个迭代都要做需求分析。在需求分析过程中，时常会遇到不确定性的用词，比如：”计算结果对精度有要求“、”对用户输入值要有合法性校验“、”按钮大小要求适中“等等。
这种描述都可视为不完整需求，因为计算机需要确切数据值才能进行比较判断，而所谓的“精度要求”、“合法检验”、“大小适中”都不够精准，类似于“温开水”问题。
经过百度，温开水定义：将新鲜开水凉自然冷却至20～25℃（也可以将开水事先冷却，到使用时再添加新开水，冲兑至适口温度）。
到此，已明确[20,25]这个区间就是温开水的温度范围，这个才是计算机真正关注核心。
26 业务是骨架，数据是血液，架构是灵魂
业务，决定一款产品最终成长为何种模样。
数据，流经一款产品任何地方，驱动产品生命力。
架构，假使产品不存在，架构也灰飞烟灭。
27 程序员本质是翻译员
程序员工作日常：
- 把 产品需求 翻译为 各个用户故事的实例化文档；
- 把 实例化文档简单 先翻译为 概要设计文档；
- 把 概要设计文档 再细化翻译为 详细设计文档；
- 把 详细设计文档 翻译为 各种代码；
所谓自测，就是把代码运行结果与最初的产品需求进行核验，若计算机反馈与需求期望一致，视为通过；
否则，检查各个环节的翻译缺陷，修复问题。
但凡任何一个环节出现信息失真或执行差错，即程序出现了BUG。
28 选择等于放弃
在程序世界中，如果程序执行if块中的代码语句，那么else块中的代码语句必定会被放弃。
在现实世界中，何尝也不是如此呢？
人生中最重要的事都是单选，你只能选择一所大学、一座城市、一个爱人、一种生活等等。
大多数人无论怎么选都会后悔，因为选择的本质是放弃。
而你之所以后悔，绝大多数都是心底无法坦然接受放弃的部分，要学会断舍离。
有句话说：“人一辈子都在为自己的选择买单！”，其实，每个程序的每次运行过程又何尝不是如此呢。
29 交付
在软件工程领域，经常会听到按期交付的问题，那么大家对“交付”标准是如何界定的呢？或者说如何理解的呢？
为了便于大家理解，类比举个生活中例子。比如：老婆让你去把家里垃圾倒一下，这个任务交付标准是什么呢？
第一步：把家里待扔的潜在垃圾都收拾一遍，保证倒垃圾时候没有遗留（即本来要扔但没有在垃圾桶中的）垃圾。
第二步：弄清楚家里垃圾桶个数，准备相同个数新垃圾袋。
第三步：分别把垃圾桶中垃圾袋都收拾（垃圾袋口扎住）一下，同时把新垃圾袋都套到垃圾桶上以保证垃圾桶可正常功能（如果不套垃圾袋，垃圾桶没法正常行使功能）。
第四步：下楼扔掉所有倒换的脏垃圾袋。
第五步：向老婆汇报一下垃圾清理任务完毕（即向上汇报的重要性）。到此，任务才算完成或按标准交付。
很多人都会忘记给垃圾桶套上新垃圾袋，导致任务交付不达标（因为别人无法正常使用垃圾桶），却总以为已完成任务。
30 架构师—中医，研发员—西医
软件行业发展到现在，不仅借鉴了建筑行业积累的很多经验，也学习了很多医学理论。
医学的最高境界是中西医结合。而在软件行业也存在相关“映射”。
比如：架构师，类似于中医，会对软件的各个系统（器官）进行精细的设计或研究，以达到最优性能（“健康”）。
研发人员，类似于西医：
负责界面视图层面实现的人员好比“皮肤科”科室医生，专攻这个界面方向；
负责计算引擎层面实现的人员好比“心脏科”科室医生，专攻这个计算引擎方向；
负责内存泄漏层面实现的人员好比“内分泌科”科室医生，专攻这个内存泄漏方向；
当然，一个医生一般都会分析处理其它科室的问题，一个程序员一般也会修复其他模块的问题即Bug。
闻道有先后，术业有专攻。中医有治病求本、防患于未然的优势，西医有辨病直观（各种仪器）、治疗效果快等优势。
一般大医院都会有针对病人进行会诊的场景，其类似于研发经理邀请架构师和各系统（模块）主责程序员开会沟通某个复杂功能大同小异。
