接口、系统、管理与熵
最近无论是写书还是设计系统都攒了不少思考，有(fei)些(chang)凌乱，但是还是想写一写。
写在前面回国之后，工作强度还是比较大的。好在经过一段时间的适应和磨合，总算慢慢找到了节奏。思考和总结的好处有很多，对我来说最重要的有两个方面：一是能够从实践中萃取最多的养分让自己快速成长；二是针对暴露出的问题进行定向改进，能极大提高工作效率。
原则上我是希望在博客中尽量保持某种意义上的中立的，但是在这里，我依然想感谢公司给予我极高的自由度，职位或者项目并没有成为桎梏，我因此得以把触角伸向各个领域。接触各个项目的好处不言而喻，除培养大局观外，学会以不同的角色站在不同部门不同角度去思考问题，也是极好的。更有意思的是，之前看的诸多『闲书』，现在竟以各种各样的方式发挥着作用，果真『功不唐捐』。
今天早上正好跟同学聊起留美还是回国，抛开各种外在因素不说，回国最吸引我的就一点——一个验证自己可能性的机会。从小就听老爸说要『在广阔天地里大有作为』，真的离开学校之后，发现很多同学早已把『星辰大海』抛诸脑后。也许每个理想主义者终究要落地，但是我想在这之前去看看天有多高，地有多厚。
如果有缘能看到，这也是我最想对还在学校的同学们说的，每一次选择在当时看起来不过如此，但是回过头来看，很多巨变在那一刻就已经开始了。不要想着『以后我要怎样怎样』，如果真的想，就『现在』去做。
回到主题，既然名义上我还是工程师，就从工程师的工作来说起吧。
接口最近在做的主要工作之一是设计接口，作为应用程序对外的『门面』，接口的设计很多时候比具体实现要重要得多，这也是为什么我花了大量时间和精力去尝试和构思。虽然大家都知道要 RESTful 要正交，但有的时候这种灵活性带来的副作用是复杂。耦合虽说不容易修改，但一旦在精心设计之后形成一股合力，本身紧密的作用力带来的好处可能要比得到一定程度的灵活性要大得多。这些内容其实任何一本经典的计算机书籍都会涉及，但是具体的度，和细节中的推敲，就需要一定的工程实践以及实际检验才能给出答案了。
设计系统是如此，写书亦是如此，甚至更要精细打磨，因为程序能够修改，书印出来了，白纸黑字就没法改了。接口之于应用，就好比目录之于书籍，新书目录的确定真真切切是非常痛苦的事情，在一个多月的时间内至少变动了几十次，终于达到了令自己满意的状态。这些改动其实是随着准备工作的进行而不断发生的，在参阅了大量经典书籍和课程后，在不断的切磋中，才终于找到了自己的方向。但其实这才是万里长征的第一步，后面还有很多艰巨的工作在等着我。虽然是初出茅庐，但依然得假扮老司机，相信假着假着，就成真了。
系统系统是复杂的，哪怕是一个小的社区，其实往深处想，也有很多门道。如何去梳理整体的逻辑？三点：大处着眼，小处着手、目标清晰。从这里出发，可以给自己提出很多问题，比如：
社区的历史包袱是什么？能不能找到一种方式，尽可能无痛甩开包袱？
社区的目标群体的层次是什么？现在主要需要抓住哪一类用户，如何去发现并抓住这些用户？
社区的推荐系统以及能量流动是怎样的规则，用户能从中获得什么，机制如何去影响用户？
社区的定位是什么，长中短期目标是什么？
能否参考不同领域的做法，比方说游戏中的常见玩法（工会、赛季、攻擂守擂等等）
如果这些问题都想清楚了，恐怕社区下一步的目标就足够清晰了。而转念一想，写书同样要考虑清楚类似的问题：读者群体是什么、内容编排怎么做、能给读者提供什么、在整个阅读过程中的长中短期目标是什么等等。
管理先提一句，这里的管理是从自我管理出发，慢慢延伸到更广义的管理的。自我管理的核心是效率，也就是说管理的终极目的是用更少的资源做成更多的事情。那么，对于我来说，自我管理就包含了一个巨大的矛盾：我需要以不同的角色参与到不同的项目中，但与此同时我们都知道『任务单一时效率最高』。
就像软件工程中没有银弹一样，这个矛盾同样没有完美的解法，只能在现有的框架中找寻最合理的解决方案。比方说我现在需要扮演的角色除了开发人员，还有产品经理、项目管理、沟通协调和部门对接，要处理的任务必然是持续且无序的。如果来一个做一个，频繁切换上下文，效率就很低。
目前的做法就是尽量把不同角色任务凑到一起，一次解决一系列问题，尽量减少切换次数，具体编排的依据就是那些不能变动的会议了，这样一口气解决，无论是状态还是具体的准备工作都能达到较好的程度。不过有的时候还是不可避免会『撞车』，今天以三个角色开完三个会之后我真的感觉自己已经是一个废人了，缓了好一阵才把各种事情梳理清晰，加入到之后的待办事项中。
解决了任务切换过多的问题，接下来就是时间控制和优先级设置的问题了，这个就我目前的经验来看，按照自己预估的完成时间乘以二或者三大概就是实际完成的时间，这样既考虑了难以预计的突发事件（比方说同事请假出去玩半个月），也照顾了需求临时变动所导致的时间变化。
个人尚且如此，如果是一个团队，则需要面对更复杂的多样性，难度是指数级增加的，关于这个问题，我自己也在慢慢摸索，这里就不妄下结论了。
熵熵是一个足够伟大的定义。考虑到热力学在一定程度上的普适性，很多风马牛不相及的事情背后，都能看到熵的影子。简单来说，熵越大，有效能量就越小，系统也就越无序。但热力学第二定律告诉我们，熵的增加从总体来看是不可逆的。就像人固有一死一样，我们的目标就是重于泰山，而不是轻于鸿毛。
就拿写代码来说，如果随着业务需求不断增补，整个工程的熵就会快速增加，直到有一天再也无法维护，所以我的做法是一边写一边重构，尽量让熵增加的量最少。而好的架构设计使得一开始的基础熵值很小，并且架构本身也抑制了熵的快速增长；而坏的架构则是『助纣为虐』，最后变成谁都不愿意接的烂摊子。
项目管理和人员管理同样也是这个道理，不过有意思的是，团队并不是热力学中的『隔离系统』，是有机会发展成『自组织系统』的。所谓『自组织系统』，要点在于内部的有序结构，以及形成这种有序结构的推动力。自组织的程度越高，创新的能力就越强。与传统的他组织系统（需要依靠外部指令维持）相比，自组织系统能够各尽其责而又协调地自动地形成有序结构，是管理者梦寐以求的。
从维基中的介绍中我们能从不同的角度感受到自组织系统的魅力：
从系统论的观点来说，”自组织”是指一个系统在内在机制的驱动下，自行从简单向复杂、从粗糙向细致方向发展，不断地提高自身的复杂度和精细度的过程
从热力学的观点来说，”自组织”是指一个系统通过与外界交换物质、能量和信息，而不断地降低自身的熵含量，提高其有序度的过程
从统计力学的观点来说，”自组织”是指一个系统自发地从最可几状态向几率较低的方向迁移的过程
从进化论的观点来说，”自组织”是指一个系统在”遗传”、”变异”和”优胜劣汰”机制的作用下，其组织结构和运行模式不断地自我完善，从而不断提高其对于环境的适应能力的过程
从结构论-泛进化理论的观点来说，”自组织”是指一个开放系统的结构稳态从低层次系统向高层次系统的构造过程，因系统的物质、能量和信息的量度增加，而形成比如生物系统的分子系统、细胞系统到器官系统乃至生态系统的组织化度增加，基因数量和种类自组织化和基因时空表达调控等导致生物的进化与发育（Evo-Dev）过程
更多的介绍可以自行搜索『自组织』。
对我来说，自组织其实是应对熵增加的法宝，也给前面提到的『自我管理』指出了一个不一样的方向。不过具体还需要一段时间的磨练，只能希望自己早点『悟道』了。不过这个跟禅修一样，勉强不来，还是顺其自然，水到渠成就好。
总结学 SIFT 算子的时候就深深意识到同一个东西，从不同的尺度去观察，就能看到不同的东西。从『看山不是山，看水不是水』到『看山还是山，看水还是水』也是这么个理儿。
不要限定自己，敢于跳出框架思考，在不同的领域和学科间游走，融会贯通后，去创造新世界。