这周从周三开始白天就埋在图书馆了，大概是因为图书馆的妹子太好看，这几天效率还不错。
上周就开始想的以arthas为入口做点开源贡献的事，终于落地且提交pr了。过程中碰到了一个很棘手且诡异的指令单起arthas-core找不到系统类的问题，也借助于思维导图做过程分析解决了，比较有成就感。开源贡献的过程很简单，确认准备做什么，基于目标仓库进行fork，在派生仓库的基础上做分支研发，研发自测完毕后，提交代码，从github上进行pull pr，提交前自己先审一遍，然后等待代码管理员处理即可。确认要做什么可以多看看项目的issue，而且issue本身里面也有很多值得关注的讨论点或user case。此次解决问题的方法很有扩大化的必要。大体过程是，基于思维导图的模式，罗列问题表现，然后从整体到细节，逐级梳理问题的解决办法，针对具体的解决办法，分析可能原因，对于每种可能的原因不要依赖推断，而是在推断的基础上考虑如果能验证和排除推断。核心要点是完备性以及不要盲目相信推断，要去做验证。
这几天也继续翻看了一下《马斯洛论管理》，一个比较有意思的感受是，感觉马大佬经常思考的一个问题是，在什么情况下，德鲁克的管理思想会失效。马的一个观点是，管理要根据成员的构成和状态分成多个阶段，德老爷子的理论适用于高级阶段，也就是成员都是优秀向上的时候。这里我没有具体实践过，仅从思考的角度是认可这种说法的。马大爷的想法大概是，德老爷子的思想是理想化的思想，不适合现实，他所想的基于心理、需求等理论和管理结合的思想才是现实管理的正解。个人的观点是，德老爷子的想法虽然是理想化，但是是做了高层抽象，面向具体场景，比较具备可实操性。马大爷的想法虽好，但是现实里几乎是无法准确收集到心理、需求的确切信息，针对于具体情况具体操作的想法虽好，但是就理论层面而言，这种说法没有太强的实操性。个人感觉仅从思维的角度而言，比较好的方式是，轮廓和引导思想按德老爷子的来，具体事务处理和策略制定分析时兼顾马大爷的理论。话说到这里，我也看过一些德老爷子的书和文章了，德老爷子的管理思想到底是个啥呢？ 囧....
我之前一直觉得马大爷的需求内容有理，但是每个人的需求层级并非完全是按马大爷的金字塔结构铺展的。今天翻看《马斯洛论管理》时，还想到了另外一个点是，基于需求模型的话，那么“你需要什么，渴望什么，你就会被什么所满足”，对于此还有一个推想是，我们可以基于需求、渴望的点，定位金字塔中的需求层级，然后从同层级的其他要素里，分析看是否具备有可替代可选择或可满足的。如果需求层级的分析是有效的，那么这种做法应该也能带来比较好的满足效果。也算是一种挖掘潜在需求的方法。
今天还看到了一个可借鉴的思路。是从关注arthas来的。扫arthas的issue时，有看到工行提供的他们基于arthas做的故障诊断的项目，代码没有开源，但从放开的信息看感觉是非常强大。我这里说的强大主要是觉得它解决了我之前一直想的arthas放生产的安全和管理的问题。方案其实很简单，就是再追加一道web的壳，让用户通过web的壳来操作arthas，由web壳负责arthas本身连接以及鉴权等相关的管理。这里就是我所看到的可借鉴的思路，追加一道web壳来解决安全、授权、管理的痛点。这种思路感觉可以适用到很多领域（当然这个思路也是没有新意的思路，我只是因为才看到才抽取出来，而且这个思路和落地方案是我个人现有技术栈就能承载的）。后面机缘巧合，恰好去哪开源的bistoury，和工行那个是一个路子。这个项目后续可以跟进一下~应该会比较有意思且能学到一点东东。
今天还看了一些UML相关的东东，UML接触和用也很久了，一直觉得这是一个很强大的东东，但是同时又感觉它有点乱。没有强制去学教程，因为感觉这个东东硬套是没什么效果的。今天又翻开了一遍，不知道思想层级有没有叠高一点点，今天梳理的信息如下
UML分1.0和2.0的版本，从2.0的维度看，它本身提供了一个4层元模型，可以作为某一个领域模型定义的范本，分别是M3、M2、M1、M0（这个范本是不是很囧~），其中M3定义基础要素，M2定义建模结构和语法，M1定义具体系统模型，M0定义模型运行时的状态。这个4层模型有啥用呢？我经常会讲的一句话是，“从XX维度的角度讲”，XX维度，就可以认为是一个领域，那么基于这种4层元模型，我们是可以定义一个具体领域的建模语法的。这个感觉会挺有意思的。然后UML2.0的具体语法落地是怎么样的呢？可以按静态图、动态图的维度来，静态图主要为用例图、活动图然后其他，其他一般是指类、对象、包图这些；动态图一般是时序图（顺序图）、交互图然后其他，其他一般是各种我觉得没啥子用的乱七八糟图。顾名思义，静态图关注的就是静态要素，比如用例图关注于有什么功能，活动图从名字看是个动的，但是它侧重关注于流程的构成，至于类、对象、包这些其他图，个人觉得是一个比较狭隘的面向对象领域的具体图落地。动态图关注于交互，时序图（顺序图）关注于用例过程的交互流程，交互图则关注于用例间的交互流程。我是这么理解的~，不能保障完全准确哈~~~~ 讲到这里可以发现一个点，UML的各种图都是强调关注某一层级或维度的实现，因为只关注于一个层级，所以简单，也因为只能关注于一个层级，所以它存在局限性和无法承载过多内容。所以看UML图和画UML图时，都要有一个边界意识，意识到它的边界在哪。