2018年/10月/01日
读到的一些文章
我觉得这三篇文章都写得很好，摘录于此，可再往深处思考
教育和管理
教育是一个困扰我的大问题。
14年，16年，我家里添了两个可爱的小生命；可同时，如何教育他们，让他们长大出人头地；或者至少自食其力，不危害社会，成为我考虑的一个大问题。
我媳妇信奉的是“高端”路线，简单的说就是：上最好的幼儿园，上最好的小学，上最好的初中，上最好的高中，然后自然大概率能上最好的大学，成为最杰出的人。当然这只是一个粗粒度的路线图，只是这么干肯定太低级。除此以外，各种培训班报起来，体验课报起来。日常妈妈爸爸吃饭，走路，穿衣，说话……都有严格的要求。
对这一套，我毫不感冒。 皇帝也不过如此吧，但皇帝成材率如果扣除掉那几个不符合“党的路线”的开国皇帝，实在低的可怕。
前几天，朋友圈有人矫（de）情（se）说买个机器人，陪娃一起组装到深夜，并感慨“他们要学习这么努力就好了”。
其实，我们现在的工作（搞IT），在老的那一辈眼里，多数是玩物丧志。 在乡下，无数家长对孩子钻网吧里玩计算机深恶痛绝（现在也是），视为洪水猛兽。在城市里，就稍微好一点。甚至部分家长会刻意加以培养和引导。而农村那些玩物丧志一直丧下去的，无非就是缺乏了那么一点引导 以前家长眼中玩物丧志耽误学习的篮球，足球；现在的电子竞技，是不是一样呢？
有时候，是我们自己太局限，是我们自己不懂，是我们自己没有能力去点拨，去引导孩子。而并不是孩子的错。 我们作为家长，是否有足够的眼界，能力，去引导孩子从兴趣，走向专业性呢
大多数的家长，都是用自己的人生经验，去衡量孩子未来的发展。中国有个故事描述了这类事情，叫什么…… 刻舟求剑。
以前社会发展较慢，尚且可以求一下；今天的我们已经和我们父辈有了巨大的思维和生活鸿沟，有什么证据证明将来变化的不会这么快，而我们基于自己过去的生活经验做的正确决策就一定对未来的孩子们是有帮助的？
除了是一个爸爸，我还是一个TL，还要对团队负责，有时候我发现教育团队和教育孩子，原则上没有区别。
作为一个研发团队，团队很多成员，喜欢钻研新技术，虽然多数其实都没什么用；我是鼓励还是反对呢？ 甚至偷偷在业务代码中用，还常常出各种问题，我是鼓励还是反对呢？
比如，有些人喜欢研究操作系统，有些人想写个浏览器，有些人想写一个宏大的无所不能的系统但是也不知道怎么弄，反正可以先弄起来……
我不能反对，我怎么能确定我一定对呢？我怎么确定，这些工作某个时候不会对我们有帮助呢（大多数时候永远不会）？但是我怎么能确定，他们不会因此而在思维或者能力上有所进步呢？只要他们努力了，并且不是作恶，为什么要局限他们 ？ 我有什么理由断定今天正确的事情，明天依然正确？ 而团队，在明天，靠谁？
某种程度，传统企业相对于互联网企业，就是失去了对瞎折腾的宽容，所以失去了活力和创新。
所以我不想孩子们朝我设想好的套套里去套，去填满他们的时间，让他们在我或者别人看来无所不能。我宁愿有时候他们自己玩，发呆，奇思妙想，甚至荒诞，充满各种可能性。
而我的存在，只是为了避免最坏的情况发生。 在铸成大错的时候，去保护他们；在有其他各种可能的情况下，让他们尽可能的发挥，获得尽可能的成就。
我曾经听到很多类似的故事，有很多不识字的农民，根本不懂得什么教育，但当自己孩子考上了大学的时候，登三轮车、检塑料瓶、吃烂白菜供养大学。
最好的教育，不外于此。 教育或者管理，有时候太简单了。简单到你什么都不需要做，只需要让他们自己尽全力去完成一件事。但是有时候太困难了，困难到你必须（ 尽量少）识别出什么时候该出手，尽全力去帮助它。
不幸的是，大多人，太简单不甘于于寂寞，太痛苦的奉献又不敢承受。
DDD
WHY：为什么需要领域模型 领域模型为解决软件的复杂性而生。
人月神话说：软件的复杂性是软件的本质属性之一。
2004年,Eric Evans写就了《领域驱动设计——软件核心复杂性应对之道》（注意书的副标题）
如果你的软件项目有如上问题，那么是时候考虑DDD了，如果没，不要XJB上DDD。（不要瞎引入复杂性，DDD本身比较耗费脑子）。比如写个代码几年不增加需求，别想太多，撸完就算了。
WHAT：如何做？ 怎么解决复杂性问题？9年制义务数学教育告诉我们，不外两种方法：抽象、分治。
抽象：任何一个业务问题，都可以最终简化为一个或者几个基本原理的问题，这些个基本原理问题，就叫做领域问题。
领域问题是某一类问题的高度抽象。它关注的不是某一笔业务，某一个请求，而是所有类似的，具有同类属性的问题，是一个通用的解决方案。
是一个化繁为简的东西。他是真正简化问题的关键。
领域模型能不能简化问题，关键要看这个。
分治：任何一个业务问题，常常是几个领域的综合。如何去确定，区分到底划分为几个领域模型
（依据是什么呢？其实就是内聚和耦合）
在DDD中，形式上，它讲了一大堆层次模型和六边形模型。这些既不重要，也很重要。
不重要的是，他对于你对具体某个业务领域的抽象和分治毫无作用——这只能依赖于你对业务的理解，依赖你的思考方式和抽象——而这，才是DDD的核心。
重要的是，他从代码形式上抽象了几乎所有代码都必定符合的结构——并且研究了代码如何写才更科学——这对写出漂亮的代码很有帮助
举例LInux管道命令为啥如何灵活，如此强大，这是因为
1，抽象所有东西都是文件
2，所有文件都有输入 ，输出，错误输出，如果没定义，走标准输出入
3，管道是一个定义两个文件的之间的文件，作用是前者的的stdout作为后者的stdin
Netty也很强大，但是也很简单核心概念只有三个EventLoop，Channel,Handler
EventLoop定义了如何去调度线程和Io的方法
Channel定义了各种IO类型，可以实现各种情况下Nio，Upd……等Io协议
Handler是业务（线程）的抽象
可以看到，这里强大的根源和精髓的地方其实是LINUX的概念抽象，和概念之间的机制作用。而和用什么语言，用什么框架，3层模型还是六边形模型，代码写的好不好……等因素毫无关系
抽象是DDD的精髓。六边形，层次模型对代码实现比较有意义
用好DDD的关键是
1，深刻了解业务领域知识，了解业务概念，
2，根据业务模型，合理抽象建模（高度简化问题）
3，（操作实现层面）尽量少的引入复杂性（尽量少引入技术框架，用最简单的方式去解决问题）不要在讨论业务的时候就考虑技术实现
所以这里强调一下我们的架构原则
1，业务和技术分离
2，技术和部署分离
3，变与不变分离
复杂性本质
1，为什么说软件的本质是概念和概念之间的关系 因为无论怎么简化，去掉实现差异，框架差异，语言差异，软件的本质最终不能再简化为一个问题域——即一些概念和他们的关系。
或者用另外一个表达式 程序 = 数据 + 逻辑 这个表达式在OO时代进化为：程序 = 对象+对象+对象…… && 对象 = 数据+逻辑 对象模型，很明显更能贴切的去表达概念和关系
2，为什么软件工程的本质是管理复杂性
软件工程是软件的形成过程，除了概念本身，涉及到了工具和人。主要是how，如何形成软件，如果使用技术，人又如何。软件工程的本质是复杂性 对软件工程而言，不可避免的东西是(需求）变化；而软件是的本质是概念和概念之间的关系，这个本质类似什么，类似于中子会影响原子裂变。 所以，这导致了软件的复杂性爆炸。
这也是为什么《人月神话》作者在论述到这个本质和变化的时候说：“如果这是事实，那么终究没有银弹”。
这里且不去论证他这个论断是否正确，但是的确反应了人月神话描述的软件工程面临的诸多难题
1，软件很容易陷入泥沼
2，陷入泥沼很难纠正调控
……
复杂性有三类
1，问题域本身的复杂性
2，采用的技术方案引入的额外复杂性
3，涉及到的人和组织再引入的额外复杂性
理解了这三个复杂性，就理解了为什么软件容易陷入泥沼，因为不能控制变化发生，就不能控制复杂性爆炸； 需求变化是变化，会引发复杂性爆炸 不能尽然计划可以视为一种计划外的变化
技术变化也是变化
组织变化也是变化
这些都会极大引发复杂度变化
软件工程 必须要解决这三个复杂性 成功的有效率的软件工程，需要引入技术熵和组织熵的概念 熵是能量中不能做功的能量 技术熵和组织熵是技术和组织在解决问题中，额外多花费的能量。 很明显，这两者越少越好。
所以，软件工程必须管理复杂性
1，技术熵越少越好
2，组织熵越少越好
3，良好的领域抽象，是真正的关键
4，如何去控制变化，隔离变化，适应变化
传统的软件工程理论是无法解决这个问题的，我们先来看一下传统的软件工程理论是个什么东西
1，将软件按照时间阶段分为几个步骤（需求，设计，开发，测试，维护），这个划分是确保了完备性的
2，将每个步骤分配给一个或者几个角色，确保了这个划分是可执行，可管理，可组织的
3，微观上控制每一个步骤和节点的时间，风险，降低整体复杂性；提升可管理性
4，引入UML和工作协作方法（敏捷，瀑布……）来实现各个步骤之间的衔接和角色之间的衔接，确保整个理论是内洽的
这个理论，是一个管理性的理论，但没有解决任何软件工程的本质问题，只是确保了可管理性。 严格按照这个理论做的话，大概率可以提升软件的成功率的，但是效率和灵活性就难以保证了——这也是微软这种传统类型的软件公司和FG这种类型的软件公司的差异