什么是短想？就是我对一些问题的突然想法(就是瞎想)。
要总结， Date Note 很重要:
一直不知道怎么写总结。笔者感觉总结这东西，是积累来的。可以将每天学到的小知识点记录着，规定一个时间点，整理这些每日的知识点。bug 让我兴奋:
这就像打怪升级一样，其中乐趣无穷啊。每修一个 bug，经验随之就变多，当经验爆棚的时候，你就要升级啦。所以出现 bug 不要沮丧，应该兴奋。有测试才能更好的重构:
- 让代码科幻起来:
能不能把代码写的科幻一些。面向对象编程、函数式编程等，感觉是站在人类现有的思维模式和处理事件的方法上构建出来的模型，能不能打破这种局限，让编程模式更加科幻一点。就像科幻电影一样，用一些逆于人类正常思维的模式，来构建出一个新的模型。比如，可不可以让类和对象具有超能力。
多读书，多积攒知识，改变公交车现象:
最近今天坐公交，发现一个现象，很多人都喜欢挤在公交前的口上，中部和后部都有很多的空地方。一开始我想不明白，大家为什么都愿意挤在前面，后面那么空旷，挤在前面，让刚上车的人误以为后面已经没有了空间。也许这是人的一种惰性吧，当一个地方可以满足现在的状态的时候，就不愿意在改变这种状态。而这些人的状态挡住和误导了后面进来人的视线(当然是因为笔者个子比较矮的原因)，如果你足够高，充满了不满现状的请求，有着足够好奇的探索精神，你当然就不会被他们误导啦。
其实这也和 coding 一样，总有一些人是安于现状的，不愿意去尝试新的东西，不愿意去学习新的知识，也许是因为他们觉得的这种状态是最好吧。当你不够强大，知识不够丰富的时候，你也许就会看不到前面原来还有另一片空旷领域等着你去探索，所有要多读书，多积攒知识，这样我们才能站的更高，看的更远。
从整体到局部:
- 读代码时，需要做到从整体到局部。开始先关注单个方法(函数)内做了什么事，然后在深入到该方法的内，了解方法内的具体每行代码干了什么事。如果方法内的某一行代码，调用了其它的方法，同样通过采取从整体到局部的步骤去分析该方法。
- 实现故事卡时，需要做到先把整体的流程跑通，然后在去调局部的细节。当整体的流程跑通后，大概就可以知道该实现方式是可行的，在确定实现方式可行的后，才去调细节，这样就可以保证调细节的工作不是白费的。
站会作用:
- 站会要说，我昨天做了什么、我遇到了什么问题、我今天要做什么。这样就把自己的工作透明化了，一个团队内的人可以知道其他人的进度。同时也细化了自己今天的任务，如果今天没有完成今天要完成的任务，就要思考问题出在哪里，哪里的工作量评估出了问题，做到时时反馈。
- 只有当你细化你的计划是才能更有效率的完成任务。比如，有的人给自己定了个读书计划，一个月读完一本书。这样有可能到最后你真正读书的时间就持续在最后的一个星期。我们可以细化这个读书计划，可以规定一天读10页，或者一天看两小时。这样才能保证我们在计划内完成我们的计划。
以结果为导向去思考一个问题:
- 最终要什么，站在结果的时刻去考虑一个问题，通过结果去反推过程中单个时间点的事情。一切事情都是可以通过凭证来进行追溯的。
一个抽象的概念都需要一个具体的例子:
- 每当我们在讲一个抽象概念时都需要一个具体的例子，用于引导和确定上下文。 - 讲解领域概念也是一样，讲解一个具体例子，可以打破边界，让听众可以更好的理解概念。怎样算是具体的例子呢，可以理解为同一上下文（环境）下，大家都能理解的例子。沟通过程中
CONFIRM重要性:- 沟通时，个人觉得`CONFIRM`很重要，在`CONFIRM`的过程，可以确保沟通之间大家处于一个上下文，因为在不同的上下文，对于同一件的事情的理解很不同相同。 - 沟通时，有时候，对方回答的观点有可能不是你想要的答案，请不要直接说不对，因为有的时候对方回答的是对，但是直接角度不一样而已，个人觉得可以先可以`CONFIRM` 一下，如果对方的答案在另一个角度是对哦，但是，不是你想要的答案，那么可以承认对方观点是对，然后接着在表示自己想要的问题。说出他的答案和自己想要问的问题不一致。这样可以让对方重新整理上下文，在回答。如果直接说不对，那么对方可能陷入之前答案的上下文中，纠结错在哪了。