阅读一

书中说从Agenda中吸取的经验，开始向自己问一些问题：“如何组织信息？如何对信息组织建模？”数据结构对于我来说，现在都还很陌生而且很麻烦，只看过简单的例子，没感受到它潜在的作用，往往却是很重要的方法。“需要哪些类别和标签？如何相互联系？如何高效的存储数据？今后怎么添加新数据？”现今计算机最为普遍使用的数据库，它的地位听名字就知道。

　　再看数据类型，我常年用都无非就是int和char，全部让它们默认为public，这就是图个简单方便。看来书才知道，变量类型看似小事，但在代码的国度却能引发宗教战争般的冲突，或者说就是没有保密和安全的意识。

　　“软件就像洋葱般层层叠叠，每一层都辛辛苦苦地建立与前一层基础上，危如累卵，指望着底下那层不要移动或变化太多。无论如何，日积月累，一层一层搭建起来。”对于这段话，我感受很深。每次一看到题目，脑海中往往都是一个想法：超级难！肯定做不出来。有时侯做到一半感觉不能成功了就马上放弃，或者找另一种方法，把程序改头换面，变量也全改了，渣渣不留。却没想过我可以把它分成几层，我大概可以做多少，如果底层做的很好我该从哪里调整......方法不是都无缘无故就存在的。

　　每个人的脑中都会记住一些代码，有的程序员会把代码放在文件中，便于管理。例如调用函数、子程序、面向对象编程的“可复用代码段”（对象库、函数库、模块库）......用处很大，随意采用、自由组合，也不用终身调试。

　　以前刚开始编程时，首先关注的都是谁谁谁敲了多少行用了多少时间，越多越厉害，现在意识到以代码行数计算真是不太可靠。软件也一样，应该关注的是特性和“功能点”，因为用户都希望这个软件既好用占的内存也小。还有过程中的缺陷数量，修复的时间（测试越多，发现的bug越多，往往开始能迅速解决大部分，而最后却卡在了几个坚如磐石上，时光飞速也毫无进展）的记录，还要估计完成时间，这都是现在觉得是多此一举的事。但是不这样怎么度量看不到的东西？“如果每个成员都不知道自己的进度，又怎么判断整个团队的进度？”我们必须认识到一点：团队，都不是一个人在战斗。在Chandler0.2即将推出前，开发者们开会检讨。“出了什么问题？下次怎么办？”这就是我们每次做完一项就要做的缺陷记录等一系列总结。

　　“计算机专业人员应当承担起创建良好用户体验的责任。”这里记下古罗马建筑理论家维楚维斯关于良好设计的原则：坚固——良好的结构、没有缺陷；适用——程序应符合其设定目标之所需；愉悦——使用程序的体验应令人愉快。

（文章上传很多遍，一直出现问题：访问被拒绝。所以删了很多东西，读起来可能不通。）