2012年1月11日

如何阅读一本书——读书笔记

摘要: 今天读玩了《如何阅读一本书》,其实也是粗略的读过了一遍,可能还需要再精读几遍,大致的了解了下书的体系,以及整个书的意图。该书是将阅读当做一种艺术来看待的,然后将其分为四个层次,每个层次也有其对应的方法。四个层次分别是:基本阅读:读懂书的字面意思,能够进行阅读检视阅读:能够大体上了解书的分类,主题思想,中心主旨分析阅读:剖析书,理解书的主要内容,大纲,同时与作者形成一种“互动”主题阅读:带着自己的问题去阅读一些书,然后进行比较,对于一个主题进行归纳总结从这本书学到即使看书的思想,价值观,以及方法,把看书当成一门艺术,本着提高自己的目的来阅读书籍。本书的很大一部分篇幅是讲的分析阅读,讲书分为很多种 阅读全文

posted @ 2012-01-11 22:33 陌路vs追忆 阅读(198) 评论(0) 推荐(0) 编辑

2011年12月29日

如何阅读一本书——读书笔记(开篇)

摘要: 今天在战隼的读书笔记里(http://www.write.org.cn)发现每天一本书的计划(http://www.write.org.cn/plan-a-book-a-day),很是震撼,因为他的坚持力、意志力让我感觉热血沸腾(之前我写blog都是两天打鱼三天晒网),于是决定效仿他也来一个每天一本书的计划。由于之前的阅读量很小,阅读速度也很慢,所以我给自己设立了一个缓冲阶段,在这个阶段急速的将自己的阅读速度和阅读能力提升上去(这个时间暂定为2周),然后在明年里做到,每天一本书。今天就拿《如何阅读一本书》来做开篇,刚好提升自己的阅读能力,以下做一个简短的笔记。暂时阅读了第一篇阅读层次的内容,以 阅读全文

posted @ 2011-12-29 22:23 陌路vs追忆 阅读(230) 评论(1) 推荐(0) 编辑

2010年11月27日

程序设计分析(2)——面向对象与面向过程的分析

摘要: 关于面向过程的一些分析:首先是数据的维护问题,面向过程是过程话的,其数据和行为是分开的,所以你不知道哪个过程修改了这个数据,不知道哪个地方调用了这个数据,你无法对其进行控制,安全性,稳定性,可维护性就大大降低了。而且所有数据都是由系统来维护,这也增加了维护的难度。然后对于面向过程的思想总是将某一个行为看成若干个过程组成,过程与过程之间就有因果关系,都联系在一起,属于紧耦合状态,一旦改变一个过程,则... 阅读全文

posted @ 2010-11-27 19:47 陌路vs追忆 阅读(347) 评论(1) 推荐(0) 编辑

2010年11月22日

程序设计分析(开篇)——混沌初开,顿悟设计

摘要: 一直以来,不断的进行着项目的设计、开发,然而,差的设计,痛苦的维护、编码,让我不断的审视自己的设计是否有问题,在最近的一些思考、理解中,终于有了一些领悟,总结一下过去的设计,以此来作为参考和警示,以免以后再入误区。   一直以来的设计都是很粗浅的,没有做过足够的分析,就开始了编码工作,可以说直接就开展到了代码的层次,没有分析清楚自己要做的是什么就开始了,直接就准备开始实现需求了。这样做的后果就是... 阅读全文

posted @ 2010-11-22 07:41 陌路vs追忆 阅读(282) 评论(0) 推荐(0) 编辑

2010年11月18日

抽象封装

摘要: 今天在总结最近一个项目的时候,突然灵感一现,理解了一些以前困惑的问题,和自己一直以来的设计上的问题,这里来分享下。  抽象与封装,是我们在做设计和写程序的时候经常用到的,然而很多时候抽象封装的不对则会造成很乱、很遭的设计。在我最近的项目里就很有体会。场景是这样的,有一个新闻表单,用户填写然后提交,程序要做的就是检查数据(包括是否合法,是否为空等),如果没有错误就向数据库中插入一条数据,如果验证不通... 阅读全文

posted @ 2010-11-18 07:35 陌路vs追忆 阅读(1072) 评论(0) 推荐(1) 编辑

2010年11月16日

设计思考

摘要: 最近在师父的帮助下完成了一个小的工具设计,这个小的设计花了我蛮长的时间,一直在更改,变化,直到现在算是设计完成,这里做下总结思考。首先,自己想做的是一个基于mysql的单表数据操作类,有着最基本的单表增删改查,还有单表特殊操作,比如审核,获取默认情况下的单表数据等(这些是基于基本操作的,为更方便的管理,因为将单表的所有操作在一个类中控制起来,就能够很好的管理),然后它能移植到各种数据库框架下,比如... 阅读全文

posted @ 2010-11-16 07:08 陌路vs追忆 阅读(274) 评论(0) 推荐(0) 编辑

2010年11月14日

引导

摘要: 今天跑去接受师父的引导,经过一个下午交流沟通,收获不小,总结思考,归纳如下:1、首先是对需求的分析不够透彻,需求不明,然后就开始直接进行方案的实施了,在这种情况下,一旦需求发生变化,则会牵一发动全身,而且往往会自己将自己的方案推倒从来,因为需求并不明晰。所以以后在做需求分析的时候,一定要明确自己要什么,要得到什么样的结果,分析清楚以后再去做方案的实施。2、环境不明,条件不明,没有认真思考,需求是建... 阅读全文

posted @ 2010-11-14 22:45 陌路vs追忆 阅读(197) 评论(1) 推荐(0) 编辑

2010年11月3日

设计模式思考:模式实践

摘要: 学习了这么长时间的模式,一直想实践一下,但是由于模式的理解不够,而且不能用形式化的模式,一直以来也没有好的实践机会。今天在做一个小的模块的时候(重构以前的模块),写出了一个自己觉得很不错的模块,感觉比以前来说有长足的进步,这里就来和大家分享下。  环境描述:由于在公司的做项目时,大部分是写小的模块,系统有一个框架,一般都是在系统的基础上写几个模块,就算完成一个小的项目了。但是由于大部分项目都有很多... 阅读全文

posted @ 2010-11-03 19:58 陌路vs追忆 阅读(287) 评论(0) 推荐(0) 编辑

2010年10月21日

设计模式思考:依赖

摘要: 钻研了几个设计模式后,发现对一个名词的意义逐渐清晰起来,这个名词就是:依赖。依赖,我的理解是,当为实现某功能的时候,你就已经开始依赖这些代码了。就比如下面的简单几句代码:[代码]简单几句代码,也存在着几处依赖,第一行的赋值语句,它是将一个固定的字符串赋给了变量$str;第二行将变量$str全部变为小写,依赖strtolower函数,第三行是打印,依赖于echo。现在我们来逐一进行分析:首先,第一行... 阅读全文

posted @ 2010-10-21 00:15 陌路vs追忆 阅读(349) 评论(0) 推荐(0) 编辑

2010年10月18日

设计模式心得:七——外观模式

摘要: 外观模式:为子系统中的一组接口提供一个一致的界面,此模式定义了一个高层接口,这个接口可以使得子系统更加容易使用。从定义中可以知道,外观模式是为了封装一个复杂的子系统的操作,以提供用户简单易懂的接口。这样做除了能够方便的使用外观模式封装的接口外,还能到达解耦的目的,从复杂的系统解耦只与高层接口交互。在生活中有很多外观模式的例子,例如:我们的电脑,它的启动就是一个外观模式很好的例子,一个启动按钮就是一... 阅读全文

posted @ 2010-10-18 22:30 陌路vs追忆 阅读(285) 评论(0) 推荐(0) 编辑

导航