杨绪勇：
《移山之道》：Chapter1 To Chapter12
抱着虔诚的心态准备看移山之道，但开始后不久，我不得不承认，我已经用看小说的心情在阅读了，所以走马观花下来一篇，什么都咩有记住。我觉得是目前还不能理解这么高纬度东西的缘故，其实在做完第一个程序作业后就相当有体会了（见即将推出的“小试牛刀感触良多”）。
Question：
1、 整个TFS架构提供了完善的源代码管理，任务管理和分析服务，但我们知道越是复杂强大的工具，越需要海量的文档支持，才能保持人员间的沟通性和产品的传承性。关于文档，书中说系统相对简单每个任务只需要用一张纸描述，那我们是不是也可以少用点时间在文档书写上？
2、 TFS平台中团队结构中，有市场、开发、测试、管理。感觉是缺了点东西，他们核心算法哪儿来的？当然一可能是项目工程不需要算法，二可能是客户已经给了算法。那么我们的问题是，当我们寻找Academic Search中改进功能，并加以实施的时候，谁来负责算法支持，我们当然也可以自己Research，但是时间上貌似。。。。
3、 对于移山之道的方法论，只有任务和缺陷，本人还是相当赞的，这里的任务和缺陷其实拓展了以前的概念，把整个开发过程描述成了发现问题解决问题再发现问题的方法。当然这是非常实用了规模较小的开发，偶很感兴趣，如果用这种方法在大型一点的项目上会不会有的成效，或者旗鼓相当，或者大败而归？那么大型项目是不是必须有这么严谨的开发流程呢。据我最近在互联网上游荡后的成果显示，大规模团队里对TFS开发方式褒贬不一，是什么造成了褒，什么造成了贬呢？（可能得在查查）
4、 TFS的合作建立在大家对自己和其他人编码能力各种能力充分了解上的，如果项目计划阶段有人过高或过低的估计了任务，可能导致所谓的项目计划基础就是不稳固的。那关于计划的拟定，是偏向于倾听开发人员的时间报表还是偏向交稿时间的限制？（可控情况下，时间挤挤总是有点，不过要小心不能挤出血来）。
5、 刚刚算了下我们每周工时：7*14=98，除掉点其余浮动的时间，一周大概90个小时吧，那老师觉得我们每周提供40小时的工时给ASE够么？我怎么感觉不够呢。
<rapid development> 和<Code Complete> 因为目前没借着，所以没能看
看的另外一本：< Pro.C#.2008.and.the.NET.3.5.Platform.Fourth.Edition> Chapter1 To Chapter12
赞一下这部书，写的很清楚，我是看中文的实体，关键术语对照英文版，偶尔跑下里面的例程。
experience：
1、 看了之后很多东西就忘了，感觉吃亏很大；
2、 但至少有了点概念，对有的功能有了印象，所以写程序的时候在需要的时候能想起来貌似某某有某某功能，可以直接调用。
3、 然后豁然开朗，其实这就是看了书和没看书最简单也最本质的区别，你知道了。你懂的，知道，就是信息，就是。。。。。。。
4、 其实看书，是不是可以尝试这种方法：仔细理解概念性的关键点（如封装，继承，多态，生命周期，接口，委托等），其他例程走马观花，总结功能，独立实验。然后写程序的时候，根据印象，先msdn、再google或者baidu。
5、 我是觉得还灰常有必要再把这本说重新看一下，相信会有不一样的理解。之前看是一无所知，现在看是知一无所，心态不一样了。但有个问题，我不知道是因为称现在就很需要复习以前知识的时候就赶紧看，还是安装之前的任务安排继续看下去？求救命！
（原文发表于CSDN博客：http://blog.csdn.net/codingcrazy/archive/2010/11/08/5994878.aspx）
