我要给团队什么样的输出 - 编程一生
我要给团队什么样的输出
我希望大家是什么样子的
之前在乐视的时候我问过我们飞哥：你希望大家是什么样子的。飞哥人特别好，因为在饭桌上，他把所有的人都说了一遍，说需要你，也需要他。需要各种各样的人。我在乐视过得蛮滋润，我可以按照自己希望的样子进行发展。这是建立在我这么多年磕磕碰碰，有了很多思考和自己想做的事情的基础上。但是我也很想知道，我怎样能领导让更满意。很多刚毕业的同学，更想得到很多的引导。所以我现在就在思考这个问题。
我希望大家有很多想法，大家一起拿出来探讨。我希望大家可以遇到事情或者有什么思路可以自己主动找我商量，我觉得这是对我的尊重和认可。我希望我有什么问题或者团队有什么问题，大家看到了或者想到了能告诉我，大家一起想办法。乐于分享，有团队精神。我希望这些是团队的共性。这和每个人的性格没有关系，更多的是一种团队合作沟通的技巧。
性格方面，我觉得遵从天性就好。如果非说要有点共性，那么我希望是感恩之心。可能其他人有自己的生活方式，但就我自己的经验而言，这在整个人生中，工作上、生活上都是成功的关键。为什么我家娃都马上要上小学了，我家男神来我们公司附近，我可以团队聚餐不去，一定要和男神一起吃饭。关系好是因为两个都是知道感恩的人，感恩上苍，感恩彼此，愿意为对方多付出一点让对方更幸福。结果，自己收获了更多的幸福。我有很多的朋友，干什么事情都不愁没人帮忙，那是因为自己这样的气质，周围聚集的也都是一些仗义的人。仗义的基础就是感恩之心。世界上最遥远的距离是每次我需要你，都不知道你在哪里。爱情不一定会败给物质，却一定会败给我需要你的时候你都不在。工作也是一样的，背道而驰路会越走越窄。
之前在乐视有次开会，我家微微一笑很倾城的男神老大说刚刚面试了一个女孩子特别满意。满意到什么程度呢，跟晓静似的。但是老大看了我一眼，看我听了不是特别高兴，就继续说这个女孩子什么学校的，有多么优秀。我也就是听听，不太高兴因为我觉得我家男神老大跟王子一样，特别完美的一个人。完美的人其实有很多，但是我从来没有觉得他们是一类人。在我心里，独一无二，不会觉得跟谁很像。我对自己也是一样，我觉得自己是独一无二的，听自己崇拜的人说自己只是一类人，多少有些失落。所以现在我自己带团队了，我有时间会去发掘每个人的个性，相信每个人都是优秀的、独一无二的。
沟通
沟通分为团队内的沟通和团队间沟通。
团队内沟通对于重要的事情，如果不是一句话两句话能说清楚的，就算文字、消息沟通过，最好也要口头沟通一下。因为信息接受者有可能因为事情多忘了或者理解的不对。口头沟通为主，消息主要记录和留证。为什么这么做呢？程序员大多数是听觉敏感型的。心理学按照感官敏感度将一般人分为视觉敏感型和听觉敏感型。视觉敏感型的人对视觉的东西更敏感，精力更集中，记忆也更深刻。更擅长处理图像。听觉敏感型对声音更敏感，更擅长语言文字。而我们从小到大学校学的东西基本是语言文字。能来咱们公司的，都是被读书坑掉的一代，听觉敏感的居多。
团队外，我们是一个team。团队外的人不管找谁询问任何事情，都绝对不能因为不是自己负责的模块而怠慢。自己处理不了，可以带人家去找可以处理的人。我们需要给团队外的人的感觉是：找谁都是一样的，不用有所顾忌。
技术、沟通、态度哪个更重要。这实际上是一个很没有价值的问题，因为这三者其实是一个东西，叫能力。任何一个不好，都是能力问题。我在东软的时候，是很受欢迎的小翻译。真的因为我是一年就过日语一级的天才，所以日语好的不得了吗？怎么可能，人家都是专业学了很多年，日本留学回来的。但是其他的翻译是字面翻译者。我是技术出身的，我理解他们实际上是在说什么，所以更好沟通。其实不懂日语都可以沟通。我在日本出差的时候，我一个同事不会说日语，有个日本的“矢野”不会说中文。他两天天都不用翻译，就用手比划，纸上画，无障碍。技术是什么，比如对咱们来说JAVA是技术，好吧，但是别忘了JAVA最根本是一种语言，是用来表达实现东西的。技术很牛逼，写了一堆漂亮代码，但是做了系统边界外的事情，后患无穷，还不如不写。所以沟通要更关键一些。而有效沟通的最好方式就是态度。
我自身要做的事情
我应该是规划者和决策者，不是执行者。我更不需要是最好的执行者。比较喜欢的美剧是《神盾局特工》和《罪恶黑名单》。不管什么剧，指挥官绝对不是电影里最身手不凡，耍枪耍的最帅的。也不是任何一方面的专家。他是将整个团队凝结到一起，让大家可以成为最酷最帅的执行者的那个人。他的职责是制定靠谱的任务。
从战略和架构上，我需要定义好系统的边界、定义好系统的核心思想。这样，系统就有了方向感，随着时间推移，系统就能形成自己的灵魂。咱们邮件的签名：我们的职责是：打造可靠、高效的交易系统。这就是系统最抽象的核心思想。
我要帮助大家提出问题。比如每个需求的时候，大家都应该问自己5个Why：这件事情有没有超越这个系统的边界？这是根据当前模型和代码中的一组特定关系作出的权宜之计呢，还是反映了底层领域的某种轮廓？我们做这件事情的收益是什么？如果需求比较大，那么每个阶段的里程碑是什么？有没有更好的解决方法？
重构
相信团队里现在很多人有这种疑问。我们现在做重构，做好了，又有变化，怎么办？我的回答是：重构就是需要是一个持续改变的过程，要保持鲜活，要拥抱变化。《极限编程》的核心思想就是要拥抱变化，要迭代。持续变化不可怕，风险是可控的。可怕的是长期不维护，大家对实现细节都淡忘的代码突然要有一个改变。《领域驱动设计》里有一段话：
通过重构得到更深层理解是一个持续不断的过程。人们可能会发现一些隐含的概念，并把它们明确地表示出来。有些设计部分变得更有柔性，或许还采用了声明式的开发风格。开发工作一下子到了突破的边缘，然后开发人员跨越这条界限，得到了一个更深层的模型，接下来又重新开始了稳步的精化过程。
重构设计的原则说：至少要有两个步骤的前瞻性。所以，两个步骤之后还是要变。从模型到代码，都是一个精化过程，不要怕变。
重构模块的划分。这一块确实是经过大家很多的思考得到的，一段时间内是稳定的。比如核心现在划分为正向、逆向、查询、命令。这是怎么划分的呢？正向和逆向是我们的业务。我们的业务再怎么变，抽象出来也逃离不出这个范围。业务执行操作。所有的操作都可以抽象为查询和命令。查询和命令为什么要分开呢？水平切分，避免副作用。这也是分布式服务和微服务的本质。
今天太晚了，未完待续……
跑题时间
女孩子心里想的就是：愿得一心人，白首不相离。男孩子：……
略心塞