《梦断代码》读书笔记 第1篇

 

第3章:原型与Python

第4章:乐高王国

第5章:管束奇客和狗

第6章:搞掂设计方案

  

 

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

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

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

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

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

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

(文章上传很多遍,一直出现问题:访问被拒绝。所以删了很多东西,读起来可能不通。)