3月每周小结

第九周小结

新年第一周的状态改观了好多，不再像年前那样焦虑到无法入眠。人，对于未知的事物、或者自己无能为力的事情，容易产生焦虑感。这种焦虑还会导致紧张、疲惫和一种无力感。好多时候，自己回头看，其实没有想象中那样的悲观；想想，倒是自己想得太多了。要有一个平常心，然后才能够平静地去想事和做事。我觉得有两种能力是一个人的核心竞争力，第一是解决问题的能力，另一个是持续学习前进的能力。所以，在接下来的工作和生活中，准备把这两个能力作为持续提升的对象。持有一个平常的心，来不断地提高自己。

还想到另一个几乎每个人都存在的问题，懒得思考并去关注身边变化。间接地反映到个体身上，就是喜欢一直地待在舒服区内，那怕恰好地呆在了一锅温水里。当然，这个问题并没有想得那么透彻。实际来看，有时候想得太多，不如先多去行动、实践为好。

这周才基本把线性代码基本看完了一次的，准备开始看看概率论这本书。

第十周小结

发现心不静的时候，是没有办法专门地把一件事情做好、做完的。在当前多个事情穿杂的情况下，要么就是同时地可以处理所有事情，要么就是一个事情一个事情地串行地进行处理。两个方法看着上都得通的，只是选择哪一个来更适合现实，同时自己也要能够Hold住。

听别人讲一个问题的时候，发现了一个规律：如果他讲得很high，很高大尚，你听完之后的收获跟他没有讲一样的收益，那么说明他没有把问题讲明讲透。这个现象说明了，讲事的人他自己就没有弄明白这个事、只是唬骗你。一般来说，除了向领导汇报只需要讲个事情的大概外， 向别人讲事会把事情讲得比较详细、比较透，特别是会有更多地细节说出来。那么，在听完别人说完之后，你提不出问题来，一部分原因是讲的人没有讲到真正的信息，另一部分原因是你没有看出问题里的根节来。

克服你的短处，与发挥你的长处相比，可能是更需要警慎的。短处一般来说是比较致命的，长处也顶多是锦上添花而已。

凡事预则立，不立则废。这句话是很有道理的，古人证明了它，跟前的人也证明了它，自己也恰好证明了它，只是有些人在试着改变，而其他人还是孰视无睹罢了。

第十二周小结

软件开发的质量使用问题单数目来衡量是否合理？从开发的角度来讲，我觉得可以从解决问题端到端的代价来看。首先，问题单数目多少只是从一个方面反映了开发过程的质量，并不一定能够反应软件本身的质量。如果开发对于软件是足够了解的，那么他不一定开发中就清理掉所有问题，但是遇到问题的时候是可以快速解决掉的。其次，问题延迟到得时间越长，其解决的代价是越大的，这是不用怀疑的。这也是为什么软件开发过程中一定要强调质量本身，尽可能少地把问题遗留到后面，尽可以早地发现问题并解决它。那么，究竟怎么一衡量软件本身的质量好坏，是一个再需要深入考虑的事情。

设计文档本身是体现设计本身的。那么，设计文档的书写要详细到什么程度呢？换句话说，设计本身要详细到什么样的程度呢，才算是一个好的设计呢？我觉得，设计要有完整性，指的是要能够说明选择什么样的方案，遇到了什么样的问题和困难，是怎么权衡备选方案的，同时还要结合系统本身的架构来说明具体的实施方案，而不是站在理论的高度泛泛而谈。与此对应的需求文档，更应该关注要解决的问题本身，用户发生问题的使用场景，还有就是解决用户问题时的接口规约。